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 .
DETAILED ACTION
This action is in response to the communication filed on 05/21/2025.
Claims 1-20 are under examination.
The Information Disclosure Statements filed on 12/04/2025 has been entered and considered.
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 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.
Claims 1, 4, 8, 10, 12, 15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Satish (US 9,058,492 B1), Sun et al. (US 2019/0318094 A1) and Toledano et al. (US 2017/0213037 A1).
Regarding claim 1, Satish discloses A computer-implemented method for determining exploitability of memory safety vulnerabilities [abs, a method for reducing executable code vulnerability], the computer-implemented method comprising: analyzing, by a computer system, a first executable by scanning a binary of the first executable to identify one or more first sequences of instructions ending with a return instruction, each first sequence of instructions situated at a fixed memory address [col. 6, lines 31-39, “binary vulnerability reduction module 154 may perform one or more searches for sequences of bytes that make instructional sense that end in a control transfer instruction where the control transfer address is fetched from the stack (e.g., a pop Executable Instruction Pointer (EIP) effect via return instruction) or moving the stack data to a register and using the register value to do a jmp also known as pop-jmp sequences (e.g., pop x; jmp *x) using any general purpose registers”]; monitoring, by the computer system, a second executable during runtime of the second executable to identify at least one pattern corresponding to a known or suspected ROP chain, wherein the second executable comprises the first executable augmented with code comprising one or more memory safety mitigation technologies [col. 12, lines 42-56, “At block 410 executable code structure may be modified to maintain a same logical outcome while changing a sequence of at least one instruction (e.g., using a jump to point to instructions in a different address space). Shell coders may analyze a copy of a binary file (e.g., their own copy of a browser Portable Executable (PE) file) and may expect vulnerable code to be located at a particular address. Thus, a modification to executable code structure such that a particular set of instructions is not at a particular address may prevent exploitation of vulnerable code (e.g., break a gadget). Furthermore, modifying the vulnerable code so that it is a sequence of instructions that end in a "call" instruction may result in the executable code not being considered a useful gadget (e.g., vulnerable) since the return address is governed by the call instruction and not by the attacker”, col. 12, line 65-col. 13, line 6, “a determination may be made whether to check for additional vulnerabilities. The determination may be made based on a count of prior scans, whether vulnerabilities are being addressed in a binary file or associated address space, whether associated address space is ASLR compliant, and other factors. If it is determined that additional checks should be performed then the method 400 may return to block 404”]; identifying, by the computer system based at least in part on the at least one pattern, one or more second sequences of instructions during runtime of the second executable [col. 11, lines 54-55, “At block 404, one or more potentially exploitable code sequences may be identified” (additional check after block 412)].
Satish does not explicitly disclose analyzing, by the computer system, the one or more sequences of machine instructions to detect one or more usable sequences in a Return Oriented Programming (ROP) chain.
However Sun et al. teaches analyzing, by the computer system, the one or more sequences of machine instructions to detect one or more usable sequences in a Return Oriented Programming (ROP) chain [par. 0083, “the system may use static or dynamic code analysis, or other known methods, to analyze objects, code flows, or other byte streams to determine whether the objects represent a potential ROP gadget chain”].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Sun et al. into the teaching of Satish with the motivation to identify within the memory a payload that is suspected to be a return-oriented programming (ROP) chain and take a security action responsive to the determining as taught by Sun et al. [Sun et al.: abs.].
They do not explicitly disclose comparing, by the computer system, the one or more first sequences with the one or more second sequences; calculating, by the computer system based on the comparison, a change in exploitation risk between the first executable and the second executable; and generating, by the computer system, a report including the calculated change in exploitation risk between the first executable and the second executable, wherein the computer system comprises a processor and a memory.
However, Toledano et al. teaches comparing, by the computer system, the one or more first sequences with the one or more second sequences [par. 0036, “comparing the characterization and/or underlying total risk score to historical characterizations and/or underlying scores for the same software application (e.g., the same instance, a separate instance of the same software application, a different version of the same software application, etc.)… comparison of the characterization and/or underlying total risk of a current software application to a historical data point”]; calculating, by the computer system based on the comparison, a change in exploitation risk between the first executable and the second executable [abs, “a system for risk scoring a software application includes a component score engine to calculate an impact component score and a likelihood component score for a security vulnerability during development of the software application based on a plurality of scored descriptions of security risk elements for the software application”, par. 0141, “The method 580 can characterize the security vulnerabilities based on the scores and the characterizations can be used to implement and/or measure the efficacy of a risk reduction plan for the software application by comparing the scores and/or the characterizations to historical risk characterizations”]; and generating, by the computer system, a report including the calculated change in exploitation risk between the first executable and the second executable, wherein the computer system comprises a processor and a memory [par. 0036, “the report and/or graphical representation can include trends and/or projections resulting from the comparison of the characterization and/or underlying total risk of a current software application to a historical data point. Displaying can also include displaying suggestions (e.g., a risk reduction plan) for modifying the software application and/or its development in a manner that will reduce the risk characterization, the underlying total risk score, the underlying risk element scores, and/or the underlying descriptions of risk element metrics. The suggestions can be based on historical data points, projections, and or predetermined risk mitigation measures”].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Toledano et al. into the teaching of Satish and Sun et al. with the motivation of utilizing risk assessment tools to effectively identify and address vulnerabilities as taught by Toledano et al. [Toledano et al.: abs.].
Regarding claim 4, the rejection of claim 1 is incorporated.
Toledano et al. teaches converting the calculated change in exploitation risk into a rating [par. 0125, “The confidentiality impact security risk element score, the integrity impact security risk element score, and the availability impact risk element score can be analyzed and/or compared to calculate an impact potential segment score. For example, the confidentiality impact security risk element score, the integrity impact security risk element score, and the availability impact risk element score can be compared and the maximum score of the three scores can be designated the impact potential segment score”].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Toledano et al. into the teaching of Satish and Sun et al. with the motivation of utilizing risk assessment tools to effectively identify and address vulnerabilities as taught by Toledano et al. [Toledano et al.: abs.].
Regarding claim 8, the rejection of claim 1 is incorporated.
Satish et al. further teaches the report comprises a number of the one or more first sequences and a number of the one or more second sequences [col. 6, lines 31-44, “binary vulnerability reduction module 154 may perform one or more searches for sequences of bytes that make instructional sense that end in a control transfer instruction... A total number of aligned or unaligned sequences of bytes that are exploitable may provide a vulnerability ranking, indicator, or score associated with a binary file or process. According to one or more embodiments, identified vulnerable code may be communicated to a central server, other security clients”].
Regarding claim 10, it recites limitations like claim 1. The reason for the rejection of claim 1 is incorporated herein.
Regarding claim 12, it recites limitations like claim 1. The reason for the rejection of claim 1 is incorporated herein.
Regarding claim 15, it recites limitations like claim 4. The reason for the rejection of claim 4 is incorporated herein.
Regarding claim 19, it recites limitations like claim 8. The reason for the rejection of claim 8 is incorporated herein.
Claims 2 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Satish (US 9,058,492 B1), Sun et al. (US 2019/0318094 A1) and Toledano et al. (US 2017/0213037 A1) as applied to claims 1, 4, 8, 10, 12, 15 and 19 above, and further in view of Levin et al. (US 2019/0258806 A1).
Regarding claim 2, the rejection of claim 1 is incorporated.
Satish discloses the monitoring of the second executable.
They do not explicitly disclose instrumenting a code of the second executable or using hardware features to log memory and/or register accesses of the second executable.
However, Levin et al. teaches instrumenting a code of the second executable or using hardware features to log memory and/or register accesses of the second executable [par. 0045, “ in order to prevent attacks that exploit the computer architecture, it may be required to have access to actual processes at the hardware and/or software computing level (for example detecting exploit below the layer of the operating system). In some embodiments, gathering data of actual computer processes (e.g., from the PMU) may allow access to logs of code execution such that exploit or breach detection may be allowed”].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Levin et al. into the teaching of Satish, Sun et al. and Toledano et al. with the motivation of detecting an exploit of a vulnerability of a computing device as taught by Levin et al. [Levin et al.: abs.].
Regarding claim 13, it recites limitations like claim 2. The reason for the rejection of claim 2 is incorporated herein.
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Satish (US 9,058,492 B1), Sun et al. (US 2019/0318094 A1) and Toledano et al. (US 2017/0213037 A1) as applied to claims 1, 4, 8, 10, 12, 15 and 19 above, and further in view of Souders (US 2022/0197777 A1).
Regarding claim 3, the rejection of claim 1 is incorporated.
Satish discloses one or more memory safety mitigation technologies.
They do not explicitly disclose the one or more memory safety mitigation technologies comprises Load-time Function Randomization (LFR).
However, Souders teaches the one or more memory safety mitigation technologies comprises Load-time Function Randomization (LFR) [par. 0030, “The randomization of a compiled binary of Example2.cpp is carried out in accordance with one or more functions residing in a separate library. In this example, the library is called Load-time Function Randomization (LFR) library”].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Souders into the teaching of Satish, Sun et al. and Toledano et al. with the motivation such that technique of randomizing the locations of functions in memory is a cyber security technique aimed at impeding attackers so that attackers do not have knowledge of how the binary resides in memory or which memory locations are accessible to be exploited for vulnerabilities as taught by Souders [Souders: par. 0030].
Regarding claim 14, it recites limitations like claim 3. The reason for the rejection of claim 3 is incorporated herein.
Claims 5-6 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Satish (US 9,058,492 B1), Sun et al. (US 2019/0318094 A1) and Toledano et al. (US 2017/0213037 A1) as applied to claims 1, 4, 8, 10, 12, 15 and 19 above, and further in view of Das et al. (US 2020/0380127 A1).
Regarding claim 5, the rejection of claim 1 is incorporated.
Satish discloses one or more memory safety mitigation technologies.
They do not explicitly disclose identifying one or more dynamically generated addresses that point to a function within the first executable; and determining whether there is a code flow path through the first executable that would allow the one or more dynamically generated addresses to be passed outside of the first executable.
However, Das et al. teaches identifying one or more dynamically generated addresses that point to a function within the first executable [par. 0039, “Vulnerabilities associated with ROP functions may also be referred to or be implemented as a “stack smashing” attack, where malicious code manipulates stack instructions by taking advantage of a bug (an unintended fault/flaw) included in a set of program code. Assume for a moment that a set of program code has been allocated 1000 bytes of memory spanning memory addresses 1000 to 2000. Assume also that malicious code issues a write command to that set of program code beginning at memory address 1500 that includes 1000 bytes of data”, par. 0041, “One way in which operations relating to a “stack pivot” attack may be identified is by an exploit detection framework that is aware of memory regions that are associated with “normal” stack functions”]; and determining whether there is a code flow path through the first executable that would allow the one or more dynamically generated addresses to be passed outside of the first executable [par. 0041, “when a “correct” stack address range/region is typically pointed by a second and a third unsigned integer of a thread's environmental block, a probe may be used to identify when a stack pointer points away from the expected stack region pointed by the second and third unsigned integer of the thread's environmental block (TEB)... When a TEB stores information relating to memory addresses that are known to be associated with a normal (or expected) memory address range, the information in the TEB may effectively be used to set boundaries when identifying whether certain commands correspond with normal or expected program activity or whether program functions/actions do not correspond to abnormal program activity that may be associated with suspicious or malicious code. When a stack pointer points to a memory address that are outside of a known stack memory address range accessed by a set of program code, the received computer information relating to that set of program code may be identified attempting to exploit a vulnerability/flaw/bug in that set of program code”].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Das et al. into the teaching of Satish, Sun et al. and Toledano et al. with the motivation to identify suspected malware based on suspicious actions performed as program code executes as taught by Das et al. [Das et al.: abs.].
Regarding claim 6, the rejection of claim 1 is incorporated.
Satish discloses one or more memory safety mitigation technologies.
They do not explicitly disclose identifying one or more dynamically generated addresses that point to a function within the second executable; and determining whether there is a code flow path through the first executable that would allow the one or more dynamically generated addresses to be passed outside of the second executable.
However, Das et al. teaches identifying one or more dynamically generated addresses that point to a function within the second executable [par. 0039, “Vulnerabilities associated with ROP functions may also be referred to or be implemented as a “stack smashing” attack, where malicious code manipulates stack instructions by taking advantage of a bug (an unintended fault/flaw) included in a set of program code. Assume for a moment that a set of program code has been allocated 1000 bytes of memory spanning memory addresses 1000 to 2000. Assume also that malicious code issues a write command to that set of program code beginning at memory address 1500 that includes 1000 bytes of data”, par. 0041, “One way in which operations relating to a “stack pivot” attack may be identified is by an exploit detection framework that is aware of memory regions that are associated with “normal” stack functions”]; and determining whether there is a code flow path through the first executable that would allow the one or more dynamically generated addresses to be passed outside of the second executable [par. 0041, “when a “correct” stack address range/region is typically pointed by a second and a third unsigned integer of a thread's environmental block, a probe may be used to identify when a stack pointer points away from the expected stack region pointed by the second and third unsigned integer of the thread's environmental block (TEB)... When a TEB stores information relating to memory addresses that are known to be associated with a normal (or expected) memory address range, the information in the TEB may effectively be used to set boundaries when identifying whether certain commands correspond with normal or expected program activity or whether program functions/actions do not correspond to abnormal program activity that may be associated with suspicious or malicious code. When a stack pointer points to a memory address that are outside of a known stack memory address range accessed by a set of program code, the received computer information relating to that set of program code may be identified attempting to exploit a vulnerability/flaw/bug in that set of program code”].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Das et al. into the teaching of Satish, Sun et al. and Toledano et al. with the motivation to identify suspected malware based on suspicious actions performed as program code executes as taught by Das et al. [Das et al.: abs.].
Regarding claim 16, it recites limitations like claim 5. The reason for the rejection of claim 5 is incorporated herein.
Regarding claim 17, it recites limitations like claim 6. The reason for the rejection of claim 6 is incorporated herein.
Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Satish (US 9,058,492 B1), Sun et al. (US 2019/0318094 A1) and Toledano et al. (US 2017/0213037 A1) as applied to claims 1, 4, 8, 10, 12, 15 and 19 above, and further in view of Flores et al. (US 2013/0347116 A1).
Regarding claim 7, the rejection of claim 1 is incorporated.
Satish discloses one or more memory safety mitigation technologies.
They do not explicitly disclose one or more of the method steps repeated multiple times to provide Monte Carlo-type results.
However, Flores et al. teaches one or more of the method steps are repeated multiple times to provide Monte Carlo-type results [par. 0073, “performs a repeatable and exhaustive analysis of a specified threat”, par. 0075, “Monte Carlo algorithms use random samples of input parameters to investigate the behavior of complex systems. If a Monte Carlo approach were to be used for the system, the cyber reference library 108 and opponent catalog 110 shown in FIG. 1 would contain probability distribution functions. The algorithm initialization 226 and the creation of opponent instances 222 would involve making a set of random draws. The threat evaluation engine 202 would also make additional random draws, as necessary. The threat evaluation results 204 would consist of probabilities of an outcome”].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Flores et al. into the teaching of Satish, Sun et al. and Toledano et al. with the motivation to evaluate threats to elements of a client computer application having a cyber reference library as taught by Flores et al. [Flores et al.: par. 0011.].
Regarding claim 18, it recites limitations like claim 7. The reason for the rejection of claim 7 is incorporated herein.
Claims 9, 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Satish (US 9,058,492 B1), Sun et al. (US 2019/0318094 A1) and Toledano et al. (US 2017/0213037 A1) as applied to claims 1, 4, 8, 10, 12, 15 and 19 above, and further in view of Parla et al. (US 2024/0031394 A1).
Regarding claim 9, the rejection of claim 1 is incorporated.
Satish discloses one or more memory safety mitigation technologies.
They do not explicitly disclose the report in a software bill of materials (SBOM).
However, Flores et al. teaches including the report in a software bill of materials (SBOM) [par. 0036, “determining a software bill of materials (SBOM) for the process and determining a code portion of the process associated with the vulnerability based at least in part on the SBOM”, par. 0090, “Determining the code portion of the process may include mapping SBOM metadata associated with the code portion to a binary image of the process. Excluding the tainted control flow directed graph may include generating a revised SBOM excluding the code portion”].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Parla et al. into the teaching of Satish, Sun et al. and Toledano et al. with the motivation of determining a software bill of materials (SBOM) for the process and determining a code portion of the process associated with the vulnerability based at least in part on the SBOM and executing the process based on the revised control flow diagram to prevent execution of the vulnerability as taught by Parla et al. [Parla et al.: par. 0036].
Regarding claim 11, it recites limitations like claim 9. The reason for the rejection of claim 9 is incorporated herein.
Regarding claim 20, it recites limitations like claim 9. The reason for the rejection of claim 9 is incorporated herein.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure:
US 20220188414 A1 RETURN-ORIENTED PROGRAMMING PROTECTION
US 11262993 B2 Application Binary Rewriting To Reduce Binary Attack Surface Area
US 20180260559 A1 COMPILER ASSISTED PROTECTION AGAINST ARBITRARY CODE EXECUTION
US 20180096139 A1 METHOD AND SYSTEM FOR DEFENSE AGAINST RETURN ORIENTED PROGRAMMING (ROP) BASED ATTACKS
US 20180096147 A1 SYSTEM, APPARATUS AND METHOD FOR PERFORMING ON-DEMAND BINARY ANALYSIS FOR DETECTING CODE REUSE ATTACKS
US 20170185775 A1 RUNTIME RETURN-ORIENTED PROGRAMMING DETECTION
US 20170116418 A1 HARDWARE HEURISTIC-DRIVEN BINARY TRANSLATION-BASED EXECUTION ANALYSIS FOR RETURN-ORIENTED PROGRAMMING MALWARE DETECTION
US 20160179546 A1 TECHNIQUES FOR ENFORCING CONTROL FLOW INTEGRITY USING BINARY TRANSLATION
US 9336386 B1 Exploit Detection Based On Heap Spray Detection
US 20250013753 A1 SYSTEMS AND METHODS FOR REVERSE ENGINEERING-BASED DETECTION OF VULNERABILITIES
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON CHIANG whose telephone number is (571)270-3393. The examiner can normally be reached on 9 AM to 6 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. 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.
/JASON CHIANG/Primary Examiner, Art Unit 2431
