Detailed Action
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted in on 10/09/2024 the
information disclosure statement is being considered by the examiner.
Claim Objections
Regarding claims 4 and 14 are objected to because of the following informalities: “if” condition Examiner recommends to change the “if” condition with “when” because if the conditional limitation step is not reached, then the remaining limitation steps do not have to followed and will render the remain limitations not valid, therefore, it will not be required to show anticipation or obviousness for all paths of the conditional limitation.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 11 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Yamada et al. (US-20150095628-A1 hereafter Yamada).
Regarding claim 1 Yamada teaches a computer-implemented method comprising (see Yamada par.0099: “a computer-implemented method for detecting a return-oriented programming attack includes translating, by a processor component, a portion of a routine comprising a branch instruction based on an address at which the routine is stored in a storage of a computing device”.):
responsive to loading code of an executing application into memory (see Yamada par.0021: “the processor component 350 translates portions of one or both of the main routine 570 and the library 370 into translated portions of one or both that are stored in the translation cache 367 for execution. It is during translation that addresses of variables and targets of branch instructions are generally derived.”),
identifying one or more call instructions in the code (see Yamada par.0022: “For at least some indirect branch instructions that incorporate an identifier of their intended targets, the translation routine 340 attempts to determine their target addresses by using those identifiers to refer to the entry point table 337 to retrieve target addresses therefrom that are known to be valid during translation from one of one or more tables of valid target addresses.”, par.0015: “the target addresses of one or more other types of indirect branch instruction may also be similarly altered in a ROP attack, including indirect "jump" instructions and "call" instructions.”); and
based on the identified one or more call instructions, creating a list of one or more legitimate return instruction destinations (See Yamada par.0025: “the translation routine 340 may retrieve target addresses known to be valid from the entry point table 337 and/or the whitelist data 130 prior to translation or execution of one or more routines (e.g., the main routine 570) to pre-load the look-up table 334a with at least some valid target addresses.”), thereby identifying legitimate code paths of the application. (See Yamada par.0011: “to detect a return-oriented programming (ROP) attack by verifying target addresses of particular branch instructions
during execution.”).
Regarding claim 11 is a system claim that recites similar limitations as the computer-implemented method claim 1 and is rejected based on the same rational as claim 1. a processor (see Yamada par. 0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units, chipsets,”); and
a memory with computer code instructions stored thereon, the processor and the memory, with the computer code instructions, being configured to cause the system to: (see Yamada par. 0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units,.. used in this application, the terms "system" and "component" are intended to refer to an entity of a computing device in which digital processing is carried out, that entity being hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by this depicted exemplary processing architecture. For example, a component can be, but is not limited to being, a process running on a processor
component, the processor component itself, a storage device (e.g., a hard disk drive, multiple storage drives in an array, etc.) that may employ an optical and/or magnetic storage medium, an software object, an executable sequence of instructions, a thread of execution, a program, and/or an entire computing device ( e.g., an entire computer).”).
Regarding claim 20 is a computer program product claim that recites similar limitations as the computer-implemented method claim 1 and is rejected based on the same rational as claim 1. one or more non-transitory computer readable storage devices and program instructions stored on at least one of the one or more storage devices, the program instructions, when loaded and executed by a processor, cause an apparatus associated with the processor to: (See Yamada par.0030-0031: “In various embodiments, the processor component 350 may include any of a wide variety of commercially available processors. Further, one or more of these processor components may include multiple processors, a multi-threaded processor, a multi-core processor (whether the multiple cores coexist on the same or separate dies), and/or a multi-processor architecture… the storage 360 may be based on any of a wide variety of information storage technologies, possibly including volatile technologies requiring the uninterrupted provision of electric power, and possibly including technologies entailing the use of machine-readable storage media that may or may not be removable.”, par. 0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units,.. used in this application, the terms "system" and "component" are intended to refer to an entity of a computing device in which digital processing is carried out, that entity being hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by this depicted exemplary processing architecture. For example, a component can be, but is not limited to being, a process running on a processor component, the processor component itself, a storage device (e.g., a hard disk drive, multiple storage drives in an array, etc.) that may employ an optical and/or magnetic storage medium, an software object, an executable sequence of instructions, a thread of execution, a program, and/or an entire computing device ( e.g., an entire computer).” furthermore par.0070 and 0071).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 2 - 9 and 12 - 19 are rejected under 35 U.S.C. 103 as being unpatentable over Yamada et al. (US-20150095628-A1 hereafter Yamada), in further view of He et al. (BBB-CFI: Lightweight CFI Approach Against Code-Reuse Attacks Using Basic Block Information hereafter He).
Regarding claim 2 Yamada teaches the method of Claim 1 Yamada appear to be silence however He teaches further comprising: prior to the identifying, causing execution of the application to pause. (see He page 10 - 11: “During program execution, the processor buffers branch information about indirect jump, indirect call, direct call, and return instructions into registers referred to as LBR+. Our checker accepts branch trace entries from LBR+ and monitors BBB-CFI in parallel with the processor execution. When the CFI checker receives a branch trace entry, it first dispatches the entry to the corresponding checking modules. Forward-edge branches including indirect jumps and indirect calls are examined in the BBB checking module It verifies whether any runtime branch redirects program control to legit BBBs instead of jumping into a basic block. However, the shadow stack module maintains a call stack. All call and return information is dispatched into this module. Note indirect calls are distributed to both modules. In view of the delay between processor execution and CFI checking, the protected program is paused at system call until all pending entries in the LBR+ are checked.”). Examiner construe that prior the identifying the program is paused until all the call instructions are checked.
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Yamada teaching “Various embodiments are generally directed to techniques to detect a return-oriented programming (ROP) attack by verifying target addresses of particular branch instructions during execution. More specifically, identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed. However, if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid, and possibly an indication of a ROP attack.”, (see Yamada par.0011) with He teaching “In view of the delay between processor execution and CFI checking, the protected program is paused at system call until all pending entries in the LBR+ are checked. This prevents the compromised program from effectual infringement of the system. This is a common practice in many CFI implementations.”, (see He pages 11).
Regarding claim 12 is a system claim that recites similar limitations as the computer-implemented method claim 2 and is rejected based on the same rational as claim 2. wherein the processor and the memory, with the computer code instructions, are further configured to cause the system to: (see Yamada par.0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units,.. used in this application, the terms "system" and "component" are intended to refer to an entity of a computing device in which digital processing is carried out, that entity being hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by this depicted exemplary processing architecture. For example, a component can be, but is not limited to being, a process running on a processor component, the processor component itself, a storage device (e.g., a hard disk drive, multiple storage drives in an array, etc.) that may employ an optical and/or magnetic storage medium, an software object, an executable sequence of instructions, a thread of execution, a program, and/or an entire computing device ( e.g., an entire computer).”).
Regarding claim 3 Yamada in view of He disclose the method of Claim 2 Yamada further discloses further comprising, after creating the list of one or more legitimate return instruction destinations:
causing execution of the application to resume (see Yamada par.0026: “Upon determining that there is a match, the translation routine 340 permits that indirect branch instruction to be executed.”); and
controlling the execution of the application based on the created list of one or more legitimate return instruction destinations. (See Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed. However, if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid”, par.0026: “the translation routine 340 replaces an indirect branch instruction in those portions with a stub instruction that causes the flow of execution by the processor component 350 to be directed back to the translation routine 340. Such a stub instruction returns control of the flow of execution to the translation routine 340 to enable the translation routine 340 to check whether the target address to which that indirect branch instruction attempts to jump matches any of the known valid target addresses stored in the look-up table 334a”, par.0026: “It should be noted that in instances where an indirect branch instruction encountered during translation is a "call" instruction ( e.g., a call from a portion of the main routine 570 to a library function of the library 370), the translation routine 340 may additionally derive a known valid target address for the return instruction that is expected to accompany that call instruction, and store that known valid target address for that return instruction in the return look-up table 334b. Then, when the stub instruction associated with a return instruction expected to be associated with that call instruction is executed, the translation routine 340 checks whether the target address of the target to which the return instruction seeks to direct the flow of execution matches the valid target address stored in the return look-up table”).
Regarding claim 13 is a system claim that recites similar limitations as the computer-implemented method claim 3 and is rejected based on the same rational as claim 3. wherein the processor and memory, with the computer code instructions, are further configured to cause the system, (see Yamada par.0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units,.. used in this application, the terms "system" and "component" are intended to refer to an entity of a computing device in which digital processing is carried out, that entity being hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by this depicted exemplary processing architecture. For example, a component can be, but is not limited to being, a process running on a processor component, the processor component itself, a storage device (e.g., a hard disk drive, multiple storage drives in an array, etc.) that may employ an optical and/or magnetic storage medium, an software object, an executable sequence of instructions, a thread of execution, a program, and/or an entire computing device ( e.g., an entire computer).”).
Regarding claim 4 Yamada in view of He disclose the method of Claim 3 Yamada further discloses wherein controlling the execution of the application based on the created list of one or more legitimate return instruction destinations (See Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed. However, if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid”, par.0026: “the translation routine 340 replaces an indirect branch instruction in those portions with a stub instruction that causes the flow of execution by the processor component 350 to be directed back to the translation routine 340. Such a stub instruction returns control of the flow of execution to the translation routine 340 to enable the translation routine 340 to check whether the target address to which that indirect branch instruction attempts to jump matches any of the known valid target addresses stored in the look-up table 334a”, par.0026: “It should be noted that in instances where an indirect branch instruction encountered during translation is a "call" instruction ( e.g., a call from a portion of the main routine 570 to a library function of the library 370), the translation routine 340 may additionally derive a known valid target address for the return instruction that is expected to accompany that call instruction, and store that known valid target address for that return instruction in the return look-up table 334b. Then, when the stub instruction associated with a return instruction expected to be associated with that call instruction is executed, the translation routine 340 checks whether the target address of the target to which the return instruction seeks to direct the flow of execution matches the valid target address stored in the return look-up table”) comprises:
upon encountering a given return instruction, determining if a given destination of the given return instruction is approved or unapproved (see Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed. However, if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid,”);
responsive to the given destination being an approved destination, allowing execution of the application to continue (see Yamada par.0011: “during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed”); and
responsive to the given destination being an unapproved destination (see Yamada par.0011: “during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed… if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid, and possibly an indication of a ROP attack.”): (i)
checking the given destination of the given return instruction against the list of one or more legitimate return instruction destinations (see Yamada par.0011: “a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s)…. if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid,”) and (ii) controlling the execution of the application based on the checking. (See Yamada par.0011: “during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s).”).
Regarding claim 14 is a system claim that recites similar limitations as the computer-implemented method claim 4 and is rejected based on the same rational as claim 4.
Regarding claim 5 Yamada in view of He disclose the method of Claim 4 Yamada further discloses wherein:
the approved destination is a destination previously determined to be in the list of one or more legitimate return instruction destinations (see Yamada par.0028: “an indirect branch instruction encountered during translation is a "call" instruction ( e.g., a call from a portion of the main routine 570 to a library function of the library 370), the translation routine 340 may additionally derive a known valid target address for the return instruction that is expected to accompany that call instruction, and store that known valid target address for that return instruction in the return look-up table 334b. Then, when the stub instruction associated with a return instruction expected to be associated with that call instruction is executed, the translation routine 340 checks whether the target address of the target to which the return instruction seeks to direct the flow of execution matches the valid target address stored in the return look-up table.”); and
the unapproved destination is a destination not previously determined to be in the list of one or more legitimate return instruction destinations. (See Yamada par.0050: “The comparison component 344 checks that the target address associated with that return instruction has a match in the return look-up table 334b that was earlier derived and stored therein in response to encountering the call instruction during translation,.. In a manner substantially similar to such checks made of target addresses derived during execution for matches among valid target addresses in the look-up table 334a, a failure to find a match to a target address associated with a return instruction in the return look-up table 334b may result in that target address being deemed an invalid target address, and again, the comparison component 344”).
Regarding claim 15 is a system claim that recites similar limitations as the computer-implemented method claim 5 and is rejected based on the same rational as claim 5.
Regarding claim 6 Yamada in view of He disclose the method of Claim 4 Yamada further discloses wherein controlling the execution based on the checking comprises:
responsive to the given destination being in the list of one or more legitimate return instruction destinations, allowing execution of the application to continue (see Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed.”); and
responsive to the given destination not being in the list of legitimate return instruction destinations, declaring a security attack. (See Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s).if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid, and possibly an indication of a ROP attack.”).
Regarding claim 16 is a system claim that recites similar limitations as the computer-implemented method claim 6 and is rejected based on the same rational as claim 6.
Regarding claim 7 Yamada in view of He disclose the method of Claim 6 Yamada further discloses further comprising:
Responsive to declaring the security attack, implementing a protection action. (See Yamada par.0027: “lack of there being a match may be deemed an indication of a ROP attack, and the translation routine 340 may take one or more possible actions in response, those actions possibly specified in the policy data 135. Among those actions may be to attempt to find a match for the target address derived during execution among the valid target addresses in one or both of the entry point table 337 and the whitelist 130.”).
Regarding claim 17 is a system claim that recites similar limitations as the computer-implemented method claim 7 and is rejected based on the same rational as claim 7. wherein the processor and the memory, with the computer code instructions, are further configured to cause the system to: (see Yamada par.0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units,.. used in this application, the terms "system" and "component" are intended to refer to an entity of a computing device in which digital processing is carried out, that entity being hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by this depicted exemplary processing architecture. For example, a component can be, but is not limited to being, a process running on a processor component, the processor component itself, a storage device (e.g., a hard disk drive, multiple storage drives in an array, etc.) that may employ an optical and/or magnetic storage medium, an software object, an executable sequence of instructions, a thread of execution, a program, and/or an entire computing device ( e.g., an entire computer).”).
Regarding claim 8 Yamada in view of He disclose the method of Claim 7 Yamada further discloses wherein the protection action is at least one of:
blocking the given destination from being reached (see Yamada par.0011: “if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid.”);
terminating execution (see par.0027: “the possible actions may simply be to terminate execution of whatever routine that branch instruction belongs to.”); and
logging the given destination. (See par.0048: “In other embodiments, the comparison component 344 may signal the security routine 140 to perform an analysis of the main routine 570 to determine whether to continue execution of the main routine 570, including the branch instruction associated with the target address for which no match among known valid target addresses was found. Such continued execution may be the response where the main routine 570 is indicated as safe in the whitelist 130 or is in some other way determined by the security routine 140 to not be a security risk.”).
Regarding claim 18 is a system claim that recites similar limitations as the computer-implemented method claim 8 and is rejected based on the same rational as claim 8.
Regarding claim 9 Yamada in view of He disclose the method of Claim 6 Yamada further discloses wherein the security attack is a return-oriented programming attack or buffer overflow attack. (See Yamada par.0027: “if the target address derived during execution of the translated portion of whatever routine that was placed in the translation cache 367 has been somehow modified since that portion was translated and placed in the translation cache 367, then there will not be a match for the target address of the target to which that indirect branch instruction would direct the flow of execution with any of the valid target addresses in the look-up table 334a. In various embodiments, this lack of there being a match may be deemed an indication of a ROP attack,”).
Regarding claim 19 is a system claim that recites similar limitations as the computer-implemented method claim 9 and is rejected based on the same rational as claim 9.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Yamada et al. (US-20150095628-A1 hereafter Yamada), in further view of Dubrovsky et al. (US-20190347413-A1 hereafter Dubrovsky).
Regarding claim 10 Yamada teaches the method of Claim 1 fails to explicitly teach however Dubrovsky teaches wherein the application is executed utilizing a Dynamic Binary Instrumentation (DBI) tool. (See Dubrovsky par.0033: “Dynamic binary instrumentation (DBI) is a method of analyzing the behavior of a binary application at runtime through the injection of instrumentation code. This instrumentation code executes as part of the normal instruction stream after being injected. Rather than considering what may occur, dynamic binary analysis has the benefit of operating on what actually does occur. While not necessarily exhaustive in terms of exercising all code paths in an application, DBI provides detailed insight into an application's concrete execution state.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Yamada teaching “Various embodiments are generally directed to techniques to detect a return-oriented programming (ROP) attack by verifying target addresses of particular branch instructions during execution. More specifically, identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed. However, if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid, and possibly an indication of a ROP attack.”, (see Yamada par.0011) with Dubrovsky teaching “Using a DBI framework, inserted program code can be used identify that a memory region is currently being allocated. The inserted program code may also access to information relating to all a set of pre-allocated memory that is associated with a certain computer process or set of computer data. As such, the DBI framework maintains visibility on memory regions as they are being written to. The DBI framework may also be aware of a current code execution path. All of this information may be used to identify that a particular memory region is being accessed that was previously written to. In an instance where a memory region has been overwritten since the region has been allocated to a particular process and consequently that same memory region is where the current code execution path reaches, then program code associated with the DBI framework can identify that dynamically unpacked code is being executed.”, (see Dubrovsky par.0038).
Conclusion
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
Lin et al. (US-11500981-B2) Enforcing shadow stack violations for dynamic code. A thread is executed at a processor, which includes generating a portion of dynamic code for execution by the thread, identifying a range of memory addresses where the portion of dynamic code is loaded in memory, and initiating execution of the portion of dynamic code. Based at least on execution of the thread, an exception triggered by a mismatch between a first return address popped from a call stack corresponding to the thread and a second return address popped from a shadow stack corresponding to the thread is processed. Processing the exception includes (i) determining whether the second return address popped from the shadow stack is within the identified range of addresses, and (ii) based on having determined that the second return address is within the range of addresses, initiating a shadow stack enforcement action.
Pan et al. (US-8117660-B2) cross-module detection system and method examine the branch instructions between modules, and build a model for each module which contains all the possible function starting addresses that can be referred to externally. A possible destination of an inter-module transfer is extracted from the binaries directly, and the set of destination addresses is used as the checking models. The extraction process is fast, and can be done either statically or dynamically. At run-time, when an inter-module control transfer is intercepted, it is checked against the checking model to see whether it is a legitimate entrance of the destination module. If the checking is successful, then the transfer continues; otherwise, an alert is generated.
Lotspeicht et al. (US-20210173921-A1) The embodiments disclosed herein propose hijacking program flow in a program binary by insert call checking CFI code before calling a target. Examples of a target can be a function within the program binary, a register, or a memory location. If the call target is a valid call target (e.g., included in a global list of addresses), normal program flow resumes and the program flow is transferred to the target. On the contrary, if the call target is not a valid call target (e.g., not included in a global list of addresses), the program binary is deliberately crashed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUILIO MUNGUIA whose telephone number is (571)270-5277. The examiner can normally be reached M-F 9:30 - 5:00Pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni A Shiferaw can be reached at (571) 272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DUILIO MUNGUIA/Examiner, Art Unit 2497 /ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497