DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-9 are pending in this office action.
Claim 10 is a new claim.
Information Disclosure Statement
The information disclosure statement filed 12/10/2025 and 10/01/2025 fails to comply with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 because entries (41 and 45 ) respectively are missing a date. It has been placed in the application file, but the information referred to therein has not been considered as to the merits. Applicant is advised that the date of any re-submission of any item of information contained in this information disclosure statement or the submission of any missing element(s) will be the date of submission for purposes of determining compliance with the requirements based on the time of filing the statement, including all certification requirements for statements under 37 CFR 1.97(e). See MPEP § 609.05(a).
37 CFR 1.98 (b):
For publications obtained from the internet, the uniform resource locator (URL) of the webpage that is the source of the publication must be provided for the place of publication (e.g., "www.uspto.gov"). The publisher may be evident from the URL of the webpage. See MPEP § 707.05(e) for examples on listing documents retrieved from the internet, including social media posts and screen shots from videos. In particular, see examples 17 and 18. Further, for an internet publication obtained from a website that archives webpages, both the URL of the archived webpage submitted for consideration and the URL of the website from which the archived copy of the webpage was obtained should be provided on the document listing (e.g., "Hand Tools," webpage <http://www.farmshopstore.com/handtools.html>, 1 page, August 18, 2009, retrieved from Internet Archive Wayback Machine <http://web.archive.org/web/20090818144217/ http://www.farmshopstore.com/handtools.html> on December 20, 2012). Where the actual publication date of a non-patent document is not known, the applicant must, at a minimum, provide a date of retrieval (e.g., the date a webpage was retrieved) or a time frame (e.g., a year, a month and year, a certain period of time ) when the document was available as a publication.[AltContent: rect]
Response to Arguments
Applicant's arguments filed 11/10/2025 have been fully considered but they are not persuasive.
Applicant’s argument:
The Office further relies on Yoo's discussion of RTTI, in which "an RTTI structure is emitted by the compiler" and "RTTI structures can be parsed." Yoo therefore expressly relies on compiler-emitted runtime type information. This disclosure is directly inconsistent with the claimed requirement that the binary code target lacks compiler-inserted runtime type instrumentation or type metadata. The Office has not identified, and cannot identify, any teaching in the applied references that satisfies this affirmative negative limitation. The Office's reliance on Dewey to address this limitation improperly conflates the absence of source code or debugging information with the absence of compiler-inserted runtime type metadata. These are distinct and non-equivalent conditions, and Dewey does not cure the reliance on compiler-emitted type information taught by Yoo. Accordingly, the applied references fail to disclose the claimed condition that no compiler-inserted runtime type instrumentation or type metadata is present.
Examiner’s response:
Yoo disclosure is directed to analyzing the binary for type mismatch or no type casting:
“In the example above assuming that foo() is declared to be virtual, the object pointer b is cast to type A∗, but the virtual method B::foo( ) is called without a typecast and this expects a pointer to an object of type B rather than type A. Therefore, the pointer has to be corrected by adding a delta value, that corrects the object pointer from A∗ to B∗. This is all done by declaring foo() a virtual function.”
Casting an object with different unexpected type or lack of type is a type confusion. And this type confusion is detected whiting the binary.
The specification of this application includes analysis of the binary by extyracting virtual table that applicant’s representative assign to Dewey(remarks page 2)
Specification of instant application [0044] “Further, the restoring of the at least one class and the inheritance relationship of the at least one class by analyzing the binary code of the object-oriented programming language may include extracting at least one virtual function table for each of at least one polymorphic class, recognizing a constructor and a destructor for each of the at least one polymorphic class by using the at least one virtual function table, and restoring the inheritance relationship of the at least one class through an overwrite analysis using the constructor and the destructor.”;
In Dewey the binary has no compiler instruction nor has debugging instrumentation or access to the source code:
[0035]” the analyses discussed herein can be performed without access to source code of the software module or debugging information that may or may not be included in the binary code representation of the software module.”;
Using the binary and extracting V-tables [0020] of Dewey, class hierarchy and size is determined:
[0019]” This pattern is characteristic of instantiation of an object in a binary code representation of a software module that was developed using the C++ programming language, where the call is a call to a constructor of the object. The memory address can then be used to track use of the object by operations within the binary code. That is, operations performed using the memory address (directly or indirectly using relative offsets from the memory address) can be said to be operations applied to the object.”;
The applicant argued that RTTI are included in the binary, and is inconsistent with the claimed invention, Dewey discloses the following:
[0010] Some binary code representations of applications, however, do include information about objects. Such information can be included in binary code as run-time type information (RTTI) or debugging information that is compiled into the binary code. Nevertheless, because the binary code representations of many applications do not include such information (e.g., to discourage reverse engineering of these applications), robust methodologies and systems for analyzing binary code based on (or derived from) source code using object-oriented techniques should not assume availability of such information.
[0011]” Thus, implementations discussed herein can identify objects and attributes such as a size thereof without referring to (or independent of) source code or explicit information about such objects which may or may not be included in the binary code.”;
So, the result based in applicant’s argument is a system with more flexibility in restoring the structure from the binary with or without such RTTI.
Applicant’s argument:
However, the cited passage describes pointer correction behavior for virtual dispatch and does not disclose detecting a type confusion bug by using a layout of a class. The passage explains how virtual function calls operate; it does not disclose evaluating a memory access against a class layout to determine whether a type confusion bug has occurred.
Examiner’s response:
The issue in the argument is that art of record do not discloses detection of type confusion.
With respect to Dewy as the reference used, the binary table is used to restore the object of the binary and respective operation without access to source code or RTTI.
Using such table the structure of the class is restored(constructor) as one of them to detect any vulnerability in accessing addresses not within the boundaries of the binary.
for layout:
[0019]“subsequent (either immediately subsequent or follows operations to set up a call stack for the call) to the memory allocation. This pattern is characteristic of instantiation of an object in a binary code representation of a software module that was developed using the C++ programming language, where the call is a call to a constructor of the object. The memory address can then be used to track use of the object by operations within the binary code. That is, operations performed using the memory address (directly or indirectly using relative offsets from the memory address) can be said to be operations applied to the object. Said differently, operations within the binary code that use the memory address as an operand are performed on the object. Thus, an object analysis system implementing process 100 can monitor use of the object by monitoring use of an identifier such as a memory address associated with instantiation of the object.”;
for address offset:
[0038]”Security vulnerabilities can arise from indirect operations, for example, when no verification is made a run-time that the data that is the subject of the operation is valid data for the operation”;
[0040] As an example of another security vulnerability, an indirect call operation can take a memory address and an offset value as operands, and call a function that is referenced by a function pointer located at a memory location referenced by a memory address defined by a value stored at the memory address operand offset by the offset value times the size of a function pointer.
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 (i.e., changing from AIA to pre-AIA ) 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.
Claims 1-10 are rejected under 35 U.S.C. 103 as being unpatentable over Yoo et al : NPL : “Recovery of Object-Oriented Features from C++ Binaries” in view of Dewey et al US20130227693A1.
As per claim 1, Yoo discloses a method, the method comprising:
restoring at least one class and an inheritance relationship of the at least one class by analyzing a binary code of the object-oriented programming language:
section IV: A- Virtual function call and RTTI discovery:
“All (100%) of the classes can be recovered as well as their names. The class hierarchy is reconstructed by utilizing RTTI. For each polymorphic class, an RTTI structure containing information about its parents is emitted by the compiler. The complete polymorphic class hierarchy can then be reconstructed by examining all RTTI structures found earlier. The layout of RTTI structures is defined by the ABI [4] that is used by the C++ compiler. RTTI structures can be parsed, thus yielding the complete polymorphic class hierarchy exactly as it was in the source C++ program even from stripped binaries.”;
recognizing a layout of the at least one class by using the at least one class and the inheritance relationship:
section IV: A- Virtual function call and RTTI discovery:
“The complete polymorphic class hierarchy can then be reconstructed by examining all RTTI structures found earlier. The layout of RTTI structures is defined by the ABI [4] that is used by the C++ compiler. RTTI structures can be parsed, thus yielding the complete polymorphic class hierarchy exactly as it was in the source C++ program even from stripped binaries.”;
But not explicitly
The method for detecting a type confusion bug of a binary code target of an object- oriented programming language using a processor of a computing device
and detecting the type confusion bug by using the layout of the at least one class:
Wherein the binary code target is an unmodified commodity binary for which source code is unavailable and no compiler-inserted runtime type instrumentation or type metadata is present
Dewey discloses:
The method for detecting a type confusion bug of a binary code target of an object- oriented programming language using a processor of a computing device:
[0012]”For example, implementations discussed herein can identify security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.”
and detecting the type confusion bug by using the layout of the at least one class:
[0019]” This pattern is characteristic of instantiation of an object in a binary code representation of a software module that was developed using the C++ programming language, where the call is a call to a constructor of the object. The memory address can then be used to track use of the object by operations within the binary code.”
Wherein the binary code target is an unmodified commodity binary for which source code is unavailable and no compiler-inserted runtime type instrumentation or type metadata is present:
[0035]” the analyses discussed herein can be performed without access to source code of the software module or debugging information that may or may not be included in the binary code representation of the software module.”;
Examiner interpretation:
the, implementations can identify objects and attributes such as a size thereof without referring to (or independent of) source code or explicit information about such objects which may or may not be included in the binary code[0011].
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Dewey into teachings of Yoo and Istvan to enable analyzing operations in a binary code to identify the object using an object analysis system by inferring a structure of the object based on operations described in the binary code, so that the system can identify the object and attributes such as size of the object, easily without referring to a source code or explicit information about the objects. For example, implementations discussed herein can identify and prevent security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.[0012] .
As per claim 2, the rejection of claim 1 is incorporated and furthermore Yoo discloses:
extracting at least one virtual function table for each of at least one polymorphic class ,recognizing a constructor and a destructor for each of the at least one polymorphic class by using the at least one virtual function table, and restoring the inheritance relationship of the at least one class through an overwrite analysis using the constructor and the destructor.
section IV: B. Discovery of Classes
Now that we have detected constructors and destructors, we can identify their classes by examining how objects of these classes are created in the binary code. This can provide us with hints on identifying them from the disassembly. Here are three types of objects that C++ creates.1) Global Object. Global objects, as the name implies, are objects declared as global variables. Memory spaces for these objects are allocated at compile-time and are placed in the data segment of the binary. The constructor for global objects is implicitly called before main(), during C++ startup, and the destructor is called at the program exit. To identify a possible global object, we first recognize the register containing the this pointer, which in the example above is ecx since it contains a pointer to a global variable. Then Then we look for a function called with the this pointer discovered above as an argument. To locate the constructor and destructor, we have to examine cross-references to this global variable. We look for locations where this variable is passed as the first argument to a function call, since the this pointer is always passed as the first argument to constructors. If this call lies between the path from program entry point and main(), it is the constructor.
As per claim 3, the rejection of claim 1 is incorporated and furthermore Yoo discloses:
wherein the constructor is a method used when the object is generated in the at least one class, and the destructor is a method used when the object is destructed in the at least one class:
section IV: B- Discovery of classes:
“In order to detect classes, we first need to detect their constructors and destructors. Constructors and destructors are detected by checking the operations they perform. A constructor of a class performs the following sequence of operations: it first calls constructors of direct base classes; second it calls constructors of data members; third it initializes vtable (virtual function table) pointer field(s); and fourth it performs userspecified initialization code in the body of the constructor. Conversely, a destructor deinitializes the object in the exact reverse order to how it was initialized”;
As per claim 4, the rejection of claim 1 is incorporated and furthermore Yoo discloses:
wherein the recognizing of the layout of the at least one class by using the at least one class and the inheritance relationship includes recognizing a size of each of the at least one class, and recognizing the layout of the at least one class by using the size of each of the at least one class and the inheritance relationship:
Section IV: C. Class, Member Functions and Variables Recovery: Identifying class members is straight-forward. We can identify class member variables by looking for accesses to offsets relative to the this parameter in the method in question. We can also identify virtual function members by looking for indirect calls to pointers located at offsets relative to this object’s virtual function table. Non-virtual member functions can be identified by checking if the this pointer is passed as a hidden parameter to the function call. To make sure that this is indeed a member function, we can check if the called function uses ecx without first initializing it.
As per claim 5, the rejection of claim 4 is incorporated and furthermore Yoo discloses:
wherein the recognizing of the size of each of the at least one class includes recognizing a start offset for the at least one class from a register of a CPU, recognizing the size of the object of the at least one class to recognize an end offset for the at least one class, and recognizing the size of each of the at least one class by using the start offset and the end offset:
Section IV: C. Class, Member Functions and Variables Recovery: Identifying class members is straight-forward. We can identify class member variables by looking for accesses to offsets relative to the this parameter in the method in question. We can also identify virtual function members by looking for indirect calls to pointers located at offsets relative to this object’s virtual function table. Non-virtual member functions can be identified by checking if the this pointer is passed as a hidden parameter to the function call. To make sure that this is indeed a member function, we can check if the called function uses ecx without first initializing it.
As per claim 6, the rejection of claim 1 is incorporated and furthermore Yoo does not explicitly disclose:
executing at least one normal binary code to identify at least one target area for the object related to the at least one class, and detecting the type confusion bug of the binary code based on the target area:
Dewey discloses:
executing at least one normal binary code to identify at least one target area for the object related to the at least one class, and detecting the type confusion bug of the binary code based on the target area:
[0042] A processor executing the indirect call operation at run-time may interpret the data at the memory location referenced by the indirect call operation as a function pointer (or memory address), and attempt to execute instructions at the memory location pointed to by that data when interpreted as a memory address. This can result in memory access violations, arbitrary code execution, execution of injected code, and/or other undesirable behavior.
[0012] “For example, implementations discussed herein can identify security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Dewey into teachings of Yoo to enable analyzing operations in a binary code to identify the object using an object analysis system by inferring a structure of the object based on operations described in the binary code, so that the system can identify the object and attributes such as size of the object, easily without referring to a source code or explicit information about the objects. For example, implementations discussed herein can identify and prevent security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.[0012] .
As per claim 7, the rejection of claim 6 is incorporated and furthermore Yoo does not explicitly disclose:
determining whether an assembly instruction accesses an object stored in a memory when the assembly instruction of the at least one normal binary code accesses the memory:
recognizing an address of an access target when it is determined that the assembly instruction accesses the object stored in the memory recognizing an offset of the object by calculating a difference value between the address of the access target and a start point of the object:
and identifying the target area for the offset of the object by using the offset of the object and the layout of the at least one class.
Dewey discloses:
determining whether an assembly instruction accesses an object stored in a memory when the assembly instruction of the at least one normal binary code accesses the memory:
[0019]” module that was developed using the C++ programming language, where the call is a call to a constructor of the object. The memory address can then be used to track use of the object by operations within the binary code. That is, operations performed using the memory address (directly or indirectly using relative offsets from the memory address) can be said to be operations applied to the object. Said differently, operations within the binary code that use the memory address as an operand are performed on the object. Thus, an object analysis system implementing process 100 can monitor use of the object by monitoring use of an identifier such as a memory address associated with instantiation of the object.”;
recognizing an address of an access target when it is determined that the assembly instruction accesses the object stored in the memory recognizing an offset of the object by calculating a difference value between the address of the access target and a start point of the object:
[0029] “As yet another example of determining a size of an object, an object analysis system can identify and catalog each unique offset value from the memory address of the object used by data access operations within binary code of a software module. Each unique offset value from the memory address of the object can identify a property of the object. In other words, to access a property of an object, a data store operation can include as operands the memory address of the object and an offset to that property.”;
and identifying the target area for the offset of the object by using the offset of the object and the layout of the at least one class.
[0032] “Accordingly, an object analysis system can use the memory addresses of memory locations that are accessed independent of the memory address of the object or a dispatch table to determine the bounds of the object or the dispatch table. That is, the object analysis system can determine a size of the object by finding a difference between a memory address of the object (or a dispatch table of the object) and memory addresses near that memory address that are operands to operations that do not include (explicitly or implicitly) the memory address of the object (or an associated dispatch table) as an operand”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Dewey into teachings of Yoo to enable analyzing operations in a binary code to identify the object using an object analysis system by inferring a structure of the object based on operations described in the binary code, so that the system can identify the object and attributes such as size of the object, easily without referring to a source code or explicit information about the objects. For example, implementations discussed herein can identify and prevent security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.[0012] .
As per claim 8, the rejection of claim 6 is incorporated and furthermore Yoo does not explicitly disclose:
writing a memory address and a class type of a target object when a target binary is executed and a class constructor is called, and when access to the target object occurs, determining whether the type confusion bug occurs according to whether the target area related to the target object is present:
Dewey discloses:
writing a memory address and a class type of a target object when a target binary is executed and a class constructor is called, and when access to the target object occurs, determining whether the type confusion bug occurs according to whether the target area related to the target object is present:
[0037] Indirect operations defined within the binary code are then identified at block 220. Indirect operations are operations that accept or have as an operand a reference (or pointer), offset, or combination thereof that points to data. Rather than operate on or with that reference and/or offset, indirect operations (or a processor executing indirect operations) operate of the data to which that reference or offset points (or refers). An operation can be identified as indirect explicitly (e.g., based on operation or machine code identifiers) or implicitly (e.g., based on syntax or operands of the operation). In other words, an object analysis system can interpret operations described in binary code to determine which operations are indirect operations. Indirect operations are identified at block 220 to identify potential security vulnerabilities in a software module.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Dewey into teachings of Yoo to enable analyzing operations in a binary code to identify the object using an object analysis system by inferring a structure of the object based on operations described in the binary code, so that the system can identify the object and attributes such as size of the object, easily without referring to a source code or explicit information about the objects. For example, implementations discussed herein can identify and prevent security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.[0012] .
As per claim 9, the rejection of claim 8 is incorporated and furthermore Yoo does not explicitly disclose:
wherein when the access to the target object occurs, the determining of whether the type confusion bug is generated according to whether the target area related to the target object is present includes when the target area related to the target object is not present in the written class type, determining that the type confusion bug is generated.
Dewey discloses:
wherein when the access to the target object occurs, the determining of whether the type confusion bug is generated according to whether the target area related to the target object is present includes when the target area related to the target object is not present in the written class type, determining that the type confusion bug is generated.
[0041] “That is, for the memory address of object A as the memory address operand, an offset of 0x00 would result in a call to the function referenced by the first function pointer of the dispatch table reference by object A. Similarly, for the memory address of object A as the memory address operand, an offset of 0x01 would result in a call to the function referenced by the second function pointer of the dispatch table reference by object A. However, because there are only two function pointers at the dispatch table reference by object A, an offset of 0x02 results in the indirect call operation accessing data that is beyond (or outside) object A”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Dewey into teachings of Yoo to enable analyzing operations in a binary code to identify the object using an object analysis system by inferring a structure of the object based on operations described in the binary code, so that the system can identify the object and attributes such as size of the object, easily without referring to a source code or explicit information about the objects. For example, implementations discussed herein can identify and prevent security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.[0012].
As per claim 10, Yoo discloses a method for detecting a type confusion bug of a binary code target of an object-oriented programming language using a processor of a computing device, the method comprising::
restoring at least one class and an inheritance relationship of the at least one class by analyzing a binary code of the object-oriented programming language:
section IV: A- Virtual function call and RTTI discovery:
“All (100%) of the classes can be recovered as well as their names. The class hierarchy is reconstructed by utilizing RTTI. For each polymorphic class, an RTTI structure containing information about its parents is emitted by the compiler. The complete polymorphic class hierarchy can then be reconstructed by examining all RTTI structures found earlier. The layout of RTTI structures is defined by the ABI [4] that is used by the C++ compiler. RTTI structures can be parsed, thus yielding the complete polymorphic class hierarchy exactly as it was in the source C++ program even from stripped binaries.”;
recognizing a layout of the at least one class by using the at least one class and the inheritance relationship:
section IV: A- Virtual function call and RTTI discovery:
“The complete polymorphic class hierarchy can then be reconstructed by examining all RTTI structures found earlier. The layout of RTTI structures is defined by the ABI [4] that is used by the C++ compiler. RTTI structures can be parsed, thus yielding the complete polymorphic class hierarchy exactly as it was in the source C++ program even from stripped binaries.”;
wherein recognizing the layout includes recognizing a size of each of the at least one class:
Section IV: C. Class, Member Functions and Variables Recovery: Identifying class members is straight-forward. We can identify class member variables by looking for accesses to offsets relative to the this parameter in the method in question. We can also identify virtual function members by looking for indirect calls to pointers located at offsets relative to this object’s virtual function table. Non-virtual member functions can be identified by checking if the this pointer is passed as a hidden parameter to the function call. To make sure that this is indeed a member function, we can check if the called function uses ecx without first initializing it.
But not explicitly:
executing at least one normal binary code to identify at least one target area for an object related to the at least one class, wherein identifying the at least one target area includes; determining whether an assembly instruction accesses the object stored in a memory;
recognizing an address of an access target when the assembly instruction accesses the object stored in the memory;
recognizing an offset of the object by calculating a difference value between the address of the access target and a start point of the object; and
identifying the target area for the offset of the object by using the offset of the object and the layout of the at least one class:
detecting the type confusion bug of the binary code based on the target area:
wherein detecting the type confusion bug includes: writing a memory address and a class type of a target object when a target binary is executed and a class constructor is called;
when access to the target object occurs, determining that the type confusion bug is generated when the target area related to the target object is not present.
Dewey discloses:
executing at least one normal binary code to identify at least one target area for an object related to the at least one class, wherein identifying the at least one target area includes:
[0042] A processor executing the indirect call operation at run-time may interpret the data at the memory location referenced by the indirect call operation as a function pointer (or memory address), and attempt to execute instructions at the memory location pointed to by that data when interpreted as a memory address. This can result in memory access violations, arbitrary code execution, execution of injected code, and/or other undesirable behavior.
[0012] “For example, implementations discussed herein can identify security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.”;
determining whether an assembly instruction accesses the object stored in a memory;
[0019]” module that was developed using the C++ programming language, where the call is a call to a constructor of the object. The memory address can then be used to track use of the object by operations within the binary code. That is, operations performed using the memory address (directly or indirectly using relative offsets from the memory address) can be said to be operations applied to the object. Said differently, operations within the binary code that use the memory address as an operand are performed on the object. Thus, an object analysis system implementing process 100 can monitor use of the object by monitoring use of an identifier such as a memory address associated with instantiation of the object.”;
recognizing an address of an access target when the assembly instruction accesses the object stored in the memory; recognizing an offset of the object by calculating a difference value between the address of the access target and a start point of the object; and
[0029] “As yet another example of determining a size of an object, an object analysis system can identify and catalog each unique offset value from the memory address of the object used by data access operations within binary code of a software module. Each unique offset value from the memory address of the object can identify a property of the object. In other words, to access a property of an object, a data store operation can include as operands the memory address of the object and an offset to that property.”;
identifying the target area for the offset of the object by using the offset of the object and the layout of the at least one class:
[0032] “Accordingly, an object analysis system can use the memory addresses of memory locations that are accessed independent of the memory address of the object or a dispatch table to determine the bounds of the object or the dispatch table. That is, the object analysis system can determine a size of the object by finding a difference between a memory address of the object (or a dispatch table of the object) and memory addresses near that memory address that are operands to operations that do not include (explicitly or implicitly) the memory address of the object (or an associated dispatch table) as an operand”;
detecting the type confusion bug of the binary code based on the target area:
[0042] A processor executing the indirect call operation at run-time may interpret the data at the memory location referenced by the indirect call operation as a function pointer (or memory address), and attempt to execute instructions at the memory location pointed to by that data when interpreted as a memory address. This can result in memory access violations, arbitrary code execution, execution of injected code, and/or other undesirable behavior.
[0012] “For example, implementations discussed herein can identify security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.”;
wherein detecting the type confusion bug includes: writing a memory address and a class type of a target object when a target binary is executed and a class constructor is called;
[0037] Indirect operations defined within the binary code are then identified at block 220. Indirect operations are operations that accept or have as an operand a reference (or pointer), offset, or combination thereof that points to data. Rather than operate on or with that reference and/or offset, indirect operations (or a processor executing indirect operations) operate of the data to which that reference or offset points (or refers). An operation can be identified as indirect explicitly (e.g., based on operation or machine code identifiers) or implicitly (e.g., based on syntax or operands of the operation). In other words, an object analysis system can interpret operations described in binary code to determine which operations are indirect operations. Indirect operations are identified at block 220 to identify potential security vulnerabilities in a software module.
when access to the target object occurs, determining that the type confusion bug is generated when the target area related to the target object is not present.
[0041] “That is, for the memory address of object A as the memory address operand, an offset of 0x00 would result in a call to the function referenced by the first function pointer of the dispatch table reference by object A. Similarly, for the memory address of object A as the memory address operand, an offset of 0x01 would result in a call to the function referenced by the second function pointer of the dispatch table reference by object A. However, because there are only two function pointers at the dispatch table reference by object A, an offset of 0x02 results in the indirect call operation accessing data that is beyond (or outside) object A”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Dewey into teachings of Yoo to enable analyzing operations in a binary code to identify the object using an object analysis system by inferring a structure of the object based on operations described in the binary code, so that the system can identify the object and attributes such as size of the object, easily without referring to a source code or explicit information about the objects. For example, implementations discussed herein can identify and prevent security vulnerabilities such as type confusion vulnerabilities that can result in arbitrary code execution, code injection, application failure, or other undesirable or unintended behavior of an application using information about objects identified by analysis of operations described in binary code.[0012].
Pertinent arts:
US20210200546A1:
preventing type confusion in object-oriented programming languages by checking the type of the supplied object storage when invoking a method.
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRAHIM BOURZIK whose telephone number is (571)270-7155. The examiner can normally be reached Monday-Friday (8-4:30).
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, Wei Y Mui can be reached on 571-270-2738. 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.
/BRAHIM BOURZIK/Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights