Identifying active code sections via memory forensics

Abstract

A system of identifying an executed code section of a software process, the system comprising a processing circuitry (PC) configured to: access a memory space of a first process executing in an operating environment; identify, from contents of the memory space, a software framework of the first process; find, in the memory space, based on the identified software framework, a first code section description structure; identify, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; and determine, based on a value of the associated CSEI, whether the first code section has been executed.

Description

[0001] IDENTIFYING ACTIVE CODE SECTIONS VIA MEMORY FORENSICS

[0002] TECHNICAL FIELD

[0003] The presently disclosed subject matter relates to computer security, and in particular to implementation of systems of identifying active code sections of computer software.

[0004] BACKGROUND

[0005] Problems of identification of active code sections of computer software in realtime have been recognized in the conventional art and various techniques have been developed to provide solutions.

[0006] BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to understand the invention and to see how it can be carried out in practice, embodiments will be described, by way of non-limiting examples, with reference to the accompanying drawings, in which:

[0008] Fig. 1 illustrates a flow diagram of an example method of dynamic loading and unloading of software of a managed software framework, in accordance with some embodiments of the presently disclosed subject matter;

[0009] Figs. 2A-2B illustrate example generalized logical structures that can be present in managed software frameworks, in accordance with some embodiments of the presently disclosed subject matter;

[0010] Fig. 3A illustrates an example memory map of a node.js process, in accordance with some embodiments of the presently disclosed subject matter;

[0011] Fig. 3B illustrates an example memory map of a Java process, in accordance with some embodiments of the presently disclosed subject matter;

[0012] Fig- 4 illustrates a logical block diagram of an example system adapted for constructing a software runtime bill-of-materials (RBOM) using memory forensics, in accordance with some embodiments of the presently disclosed subject matter; Fig- 5 illustrates a flow diagram of an example method of identifying executed software modules of an application executing in a managed software framework, in accordance with some embodiments of the presently disclosed subject matter;

[0013] Fig- 6 illustrates flow diagram of an example method of constructing a software RBOM based on file access times, in accordance with some embodiments of the presently disclosed subject matter;

[0014] Fig- 7 illustrates example memory layouts of an executable file and process memory, which can be usable in a stack probing-based method of determining a software RBOM, in accordance with some embodiments of the presently disclosed subject matter;

[0015] Fig. 8 illustrates a flow diagram of an example stack probing-based method of constructing a software RBOM, in accordance with some embodiments of the presently disclosed subject matter;

[0016] Figs. 9A, 9B, and 9C illustrate an example logical structure of a process utilizing a Python software framework, in accordance with some embodiments of the presently disclosed subject matter; and

[0017] Fig. 10 illustrates a flow diagram of an example method of detecting whether a software process has executed a particular code section, in accordance with some embodiments of the presently disclosed subject matter.

[0018] GENERAL DESCRIPTION

[0019] According to one aspect of the presently disclosed subject matter there is provided a system of identifying an executed code section of a software process, the system comprising a processing circuitry configured to: a. access a memory space of a first process executing in an operating environment; b. identify, from contents of the memory space, a software framework of the first process; c. find, in the memory space, based on the identified software framework, a first code section description structure; d. identify, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; and e. determine, based on a value of the associated CSEI, whether the first code section has been executed.

[0020] In addition to the above features, the system according to this aspect of the presently disclosed subject matter can comprise one or more of features (i) to (xv) listed below, in any desired combination or permutation which is technically possible:

[0021] (i) the PC is additionally configured to: f. add, to a software runtime bill-of-materials (RBOM), a code section identifier of the first code section, the code section identifier being based on the first code section description structure.

[0022] (ii) the PC is additionally configured to: g. repeat c. - f. for one or more additional code section description structures.

[0023] (iii) the PC is additionally configured to: h. responsive to an event, repeat a.-g. for one or more additional iterations.

[0024] (iv) the PC is additionally configured to: repeat a. - g. for one or more additional processes executing in the operating environment.

[0025] (v) the event is an expiry of a delay (vi) the PC is additionally configured to, subsequent to e. : identify, in the memory space, based on the identified software framework, an unloaded code section log structure; determine, based on identifying one or more code section identifiers in the unloaded code section log structure, that respective code sections have been executed.

[0026] (vii) the PC is additionally configured to: adding the identified one or more code section identifiers to the RBOM.

[0027] (viii) the code section identifier is selected from a group consisting of: a. a module name, b. a module path, c. a file path, d. a class name, e. a function name, f. a function signature, g. a method name, h. a method signature, i. a namespace, j. a scope, k. a file name, l. a file name with a starting line number, and m. a file name with a starting line number and ending line number.

[0028] (ix) the CSEI is based on at least one of a group consisting of: a. a value of a pointer, identified from the code section description structure, to data or instructions of the first code section; b. contents of a memory address that is written to by the first code section; c. a value of a data field, identified from the code section description structure, indicative of whether code of the first code section has been cached; d. a value of a data field, identified from the code section description structure, indicative of whether a data object associated with the first code section has been cached; e. a value of a data field, identified from the code section description structure, utilized by a virtual machine for code use profiling, and f. a value of a data field, identified from the code section description structure, used by a virtual machine for profiling indicating a count of invocations of the first code section.

[0029] (x) the software framework is Java and the unloaded code section log structure is UnloadingEventLog

[0030] (xi) the PC is configured to, responsive to determining that the software framework is Java, utilize a methodCounters field of a Methods structure as CSEI.

[0031] (xii) the PC is configured to, responsive to determining that the software framework is node.js, utilize a function data field of a SharedFunctionlnfo structure as CSEI. (xiii) the PC is configured to, responsive to determining that the software framework is node.js, utilize a function data field of a SharedFunctionlnfo structure as CSEI

[0032] (xiv) the PC is configured to, responsive to determining that the software framework is Ruby, utilize a flags field of a rb_method_entry_t structure as CSEI.

[0033] (xv) the PC is configured to, responsive to determining that the software framework is Ruby, utilize a total calls field of a rb_iseq_constant_body structure as CSEI.

[0034] According to another aspect of the presently disclosed subject matter there is provided a processing circuitry-based method of identifying an executed code section of a software process, the method comprising: a. accessing a memory space of a first process executing in an operating environment; b. identifying, from contents of the memory space, a software framework of the first process; c. finding, in the memory space, based on the identified software framework, a first code section description structure; d. identifying, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; and e. determining, based on a value of the associated CSEI, whether the first code section has been executed. This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (xv) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0035] According to another aspect of the presently disclosed subject matter there is provided a computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of determining a software runtime bill-of-materials (RBOM) of an operating environment, the method comprising: a. accessing a memory space of a first process executing in an operating environment; b. identifying, from contents of the memory space, a software framework of the first process; c. finding, in the memory space, based on the identified software framework, a first code section description structure; d. identifying, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; and e. determining, based on a value of the associated CSEI, whether the first code section has been executed.

[0036] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (xv) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible. According to one aspect of the presently disclosed subject matter there is provided a system of determining a software runtime bill-of-materials (RBOM) of an operating environment, the system comprising a processing circuitry configured to: a. identify a first software process executing in the operating environment; b. determine, from data or metadata of a file associated with the first software process, a software framework of the first software process; c. for each of one or more runnable files located in the operating environment and associated with the identified software framework: i. determine, from metadata associated with the runnable file, a respective time of most recent access of the runnable file, ii. responsive to the respective time of most recent access of the runnable file being later than a start time of the first software process: adding a respective file path of the runnable file to the RBOM.

[0037] In addition to the above features, the system according to this aspect of the presently disclosed subject matter can comprise one or more of features (i) to (iv) listed below, in any desired combination or permutation which is technically possible:

[0038] (i) the processing circuitry is further configured to perform the determination of the software framework based on at least one of: a) a path of a file run by the first software process; and b) metadata of the file run by the first software process. (ii) the processing circuitry is further configured to: d. repeat a.-c. for one or more additional processes executing in the operating environment.

[0039] (iii) the processing circuitry is further configured to: e. responsive to an event, repeat a.-d. for one or more additional iterations.

[0040] (iv) the event is an expiration of a delay.

[0041] According to another aspect of the presently disclosed subject matter there is provided a processing circuitry-based method of determining a software bill-of-materials (RBOM) of an operating environment, the method comprising: a. accessing a memory space of a first process executing in the operating environment; b. for one or more threads of the first process: i. reading contents of one or more memory locations of a thread stack associated with the respective thread, ii. determining whether the contained value of a respective memory location is a code section execution address, and iii. responsive to the contained value of the respective memory location of the thread stack being a code section execution address: a) determining, based on the memory space of the first process and / or an executable file associated with the first process, a code section identifier associated with the code section, and b) adding the code section identifier associated with the code section to the RBOM.

[0042] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (iv) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0043] According to another aspect of the presently disclosed subject matter there is provided a computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of determining a software runtime bill-of-materials (RBOM) of an operating environment, the method comprising: a. identifying a first software process executing in the operating environment; b. determining, from data or metadata of a file associated with the first software process, a software framework of the first software process; c. for each of one or more runnable files located in the operating environment and associated with the identified software framework: i. determining, from metadata associated with the runnable file, a respective time of most recent access of the runnable file, ii. responsive to the respective time of most recent access of the runnable file being later than a start time of the first software process: adding a respective file path of the runnable file to the RBOM. This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (iv) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0044] According to one aspect of the presently disclosed subject matter there is provided a system of determining a software bill-of-materials (RBOM) of an operating environment, the system comprising a processing circuitry configured to: a. access a memory space of a first process executing in the operating environment; b. for one or more threads of the first process: i. read contents of one or more memory locations of a thread stack associated with the respective thread, ii. determine whether the contained value of a respective memory location is a code section execution address, and iii. responsive to the contained value of the respective memory location of the thread stack being a code section execution address: a) determine, based on the memory space of the first process and / or an executable file associated with the first process, a code section identifier associated with the code section, and b) add the code section identifier associated with the code section to the RBOM.

[0045] In addition to the above features, the system according to this aspect of the presently disclosed subject matter can comprise one or more of features (i) to (iv) listed below, in any desired combination or permutation which is technically possible: (i) the processing circuitry is further configured to perform the determining the code section identifier based on one or more of: a) a symbol table of the executable file; b) a debug section of the executable file; c) a program database associated with the executable file; and d) an abstract syntax tree derivative of one or more source code files associated with the executable file.

[0046] (ii) the processing circuitry is further configured to: c. repeat a.-b. for one or more additional processes executing in the operating environment.

[0047] (iii) the processing circuitry is further configured to: d. responsive to an event, repeat a.-c. for one or more additional iterations.

[0048] (iv) the event is an expiration of a delay

[0049] According to another aspect of the presently disclosed subject matter there is provided a processing circuitry-based method of determining a software bill-of-materials (RBOM) of an operating environment, the method comprising: a) accessing a memory space of a first process executing in the operating environment; b) for one or more threads of the first process: i. reading contents of one or more memory locations of a thread stack associated with the respective thread, ii. determining whether the contained value of a respective memory location is a code section execution address, and iii. responsive to the contained value of the respective memory location of the thread stack being a code section execution address: a) determining, based on the memory space of the first process and / or an executable file associated with the first process, a code section identifier associated with the code section, and b) adding the code section identifier associated with the code section to the RBOM.

[0050] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (iv) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0051] According to another aspect of the presently disclosed subject matter there is provided a computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of determining a software bill-of-materials (RBOM) of an operating environment, the method comprising: a. accessing a memory space of a first process executing in the operating environment; b. for one or more threads of the first process: i. reading contents of one or more memory locations of a thread stack associated with the respective thread, ii. determining whether the contained value of a respective memory location is a code section execution address, and iii. responsive to the contained value of the respective memory location of the thread stack being a code section execution address: a) determining, based on the memory space of the first process and / or an executable file associated with the first process, a code section identifier associated with the code section, and b) adding the code section identifier associated with the code section to the RBOM.

[0052] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (iv) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0053] According to one aspect of the presently disclosed subject matter there is provided a system of identifying an executed code section of a software process, the system comprising a processing circuitry (PC) configured to: a. access a memory space of a first process executing in an operating environment; b. identify, from contents of the memory space, a software framework of the first process; c. find, in the memory space, based on the identified software framework, a first code section description structure; d. identify, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; and e. determine, based on a value of the associated CSEI, whether the first code section has been executed.

[0054] In addition to the above features, the method according to this aspect of the presently disclosed subject matter can comprise one or more of features (i) to (xxiii) listed below, in any desired combination or permutation which is technically possible:

[0055] (i) the PC is additionally configured to: f. add, to a software runtime bill-of-materials (RBOM), a code section identifier of the first code section, the code section identifier being based on the first code section description structure.

[0056] (ii) the PC is additionally configured to: g. repeat c. - f. for one or more additional code section description structures.

[0057] (iii) the PC is additionally configured to: h. responsive to an event, repeat a.-g. for one or more additional iterations.

[0058] (iv) the PC is additionally configured to: repeat a. - g. for one or more additional processes executing in the operating environment.

[0059] (v) the event is an expiration of a delay.

[0060] (vi) the PC is additionally configured to, subsequent to e. : identify, in the memory space, based on the identified software framework, an unloaded code section log structure; determine, based on identifying one or more code section identifiers in the unloaded code section log structure, that respective code sections have been executed.

[0061] (vii) the PC is additionally configured to: adding the identified one or more code section identifiers to the RBOM.

[0062] (viii) the code section identifier is based one or more of: a. a module name, b. a module path, c. a file path, d. a class name, e. a function name, f. a function signature, g. a method name, Y1 h. a method signature, i. a namespace, j. a scope, k. a file name, l. a starting line number, and m. an ending line number.

[0063] (ix) the memory space is a memory snapshot.

[0064] (x) the memory snapshot is partial.

[0065] (xi) the memory snapshot is of a currently executing process.

[0066] (xii) the memory snapshot is of a previously executing process.

[0067] (xiii) the PC is configured to access file-mapped memory regions of the memory space, thereby finding the first code section description structure.

[0068] (xiv) the PC is further configured to find, in the memory space, a binary signature associated with the first code section description structure or a predecessor structure thereof, thereby facilitating the finding of the first code section description structure.

[0069] (xv) the PC is further configured to find, in an executable file associated with the memory space, a symbol associated with the first code section description structure or a predecessor structure thereof, thereby facilitating the finding of the first code section description structure.

[0070] (xvi) the CSEI is based on at least one of a group consisting of: a. a value of a pointer, identified from the code section description structure, to data or instructions of the first code section; b. contents of a memory address that is written to by the first code section; c. a value of a data field, identified from the code section description structure, indicative of whether code of the first code section has been cached; d. a value of a data field, identified from the code section description structure, indicative of whether a data object associated with the first code section has been cached; e. a value of a data field, identified from the code section description structure, utilized by a virtual machine for code use profiling; and f. a value of a data field, identified from the code section description structure, indicating a count of invocations of the first code section.

[0071] (xvii) the software framework is Java and the unloaded code section log structure is UnloadingEventLog.

[0072] (xviii) the PC is configured to, responsive to determining that the software framework is Java, utilize a methodCounters field of a Methods structure as CSEI.

[0073] (xix) the PC is configured to, responsive to determining that the software framework is node.js, utilize a function data field of a SharedFunctionlnfo structure as CSEI.

[0074] (xx) the PC is configured to, responsive to determining that the software framework is Ruby, utilize a flags field of a rb_method_entry_t structure as CSEI.

[0075] (xxi) the PC is configured to, responsive to determining that the software framework is Ruby, utilize a total calls field of a rb_iseq_constant_body structure as CSEI. (xxii) the PC is configured to, responsive to determining that the software framework is Python, utilize one or more of: a. co zombieframe, b. co opcache flag, and c. co warmup, of a PyCodeObject structure as CSEI.

[0076] (xxiii) the PC is configured to, responsive to determining that the software framework is Python, utilize, as CSEI, a counter field of a cache structure, wherein the cache structure is associated with a []_Py_CODEUNIT entry of a PyCodeObject structure.

[0077] According to another aspect of the presently disclosed subject matter there is provided a processor-based method of identifying an executed code section of a software process, the method comprising: a. accessing a memory space of a first process executing in an operating environment; b. identifying, from contents of the memory space, a software framework of the first process; c. finding, in the memory space, based on the identified software framework, a first code section description structure; d. identifying, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; and e. determining, based on a value of the associated CSEI, whether the first code section has been executed.

[0078] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (xxiii) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0079] According to another aspect of the presently disclosed subject matter there is provided a computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of identifying an executed code section of a software process, the method comprising, the method comprising: a. accessing a memory space of a first process executing in an operating environment; b. identifying, from contents of the memory space, a software framework of the first process; c. finding, in the memory space, based on the identified software framework, a first code section description structure; d. identifying, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; and e. determining, based on a value of the associated CSEI, whether the first code section has been executed.

[0080] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (xxiii) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible. According to another aspect of the presently disclosed subject matter there is provided a system of identifying an executed code section of a software process, the system comprising a processing circuitry (PC) configured to: f. identify one or more functions defined in a software object associated with an executing process; g. for each of the one or more identified functions: i. identify a memory address range associated with the respective identified function, and ii. responsive to determining that the executing process accessed the respective identified memory address range: add, to a software runtime bill-of-materials (RBOM), a code section identifier of the respective identified function, the code section identifier being based on, at least, a function name of the respective identified function.

[0081] In addition to the above features, the method according to this aspect of the presently disclosed subject matter can comprise one or more of features (i) to (xiv) listed below, in any desired combination or permutation which is technically possible:

[0082] (i) the processing circuitry (PC) is further configured to: iii. responsive to determining that the executing process has not accessed the respective identified memory address range: log, to a system log, a code section identifier of the respective identified function, the code section identifier being based on, at least, a function name of the respective identified function.

[0083] (ii) the processing circuitry (PC) is further configured to repeat a. - c. periodically.

[0084] (iii) the processing circuitry (PC) is further configured to repeat a. - c. for one or more additional software objects associated with the executing process.

[0085] (iv) the identifying the memory address range is based on, at least, one or more of: a. a symbol table; b. a debug section; c. an associated program database; and d. an abstract syntax tree derivative of one or more associated source code files; of an executable software object or a dynamically loaded software object.

[0086] (v) the PC is configured to determine whether the executing process accessed the respective identified memory address range based on, at least: a page presence flag of an operating system pagemap entry associated with the respective identified memory address range.

[0087] (vi) the PC is configured to determine whether the executing process accessed the respective identified memory address range based on, at least: one or more metadata flags of an operating system memory page metadata vector associated with the respective identified memory address range. (vii) the PC is configured to determine whether the executing process accessed the respective identified memory address range based on, at least, at least one of:

[0088] ACTIVE, LRU, REFERENCED, and / or MMAP bits of a Linux kpageflags vector.

[0089] (viii) the PC is configured to determine whether the executing process accessed the respective identified memory address range based on, at least: an access flag of a page table entry (PTE) associated with the respective identified memory address range.

[0090] (ix) the PC is configured to determine that the executing process did not access the respective identified memory address range based on, at least: an access flag of a page directory structure associated with the respective identified memory address range.

[0091] (x) the PC is configured to identify one or more functions defined in the software object, wherein the one or more functions comprises one or more in-line functions.

[0092] (xi) the memory space is a memory snapshot.

[0093] (xii) the memory snapshot is partial.

[0094] (xiii) the memory snapshot is of a currently executing process.

[0095] (xiv) the memory snapshot is of a previously executing process. According to another aspect of the presently disclosed subject matter there is provided a processor-based method of identifying an executed code section of a software process, the method comprising: a. identifying one or more functions defined in a software object associated with an executing process; b. for each of the one or more identified functions: i. identifying a memory address range associated with the respective identified function, and ii. responsive to determining that the executing process accessed the respective identified memory address range: adding, to a software runtime bill-of-materials (RBOM), a code section identifier of the respective identified function, the code section identifier being based on, at least, a function name of the respective identified function.

[0096] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (xiv) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0097] According to another aspect of the presently disclosed subject matter there is provided computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of runtime identification of identifying an executed code section of a software process, the method comprising: a. identifying one or more functions defined in a software object associated with an executing process; b. for each of the one or more identified functions: i. identifying a memory address range associated with the respective identified function, and ii. responsive to determining that the executing process accessed the respective identified memory address range: adding, to a software runtime bill-of-materials (RBOM), a code section identifier of the respective identified function, the code section identifier being based on, at least, a function name of the respective identified function.

[0098] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (xiv) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0099] DETAILED DESCRIPTION

[0100] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the presently disclosed subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the presently disclosed subject matter.

[0101] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as “processing”, “computing”, “comparing”, “reading”, “writing”, “detecting”, “determining”, “calculating”, “receiving”, “providing”, “obtaining”, “emulating” or the like, refer to the action(s) and / or process(es) of a computer that manipulate and / or transform data into other data, said data represented as physical, such as electronic, quantities and / or said data representing the physical objects. The term “computer” should be expansively construed to cover any kind of hardware-based electronic device with data processing capabilities including, by way of non-limiting example, the processor, mitigation unit, and inspection unit therein disclosed in the present application.

[0102] The terms "non-transitory memory” and “non-transitory storage medium” used herein should be expansively construed to cover any volatile or non-volatile computer memory suitable to the presently disclosed subject matter.

[0103] The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general-purpose computer specially configured for the desired purpose by a computer program stored in a non- transitory computer-readable storage medium.

[0104] Embodiments of the presently disclosed subject matter are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the presently disclosed subject matter as described herein.

[0105] Ensuring security of modern computer systems can be a time-consuming and cumbersome task. In particular, ensuring that software components are updated and properly configured, - and in particular in response to security alerts - can require substantial organizational resources. It is noted that a computer system can include large numbers of software modules which are rarely or never invoked. Accordingly, it can be valuable to know which software code sections of an operational computer system are in fact in active use, and to prioritize the security maintenance of relevant modules or packages.

[0106] A list of currently active software modules can be termed “software bill-of- materials” (SBOM) or “runtime software bill-of-materials” (RBOM). Example systems and methods for constructing an RBOM - and example use cases - are described in United States Patent Application No. 17 / 813,220 “Computer system enabled with runtime software module tracking”, which is hereby incorporated by reference.

[0107] Some embodiments of the presently disclosed subject matter identify active (software functions, modules, object classes, “basic blocks” or other specific sections of code (e.g. as denoted by a source code filename and start line / end line), or other types of code sections. Some embodiments of the presently disclosed subject matter utilize the determined active code section information to construct an RBOM. Some methods described herein apply to specific types of operating environments or software frameworks, as will be described hereinbelow. Some embodiments of the presently disclosed subject matter utilize appropriate methods for different environments or frameworks, and thereby generate a combined RBOM.

[0108] As used herein, “active” code sections include code sections that are currently being executed or were executed on the current system (e.g. executed since system initialization, executed since a particular event, executed within a particular time frame). The term “managed software framework” is herein interpreted to include a system provided within an operating system (e.g. Microsoft™ Windows™, Linux™, Android™ etc.) which utilizes e.g. an interpreter or a virtual machine to execute code written in a particular language such as Java, Python, node.js etc.

[0109] Fig- 1 illustrates a flow diagram of an example method of dynamic loading and unloading of software code sections (e.g. functions) that can be executed by a managed software framework, in accordance with some embodiments of the presently disclosed subject matter.

[0110] A managed framework can load 105 a code section (for example: a function or software module) of an application into memory space (for example: in preparation for invocation by a currently executing module). In particular, there can be a type of code section description structure loaded into memory. As the application executes, invocations of the code section of course affect 110 contents of the memory. In the present disclosure, memory locations (or structure fields) which predictably change due to processor invocation of a particular function (or module or other code section) are termed “code section execution indications” (CSEIs).

[0111] As will be discussed in detail below, some embodiments of the presently disclosed subject matter access memory of running processes, and utilize the code section execution indications to detect which code sections (e.g. functions, modules etc.) are active. Using this method, it is possible to maintain an RBOM (e.g. a function-granular RBOM, module-granular RBOM, or basic-block granular RBOM) as will be described in detail below.

[0112] Code section execution indications can include, by way of non-limiting example, the Java MethodCounters field (of the Method structure), or the node.js Function pointer (of the FunctionsHolder structure), as will be described below.

[0113] In some managed software frameworks (for example: recent versions of Java), the managed framework can - responsive to e.g. lack of use of the function or due to memory reclamation, unload 115 code section data from memory. Some such frameworks (e.g. Java) log 120 an indication of this unloading into a memory structure. The term “unloaded code section log” is herein interpreted to include such a memory structure including indications of unloading of code sections.

[0114] Figs. 2A-2B illustrate generalized logical structures that can be present in implementations of managed software frameworks, in accordance with some embodiments of the presently disclosed subject matter.

[0115] Fig. 2A illustrates a process memory 205, which can include one or more memory sections 210 (i.e. portions of the memory available to a monitoring process). A memory section can include a framework-specific code section holder structure 220.

[0116] Fig. 2B illustrates an example code section holder structure 220, which includes one or more pointers 225A 225B 225C to respective code section description structure instances 235. A code section description structure instance can include e.g. code section name (e.g. function name, module name, module path, file path, class name, function signature, source file name with or without starting line number and / or ending line number etc.) 240A 240B 240C, code section execution indication field 245A 245B 245C, code section address 250A 250B 250C, and code section metadata 255A 255B 255C.

[0117] It is noted that the code section holder and code section descriptor structures can be divided among multiple structures, or integrated with other structures, and that fields therein can be encoded in various manners. It is further noted that these structures might not be present in some managed software frameworks.

[0118] It is noted that the term “code section description structure” is interpreted to include a data structure (or group of data structures) enabling access to, at least, a code section identifier (e.g. function name, function signature, source file name with line offset, scope etc.) and an associated execution indication field. In this context, the term “scope” is interpreted to include a region of code where a code section identifier is visible and can be invoked. The scope defines the accessibility and lifetime of a code section identifier within a program.

[0119] Fig. 3A illustrates an example memory map of a node.js process, in accordance with some embodiments of the presently disclosed subject matter.

[0120] Process memory 305A can include one or more isolates 310A. An isolate can be an instance of node.js structures. Each isolate can include its own node.js scripts and methods.

[0121] Each isolate can include respective pointers (direct or indirect) to one or more scripts 325A located in a scriptlist 320A structure. Each script 325A can include a pointer to a script. js object 330A, which in turn can include a pointer to an array of pointers to SharedFunctionlnfo structures 335A. Each SharedFunctionlnfo structure 340A can contain function name and parameter info, as well as a “function data” property 345A.

[0122] The function data property 345A can be a pointer that can point to multiple types of objects. If the function data property 345A points at a structure of type “UncompiledData” 350A, then the function has not been recently executed, whereas the function data property points at a structure of a different type in a case where the function has been recently executed.

[0123] Fig. 3B illustrates an example memory map of a Java process, in accordance with some embodiments of the presently disclosed subject matter.

[0124] Process memory 305B can include a Metaspace 310B region, which in turn can contain instances of the Klasslnstance structure 315B. Instances of the Klasslnstance structure 315B can include an array of pointers to Symbol structures (which in turn can contain function signature data). Instances of the Klasslnstance structure 315B can also include an array of pointers 320B to Method structures 325B. Method structures 325B can include pointers which lead back to Symbol structures 330B (including the function signature data), and can also include function execution addresses and metadata.

[0125] This metadata can include the MethodCounters 335B field, which is a field that can be used by the Java framework to profile system performance. As will be described below, some embodiments of the presently disclosed subject matter utilize the MethodCounters field for identification of active code sections, and optionally for RBOM construction.

[0126] Fig- 4 illustrates a logical block diagram of an example system adapted for constructing an RBOM using memory forensics, in accordance with some embodiments of the presently disclosed subject matter.

[0127] Processing circuitry 405 can include a processor 410 and memory 415.

[0128] Processor 410 can be a suitable hardware-based electronic device with data processing capabilities, such as, for example, a general purpose processor, digital signal processor (DSP), a specialized Application Specific Integrated Circuit (ASIC), one or more cores in a multicore processor, etc. Processor 410 can also consist, for example, of multiple processors, multiple ASICs, virtual processors, combinations thereof etc.

[0129] Memory 415 can be, for example, a suitable kind of volatile and / or non-volatile storage, and can include, for example, a single physical memory component or a plurality of physical memory components. Memory 415 can also include virtual memory. Memory 415 can be configured to, for example, store various data used in computation.

[0130] Processing circuitry 405 can be configured to execute several functional modules in accordance with computer-readable instructions implemented on a non-transitory computer-readable storage medium. Such functional modules are referred to hereinafter as comprised in the processing circuitry. These modules can include, for example, operating system 420, RBOM construction module 425, and processes 430.

[0131] RBOM construction module 425 can be e.g. a process executing within operating system 420. RBOM construction module 425 can execute methods such as those described hereinbelow, thereby determining e.g. which software code sections are active (e.g. currently executing, recently executed, or executed within some time frame or since some event). RBOM construction module 425 can optionally use this determined information to create a list of active software modules ie. a “runtime software bill-of- materials” (RBOM).

[0132] Fig- 5 illustrates a flow diagram of an example method of identifying executed code sections of an application executing in a managed software framework, in accordance with some embodiments of the presently disclosed subject matter.

[0133] It is noted that the method illustrated in Fig. 5 can be utilized as part of determining a RBOM for a process executing within a managed software framework.

[0134] It is noted that the method illustrated in Fig. 5 can determine which software modules are active (i.e. have been executed), for utilization in security, management, or other purposes.

[0135] Processing circuitry 405 (RBOM construction module 425) can perform the method repeatedly, on multiple processes, determining which processes utilize a managed software framework, and in this manner generate e.g. a partial system RBOM i.e. a list of code sections invoked by applications utilizing managed frameworks (such as Java, node.js, Python etc.). Processing circuitry 405 (RBOM construction module) can begin construction of an RBOM by accessing 505 memory of an executing process. By way of non-limiting example: on a Linux™ system, the processing circuitry 405 (e.g. RBOM construction module 425) can access a file located in / proc / <PID> / maps, where <PID> is a process identifier. Fig- 2 illustrates an example layout of process memory. By way of nonlimiting example: on a Windows™ system, the processing circuitry 405 (e.g. RBOM construction module 425) can utilize ReadProcessMemoryQ, which enables a process to read memory of a different process. Alternatively, another method of accessing process memory can be utilized. In other types of systems, a suitable method of accessing process memory can be utilized. It is noted that in some embodiments, processing circuitry 405 (RBOM construction module) can access a full or partial snapshot of the process memory at a particular time (e.g. a dump of a currently executing process, or of a previously executing process).

[0136] It is noted that in some examples, process memory can include file-mapped memory regions (i.e. portions of process memory that are stored e.g. on disk or drive media rather than e.g. random access memory). In some embodiments, processing circuitry 405 (RBOM construction module) can access these file-mapped memory regions.

[0137] Processing circuitry 405 (RBOM construction module 425) can next detect 510 the software framework of the currently analyzed process. Methods for detecting the software framework of a process can involve identification of framework-specific memory structures, shared libraries, or interpreters, or other techniques as known in the art. In some managed software frameworks (e.g. Java, node.js, python), a virtual machine, client, or interpreter or the like can be part of each application process, and can manage e.g. application functions or modules in accordance with the scheme described above, with reference to Fig. 1.

[0138] Processing circuitry 405 (RBOM construction module 425) can now, based on the detected software framework, locate 515 an instance of a code section description structure within process memory. As described above, a code section description structure can be a software structure (or group of structures) which specifies data pertaining to code section (e.g. function, module, basic block etc.) invocation. By way of non-limiting example, this data can include: code section name (e.g. function name etc.)

[0139] Function parameters and return value type (in the case of a function) Execution address

[0140] Metadata

[0141] Processing circuitry 405 (e.g. RBOM construction module 425) can locate one or more instances of code section description structures in a framework-specific manner.

[0142] For example, in a node.js process, as illustrated above with reference to Fig. 3A, processing circuitry 405 (e.g. RBOM construction module 425) can - by way of nonlimiting example - first identify an isolate structure within process memory (as known in the art), and successively locate the roots table, script list, script.) s, and SharedFunctionlnfo structures 340A. SharedFunctionlnfo structures 340A can thus be regarded as code section description structures (alone or in combination with other structures).

[0143] Similarly, in a Java process, as illustrated above with reference to Fig. 3B, processing circuitry 405 (e.g. RBOM construction module 425) can - by way of nonlimiting example - first identify a Metaspace 310B structure within process memory 305B (as known in the art), and successively locate the Klasslnstance structure 315B, Array<Method> pointer structure 320B, and finally the Method structures 325B. Method structures 325B can thus be regarded as examples of code section description structures (alone or in combination with other structures).

[0144] It is further noted that in a Ruby process, a structure rb method entry t can maintain a Flags property, which in turn can contain multiple sub-properties. In some examples, the “METHOD ENTRY C ACHED” bit (the 21th bit, (bit mask 0x100000) ) is either on or off in the flags property.

[0145] The structure rb method entry t can thus be regarded as an example code section description structure. Processing circuitry 405 (e.g. RBOM construction module 425) can, by way of non-limiting example, detect if the function was executed by checking if the “METHOD ENTRY CACHED” bit is on or off in the flags property. In some examples, “METHOD ENTRY C ACHED” is the 21th bit, (bit mask 0x100000)

[0146] Processing circuitry 405 (e.g. RBOM construction module 425) can - by way of non-limiting example - evaluate whether the mathematical term: flags & 0x100000 is non-zero,and if so can infer the code section was executed.

[0147] It is further noted that if Ruby “just-in-time” (JIT) is enabled, rb method entry t can contain a pointer to a chain of structures which eventually reaches a “rb_iseq_constant_body” structure., A rb_iseq_constant_body structure can have the property “total calls” indicating the number of times the function was called (similar to the Java example above). The structure rb method entry t can thus also be regarded as an example code section description structure.

[0148] In a Python process, as illustrated below with reference to Figs. 9A-9C, processing circuitry 405 (e.g. RBOM construction module 425) can - by way of nonlimiting example - first identify a PyRuntimeState structure within process memory (as known in the art), and successively locate structures (e.g. pyinterpreters, PyinterpreterState, PyDictObject etc) that enable location of PyCodeObject instances. The successively located structures are herein termed “predecessor structures”.

[0149] PyCodeObject instances can include fields co warmpup indicative of whether a function has been executed. Thus PyCodeObject can be utilized as a code section description structure (alone or in combination with other structures)..

[0150] []_Py_CODEUNIT table entries can include cache structures which can in turn include counters indicative of whether a function has been executed. Thus a []_Py_CODEUNIT table can be utilized as a code section description structure (alone or in combination with other structures). It is noted that the examples of code section description structures are non-limiting, and are likely to change in subsequent versions of these software frameworks. Processing circuitry 405 (e.g. RBOM construction module) can next locate 520 a code section execution indicator (CSEI) associated with a code section descriptor structure (i.e. associated with a function, basic block, or module instance etc).

[0151] Generally: processing circuitry 405 (e.g. RBOM construction module 425) can use various methods to locate code section description structures in memory.

[0152] By way of non-limiting example: processing circuitry 405 (e.g. RBOM construction module 425) can - as described above for various frameworks 0 find, in the memory space, a symbol associated with the first code section description structure or a predecessor structure thereof, thereby facilitating the finding of the first code section description structure.

[0153] By way of further non-limiting example: processing circuitry 405 (e.g. RBOM construction module 425) can find, in the memory space, a binary pattern (i.e. “signature”) associated with the first code section description structure or a predecessor structure thereof, thereby facilitating the finding of the first code section description structure. As described above with reference to Fig. 1, managed software frameworks include data structures (termed CSEIs) that processing circuitry 405 (e.g. RBOM construction module 425) can monitor to determine if code sections have been executed.

[0154] For example, in a node.js process, processing circuitry 405 (e.g. RBOM construction module 425) can - by way of non-limiting example - read a function data pointer from the sharedFunctionlnfo structure 330A (i.e. function data is the CSEI). If the function data pointer points to a structure that is not of type “UncompiledData”, then a function has been executed, and has thus been identified as active.

[0155] By way for further non-limiting example: in a Java process, processing circuitry 405 (e.g. RBOM construction module 425) can read MethodCounters 335B from the Method structure 325B (i.e. MethodCounters is the CSEI). The Java environment utilizes MethodCounters 335B to monitor the extent of utilization of the function, for purposes of performance profiling. If the value of MethodCounters 335B is greater than 0, then the function has been executed, and has thus been identified as active. By way for further non-limiting example: in a Ruby process, processing circuitry 405 (e.g. RBOM construction module 425) can -evaluate whether the mathematical term: flags (of the rb method entry t structure ) & 0x100000 is non-zero,and if so can infer the code section was executed and can thus been identified as active.

[0156] By way for further non-limiting example: in a Ruby process, processing circuitry 405 (e.g. RBOM construction module 425) can -evaluate whether the mathematical term: flags (of the rb method entry t structure ) & 0x100000 is non-zero,and if so can infer the code section was executed and can thus been identified as active.

[0157] By way for further non-limiting example: in a Ruby process, processing circuitry 405 (e.g. RBOM construction module 425) can, determine if total calls of a rb method entry t structure is non-zero, and if so can infer that the code section was executed.

[0158] By way for further non-limiting example: in a Python process of certain versions, processing circuitry 405 (e.g. RBOM construction module 425) can, determine if co zombieframe of a PyCodeObject structure is non-zero, and if so can infer that the code section was executed.

[0159] By way for further non-limiting example: in a Python process of certain versions, processing circuitry 405 (e.g. RBOM construction module 425) can, determine if co opcache flag of a PyCodeObject structure is non-zero, and if so can infer that the code section was executed.

[0160] By way for further non-limiting example: in a Python process of certain versions, processing circuitry 405 (e.g. RBOM construction module 425) can, determine if warmup of a PyCodeObject structure is a value other than 0xfff8, and if so can infer that the code section was executed.

[0161] By way for further non-limiting example: in a Python process of certain versions, processing circuitry 405 (e.g. RBOM construction module 425) can, determine if a counter field of a cache structure is non-zero, wherein the cache structure is associated with a []_Py CODEUNIT entry of a PyCodeObject structure and if so can infer that the code section was executed.

[0162] It is noted that the examples of CSEIs are non-limiting, and are likely to change in subsequent versions of these software frameworks.

[0163] Having determined that a code section has been executed, processing circuitry 405 (e.g. RBOM construction module 425) can determine code section identifier data from the code section description structure. Code section identifier data can include, for example: a name or other identifier of the code section, and in some examples (e.g. object-oriented languages) also the function parameters and return value type.

[0164] By way of non-limiting example: in node.js, processing circuitry 405 (e.g. RBOM construction module 425) can access the function name directly from the sharedFunctionlnfo structure 330A.

[0165] By way of further non-limiting example: in Java, processing circuitry 405 (e.g. RBOM construction module 425) can access the ConstMethod field of the Method structure, and follow pointers to access the Symbol structure (which contains the function signature data), as illustrated in Fig. 2B.

[0166] Processing circuitry 405 (e.g. RBOM construction module 425) can then optionally add the code section identifier data to the RBOM.

[0167] Processing circuitry 405 (e.g. RBOM construction module 425) can repeat 530 these steps to identify additional code section descriptor structures in the process memory space, detect whether they have been utilized, and if so to add the code section identifier data to the RBOM.

[0168] Optionally: processing circuitry 405 (e.g. RBOM construction module 425) can access a structure in the process memory that logs when code sections have been unloaded from memory (termed unloaded code sections log above), and identify 535 any such unloaded code sections, thereby determining that they may have been active. Processing circuitry 405 (e.g. RBOM construction module 425) can assume that the code was active, and write code section identifier data associated with the unloaded code sections to the RBOM.

[0169] Processing circuitry 405 (e.g. RBOM construction module 425) can (optionally) delay for a delay period, or until an occurrence of an event, and then perform the steps of the method again, so as to detect subsequently executed code sections of the process, and then optionally add these to the RBOM.

[0170] Fig- 6 illustrates a flow diagram of an example method of constructing a software RBOM based on file access times, in accordance with some embodiments of the presently disclosed subject matter.

[0171] The method illustrated in Fig. 6 can be applicable to processes utilizing an application framework which performs on-demand runtime access of code files (e.g. Python). In the present description, the term “runnable files” is interpreted to include files which are executed (e.g executable files resulting from a compilation process), as well as files of scripting languages or intermediate format files which are run e.g. on virtual machines or via interpreters (e.g. Python, Node.js etc.)

[0172] Processing circuitry (e.g. RBOM construction module 425) can begin by identifying 605 the software framework of a running process. Processing circuitry (e.g. RBOM construction module 425) can do this, for example, from observing the data or metadata of a file associated with the running process. By way of non-limiting example, processing circuitry (e.g. RBOM construction module 425) can examine e.g. the contents, file path, file extension, or file metadata of the runnable file. For example: if the process was initialized by running the command “foo.py”, then processing circuitry (e.g. RBOM construction module 425) can infer that the process is based on Python. Alternatively, processing circuitry (e.g. RBOM construction module 425) can identify the software framework from a different file (e.g. memory, as described above), or utilizing a different method.

[0173] Next, processing circuitry (e.g. RBOM construction module 425) can examine 610 file metadata indicative of file access times (e.g. times of most recent file reads as maintained by a file system) of runnable files associated with the framework. For example: in the case of Python, processing circuitry (e.g. RBOM construction module 425) can examine most recent file access times for all Python library files (or all Python libraries files potentially usable by the process).

[0174] When processing circuitry (e.g. RBOM construction module) finds a file with an access time more recent than e.g. the start time of process, processing circuitry (e.g. RBOM construction module 425) can add 615 the filepath to the RBOM.

[0175] Processing circuitry (RBOM construction module 425) can perform the method repeatedly, on multiple processes, and in this manner (or in conjunction with other methods described hereinabove) generate a full or partial system RBOM i.e. a list of files or code sections invoked by applications.

[0176] Fig- 7 illustrates example memory layouts of an executable file and process memory, which can be usable in a stack probing-based method of constructing a software RBOM, in accordance with some embodiments of the presently disclosed subject matter.

[0177] Executable file 710 can be a file that resides on a storage medium of a computer, and that is executed, for example, via a command line instruction. In some embodiments, executable file 710 can be Executable and Linkable Format (ELF) file.

[0178] Executable file 710 can include a .symtbl section 730, which in turn can include a symbol table 715. The symbol table 715 can contain a series of table entries 735A 735B 735C, where each table entry can include data indicative of a function signature, function metadata, and a memory pointer that represents an offset of the start address of function code 745A 745B 745C in the execution memory region (i.e. “.text” section 740 of process memory).

[0179] Process memory 720 can include a stack memory section 750, which in turn can include a number of thread stacks 755A 755B 755C. A thread stack can include data describing a series of nested function calls, where each nested function has placed data and a callback address on the stack. In some examples, a thread stack is an operating system based structure such as a Linux thread. In some other examples, a thread stack is a software framework-specific structure enabling multiprocessing, such as (for example) a “goroutine” of the Go language. In some embodiments of the presently disclosed subject matter, processing circuitry (e.g. RBOM construction module) can monitor these structures to construct an RBOM, as described below.

[0180] Fig- 8 illustrates a flow diagram of an example stack probing-based method of constructing a software RBOM, in accordance with some embodiments of the presently disclosed subject matter.

[0181] The RBOM construction method illustrated in Fig. 8, can - in some embodiments - be applied across a variety of software frameworks (including, for example, compiled and interpreted applications). In particular, in some embodiments, this method is suited for use with compiled languages such as C and C++.

[0182] Processing circuitry 405 (e.g. RBOM construction module 425) can perform the method repeatedly, on multiple processes, and in this manner (or in conjunction with other methods described hereinabove) generate a full or partial system RBOM i.e. a list of functions invoked by applications.

[0183] Processing circuitry 405 (e.g. RBOM construction module 425) can access 805 a memory space of a process. Processing circuitry 405 (RBOM construction module 425) can access the memory space, for example, in the manner described for managed software frameworks as described above with reference to Fig. 4, or by another suitable method

[0184] Processing circuitry 405 (e.g. RBOM construction module 425) can next select 810 a thread of the process, and access the associated thread stack (for example: as illustrated in Fig. 7)

[0185] Processing circuitry 405 (e.g. RBOM construction module 425) can then scan 815 one or more memory addresses (for example: all memory addresses) in the stack, and determine, for each memory address, whether the contained value of the memory contents is a pointer to executable code (i.e. a callback address) of a code section which e.g. invoked a function. Processing circuitry 405 (e.g. RBOM construction module 425) can perform this determination by - for example - obtaining, from the operating system, the starting memory address of a region in which the executable function code is stored. This region is herein termed the “execution memory region”.

[0186] Processing circuitry 405 (e.g. RBOM construction module 425) can then access a symbol table of the executable file from which the process was initiated. A symbol table can indicate function signature data, together with values that indicate offset locations of functions in the execution memory region. By way of non-limiting example: in a LinuxTmsystem, processing circuitry 405 (e.g. RBOM construction module 425) can access one or more of: a main symbol table (e.g. .symtab of an ELF file), a dynamic symbol table (.dynsym), debug sections (such as ,debug_line, ,debug_loc) etc. By way of non-limiting example: in a Windows1™ system, processing circuitry 405 (e.g. RBOM construction module 425) can utilize an appropriate mechanism such as program database (PDB) files. In some examples, processing circuitry 405 (e.g. RBOM construction module 425) utilizes an abstract syntax tree (AST) derived from one or more source code files associated with the executable file. ASTs are described in, for example, “On Matching Binary to Source Code” by Arash Shahkar (2016) |(

[0187] Accordingly, processing circuitry 405 (RBOM construction module 425) can utilize awareness of the location of the execution memory region and the function offsets, and determine whether the contents of the stack memory is pointing at instructions that are part of a specific code section (e.g. a function, a part of a function, or a class or module including a function etc.).

[0188] When a function is identified, processing circuitry 405 (e.g. RBOM construction module 425) can determine 820 the function signature data from the symbol table, and add 825 it to the RBOM. To identify a different granularity of code section, processing circuitry 405 (e.g. RBOM construction module 425) can, for example, utilize data from the symbol table to identify a function, and then access e.g. a data structure describing e.g. a class or module or larger code section including the function, and can determine a code section identifier from the appropriate data structure. Alternatively, processing circuitry 405 (e.g. RBOM construction module 425) can, for example, utilize data from the symbol table to access an identifier of a smaller code section (e.g. a particular source file and line number).

[0189] Processing circuitry 405 e.g. (e.g. RBOM construction module 425) can optionally repeat 830 the steps for one or more additional threads / thread stacks of the process (for example: all thread stacks of the process).

[0190] Processing circuitry 405 (e.g. RBOM construction module 425) can periodically repeat the entire series of steps, so as to obtain wide coverage of the functions being invoked in the process.

[0191] Figs. 9A, 9B, and 9C illustrate an example logical structure of a process utilizing a Python software framework, in accordance with some embodiments of the presently disclosed subject matter.

[0192] A Python runtime executable file 905 can contain a symbol table 910. The symbol table can include an entry for a symbol corresponding to teh Python main runtime function (“ PyRuntime”) and an associated memory offset. Processing circuitry 405 (e.g. SBOM construction module) can utilize this memory offset to locate, in a given instance of Python process 915, a PyRuntime variable which can point to a PyRuntimeState structure.

[0193] The PYRuntimeState structure can include a pyinterpreters structure, which in turn can include a pointer to a linked list of PYinterpreter State structures. PYInterpreterState, in turn, can include a “dictionary” named SysDict. SysDict can contain a key named “modules”, and the value of the key can point to another dictionary (“sys. modules”).

[0194] 'The “sys. modules" dictionary can point toward multiple PyModuleObjects

[0195] A Py ModuleObject instance can contain data describing a Python module: e.g. a module name, a module path, and PyFunctionObject structures - which describe a particular Python function. The PyFunctionObject can include a func code pointer, which in turn can point at a PyCodeObject of (for example) a particular Python version. PyCodeObject can be an object of a particular code type used in Python (e.g, Lambda, function, decorator etc.) These PyFunctionObjects can - in some embodiments - include fields or structures that processing circuitry 405 (e.g. SBOM construction module) can examine to determine whether the associated Python function has in fact been executed.

[0196] In a PyCodeObject for Python 3.6-3.7, the co zombie frame field can be a CSEI, i.e., if the co zombie frame field is non-zero, the associated Python function object has been executed. In a PyCodeObject of type Python 3.8-3.10, the co opcache flag field can similarly act as CSEI. In a PyCodeObject of type Python 3.11, the co warmup field can serve as CSEI (e.g. a value of 0xfff8 can indicate that the function has not been executed)..

[0197] A PyCodeObject can include a co code adaptive field, which can be a pointer to an entry in a py code unit table. In some versions of Python, each entry of the py code unit table can include data pertaining to an opcode, as well as a cache pointer, which can point to various cache types and structs, as illustrated. The cache pointer can serve as CSEI, that is to say, if any entry of the py code unit table has a cache pointer that is non-null, the process has executed the associated function code.

[0198] Fig. 10 illustrates a flow diagram of an example method of detecting whether a software process has executed a particular code section, in accordance with some embodiments of the presently disclosed subject matter.

[0199] The method of Fig. 10 can be suitable - for example - for utilization on software objects derivative of compiled languages (e.g. C, C++, Go etc.)

[0200] Processing circuitry 405 (e.g., SBOM construction module 425) can access a symbol table of a software object associated with the process, 1005. The symbol table can include e.g. function names and variable names utilized in the process, and can provide memory offsets associated with each symbol e.g. function or variable). These offsets can indicate a memory address in the memory space of an executing process where the function code (or variable storage) will be located. Processing circuitry 405 (e.g., SBOM construction module 425) can access a symbol table e.g in an Executable Linkable Format (ELF) file (or equivalent) from which a process was initiated, or in a shared (e.g. dynamically linked) library etc. that is utilized by the process.

[0201] Processing circuitry 405 (e.g., SBOM construction module 425) can next select 1010 a symbol from the symbol table that is associated with a code section (e.g. a function name), and determine its associated memory offset or memory range offset.

[0202] Processing circuitry 405 (e.g., SBOM construction module 425) can next determine 1015 whether the process has accessed data in the memory range associated with the code section. If processing circuitry 405 (e.g., SBOM construction module 425 has accessed the memory range, it can add the name of the function to the RBOM.

[0203] It is noted that in some examples, if processing circuitry 405 (e.g., SBOM construction module 425 has not accessed the memory range, processing circuitry 405 (e.g., SBOM construction module 425 can log - via a suitable mechanism - that the function was not accessed or was not executed. For example: processing circuitry 405 (e.g., SBOM construction module 425 can add the name of the function to the RBOM - together with an indication that the function was not accessed or was not executed.

[0204] It is noted that in some embodiments, processing circuitry 405 (e.g., SBOM construction module 425 can determine from a full or partial snapshot of the process memory at a particular time (e.g. a dump of a currently executing process, or of a previously executing process) whether the process accessed data in the memory range associated with the code section.

[0205] Processing circuitry 405 (e.g., SBOM construction module 425) can utilize various methods to determine whether the process has accessed the memory range associated with the function. For example:

[0206] Processing circuitry 405 (e.g., SBOM construction module 425) can utilize a “page presence” flag contained in pagemap data provided by an operating system. By way of non-limiting example: in Linux, processing circuitry 405 (e.g., SBOM construction module 425) can utilize the “page present” bit in a page in / proc / pid / pagemap. In other operating systems, equivalent or similar mechanisms can be utilized.

[0207] Processing circuitry 405 (e.g., SBOM construction module 425) can utilize one or more metadata flags of an operating system memory page metadata vector associated with the respective identified memory address range. By way of nonlimiting example: in Linux, processing circuitry 405 (e.g., SBOM construction module 425) can utilize ACTIVE, LRU, REFERENCED, and / or MMAP bits of a Linux kpageflags vector (i.e. from / proc / kpageflags). In other operating systems, equivalent or similar mechanisms can be utilized.

[0208] Processing circuitry 405 (e.g., SBOM construction module 425) can utilize an access flag of a page directory associated with the respective identified memory address range. By way of non-limiting example: in Linux, processing circuitry 405 (e.g., SBOM construction module 425) can - for a particular address of process virtual memory - traverse a sequence of hierarchical page directories, to arrive at an entry of a page table.

[0209] By way of non-limiting example: in an Intel™ x86-64 architecture, the common paging scheme is page map level 4 (PML4), which has:

[0210] Page global directory (Level 4) - Describes a 512 gigabyte (GB) region Page global directory (Level 3) - Describes 1GB region Page global directory - Describes 2 megabyte (MB) region Page table entries (Level 1) - Describes a single page (4 Kilobyte)

[0211] These page directory structures can include an bit (termed an access bit and named “Accessed” in some Linux documentation) indicating if the page directory structure has in fact been accessed. If the access bit indicates that no access has occurred, processing circuitry 405 (e.g., SBOM construction module 425) can halt traversal, as itis known that subsidiary tables (if present) are also unaccessed. In other operating systems, equivalent or similar mechanisms can be utilized. Processing circuitry 405 (e.g., SBOM construction module 425) can utilize an access flag of a page table entry (PTE) associated with the respective identified memory address range. By way of non-limiting example: in Linux, processing circuitry 405 (e.g., SBOM construction module 425) can - for a particular address of process virtual memory - traverse a sequence of hierarchical page directories, to arrive at an entry of a page table. The page table entry can include an control bit (termed an access bit and named “Accessed” in some Linux documentation) indicating if the page has in fact been accessed. In other operating systems, equivalent or similar mechanisms can be utilized.

[0212] Processing circuitry 405 (e.g., SBOM construction module 425) can next determine whether there are additional functions of interest in the symbol table, 1020. If so, processing circuitry 405 (e.g., SBOM construction module 425) can return to step 1010 and select the next function. If there are no additional functions of interest in the symbol table, processing circuitry 405 (e.g., SBOM construction module 425) can next determine if there are additional software objects of interest associated with the process, 1025. If so, it can return to step 1005 to access the symbol table of the additional software object.

[0213] It is noted that in some embodiments processing circuitry 405 (e.g., SBOM construction module 425) examines each code section (e.g. function) that it finds in the symbol table (or equivalent or similar structure). In some embodiments processing circuitry 405 (e.g., SBOM construction module 425) examines a subset of code sections (e.g. only code sections of interest).

[0214] It is noted that in some embodiments processing circuitry 405 (e.g., SBOM construction module 425) examines each software object associated with the process. In some embodiments processing circuitry 405 (e.g., SBOM construction module 425) examines a subset of software objects (e.g. only software objects of interest).

[0215] It is noted that processing circuitry 405 (e.g., SBOM construction module 425) can repeat the method of Fig. 10 periodically (e.g. in response to an event or timer expiration), so as to maintain up to date information about which code sections have been executed.

[0216] It is noted that processing circuitry 405 (e.g., SBOM construction module 425) can repeat the method of Fig. 10 for some or all additional processes in the system.

[0217] It is noted that processing circuitry 405 (e.g., SBOM construction module 425) can determine function names and associated memory offsets / memory range offsets by various methods other than (or in conjunction with) a symbol table.

[0218] By way of non-limiting example: processing circuitry 405 (e.g., SBOM construction module 425) can determine function names and associate memory offsets / memory range offsets based on one or more of: a symbol table of an executable software object or a dynamically loaded software object a debug section of an executable software object or a dynamically loaded software object an program database associated associated with an executable software object or a dynamically loaded software object an abstract syntax tree derivative of one or more source code files associated of an executable software object or a dynamically loaded software object

[0219] Accordingly, in the method described in Fig. 10, processing circuitry 405 (e.g., SBOM construction module 425) can utilize these and other suitable mechanisms of determining function names and associate memory offsets / memory range offsets.

[0220] It is noted that some programming languages (e.g. C) enable definition of “inline” functions i.e. functions that in some examples are included multiple times in an ELF file. Symbols representing inline functions can thus occur multiple times in a symbol table (or equivalent or similar structure). Processing circuitry 405 (e.g., SBOM construction module 425) can regard the memory of the code section as accessed, responsive to whether memory corresponding to any one of the multiple instances of the symbol table has been accessed. It is noted that a symbol table (or comparable structure) can associate a code section (e.g. function) with a range of memory addresses in process memory space, and that the address range can correspond to multiple pages of mapped memory. Accordingly, processing circuitry 405 (e.g., SBOM construction module 425) can regard the memory of the code section as accessed, responsive to whether any of the mapped memory pages have been accessed.

[0221] It is to be understood that the invention is not limited in its application to the details set forth in the description contained herein or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Hence, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. As such, those skilled in the art will appreciate that the conception upon which this disclosure is based may readily be utilized as a basis for designing other structures, methods, and systems for carrying out the several purposes of the presently disclosed subject matter.

[0222] It will also be understood that the system according to the invention may be, at least partly, implemented on a suitably programmed computer. Likewise, the invention contemplates a computer program being readable by a computer for executing the method of the invention. The invention further contemplates a non-transitory computer-readable memory tangibly embodying a program of instructions executable by the computer for executing the method of the invention.

[0223] Those skilled in the art will readily appreciate that various modifications and changes can be applied to the embodiments of the invention as hereinbefore described without departing from its scope, defined in and by the appended claims.

Claims

CLAIMS1. A system of identifying an executed code section of a software process, the system comprising a processing circuitry (PC) configured to: a. access a memory space of a first process executing in an operating environment; b. identify, from contents of the memory space, a software framework of the first process; c. find, in the memory space, based on the identified software framework, a first code section description structure; d. identify, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; and e. determine, based on a value of the associated CSEI, whether the first code section has been executed.

2. The system of claim 1, wherein the PC is additionally configured to: f. add, to a software runtime bill-of-materials (RBOM), a code section identifier of the first code section, the code section identifier being based on the first code section description structure.

3. The system of claim 2, wherein the PC is additionally configured to: g. repeat c. - f. for one or more additional code section description structures.

4. The system of claim 3, wherein the PC is additionally configured to: h. responsive to an event, repeat a.-g. for one or more additional iterations.

5. The system of claim 3, wherein the PC is additionally configured to: repeat a. - g. for one or more additional processes executing in the operating environment.

6. The system of claim 4, wherein the event is an expiration of a delay.

7. The system of claim 1, wherein the PC is additionally configured to, subsequent to e. : identify, in the memory space, based on the identified software framework, an unloaded code section log structure; determine, based on identifying one or more code section identifiers in the unloaded code section log structure, that respective code sections have been executed.

8. The system of claim 7, wherein the PC is additionally configured to: adding the identified one or more code section identifiers to the RBOM.

9. The system of claim 1, wherein the code section identifier is based one or more of: a. a module name, b. a module path, c. a file path, d. a class name,e. a function name, f. a function signature, g. a method name, h. a method signature, i. a namespace, j. a scope, k. a file name, l. a starting line number, and m. an ending line number.

10. The system of claim 1, wherein the memory space is a memory snapshot.

11. The system of claim 10, wherein the memory snapshot is partial.

12. The system of claim 10, wherein the memory snapshot is of a currently executing process.

13. The system of claim 10, wherein the memory snapshot is of a previously executing process.

14. The system of claim 1, wherein the PC is configured to access file-mapped memory regions of the memory space, thereby finding the first code section description structure.

15. The system of claim 1, wherein the PC is further configured to find, in the memory space, a binary signature associated with the first code section description structure or a predecessor structure thereof, thereby facilitating the finding of the first code section description structure.

16. The system of claim 1, wherein the PC is further configured to find, in an executable file associated with the memory space, a symbol associated with the first code section description structure or a predecessor structurethereof, thereby facilitating the finding of the first code section description structure.

17. The system of claim 1, wherein the CSEI is based on at least one of a group consisting of: a. a value of a pointer, identified from the code section description structure, to data or instructions of the first code section; b. contents of a memory address that is written to by the first code section; c. a value of a data field, identified from the code section description structure, indicative of whether code of the first code section has been cached; d. a value of a data field, identified from the code section description structure, indicative of whether a data object associated with the first code section has been cached; e. a value of a data field, identified from the code section description structure, utilized by a virtual machine for code use profiling; and f. a value of a data field, identified from the code section description structure, indicating a count of invocations of the first code section.

18. The system of claim 7, wherein the software framework is Java and the unloaded code section log structure is UnloadingEventLog.

19. The system of claim 17, wherein the PC is configured to, responsive to determining that the software framework is Java, utilize a methodCounters field of a Methods structure as CSEI.

20. The system of claim 17, wherein the PC is configured to, responsive to determining that the software framework is node.js, utilize a function data field of a SharedFunctionlnfo structure as CSEI.21 . The system of claim 17, wherein the PC is configured to, responsive to determining that the software framework is Ruby, utilize a flags field of a rb_method_entry_t structure as CSEI.

22. The system of claim 17, wherein the PC is configured to, responsive to determining that the software framework is Ruby, utilize a total calls field of a rb_iseq_constant_body structure as CSEI.

23. The system of claim 17, wherein the PC is configured to, responsive to determining that the software framework is Python, utilize one or more of: a. co zombieframe, b. co opcache flag, and c. co warmup, of a PyCodeObject structure as CSEI.

24. The system of claim 17, wherein the PC is configured to, responsive to determining that the software framework is Python, utilize, as CSEI, a counter field of a cache structure, wherein the cache structure is associated with a []_Py_CODEUNIT entry of a PyCodeObject structure.

25. A processing circuitry-based method of identifying an executed code section of a software process, the method comprising: a. accessing a memory space of a first process executing in an operating environment;b. identifying, from contents of the memory space, a software framework of the first process; c. finding, in the memory space, based on the identified software framework, a first code section description structure; d. identifying, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; and e. determining, based on a value of the associated CSEI, whether the first code section has been executed.

26. A computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of identifying an executed code section of a software process, the method comprising: a. accessing a memory space of a first process executing in an operating environment; b. identifying, from contents of the memory space, a software framework of the first process; c. finding, in the memory space, based on the identified software framework, a first code section description structure; d. identifying, from the first code section description structure, a code section execution indicator (CSEI) associated with a first code section; ande. determining, based on a value of the associated CSEI, whether the first code section has been executed.

27. A system of determining a software runtime bill-of-materials (RBOM) of an operating environment, the system comprising a processing circuitry configured to: a. identify a first software process executing in the operating environment; b. determine, from data or metadata of a file associated with the first software process, a software framework of the first software process; and c. for each of one or more runnable files located in the operating environment and associated with the identified software framework: i. determine, from metadata associated with the runnable file, a respective time of most recent access of the runnable file, and ii. responsive to the respective time of most recent access of the runnable file being later than a start time of the first software process: adding a respective file path of the runnable file to the RBOM.

28. The system of claim 27, wherein the processing circuitry is further configured to perform the determination of the software framework based on at least one of: a. a path of a file run by the first software process; and b. metadata of the file run by the first software process.

29. The system of claim 27, the processing circuitry being further configured to: d. repeat a.-c. for one or more additional processes executing in the operating environment.

30. The system of claim 29, wherein the processing circuitry is further configured to: d. responsive to an event, repeat a.-c. for one or more additional iterations.

31. The system of claim 30, wherein the event is an expiration of a delay.

32. A processing circuitry-based method of determining a software runtime bill-of-materials (RBOM) of an operating environment, the method comprising: a. identifying a first software process executing in the operating environment; b. determining, from data or metadata of a file associated with the first software process, a software framework of the first software process; and c. for each of one or more runnable files located in the operating environment and associated with the identified software framework: i. determining, from metadata associated with the runnable file, a respective time of most recent access of the runnable file, andii. responsive to the respective time of most recent access of the runnable file being later than a start time of the first software process: adding a respective file path of the runnable file to the RBOM.

33. A computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform of determining a software runtime bill-of-materials (RBOM) of an operating environment, the method comprising: a. identifying a first software process executing in the operating environment; b. determining, from data or metadata of a file associated with the first software process, a software framework of the first software process; and c. for each of one or more runnable files located in the operating environment and associated with the identified software framework: i. determining, from metadata associated with the runnable file, a respective time of most recent access of the runnable file, and ii. responsive to the respective time of most recent access of the runnable file being later than a start time of the first software process: adding a respective file path of the runnable file to the RBOM.

34. A system of determining a software bill-of-materials (RBOM) of an operating environment, the system comprising a processing circuitry configured to: a. access a memory space of a first process executing in the operating environment; b. for one or more threads of the first process: i. read contents of one or more memory location of a thread stack associated with the respective thread, ii. determine whether a contained value of a respective memory location is a code section execution address, and iii. responsive to the contained value of the respective memory location of the thread stack being a code section execution address: a) determine, based on the memory space of the first process and / or an executable file associated with the first process, a code section identifier associated with the code section, and b) add the code section identifier associated with the code section to the RBOM.

35. The system of claim 34, wherein the processing circuitry is further configured to perform the determining the code section identifier based on one or more of: a. a symbol table of the executable file; b. a debug section of the executable file;c. a program database associated with the executable file and d. an abstract syntax tree derivative of one or more source code files associated with the executable file.

36. The system of claim 35, wherein the processing circuitry is further configured to: e. repeat a.-b. for one or more additional processes executing in the operating environment.

37. The system of claim 36, wherein the processing circuitry is further configured to: f. responsive to an event, repeat a.-d. for one or more additional iterations.

38. The system of claim 37, wherein the event is an expiration of a delay.

39. A processing circuitry-based method of determining a software bill-of- materials (RBOM) of an operating environment, the method comprising: a. accessing a memory space of a first process executing in the operating environment; b. for one or more threads of the first process: i. reading contents of one or more memory locations of a thread stack associated with the respective thread, ii. determining whether a contained value of a respective memory location is a code section execution address, andiii. responsive to the contained value of the respective memory location of the thread stack being a code section execution address: a) determining, based on the memory space of the first process and / or an executable file associated with the first process, a code section identifier associated with the code section, and b) adding the code section identifier associated with the code section to the RBOM.

40. A computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of determining a software bill-of-materials (RBOM) of an operating environment, the method comprising: a. accessing a memory space of a first process executing in the operating environment; b. for one or more threads of the first process: i. reading contents of one or more memory locations of a thread stack associated with the respective thread, ii. determining whether a contained value of a respective memory location is a code section execution address, andiii. responsive to the contained value of the respective memory location of the thread stack being a code section execution address: a) determining, based on the memory space of the first process and / or an executable file associated with the first process, a code section identifier associated with the code section, and b) adding the code section identifier associated with the code section to the RBOM.

41. A system of identifying an executed code section of a software process, the system comprising a processing circuitry (PC) configured to: a. identify one or more functions defined in a software object associated with an executing process; b. for each of the one or more identified functions: i. identify a memory address range associated with the respective identified function, and ii. responsive to determining that the executing process accessed the respective identified memory address range: add, to a software runtime bill-of-materials (RBOM), a code section identifier of the respective identified function, the code section identifier being based on, at least, a function name of the respective identified function.

42. The system of claim 41, wherein the processing circuitry (PC) is further configured to: c. responsive to determining that the executing process has not accessed the respective identified memory address range: log, to a system log, a code section identifier of the respective identified function, the code section identifier being based on, at least, a function name of the respective identified function.

43. The system of claim 41, wherein the processing circuitry (PC) is further configured to repeat a. - c. periodically.

44. The system of claim 41, wherein the processing circuitry (PC) is further configured to repeat a. - c. for one or more additional software objects associated with the executing process.

45. The system of claim 41, wherein the identifying the memory address range is based on, at least, one or more of: a. a symbol table; b. a debug section; c. an associated program database; and d. an abstract syntax tree derivative of one or more associated source code files; of an executable software object or a dynamically loaded software object.

46. The system of claim 41, wherein the PC is configured to determine whether the executing process accessed the respective identified memory address range based on, at least:a page presence flag of an operating system pagemap entry associated with the respective identified memory address range.

47. The system of claim 41, wherein the PC is configured to determine whether the executing process accessed the respective identified memory address range based on, at least: one or more metadata flags of an operating system memory page metadata vector associated with the respective identified memory address range.

48. The system of claim 47, wherein the PC is configured to determine whether the executing process accessed the respective identified memory address range based on, at least, at least one of:ACTIVE, LRU, REFERENCED, and / or MMAP bits of a Linux kpageflags vector.

49. The system of claim 41, wherein the PC is configured to determine whether the executing process accessed the respective identified memory address range based on, at least: an access flag of a page table entry (PTE) associated with the respective identified memory address range.

50. The system of claim 41, wherein the PC is configured to determine that the executing process did not access the respective identified memory address range based on, at least: an access flag of a page directory structure associated with the respective identified memory address range.

51. The system of claim 41, wherein the PC is configured to identify one or more functions defined in the software object, wherein the one or more functions comprises one or more in-line functions.

52. The system of claim 41, wherein the memory space is a memory snapshot.

53. The system of claim 52, wherein the memory snapshot is partial.

54. The system of claim 52, wherein the memory snapshot is of a currently executing process.

55. The system of claim 52, wherein the memory snapshot is of a previously executing process.

56. A processor-based method of identifying an executed code section of a software process, the method comprising: a. identifying one or more functions defined in a software object associated with an executing process; b. for each of the one or more identified functions: i. identifying a memory address range associated with the respective identified function, and ii. responsive to determining that the executing process accessed the respective identified memory address range: adding, to a software runtime bill-of-materials (RBOM), a code section identifier of the respective identified function, the code section identifier beingbased on, at least, a function name of the respective identified function.

57. A computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of runtime identification of identifying an executed code section of a software process, the method comprising: a. identifying one or more functions defined in a software object associated with an executing process; b. for each of the one or more identified functions: i. identifying a memory address range associated with the respective identified function, and ii. responsive to determining that the executing process accessed the respective identified memory address range: adding, to a software runtime bill-of-materials (RBOM), a code section identifier of the respective identified function, the code section identifier being based on, at least, a function name of the respective identified function.

Images