DETAILED ACTION
Response to Arguments
Applicant's arguments ("REMARKS") filed 09 December 2025 have been fully considered, and they are persuasive as to the previous grounds of rejection.
Claims 2, 8-11, and 15-18 were objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form.
Claims 1, 4-6, and 12-13 were amended. Claims 1, 5, and 12 are independent. Claims 1-18 are currently pending.
Re: Claim Rejections Under 35 U.S.C. §103
Applicant’s amendment and arguments, indicated on pp.9-14 of the REMARKS, in response to the rejection of the claims under 35 U.S.C. §103 with respect to Ge et al., US 2021/0209201 A1 (hereinafter, “Ge ‘201”), Singh Dilip Thakur et al., US 2021/0232571 A1 (hereinafter, “Singh ‘571”), Fischer et al., US 2022/0067179 A1 (hereinafter, “Fischer ‘179”), and Zhang et al., US 2017/0255416 A1 (hereinafter, “Zhang ‘416”) have been fully considered, and they are persuasive as to the previous grounds of rejection. In particular, Applicant argues that:
With respect to independent claim 1, Ge ‘201, in view of Singh ‘571, and further in view of Fischer ‘179 does not explicitly disclose the limitations “… a metadata extractor for analyzing the payload file to extract control flow information, segmenting instruction sequences included in a payload into basic blocks based on the extracted control flow information, and generating metadata on each of the basic blocks including inbound/outbound control flow reference information comprising locations of a source instruction and a target instruction that define a control flow transfer between the basic blocks, for use in dynamic code randomization …”, as amended.
With respect to dependent claims 3 and 4, Ge ‘201’s metadata is limited to managing physical locations of data and does not define or restore execution flow logic
With respect to dependent claim 4, the combination with Zhang ‘416 is improper.
With respect to independent claims 5 and 12, Ge ‘201 in view of Singh ‘571 does not explicitly disclose the limitations: “… decrypting the payload and dynamically relocating the decrypted payload in the confidential execution region in units of basic blocks at randomized memory locations and restoring disconnected control flow between the basic blocks by utilizing control flow reference information included in metadata distributed by the publisher apparatus”, as amended.
In response to Argument A
With respect to independent claim 1, Applicant argues that the mapping of Ge ‘201’s code sections to “basic blocks” is improper. Under the broadest reasonable interpretation, Ge ‘201’s separation of code into sections (Ge ‘201, ¶¶37-41, 52, 54, 75-76; Fig.1) was mapped to the original claim language “segmenting instruction sequences included in a payload into basic blocks”. The claim language, however, has now been amended to tie the “segmenting” process to “extracted control flow information” and the generation of “control flow reference” metadata. Applicant further argues that none of the references explicitly disclose the specific functions of the “metadata extractor”, which includes extracting control flow link information from “basic blocks” to enable runtime control flow restoration after random relocation.
Ge ‘201 in view of Singh ‘571, and further in view of Fischer ‘179 does not explicitly disclose the above limitations recited in claim 1. Accordingly, Applicant's arguments and amendments have necessitated new ground(s) of rejection presented in this Office Action. A new ground of rejection has been asserted over Koo et al., “Compiler-assisted Code Randomization,” IEEE Symposium on Security & Privacy (S&P), 2018 (hereinafter, “Koo ‘18”).
Koo ‘18 discloses a metadata extraction process in which a modified compiler toolchain analyzes program code, segments instruction sequences into basic blocks, and generates per-basic-block metadata including fixup information that records the locations of source and target instructions defining control flow transfers, for use in fine-grained basic block reordering (Koo ‘18, Table I, Sections IV-B2, IV-B3, IV-D).
In particular, Koo ‘18 explicitly discloses a modified compiler toolchain that: (1) analyzes program code to extract control flow information, including basic block boundaries defined by branch instructions and fall-through relationships (Koo ‘18, Section IV-B2, Fig.3); (2) segments all instruction sequences in the code section into basic blocks, recording each block’s size, boundary type, and fall-through status (Koo ‘18, Table I, Section IV-B2); and (3) generates metadata on each basic block including fixup information, where code-to-code (c2c) fixups record the offset of a source branch instruction and reference a target location, thereby defining control flow transfers between basic blocks (Koo ‘18, Table I, Section IV-B3). A binary rewriter then leverages this metadata to perform basic block reordering and update all fixups to restore correct control flow; generating metadata expressly designed for fine-grained code randomization at the basic block level (Koo ‘18, Fig.6, Section IV-D). Thus, Koo ‘18 discloses, at least, “… analyzing the payload file to extract control flow information ... based on the extracted control flow information ... including inbound/outbound control flow reference information comprising locations of a source instruction and a target instruction that define a control flow transfer between the basic blocks, for use in dynamic code randomization …”, as amended in claim 1.
Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) and Koo ‘18 are analogous art because they are from the same field of endeavor, namely that of protecting and transforming executable code for security purposes. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) and Koo ‘18 before them, to modify the method in Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) to include the teachings of Koo ‘18, namely to implement the program analysis performed by the platform of Ge ‘201 to include the metadata extraction process of Koo ‘18, where the payload file is analyzed to extract control flow information, instruction sequences are segmented into basic blocks based on the extracted control flow information, and per-basic-block metadata is generated that includes code-to-code fixup information recording source and target instruction locations that define control flow transfers between the basic blocks, for use in code randomization. A motivation for doing so would be to augment binaries with a minimal set of transformation-assisting metadata that facilitates rapid fine-grained code randomization at the basic block level, thereby providing an additional layer of defense against code-reuse attacks beyond the protections already afforded by the encryption scheme of Ge ‘201 (see Koo ‘18, Abstract).
See Claim Rejections – 35 USC §103 below for further details.
In response to Argument B
With respect to dependent claims 3 and 4, Examiner agrees with Applicant’s argument that Ge ‘201’s metadata is limited to data reference management, not control flow transfers. Koo ‘18, as stated above, discloses: after the new layout is available, the rewriter updates all fixups accordingly, where c2c fixups specify the source instruction offset and the target location for each control flow transfer, thereby reconnecting the control flow that was disconnected by the movement of basic blocks (CCR, Section IV-D; Fig.6). Thus, Koo ‘18 discloses “… restoring a control flow disconnected by movement of the code block by reconnecting the control flow using instruction location information specified in inbound/outbound metadata entries of corresponding code blocks”, as recited in claim 3.
Furthermore, Koo ‘18 discloses: for each basic block, the compiler generates fixup metadata that records code-to-code (c2c) fixups, where each fixup records an offset of a source branch instruction from the section base and references a target instruction location, thereby defining control flow transfers between basic blocks; the c2c fixup type inherently captures both outbound references from a source basic block and inbound references to a target basic block (Koo ‘18, Table I, Section IV-B3). Accordingly, Koo ’18 also discloses “… inbound/outbound control flow reference information including locations of a source instruction and a target instruction that cause movement between the basic blocks …”, as previously recited in claim 4, now incorporated into claim 1.
See Claim Rejections – 35 USC §103 below for further details.
In response to Argument C
With respect to dependent claim 4, now amended, the argument regarding the Zhang ‘416 combination is rendered moot as Zhang ‘416 is no longer relied upon. See Claim Rejections – 35 USC §103 below for further details.
In response to Argument D
With respect to independent claims 5 and 12, Applicant argues that Ge ‘201 does not explicitly disclose “units of basic blocks”, where the claims are now amended to explicitly require “dynamically relocating” in units of basic blocks “at randomized memory locations”. Furthermore, Applicant argues that amended claims 5 and 12 recite “restoring disconnected control flow . . . by utilizing control flow reference information …”, whereas the metadata in Ge ‘201 is only used to modify data references to ensure data integrity when code sections are moved.
Ge ‘201 does not explicitly disclose the above limitations recited in claims 5 and 12. Accordingly, Applicant's arguments and amendments have necessitated new ground(s) of rejection presented in this Office Action. A new ground of rejection has been asserted over Friedman et al., US 2019/0286818 A1 (hereinafter, “Friedman ‘818”).
Friedman ‘818 discloses computing basic blocks and relocating them individually to random locations in a block relocation space during runtime (Friedman ‘818, ¶¶49, 51-52, 75). In particular, Friedman ‘818 discloses repairing control flow after basic block relocation, where the chronomorphic binary repairs previous control flow with recomputed jump instructions to the corresponding location in the block relocation space (Friedman ‘818, ¶49). The morph table, which accompanies the binary, contains the content of relocatable blocks alongside their corresponding jump addresses (Friedman ‘818, ¶¶55, 69), constituting control flow reference information used to perform the restoration. Friedman ‘818 further discloses that the chronomorphic binary preserves the control flow of the target program and executes in the same manner as the original non-chronomorphic variant (Friedman ‘818, ¶¶48, 72). Thus Friedman ‘818 discloses, at least “…restoring disconnected control flow between the basic blocks by utilizing control flow reference information included in …”, as amended in claims 5 and 12.
Moreover, Friedman ‘818 discloses runtime code diversification, where ‘whenever the chronomorphic binary triggers a morph … the chronomorphic binary shuffles relocated blocks to random locations in the block relocation space’ during program execution (Friedman ‘818, ¶49). The morphing process is periodically, continually, or substantially continually repeated during runtime (Friedman ‘818, ¶82). Each morph trigger causes relocated basic blocks to be inserted to a random block relocation space address with corresponding jump instructions rewritten accordingly (Friedman ‘818, ¶75). Thus, Friedman ‘818 further discloses “… dynamically relocating the decrypted payload in the confidential execution region in units of basic blocks at randomized memory locations …”, as amended in claims 5 and 12.
Ge ‘201 (modified by Singh ‘571) and Friedman ‘818 are analogous art because they are from the same field of endeavor, namely that of protecting executable code from cyber-attacks using code diversification and randomization techniques. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Singh ‘571) and Friedman ‘818 before them, to modify the method in Ge ‘201 (modified by Singh ‘571) to include the teachings of Friedman ‘818, namely to implement the code placement process of Ge ‘201 to include the dynamic basic block relocation and control flow restoration process of Friedman ‘818, where the decrypted payload is dynamically relocated in units of basic blocks at randomized memory locations and the disconnected control flow is restored by utilizing control flow reference information (i.e., the jump addresses and block content stored in the morph table) included in metadata. A motivation for doing so would be to defend against code-reuse attacks such as Return Oriented Programming (ROP) and Blind ROP by continually diversifying the executable memory space during runtime, such that even if an attacker performs reconnaissance to map the binary, the layout changes before the attack can be mounted (see Friedman ‘818, ¶¶4, 12).
See Claim Rejections – 35 USC §103 below for further details.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“metadata extractor … for …” in claim 1
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 and 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Ge et al., US 2021/0209201 A1 (hereinafter, “Ge ‘201”), in view of Singh Dilip Thakur et al., US 2021/0232571 A1 (hereinafter, “Singh ‘571”), and further in view of Fischer et al., US 2022/0067179 A1 (hereinafter, “Fischer ‘179”), and further in view of Koo et al., “Compiler-assisted Code Randomization,” IEEE Symposium on Security & Privacy (S&P), 2018 (hereinafter, “Koo ‘18”).
As per claim 1: Ge ‘201 discloses:
A publisher apparatus, comprising: memory in which at least one program is recorded; and a processor for executing the program (system 100, where the system 100 comprises a memory including instructions that are executable by a processor to perform operations [Ge ‘201, ¶¶51-52, 113-115; Fig.1, Fig.7]), wherein the program includes
a confidential execution engine generator for receiving a user application execution file or a payload file (a platform 102 for receiving a program 108a, where the program 108a may a comprise a user executable program and Dynamic-Link Library (DLL) files [Ge ‘201, ¶¶37, 50-53; Fig.1]) and
generating (the platform 102 generating modified programs 108b and 108c, where the modified programs are to be executed in a secure enclave, and where the secure enclave may be an encrypted SGX enclave [Ge ‘201, ¶¶35, 42, 54, 61-62; Fig.1]), an encrypted payload file (encrypting certain portions of the received program 108a [Ge ‘201, ¶¶38, 40, 55-57]), and a user application execution file (a user executable program of the received program 108a, where the received program 108a may comprise startup code to start the corresponding applications [Ge ‘201, ¶¶42-44, 63, 80, 89]);
and a metadata extractor for analyzing the payload file (the platform 102 executing instructions to analyze the received program 108a and segment the program into separate files, binaries, and code sections, where each code section comprises data reference instructions [Ge ‘201, ¶¶37-41, 52, 54, 75-76; Fig.1]) (the platform 102 configured to generate headers for each binary/file that contains metadata [Ge ‘201, ¶¶38, 41, 55-56, 78; Fig.1])
and wherein the (the modified program 108c, the encrypted portions of the received program, the user executable program comprising startup code, and the corresponding headers are distributed to a computing device 104 capable of executing an SGX enclave [Ge ‘201, ¶¶35, 38, 75-76, 87, 92, 94; Fig.1]).
As stated above, while Ge ‘201 discloses a modified program file capable of being executed within an SFX enclave, Ge ‘201 does not explicitly disclose “… generating a Software Guard eXtensions (SGX) enclave shared object file … analyzing the payload file to extract control flow information …… including inbound/outbound control flow reference information comprising locations of a source instruction and a target instruction that define a control flow transfer between the basic blocks, for use in dynamic code randomization … and wherein the SGX enclave shared object file … distributed to a cloud node …”.
Singh ‘571, however, discloses:
… generating a Software Guard eXtensions (SGX) enclave shared object file (code is converted to an enclave shared object (.so) is encrypted at build time and is decrypted at enclave load time as a result the code details are protected. During execution, the SGX enclave runs the code and signs the output [Singh ‘571, ¶111])
… …
… and wherein the SGX enclave shared object file (code is converted to an enclave shared object (.so) is encrypted at build time and is decrypted at enclave load time as a result the code details are protected. During execution, the SGX enclave runs the code and signs the output [Singh ‘571, ¶111]) …
Ge ‘201 and Singh ‘571 are analogous art because they are from the same field of endeavor, namely that of using SGX enclaves for the secure management of data. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 and Singh ‘571 before them, to modify the method in Ge ‘201 to include the teachings of Singh ‘571, namely to implement the modified program file of Ge ‘201 (which is to be executed in an SGX enclave), to be an enclave shared object file, as disclosed in Singh ‘571. A motivation for doing so would be to create a secure and trusted file format to protect code and data from unauthorized access while also having dynamic loading and unloading properties (see Singh ‘571, ¶111).
As stated above, Ge ‘201 in view of Singh ‘571 does not explicitly disclose the limitation “… analyzing the payload file to extract control flow information … based on the extracted control flow information … including inbound/outbound control flow reference information comprising locations of a source instruction and a target instruction that define a control flow transfer between the basic blocks, for use in dynamic code randomization … distributed to a cloud node …”.
Fischer ‘179, however, discloses:
… …
… distributed to a cloud node (a method for executing encrypted data using a secure SGX enclave, where the encrypted data is distributed to and executed on a cloud platform [Fischer ‘179, ¶¶12, 14, 26]) …
Ge ‘201 (modified by Singh ‘571) and Fischer ‘179 are analogous art because they are from the same field of endeavor, namely that of using SGX enclaves for the secure management and execution of data. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Singh ‘571) and Fischer ‘179 before them, to modify the method in Ge ‘201 (modified by Singh ‘571) to include the teachings of Fischer ‘179, namely to implement the computing device of Ge ‘201 (which receives the modified program file), to be a cloud customer device, as disclosed in Fischer ‘179. A motivation for doing so would be to provide on-demand access to cost-efficient computing resources such as data storage and computing power (see Fischer ‘179, ¶¶1, 12).
As stated above, Ge ‘201 in view of Singh ‘571, and further in view of Fischer ‘179 does not explicitly disclose the limitation “... analyzing the payload file to extract control flow information … based on the extracted control flow information … including inbound/outbound control flow reference information comprising locations of a source instruction and a target instruction that define a control flow transfer between the basic blocks, for use in dynamic code randomization …”.
Koo ‘18, however, discloses:
… analyzing the payload file to extract control flow information (a modified LLVM compiler toolchain that analyzes program code to extract control flow information, including basic block boundaries defined by branch instructions and fall-through relationships [Koo ‘18, Section IV-B2]),
segmenting instruction sequences included in a payload into basic blocks based on the extracted control flow information (the compiler toolchain segments all instruction sequences in the code section into basic blocks, recording each basic block’s size, boundary type (BBL, FUN, OBJ), and fall-through status, where basic block boundaries are determined by control flow constructs such as conditional branches [Koo ‘18, Table I, Section IV-B2]),
and generating metadata on each of the basic blocks including inbound/outbound control flow reference information comprising locations of a source instruction and a target instruction that define a control flow transfer between the basic blocks (for each basic block, the compiler generates fixup metadata that records code-to-code (c2c) fixups, where each fixup records an offset of a source branch instruction from the section base and references a target instruction location, thereby defining control flow transfers between basic blocks; the c2c fixup type inherently captures both outbound references from a source basic block and inbound references to a target basic block [Koo ‘18, Table I, Section IV-B3]),
for use in dynamic code randomization (the collected metadata is embedded in the binary and used by a binary rewriter to perform fine-grained code randomization at the basic block level, where the rewriter leverages the metadata to randomly reorder basic blocks and then updates all fixups accordingly to restore correct control flow [Koo ‘18, Section IV-D, Fig.6]) …
Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) and Koo ‘18 are analogous art because they are from the same field of endeavor, namely that of protecting and transforming executable code for security purposes. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) and Koo ‘18 before them, to modify the method in Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) to include the teachings of Koo ‘18, namely to implement the program analysis performed by the platform of Ge ‘201 to include the metadata extraction process of Koo ‘18, where the payload file is analyzed to extract control flow information, instruction sequences are segmented into basic blocks based on the extracted control flow information, and per-basic-block metadata is generated that includes code-to-code fixup information recording source and target instruction locations that define control flow transfers between the basic blocks, for use in code randomization. A motivation for doing so would be to augment binaries with a minimal set of transformation-assisting metadata that facilitates rapid fine-grained code randomization at the basic block level, thereby providing an additional layer of defense against code-reuse attacks beyond the protections already afforded by the encryption scheme of Ge ‘201 (see Koo ‘18, Abstract).
As per claim 3: Ge ‘201 in view of Singh ‘571, and further in view of Fischer ‘179, and further in view of Koo ‘18 discloses all limitations of claim 1, as stated above, from which claim 3 is dependent upon. Furthermore, Ge ‘201 discloses:
wherein the (the SGX enclave includes an in-enclave loader for decrypting and loading the specified portions of the modified program into an memory region for execution, where the loader determines where to load certain portions of the modified program based on whether the portion comprises executable code [Ge ‘201, ¶¶35, 61-64]), and
As stated above, while Ge ‘201 discloses a modified program file capable of being executed within an SFX enclave, Ge ‘201 in view of Fischer ‘179 does not explicitly disclose “… the SGX enclave shared object file … relocating a selected payload code block according to a randomization policy; and a payload code randomizer for selecting a code block to be moved based on distributed payload metadata, determining a memory location in the enclave to which the selected code block is to be moved, moving the selected code block thereto, and restoring a control flow disconnected by movement of the code block by reconnecting the control flow using instruction location information specified in inbound/outbound metadata entries of corresponding code blocks.”
Singh ‘571, however, discloses:
… the SGX enclave shared object file (code is converted to an enclave shared object (.so) is encrypted at build time and is decrypted at enclave load time as a result the code details are protected. During execution, the SGX enclave runs the code and signs the output [Singh ‘571, ¶111])
… .
Ge ‘201 (modified by Fischer ‘179) and Singh ‘571 are analogous art because they are from the same field of endeavor, namely that of using SGX enclaves for the secure management of data. For the reasons stated in claim 1, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Fischer ‘179) and Singh ‘571 before them, to modify the method in Ge ‘201 (modified by Fischer ‘179) to include the teachings of Singh ‘571.
As stated above, Ge ‘201 in view of Singh ‘571, and further in view of Fischer ‘179 does not explicitly disclose the limitation “... relocating a selected payload code block according to a randomization policy; and a payload code randomizer for selecting a code block to be moved based on distributed payload metadata, determining a memory location in the enclave to which the selected code block is to be moved, moving the selected code block thereto, and restoring a control flow disconnected by movement of the code block by reconnecting the control flow using instruction location information specified in inbound/outbound metadata entries of corresponding code blocks.”
Koo ‘18, however, discloses:
... relocating a selected payload code block according to a randomization policy (the binary rewriter of CCR relocates selected code blocks according to a randomization policy that prioritizes basic block reordering at intra-function level and then proceeds with function-level reordering [Koo ‘18, Section IV-D, Fig.6]);
and a payload code randomizer for selecting a code block to be moved based on distributed payload metadata, determining a memory location in the enclave to which the selected code block is to be moved, moving the selected code block thereto (the binary rewriter selects code blocks for reordering based on the embedded metadata, determines new locations for the selected blocks subject to distance constraints imposed by fixup sizes, and moves the selected code blocks to the determined locations [Koo ‘18, Section IV-D,Fig.6]), and
restoring a control flow disconnected by movement of the code block by reconnecting the control flow using instruction location information specified in inbound/outbound metadata entries of corresponding code blocks (after the new layout is available, the rewriter updates all fixups accordingly, where c2c fixups specify the source instruction offset and the target location for each control flow transfer, thereby reconnecting the control flow that was disconnected by the movement of basic blocks [Koo ‘18, Section IV-D, Fig.6]).
Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) and Koo ‘18 are analogous art because they are from the same field of endeavor, namely that of protecting and transforming executable code for security purposes. For the reasons stated in claim 1, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) and Koo ‘18 before them, to modify the method in Ge ‘201’ (modified by Singh ‘571 and Fischer ‘179) to include the teachings of Koo ‘18.
As per claim 4: Ge ‘201 in view of Singh ‘571, and further in view of Fischer ‘179, and further in view of Koo ‘18 discloses all limitations of claim 1, as stated above, from which claim 4 is dependent upon. Ge ‘201 in view of Singh ‘571, and further in view of Fischer ‘179 does not explicitly disclose the limitations of claim 4. Koo ‘18, however, discloses:
wherein the metadata on each of the basic blocks further includes a range of the basic block represented as a pair of byte offsets from a start point of payload code (the metadata for each basic block includes the BBL size in bytes, and each basic block’s position is determined by its offset relative to the section base in the .text section, such that the start and end of each basic block are representable as byte offsets from the start point of the code section [Koo ‘18, Table I, Section IV-B2]),
a relationship with a predecessor basic block or a successor basic block according to a control flow of the code (the metadata records fall-through status for each basic block and the BBL boundary type, which indicates whether a basic block is followed by the next basic block (BBL), ends a function (FUN), or ends an object (OBJ), thereby establishing the relationship between a basic block and its successor according to the control flow; specifically, a basic block terminated with a conditional branch implicitly falls through its successor depending on the evaluation of the condition [Koo ‘18, Table I, Section IV-B2]), and
locations of instructions of a designated type in the basic block (the fixup metadata records the offset from the section base for each fixup within a basic block, where fixups correspond to designated types of instructions such as branch instructions (e.g., call, jmp) and data reference instructions, and where relaxable fragments are generated only for branch instructions [Koo ‘18, Table I, Section IV-B2]).
Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) and Koo ‘18 are analogous art because they are from the same field of endeavor, namely that of protecting and transforming executable code for security purposes. For the reasons stated in claim 1, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) and Koo ‘18 before them, to modify the method in Ge ‘201 (modified by Singh ‘571 and Fischer ‘179) to include the teachings of Koo ‘18.
Claims 5-7 and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Ge ‘201, in view of Singh ‘571, and further in view of Friedman et al., US 2019/0286818 A1 (hereinafter, “Friedman ‘818”).
As per claim 5: Ge ‘201 discloses:
An apparatus for code randomization in a Software Guard eXtensions (SGX)-based confidential execution region (executing code in an SGX enclave, where the method uses Address Space Layout Randomization (ASLR) on the executed code [Ge ‘201, ¶¶35, 77]), comprising: memory in which at least one program is recorded; and a processor for executing the program, wherein the program performs (system 100, where the system 100 comprises a memory including instructions that are executable by a processor to perform operations [Ge ‘201, ¶¶51-52, 113-115; Fig.1, Fig.7])
initializing a confidential execution region by executing (the platform 102 generating modified programs 108b and 108c, where the modified programs are to be executed in a secure enclave, and where the secure enclave may be an encrypted SGX enclave [Ge ‘201, ¶¶35, 42, 54, 61-62; Fig.1]),
loading an encrypted payload into memory (the modified program 108c, the encrypted portions of the received program, the user executable program comprising startup code, and the corresponding headers are distributed to a memory of the computing device 104 capable of executing an SGX enclave [Ge ‘201, ¶¶35, 38, 75-76, 87, 92, 94; Fig.1]), and
acquiring a decryption key for decrypting the encrypted payload; and decrypting the payload and publisher apparatus (acquiring a decryption key for decrypting the encrypted portions of the modified program, where the decrypted portions are placed in the enclave with reference to the headers provided by the platform 102 [Ge ‘201, ¶¶55-56, 64, 69, 84-85; Fig.1]).
As stated above, while Ge ‘201 discloses a modified program file capable of being executed within an SFX enclave, Ge ‘201 does not explicitly disclose “… executing an SGX enclave shared object file … dynamically relocating the decrypted payload in the confidential execution region in units of basic blocks at randomized memory locations and restoring disconnected control flow between the basic blocks by utilizing control flow reference information included in metadata …”.
Singh ‘571, however, discloses:
… executing an SGX enclave shared object file (code is converted to an enclave shared object (.so) is encrypted at build time and is decrypted at enclave load time as a result the code details are protected. During execution, the SGX enclave runs the code and signs the output [Singh ‘571, ¶111]) …
…
Ge ‘201 and Singh ‘571 are analogous art because they are from the same field of endeavor, namely that of using SGX enclaves for the secure management of data. For the reasons stated in claim 1, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 and Singh ‘571 before them, to modify the method in Ge ‘201 to include the teachings of Singh ‘571.
As stated above, Ge ‘201 in view of Singh ‘571 does not explicitly disclose the limitation “... dynamically relocating the decrypted payload in the confidential execution region in units of basic blocks at randomized memory locations and restoring disconnected control flow between the basic blocks by utilizing control flow reference information included in metadata ...”.
Friedman ‘818, however, discloses:
… dynamically relocating the decrypted payload in the confidential execution region in units of basic blocks at randomized memory locations (a chronomorphic binary that dynamically relocates code during runtime, where basic blocks containing gadgets are relocated to random addresses in a block relocation space, and where a basic block is defined as a sequence of instructions with exactly one entry and exit point [Friedman ‘818, ¶¶49, 51-52, 75, 82]) and
restoring disconnected control flow between the basic blocks by utilizing control flow reference information included in metadata (the chronomorphic binary restores control flow after relocation by recomputing jump instructions to the corresponding location in the block relocation space, utilizing relocation data contained in a morph table that is external to the binary, where the morph table contains the content of relocatable blocks alongside their corresponding jump addresses [Friedman ‘818, ¶¶49, 55, 69, 72]) …
Ge ‘201 (modified by Singh ‘571) and Friedman ‘818 are analogous art because they are from the same field of endeavor, namely that of protecting executable code from cyber-attacks using code diversification and randomization techniques. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Singh ‘571) and Friedman ‘818 before them, to modify the method in Ge ‘201’ (modified by Singh ‘571) to include the teachings of Friedman ‘818, namely to implement the code placement process of Ge ‘201 to include the dynamic basic block relocation and control flow restoration process of Friedman ‘818, where the decrypted payload is dynamically relocated in units of basic blocks at randomized memory locations and the disconnected control flow is restored by utilizing control flow reference information (i.e., the jump addresses and block content stored in the morph table) included in metadata. A motivation for doing so would be to defend against code-reuse attacks such as Return Oriented Programming (ROP) and Blind ROP by continually diversifying the executable memory space during runtime, such that even if an attacker performs reconnaissance to map the binary, the layout changes before the attack can be mounted (see Friedman ‘818, ¶¶4, 12).
As per claim 6: Ge ‘201 in view of Singh ‘571, and further in view of Friedman ‘818 discloses all limitations of claim 5, as stated above, from which claim 6 is dependent upon. Furthermore, Ge ‘201 discloses:
wherein, when dynamically relocating the decrypted payload, the program performs decrypting payload code in enclave memory (acquiring a decryption key for decrypting the encrypted portions of the modified program, where the decrypted portions are placed in the enclave with reference to the headers provided by the platform 102 [Ge ‘201, ¶¶55-56, 64, 69, 84-85; Fig.1]); initially placing the payload code in the confidential execution region depending on a file format (the SGX enclave includes an in-enclave loader for decrypting and loading the specified portions of the modified program into an memory region for execution, where the loader determines where to load certain portions of the modified program based on whether the portion comprises executable code [Ge ‘201, ¶¶35, 61-64]);
As stated above, Ge ‘201 in view of Singh ‘571 does not explicitly disclose the limitation “... randomly relocating a part of code blocks of the initially placed payload code based on the metadata; and relocating and redirecting a remaining part of the payload code that is not randomly relocated.”
Friedman ‘818, however, discloses:
… randomly relocating a part of code blocks of the initially placed payload code based on the metadata (the chronomorphic binary selects a part of the code blocks (i.e., basic blocks containing relocatable gadgets) and relocates those selected blocks to random locations in the block relocation space based on relocation data contained in the morph table [Friedman ‘818, ¶¶49, 51-52, 69]); and
relocating and redirecting a remaining part of the payload code that is not randomly relocated (for the remaining part of the code that is not relocated via block relocation, the chronomorphic binary uses in-place code randomization (IPCR) strategies to randomize non-relocated instructions, which perform narrow-scope transformations without changing the byte-length of instruction sequences, including instruction substitution and register preservation code reordering [Friedman ‘818, ¶¶64-66]).
Ge ‘201 (modified by Singh ‘571) and Friedman ‘818 are analogous art because they are from the same field of endeavor, namely that of protecting executable code from cyber-attacks using code diversification and randomization techniques. For the reasons stated in claim 5, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Singh ‘571) and Friedman ‘818 before them, to modify the method in Ge ‘201 (modified by Singh ‘571) to include the teachings of Friedman ‘818.
As per claim 7: Ge ‘201 in view of Singh ‘571, and further in view of Friedman ‘818 discloses all limitations of claims 5-6, as stated above, from which claim 7 is dependent upon. Furthermore, Ge ‘201 discloses:
wherein, when randomly relocating the code blocks, the program performs reading an encrypted metadata file into an enclave (relocating selected portions of code according to an Address Layout Randomization (ASLR) policy where, based on metadata provided in the header and the ASLR policy, selecting and relocating portions of code to corresponding arbitrary memory locations in the enclave [Ge ‘201, ¶¶62, 76-78, 81-82]) and decrypting the encrypted metadata file (acquiring a decryption key for decrypting the encrypted portions of the modified program, where the decrypted portions are placed in the enclave with reference to the headers provided by the platform 102 [Ge ‘201, ¶¶55-56, 64, 69, 84-85; Fig.1]);
As stated above, Ge ‘201 in view of Singh ‘571 does not explicitly disclose the limitation “... determining a randomization policy and target code blocks to which the randomization policy is applied; and moving each of the selected code blocks and updating instructions and associated metadata entries for code blocks included in a control flow by referring to the metadata.”
Friedman ‘818, however, discloses:
… determining a randomization policy and target code blocks to which the randomization policy is applied (the offline analysis tool determines a randomization policy by analyzing the binary to identify and prioritize gadgets; attack gadgets are given the highest priority for the highest-diversity transforms, available gadgets are given medium priority, and instructions not linked to an available gadget are given the lowest priority; the target code blocks to which the policy is applied are the basic blocks containing those identified gadgets [Friedman ‘818, ¶¶43-46, 48]); and
moving each of the selected code blocks and updating instructions and associated metadata entries for code blocks included in a control flow by referring to the metadata (for each selected code block, the chronomorphic binary relocates the byte sequence of the gadget’s basic block to an empty area in the block relocation space, writes a jump instruction from the head of the basic block to the new address in the block relocation space, and writes the block’s byte sequence and the address of the new jump instruction to the morph table, thereby updating the instructions and associated metadata entries for code blocks included in a control flow; at runtime, the chronomorphic binary shuffles relocated blocks to random locations and repairs previous control flow with recomputed jump instructions by referring to the morph table [Friedman ‘818, ¶¶49, 52-56]).
Ge ‘201 (modified by Singh ‘571) and Friedman ‘818 are analogous art because they are from the same field of endeavor, namely that of protecting executable code from cyber-attacks using code diversification and randomization techniques. For the reasons stated in claim 5, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Ge ‘201 (modified by Singh ‘571) and Friedman ‘818 before them, to modify the method in Ge ‘201 (modified by Singh ‘571) to include the teachings of Friedman ‘818.
As per claims 12-14: Claims 12-14 define a method that recites substantially similar subject matter as the method of claims 5-7, respectively. Specifically, claims 12-14 are directed to a method for code randomization in a Software Guard eXtensions (SGX)-based confidential execution region that may be performed by the apparatus of claims 5-7, respectively. Thus, the rejection of claims 5-7 is equally applicable to claims 12-14, respectively.
Allowable Subject Matter
Dependent claims 2, 8-11, and 15-18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claims 15-18 define a method that recites substantially similar subject matter as the apparatus of claims 8-11, respectively.
The aforementioned claims further define the claimed invention and are not taught by the current prior arts of record.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Seo, Jaebaek, et al., “SGX-shield: Enabling address space layout randomization for SGX programs”, NDSS, 2017.
Leslie-Hurd et al., US 9311508 B2: in response to the user-level instruction, to change an initial linear address of the page of the secure enclave. The initial linear address is to be stored in an enclave page storage metadata unit. The initial linear address is to be changed by the execution logic to the linear address.
Park et al., US 11061998 B2: method for executing security to protect a code of a shared object. An object file extraction unit configured to extract a shared object file from an execution package and protecting the important execution code of the shared object file from a static analysis attack.
Roth et al., US 9584517 B1: instantiating an enclave according to a request, the enclave being instantiated at a determined location of a set of locations in a computing environment of a computing resource service provider hosting a set of computing resources.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN L KONG whose telephone number is (571)272-2646. The examiner can normally be reached Monday-Thursday 9:00am-7:00pm EST.
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, JUNG (JAY) KIM can be reached on (571)272-3804. 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.
/ALAN L KONG/Examiner, Art Unit 2494
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494