DETAILED ACTION
1. This office action is in response to the communication filed on 01/07/2025.
2. Claims 1-19 are pending.
Notice of Pre-AIA or AIA Status
3. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
4. Claim(s) 1-3, 9-12, and 18-19 is/are objected to because of the following informalities:
Regarding claims 1, 9, 10, 18, and 19: the limitations “the process” should be “the executing process” referring to the limitation “an executing process”.
Regarding claims 2 and 11: the limitation “the memory location” should be “the target memory location”.
Regarding claims 3 and 12: the limitation “the selected location” should be “the target memory location”.
Appropriate correction(s) is/are required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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.
5. Claim(s) 1-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jung et al. (US 12,223,044 B1, hereafter Jung) in view of Craske et al. (US 2025/0284495 A1, hereafter Craske).
Regarding claim(s) 1, 10, and 19:
Jung discloses a computer system comprising at least one hardware processor (see col. 2, lines 18-34, where a computer system comprising a hardware processor (e.g., circuit) executing computer instructions stored in a memory) configured to:
in response to an occurrence of a trigger event caused by an executing process, identify an executable module loaded into memory for use by the process, the executable module identified according to a current content of a call stack of the process, and wherein the executable module comprises executable code (see fig. 4B and col. 11, lines 59-66, where a system function call event triggers an operation for walking the stack (i.e., call stack) associated with a sample/program during execution of the sample/program; see col. 12, lines 29-30 and lines 47-48, where the status of the contents of the stack is determined, and wherein a system function/call (i.e., executable module) is identified);
identify a target memory location according to memory relocation data or according to exception handling data included in the executable module, wherein: the memory relocation data is indicative of addresses referenced by the executable code, addresses which were translated upon loading the executable code into memory, and [the exception handling data instructs an operating system of the computer system on handling exceptions occurring during execution of the executable code] (see col. 11, line 67 – col. 12, line 1, where an instruction/function pointer (i.e., memory relocation data) is checked to determine if the return location/address (i.e., target memory location) has changed; see col. 3, lines 55-57, where a function pointer refers to a pointer in memory that points to executable code within memory; see col. 28, lines 15-17, where a call stack is inspected to determine whether a return address in the call stack points to a memory address that has changed);
determine whether a content stored at the target memory location has been overwritten following a loading of the executable module into memory; and in response, if yes, determine that the executable module comprises malicious software (see fig. 4C and col. 12, lines 5-17 where the return location has been changed; see col. 14, lines 8-10, where resolving/changing a function pointer is malicious activity of a malware; see abstract where a sample/program is determined to be malicious based on changes in memory associated with a function pointer).
Jung does not, but Craske discloses:
the exception handling data instructs an operating system of the computer system on handling exceptions occurring during execution of the executable code (see Craske, para. 60, where an Operating System (OS) controls and manages computing resources to software/program/application executing on a computing system; see para. 42 where a software has an exception handler for an exception; see para. 76 where an exception handler pushes the exception return state information in a stack; see para. 23 where an attack corrupts the return state information used to return from an exception).
It would have been obvious to one having ordinary skill in the art to which the claimed invention pertains, before the effective filing date of the claimed invention, to modify Jung's invention by enhancing it for the exception handling data instructs an operating system of the computer system on handling exceptions occurring during execution of the executable code, as taught by Craske, in order to guard against return-oriented-programming based attack tampering with exception return state information (Craske, para. 24).
Regarding claim(s) 2 and 11:
Jung discloses:
wherein determining whether the content stored at the target memory location has been overwritten comprises: determining whether the content stored at the target memory location comprises an address within a section of memory allocated for the executable module; and in response, if yes, determine that the content stored at the memory location has not been overwritten (see col. 12, lines 1-3, where the return location/address is determined to have not been changed; see col. 19, lines 2-3, where a return address points to a memory address).
Regarding claim(s) 3 and 12:
Jung discloses:
wherein determining whether the content stored at the target memory location has been overwritten comprises: determining whether the content stored at the target memory location comprises an address within a section of memory allocated for another executable module; and in response, if yes, determine that the content stored at the selected location has not been overwritten (see col. 11, line 67 – col. 12, line 1, where an instruction/function pointer (i.e., memory relocation data) is checked to determine if the return location/address (i.e., target memory location) has changed; see col. 3, lines 55-57, where a function pointer refers to a pointer in memory that points to executable code within memory; see col. 28, lines 15-17, where a call stack is inspected to determine whether a return address in the call stack points to a memory address that has changed (i.e., whether a return address has change to points to different executable code within memory); see col. 12, lines 1-3, where the return location/address is determined to have not been changed. Note: Craske, para. 23, also discloses a successful ROP attack can cause the function return to return program flow to an instruction other than the next instruction after the point at which the function was called, which can allow the attacker to perform arbitrary operations other than the sequence of intended operations).
Regarding claim(s) 4 and 13:
Jung does not, but Craske discloses:
determining an expected location of a function prologue within a section of memory storing the executable code, the expected location determined according to the exception handling data; and identifying the target memory location according to the expected location (see Craske, paras. 23-24, where a return state information is used to return a program flow to next instruction stored in a memory’s protected region (i.e., an expected location within memory’s protected region storing next instruction of a program) after the point at which the exception was taken, wherein the return state information is obtained from a stack (e.g., guarded control stack (GCS) data structure). Note: see para. 109 for further disclosure to pop a return state information from a stack).
Regarding claim(s) 5 and 14:
Jung does not, but Craske discloses:
wherein the exception handling data comprises instructions for unwinding the call stack in response to the exception, and wherein the at least one hardware processor is configured to determine the expected location of the function prologue according to the instructions for unwinding the call stack (see Craske, paras. 23-24, where a return state information is used to return a program flow to next instruction stored in a memory’s protected region (i.e., an expected location within memory’s protected region storing next instruction of a program) after the point at which the exception was taken, wherein the return state information is obtained from a stack using a pop instruction (i.e., instruction for popping/unwinding a stack/call stack)).
Regarding claim(s) 6 and 15:
Jung does not, but Craske discloses:
wherein determining whether the content stored at the target memory location has been overwritten comprises: determining an expected processor instruction according to the exception handling data; determining whether the content stored at the target memory location comprises an encoding of the expected processor instruction; and in response, if no, determining that the content stored at the target memory location has been overwritten (see Craske, para. 25, where the return state information is modified by an attacker while being stored in an exception return state register; see para. 48 where a return state information obtained from the GCS data structure is verified, wherein a valid return state information is encoded; see para. 110 where the return state information stored in the exception return register is verified again the return state information popped from the GCS data structure, and wherein a mismatch is determined).
It would have been obvious to one having ordinary skill in the art to which the claimed invention pertains, before the effective filing date of the claimed invention, to modify Jung's invention by enhancing it for determining whether the content stored at the target memory location has been overwritten comprises: determining an expected processor instruction according to the exception handling data; determining whether the content stored at the target memory location comprises an encoding of the expected processor instruction; and in response, if no, determining that the content stored at the target memory location has been overwritten, as taught by Craske. The motivation is the same as presented in the independent claim.
Regarding claim(s) 7 and 16:
See the rejection to claim 5 or 14.
Regarding claim(s) 8 and 17:
Jung discloses:
wherein the executable module is structured according to a portable executable (PE) format, and wherein the at least one hardware processor is configured to determine whether the executable module comprises malicious software according to a content of a .RELOC section of the executable module or according to a content of a .PDATA section of the executable module (see col. 3, lines 1-7, 55-57, where malware obfuscate a function call (i.e., executable module) in the malicious code executed at runtime (i.e. malicious code including a function call is structured in an executable format to be executed at runtime by a processor), where a function pointer refers to a pointer in memory that points to executable code within memory; see col. 24, line 60 – col. 25, line 2 where malware is identified based on a function pointer (i.e., a content of a .RELOC section of a function call) associated with malware code in malware sample/program; see abstract where a sample/program is determined to be malicious based on changes in memory associated with a function pointer. Note: Craske, para. 23, also discloses a successful ROP attack can cause the function return to return program flow to an instruction other than the next instruction after the point at which the function was called, which can allow the attacker to perform arbitrary operations other than the sequence of intended operations).
Regarding claim(s) 9 and 18:
Jung discloses:
wherein the trigger event is indicative of an action performed by the process, the action selected from a group consisting of loading another executable module into memory, spawning a child process, creating a thread, connecting to a network socket, and accessing a storage device of the computer system (see fig. 4B and col. 11, lines 59-66, where a system function call event triggers operations for walking a stack, checking an instruction/function pointer, and determining if the return location has changed during execution of the sample/program; see col. 3, lines 55-57, where a function pointer refers to a pointer in memory that points to executable code within memory. In other words, a system function call event triggers operation to accessing a memory of a computer system to determine if a return location has changed).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Britton et al. (US 2025/0363221 A1), COMPUTER SYSTEMS, METHODS, AND DEVICES FOR ANALYZING EXPLOITABILITY OF MEMORY SAFETY VULNERABILITIES.
Linde (US 12223040 B2), Blocking routine redirection.
West (US 2021/0286736 A1), SYSTEMS AND METHODS FOR SECURING PROTECTED ITEMS IN MEMORY.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUAN V. DOAN whose telephone number is 571-272-3809. The examiner can normally be reached on Monday – Thursday, 9:00am – 5:00pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PHILIP CHEA, can be reached on 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUAN V DOAN/Primary Examiner, Art Unit 2499
Prosecution Insights