Using entropy to prevent payload data from being included in code execution log data

Abstract

Using entropy to prevent inclusion of payload data in code execution log data. Some embodiments determine that a payload data item associated with code execution log data has entropy above a predetermined entropy threshold and identify the particular executable code that interacted with the payload data item. Some embodiments then take preventive action to exclude the payload data item from being included in execution records of the particular executable code. Examples of preventive action include preventing the payload data item from being exported from a computer system, preventing the payload data item from being included in code execution log data, and adding the payload data item to a block list with reference to the particular executable code.

Description

Technical Field

[0001]

[0001] This disclosure relates to systems, methods, and devices that prevent confidential payload data, such as personally identifiable information (PII), cryptographic keys, and passwords, from being included in reproducible execution traces and other execution logs.

Background Art

[0002]

[0002] Tracking and fixing undesirable software behavior / glitches is a core activity in software development. Undesirable software behavior can include many things, such as execution crashes, runtime exceptions, slow execution performance, incorrect data results, data corruption, etc. Undesirable software behavior is triggered by various factors, such as data input, user input, race conditions (e.g., when accessing shared resources). Assuming various triggers, undesirable software behavior is rare and often appears random and very difficult to reproduce. Therefore, it is often very time-consuming and difficult for developers to identify a given undesirable software behavior. Even when an undesirable software behavior is identified, it is often again time-consuming and difficult to determine its root cause.

[0003]

[0003] Developers use various techniques to identify undesirable software behavior and then identify one or more locations in the application code that cause the undesirable software behavior. For example, developers often test different parts of the application code against different inputs (e.g., unit tests). Another example is developers inferring about the execution of the application code in a debugger (e.g., by setting breakpoints / watchpoints or by stepping through code lines as the code is executed). Another example is developers often observing code execution behavior (e.g., timing, coverage) with a profiler. Another example is developers often inserting diagnostic code (e.g., trace statements) into the application code. Each of these activities is supported by code execution logs, such as event logs, generated by the diagnostic code included in the application in question.

[0004]

[0004] While conventional diagnostic tools (e.g., debuggers and profilers) operate on "live" forward-executing code, new forms of diagnostic tools enable "history" debugging (also known as "time travel" or "reverse" debugging), where at least a portion of the execution context (e.g., processes and threads) of an executable computer program is recorded in a code execution log containing one or more trace files (i.e., execution traces). Using several tracing techniques, the execution trace contains "bit-precision" history execution trace data. This allows any recorded portion of the traced execution context to be virtually "replayed" (e.g., via emulation) down to the granularity of individual instructions (e.g., machine code instructions and intermediate language code instructions). Thus, using bit-precision trace data, diagnostic tools allow developers to infer about recorded previous executions of an executable program, in contrast to conventional debugging which is limited to "live" forward execution. For example, using replayable execution traces, some history debuggers provide a user experience that allows, for example, breakpoints / watchpoints in both forward and reverse directions, or allows stepping through code in both forward and reverse directions. On the other hand, some history profilers can derive code execution behavior (e.g., timing and coverage) from previously executed code.

[0005]

[0005] A reproducible execution trace explicitly or implicitly includes all inputs to and outputs from each recorded instruction. Thus, a reproducible execution trace includes all data consumed or generated by the traced code. When the traced code consumes or generates sensitive data items such as PII, cryptographic keys, and passwords, the execution trace of that traced code also includes these sensitive data items. Less stringent forms of code execution logs, such as event logs generated by application diagnostic code, may also include sensitive data items. [Overview of the Initiative]

[0006]

[0006] At least some embodiments described herein enhance data security by using entropy analysis to prevent payload data from being included in code execution log data. These embodiments address the technical challenge of efficiently and reliably determining whether certain data items should be considered sensitive data items (e.g., PII, cryptographic keys, passwords, etc.). These embodiments are based on the inventors' observation that sensitive data items tend to have relatively high entropy when compared to less sensitive data items (e.g., environment variables, mathematical constants, etc.). In some embodiments, the entropy of a data item is considered intrinsically (i.e., by looking at the ratio of the number of bits of entropy to the total length of the data item) and / or contextually (i.e., by determining the uniqueness of the value of a given data item in a code execution log dataset when compared to the values ​​of data items in other code execution log datasets). Recognizing that sensitive data items have relatively high entropy, these embodiments identify high-entropy data items and exclude them from being included in code execution log data such as reproducible execution traces and event logs.

[0007]

[0007] In some embodiments, excluding high-entropy data items from code execution log data has the technical effect of promoting data security by preventing sensitive data items from being inadvertently exposed through the code execution log data. Furthermore, excluding high-entropy data items from code execution log data reduces the size of the code execution log data by removing some of the data, including the removal of high-entropy data which is often not easily compressible, which has the additional technical effect of saving computing resources. For example, reducing the size of the code execution log data saves processing resources when analyzing that log data and saves storage and network resources required to store and transmit the code execution log data.

[0008]

[0008] Accordingly, in some embodiments, methods, systems, and computer products utilize entropy to prevent payload data from being included in code execution log data. These embodiments determine that a payload data item associated with code execution log data has an entropy above a predetermined entropy threshold. Based on the determination that a payload data item has an entropy above a predetermined entropy threshold, these embodiments identify a specific executable code that interacted with the payload data item. These embodiments then take preventive actions to exclude the payload data item from being included in the execution log of the specific executable code.

[0009]

[0009] At least some additional or alternative embodiments described herein enhance data security by removing up to all payload data from the execution trace without impairing the ability to perform some forms of execution trace analysis that do not rely on analysis of the payload data itself (e.g., code and / or data flow analysis, memory locality analysis, memory access pattern analysis, cache usage analysis, race condition analysis, buffer overflow analysis, conventional debugging, etc.). For example, some embodiments process the execution trace to identify payload data items. For each identified payload data item, some embodiments determine the constraints that the execution of the code that interacted with the data item has imposed on the data item and replace the values ​​of the data item in the execution trace with information that maintains those constraints. In some embodiments, this information includes the executable code itself, the memory address of the data item, and / or data structured to preserve the code flow (e.g., replacement values ​​for the data item, specifications for valid values ​​for the data item, instructions for the code path to follow, etc.).

[0010]

[0010] In some embodiments, excluding payload data from execution traces has the technical effect of promoting data security by preventing sensitive data items from being inadvertently exposed through execution traces. Furthermore, in some embodiments, excluding payload data from execution traces can significantly increase the compression ratio of those execution traces. In any case, excluding payload data from execution traces can significantly reduce the size of the execution traces, which has the additional technical effect of saving computing resources. For example, reducing the size of execution traces saves processing resources when analyzing those execution traces and saves storage and network resources required when storing and transmitting execution traces.

[0011]

[0011] Accordingly, in some embodiments, methods, systems, and computer products are targeted to remove payload data from execution traces. These embodiments identify payload data items in the execution trace and identify specific executable code that interacted with the payload data items. Based on the payload data items and the specific executable code, these embodiments determine one or more constraints that the execution of the specific executable code imposes on the payload data item, and then replace the value of the payload data item in the execution trace with information that maintains one or more constraints. In various embodiments, one or more constraints include one or more bytes of the specific executable code, a memory address corresponding to the payload data item, or data structured to store the code flow, and the information that maintains one or more constraints includes one or more bytes of the specific executable code, a memory address corresponding to the payload data item, or data structured to store the code flow.

[0012]

[0012] This summary is provided to introduce in a simplified form some of the concepts that will be further described below in the section on modes for carrying out the invention. This summary is not intended to identify the main or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0013]

[0013] In order to describe how the above and other advantages and features of the present invention can be obtained, a more specific description of the present invention described above will be made with reference to the specific embodiments shown in the accompanying drawings. With the understanding that these drawings show only typical embodiments of the present invention and should not be considered to limit the scope of the present invention, the present invention will be described more specifically and in detail with reference to the accompanying drawings. [Brief explanation of the drawing]

[0014] [Figure 1]

[0014] This figure shows an exemplary computing environment that facilitates the use of entropy to prevent payload data from being included in code execution log data, or one or more of the removal of payload data from execution traces. [Figure 2]

[0015] This figure shows additional details of a debug component configured to use entropy to prevent payload data from being included in the code execution log data. [Figure 3]

[0016] This figure shows the details of a debug component configured to remove payload data from the execution trace. [Figure 4]

[0017] Figure 1 shows an exemplary computing environment in which the computer system shown is connected to one or more other computer systems via one or more networks. [Figure 5]

[0018] This figure shows an example of an execution trace. [Figure 6]

[0019] This is a flowchart illustrating an exemplary method for using entropy to prevent payload data from being included in code execution log data. [Figure 7]

[0020] This diagram shows a flowchart illustrating an exemplary method for removing payload data from an execution trace. [Modes for carrying out the invention]

[0015]

[0021] As noted, at least some embodiments described herein cover one or more of the following: (i) embodiments for using entropy to prevent payload data from being included in code execution log data (such as execution traces or event logs), or (ii) embodiments for removing payload data from execution traces. Both embodiments promote data security, reduce the size of code execution log data / execution traces, and address the technical challenge of efficiently and reliably determining which data items should be considered sensitive data items.

[0016]

[0022] In some embodiments, the execution traces used by the embodiments herein are generated by one or more of various history debugging techniques. Generally, history debugging techniques record or reconstruct the state of an execution context (e.g., a process or thread) at various points in time as the code of the corresponding executable computer program is executed, so that the execution context can be reconstructed at least partially from its execution state. The fidelity of the virtual execution depends on the traced execution state available.

[0017]

[0023] For example, several classes of history debugging techniques, referred to herein as time travel debugging, continuously record a bit-precision trace of the execution context. This bit-precision trace can later be used to replay previous executions of the execution context with fidelity down to the level of individual code instructions. For example, the bit-precision trace records enough information (e.g., by recording a snapshot of processor registers) to reconstruct the initial processor state at least one point in time during a previous execution of the execution context, along with data values ​​(e.g., memory reads) read by executable instructions executed since that point in time. This bit-precision trace can then be used to replay the execution of those executable instructions (starting from the initial processor state) based on providing the recorded reads to the instructions.

[0018]

[0024] Another class of history debugging techniques, referred to herein as branch trace debugging, relies on reconstructing at least part of the execution context state based on calculations from a dump or snapshot (e.g., a crash dump) that includes a processor branch trace (i.e., a record of whether or not a branch occurred). These techniques start with values ​​(e.g., memory and registers) from this dump or snapshot, use the branch trace to determine at least part of the code execution flow, and repeatedly replay the code instructions executed as part of the execution context in forward and reverse directions to reconstruct the intermediate data values ​​(e.g., registers and memory) used by the code instructions until those values ​​reach a steady state. These techniques may have limitations on how far back the data values ​​can be reconstructed and the number of data values ​​that can be reconstructed. Nevertheless, the reconstructed history execution data can be used for history debugging.

[0019]

[0025] Another class of history debugging techniques, referred to herein as replay and snapshot debugging, periodically records a complete snapshot of the memory space and processor registers of the execution context during execution. Where the execution context relies on data from sources other than the execution context's own memory, or from non-deterministic sources, in some embodiments, these techniques also record such data along with the snapshots. These techniques then use the data in the snapshots to replay the execution of the executable program's code between snapshots.

[0020]

[0026] FIG. 1 illustrates an exemplary computing environment 100 that facilitates one or more of the use of entropy to prevent payload data from being included in code execution log data or the removal of payload data from an execution trace. As illustrated, computing environment 100 includes a computer system 101 (e.g., a dedicated or general-purpose computing device) that includes a processor 102 (or processors). As illustrated, in addition to processor 102, computer system 101 also includes a system memory 103, persistent storage 104, and optionally a network device 105 (or network devices), which are communicatively coupled to each other and to processor 102 using at least one communication bus 106.

[0021]

[0027] Embodiments within the scope of the present invention can include physical media and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. A computer-readable media that stores computer-executable instructions and / or data structures is a computer storage media. A computer-readable media that carries computer-executable instructions and / or data structures is a transmission media. Thus, by way of example and not limitation, embodiments of the present invention can comprise at least two distinctly different types of computer-readable media, namely computer storage media and transmission media.

[0022]

[0028] A computer storage medium is a physical storage medium (e.g., system memory 103 and / or persistent storage 104) that stores computer-executable instructions and / or data structures. The physical storage medium includes computer hardware such as RAM, ROM, EEPROM, solid state drive ("SSD"), flash memory, phase change memory ("PCM"), optical disk storage, magnetic disk storage devices or other magnetic storage devices, or any other hardware storage device, and can use it to store program code in the form of computer-executable instructions or data structures, and the program code can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functions of the present invention.

[0023]

[0029] A transmission medium can include a network and / or a data link, and the network and / or the data link can be used to carry program code in the form of computer-executable instructions or data structures and can be accessed by a general-purpose or special-purpose computer. A "network" is defined as one or more data links that enable the transfer of electronic data between computer systems and / or modules and / or other electronic devices. When information is transferred or provided to a computer system via a network (e.g., network device 105) or another communication connection (either wired, wireless, or a combination of wired and wireless), the computer system can consider that connection as a transmission medium. The above combinations should also be included within the scope of computer-readable media.

[0024]

[0030] Furthermore, upon reaching various computer system components, program code in the form of computer executable instructions or data structures may be automatically transferred from the transmission medium to the computer storage medium (or vice versa). For example, computer executable instructions or data structures received via a network or data link can be buffered in RAM within a network interface module (not shown) and then finally transferred to the computer system's RAM (e.g., system memory 103) and / or low-volatility computer storage medium in the computer system (e.g., persistent storage 104). Therefore, it should be understood that computer storage medium can be included in computer system components that further (or primarily) utilize the transmission medium.

[0025]

[0031] Computer executable instructions include instructions and data that cause a general-purpose computer system, a dedicated computer system, or a dedicated processing device to perform a specific function or group of functions when executed on one or more processors. Computer executable instructions may be, for example, machine code instructions (e.g., binary), intermediate format instructions such as assembly language, or even source code.

[0026]

[0032] Those skilled in the art will understand that the present invention can be implemented in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablets, pagers, routers, switches, and the like. The present invention can also be implemented in a distributed system environment in which both local and remote computer systems, linked over a network (either by wired data links, wireless data links, or a combination of wired and wireless data links), perform tasks. Thus, in a distributed system environment, the computer system may include multiple configured computer systems. In a distributed system environment, program modules may reside in both local and remote memory storage devices.

[0027]

[0033] Furthermore, those skilled in the art will understand that the present invention can be implemented in a cloud computing environment. While a cloud computing environment may be distributed, this is not mandatory. If distributed, a cloud computing environment may have components that are internationally distributed within an organization and / or owned across multiple organizations. In this specification and the following claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the many other benefits that can be derived from such a model when properly deployed.

[0028]

[0034] Cloud computing models can comprise a variety of characteristics, including on-demand self-service, broad network access, resource pooling, rapid resilience, and measurable services. Cloud computing models may also take the form of various service models, such as Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a Service ("IaaS"). Cloud computing models can also be deployed using various deployment models, such as private clouds, community clouds, public clouds, and hybrid clouds.

[0029]

[0035] Some embodiments, such as cloud computing environments, may comprise a system including one or more hosts, each capable of running one or more virtual machines. While in operation, a virtual machine emulates a running computing system and supports an operating system and, optionally, one or more other applications. In some embodiments, each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources abstracted from the perspective of the virtual machines. The hypervisor also provides adequate isolation between virtual machines. Thus, from the perspective of any given virtual machine, even if the virtual machine is merely interfaced with the appearance of physical resources (e.g., virtual resources), the hypervisor gives the illusion that the virtual machine is interfaced with the physical resources. Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, and so on.

[0030]

[0036] As shown in Figure 1, in some embodiments, the processor 102 includes, for example, processing units 107 (or more processing units) and memory caches 108 (or more memory caches). Each processing unit 107 (e.g., a processor core) loads and executes machine code instructions into at least one of several execution units 107b. While executing these machine code instructions, the instructions can use registers 107a as temporary storage locations and can be read from and written to various locations in system memory 103 via the memory caches 108. Each processing unit 107 executes machine code instructions defined by a processor instruction set architecture (ISA). The specific ISA for each processor 102 may differ based on the processor manufacturer and processor model. Common ISAs include the IA-64 and IA-32 architectures from INTEL, INC., the AMD64 architecture from ADVANCED MICRO DEVICES, INC., and various Advanced RISC Machine ("ARM") architectures from ARM HOLDINGS, PLC, but many other ISAs also exist and can be used by the present invention. As is generally understood, machine code instructions are the smallest units of code that are executable by a processor and visible from the outside (i.e., outside the processor).

[0031]

[0037] Register 107a is a hardware memory location defined based on the ISA of processor 102. Register 107a is read from and / or written to machine code instructions or processing unit 107 when those instructions are executed in execution unit 107b. Register 107a is commonly used to store values ​​fetched from memory cache 108 for use as input for executing machine code instructions, to store the results of executing machine code instructions, to store program instruction counts, to support thread stack maintenance, etc. In some embodiments, register 107a includes "flags" used to signal any state changes caused by executing machine code instructions (e.g., to indicate whether an arithmetic operation resulted in a carry or zero). In some embodiments, register 107a includes one or more control registers (e.g., used to control different aspects of processor operation) and / or other processor model-specific registers (MSRs).

[0032]

[0038] The memory cache 108 temporarily caches blocks of system memory 103 while the processing unit 107 is executing machine code instructions. In some implementations, the memory cache 108 includes one or more "code" portions that cache portions of system memory 103 that store application code, and one or more "data" portions that cache portions of system memory 103 that store application runtime data. When the processing unit 107 requests data (e.g., code or application runtime data) that is not yet stored in the memory cache 108, the processing unit 107 then initiates a "cache miss," and one or more data blocks are fetched from system memory 103 and flow into the memory cache 108. In the process, it may "evict" some other data already stored in the memory cache 108 into system memory 103.

[0033]

[0039] As illustrated, persistent storage 104 stores data structures representing computer executable instructions and / or executable software components. Correspondingly, during execution of this software on processor 102, one or more portions of these computer executable instructions and / or data structures are loaded into system memory 103. For example, persistent storage 104 is shown as storing computer executable instructions and / or data structures corresponding to debug component 109, and more optionally, as storing computer executable instructions and / or data structures corresponding to one or more of the tracer component 110, emulation component 111, or (one or more) applications 112. In some embodiments, persistent storage 104 also stores data such as a reproducible execution trace 113 (e.g., generated by tracer component 110 using one or more of the historical debugging techniques described above) and (one or more) block lists 114 generated and / or used by debug component 109.

[0034]

[0040] In some embodiments, under the direction of the debug component 109, the tracer component 110 records or "traces" the execution of application 112 into one or more reproducible execution traces 113. In some embodiments, the tracer component 110 records the execution of application 112 when it is a direct "live" execution on processor 102, when it is a "live" execution on processor 102 by a managed runtime, and / or an emulated execution via emulation component 111. Thus, Figure 1 also shows that in some embodiments, the debug component 109 and the tracer component 110 are loaded into system memory 103 (i.e., debug component 109' and tracer component 110'). The arrow between the tracer component 110' and the reproducible execution trace 113' indicates that the tracer component 110' can record trace data into one or more reproducible execution traces 113', which can then be persistently stored in persistent storage 104 as one or more reproducible execution traces 113.

[0035]

[0041] Figure 5 shows an example of an execution trace. In particular, Figure 5 shows an execution trace 500 that includes multiple data streams (i.e., data streams 501a to 501n). In some embodiments, each data stream represents the execution of a different execution context, such as a different thread executed from application 112. In one example, data stream 501a records the execution of a first thread of application 112, and data stream 501n records the nth thread of application 112. As illustrated, data stream 501a includes multiple data packets 502. These data packets are shown as having different sizes, as the specific data logged in each data packet 502 may be different. In some embodiments, when using time-travel debugging techniques, one or more of the data packets 502 record inputs (e.g., register values ​​or memory values) to one or more executable instructions executed as part of this first thread of application 112. In some embodiments, memory values ​​are obtained as inflows into memory cache 108 and / or as uncached read values. In some embodiments, the data stream 501a also includes one or more keyframes (e.g., keyframes 503a and 503b), each keyframe capturing enough information (e.g., a snapshot of registers and / or memory values) to allow the thread's previous execution to be replayed forward, starting from the time of the keyframe.

[0036]

[0042] In some embodiments, the execution trace also includes the actual code that was executed. Thus, in Figure 5, each data packet 502 is shown as containing a data input portion 504 (white portion) and a code portion 505 (shaded portion). In some embodiments, the code portion 505 of each data packet 502 contains an executable instruction, if present, that is executed based on the corresponding data input. However, in other embodiments, the execution trace omits the actual code that was executed and instead relies on having separate access to the executable code (e.g., a copy of application 112). In these other embodiments, each data packet specifies an address or offset to the appropriate executable instruction in the application binary image. Although not shown, the execution trace 500 may also contain a data stream that stores one or more of the outputs of the code execution. Note that the use of different data inputs and code portions of data packets is illustrative, and the same data can also be stored in various ways, such as using multiple data packets.

[0037]

[0043] When there are multiple data streams, in some embodiments these data streams may contain sequence events. Each sequence event records the occurrence of an orderable event across various execution contexts, such as threads. For example, sequence events correspond to interactions between threads, such as access to memory shared by threads. For example, if a first thread traced to a first data stream (e.g., data stream 501a) writes to a synchronization variable, a first sequence event is recorded in that data stream (e.g., data stream 501a). Then, if a second thread traced to a second data stream (e.g., data stream 501n) reads from that synchronization variable, a second sequence event is recorded in that data stream (e.g., data stream 501n). These sequence events are inherently ordered. For example, in some embodiments, each sequence event is associated with a monotonically increasing value, which defines the overall order among the sequence events. For example, a first sequence event recorded in the first data stream is given the value 1, a second sequence event recorded in the second data stream is given the value 2, and so on.

[0038]

[0044] In some embodiments, under the direction of the debug component 109, the emulation component 111 emulates the execution of code of an executable entity, such as an application 112, based on execution state data obtained from one of the reproducible execution traces 113. Thus, Figure 1 shows that in some embodiments, the debug component 109 and the emulation component 111 are loaded into system memory 103 (i.e., debug component 109' and emulation component 111'), and the execution of application 112 is emulated within the emulation component 111' (i.e., application 112').

[0039]

[0045] In some embodiments, computer system 101 is part of a networked computing environment, and computer system 101 is connected to one or more remote computer systems (e.g., using a network device 105), each remote computer system including one or more corresponding debug components, corresponding tracer components, or corresponding emulation components. For example, Figure 4 shows an exemplary computing environment 400, and computer system 101 of Figure 1 is shown as being connected to one or more remote computer systems (e.g., remote computer systems 402a to 402n) via a network 401. In one embodiment, computer system 101 receives one or more reproducible execution traces 113 via the network 401 from one or more remote computer systems, each including a tracer component (e.g., for analysis of those traces by a debug component 109 on computer system 101). In another embodiment, the computer system 101 uses a tracer component 110 to record one or more reproducible execution traces 113 and transmits those traces over the network 401 to one or more remote computer systems, each containing one or more debug components or emulation components (for example, for analysis of those traces by the remote computer systems). In some embodiments, the computer system 101 also sends and receives block lists 114 to and from one or more remote computer systems over the network 401.

[0040]

[0046] It should be noted that in some embodiments, the debug component 109, the tracer component 110, and / or the emulation component 111 are independent components or applications, but in other embodiments, they are integrated into the same application (e.g., a debug suite) or into another software component (e.g., an operating system component, a hypervisor, a cloud fabric). Therefore, those skilled in the art will understand that the present invention can also be implemented in a cloud computing environment including a computer system 101. For example, in some embodiments, these components take the form of one or more software applications running on the user's local computer, while in other embodiments, they take the form of services provided by the cloud computing environment.

[0041]

[0047] In some embodiments, the debug component 109 is a tool (e.g., a debugger, profiler, cloud service, etc.) that consumes one or more reproducible execution traces 113 as part of an analysis of previous executions of the application 112. As described in more detail here in relation to Figures 2 and 6, in some embodiments, the debug component 109 provides functionality for using entropy analysis to prevent payload data from being included in code execution log data such as reproducible execution traces 113. As an addition or alternative, as described in more detail here in relation to Figures 3 and 7, in some embodiments, the debug component 109 provides functionality for removing payload data from reproducible execution traces 113. I. Using entropy to prevent payload data from being included in code execution log data

[0048] As mentioned above, some embodiments of the debug component 109 provide the capability to use entropy analysis to prevent payload data from being included in code execution log data. These embodiments address the challenge that it can be very difficult for sensitive data items to be programmatically identified by leveraging the observation that sensitive data items (e.g., PII, cryptographic keys, passwords, etc.) tend to have high entropy. Using this observation, these embodiments identify high-entropy data items such as inputs and outputs to executable instructions and functions, and exclude those data items from being included in code execution log data such as reproducible execution traces and event logs.

[0042]

[0049] When used herein, a data item is considered to have “high entropy” if its intrinsic and / or contextual entropy meets a predetermined threshold. In some embodiments, a data item is considered to have high intrinsic entropy (and therefore high entropy) if the ratio of the number of bits of entropy in the data item to the total number of bits in the data item exceeds a predetermined threshold. For example, cryptographic keys and passwords tend to have high intrinsic entropy because they tend to contain a relatively large number of unique characters relative to the total number of characters in the key / password. Conversely, natural language text tends to have low intrinsic entropy because it tends to contain a relatively small number of unique characters relative to the total number of characters in the text. In particular, data items with high intrinsic entropy have relatively low internal character repetitions compared to data items with low intrinsic entropy, and therefore, data items with high intrinsic entropy have a lower compression ratio compared to data items with high intrinsic entropy. Conversely, data items with low intrinsic entropy have relatively high internal character repetitions compared to data items with high intrinsic entropy, and therefore, data items with low intrinsic entropy have a higher compression ratio compared to data items with low intrinsic entropy. Thus, in some embodiments, the compression ratio of a data item is used to determine whether a data item is considered to have low or high intrinsic entropy.

[0043]

[0050] In some embodiments, a data item is considered to have high contextual entropy (and therefore high entropy) when the ratio of the number of times a particular value of the data item appears to the total number of times the data item appears in the collection of execution traces is less than a predetermined threshold, or when the ratio of the number of traces in which a particular value of the data item appears to the total number of traces in the collection of execution traces is less than a predetermined threshold. For example, social security numbers tend to have high contextual entropy because, assuming a large data collection collected across many computer systems, a given social security number tends to appear infrequently. Conversely, state names tend to have low contextual entropy because, assuming a large data collection collected across many computer systems, a given state name tends to appear frequently.

[0044]

[0051] In some embodiments, the computer system generating the code execution log data takes action to exclude high-entropy data from the code execution log data. For example, during the generation of one or more reproducible execution traces 113 by the tracer component 110 in computer system 101, the debug component 109 in computer system 101 uses a blocklist 114 and / or intrinsic entropy analysis to identify high-entropy payload data items and exclude those payload data items from their traces. In another example, during post-processing of one or more reproducible execution traces 113 generated by the debug component 109 in computer system 101, the debug component 109 in computer system 101 uses a blocklist 114 and / or intrinsic entropy analysis to identify high-entropy payload data items and exclude those payload data items from their traces. In any case, high-entropy payload data items are excluded from the code execution log data before the log data is exported from computer system 101 (for example, to a remote computer system 402a).

[0045]

[0052] In other embodiments, a computer system processing a collection of code execution log data takes action to exclude high-entropy data from future collections by identifying code that interacts with high-entropy data in a blocklist 114 and by sending the blocklist 114 to one or more remote computer systems. In these embodiments, the computer system can also remove high-entropy data items from the collection of code execution log data used to identify the high-entropy data items. For example, while a debug component 109 on computer system 101 processes multiple reproducible execution traces 113 of an application 112 received from multiple remote computer systems, the debug component 109 uses intrinsic entropy analysis and / or contextual entropy analysis to identify high-entropy payload data items in these execution traces. Next, the debug component 109 adds those data items to a blocklist 114 (or blocklist 114' in system memory 103) based on references to the code that interacted with those data items, and distributes this blocklist 114 to remote computer systems to prevent those data items from being included in future execution traces collected from those remote computer systems. In some embodiments, the debug component 109 also removes these high-entropy payload data items from multiple execution traces.

[0046]

[0053] To further demonstrate these concepts, Figure 2 shows an example of a debug component 200 (e.g., one embodiment of debug component 109) configured to use entropy to prevent payload data from being included in code execution log data, and includes components that operate to use entropy to prevent payload data from being included in code execution log data (e.g., log data interaction component 202, high-entropy payload identification component 203, code interaction component 204, blocklist interaction component 205, preventive action component 206, export component 207, etc.). The illustrated components of debug component 201, including subcomponents, represent various functions that debug component 201 may implement or utilize according to the various embodiments described herein. However, it should be understood that the illustrated components (including their identities, subcomponents, and arrangement) are presented only as an aid to illustrating the various embodiments of debug component 201 described herein, and these components do not limit how software and / or hardware may implement the various embodiments of debug component 201 or any particular function described herein.

[0047]

[0054] The debug component 201 is described in relation to Figure 6. Figure 6 shows a flowchart of Method 600 for using entropy to prevent payload data from being included in code execution log data. Thus, the following discussion refers to Method and Method operations. Method operations may be discussed in a specific order, or shown in flowcharts as being performed in a specific order, but no specific order is required unless specifically specified, or unless an operation depends on another operation that has been completed before it is performed. In some embodiments, instructions for implementing Method 600 are encoded as computer-executable instructions (e.g., debug component 201) stored in a hardware storage device (e.g., persistent storage 104) that is executable by a processor (e.g., processor 102) to cause a computer system (e.g., computer system 101) to perform Method 600.

[0048]

[0055] The log data interaction component 202 interacts with code execution log data, such as a reproducible execution trace 113, or other code execution logs, such as an event log. As illustrated, in various implementations, the log data interaction component 202 includes one or more log data access components 202a (i.e., for accessing existing code execution log data, such as a reproducible execution trace 113, stored in persistent storage 104), a log data generation component 202b (i.e., for generating code execution log data, such as a reproducible execution trace 113), or a log data modification component 202c (i.e., for modifying existing code execution log data, such as a reproducible execution trace 113, stored in persistent storage 104). The type of code execution log data that the log data interaction component 202 acts on may vary, but in some embodiments, the code execution log data is a reproducible execution trace, such as one of the reproducible execution traces 113.

[0049]

[0056] The high-entropy payload identification component 203 identifies high-entropy payload data items in connection with the generation of code execution log data (for example, by the tracer component 110) or in connection with post-processing of code execution log data. The code interaction component 204 identifies the code that interacted with the high-entropy payload data item by analyzing the interaction between the high-entropy payload data item and the executed code, or by examining the blocklist 114.

[0050]

[0057] As shown in Figure 6, method 600 includes operation 601 to identify a high-entropy payload data item associated with code execution log data, and operation 602 to identify a specific code that interacted with the high-entropy payload data item. Operations 601 and 602 are shown without any particular order between them. In some embodiments, operation 601 first identifies the high-entropy payload data item, and then operation 602 identifies a specific code that interacted with the high-entropy payload data item. In other embodiments, the operation identifies a specific code that interacted with the high-entropy payload data item from the blocklist 114, and then operation 601 identifies the high-entropy payload data item as the item that the specific code interacted with.

[0051]

[0058] In some embodiments, operation 601 includes determining that a payload data item associated with code execution log data has an entropy exceeding a predetermined entropy threshold. In some embodiments, operation 602 includes identifying specific executable code that interacted with the payload data item. In some embodiments, operations 601 and 602 have the technical effect of identifying payload data that may be sensitive data, such as PII, cryptographic keys, and passwords, along with the code that interacted with that payload data. In particular, by identifying payload data that may be sensitive data in operation 601 and the code that interacted with sensitive data in operation 602, data security can be improved by allowing this high-entropy payload data to be excluded from the code execution log data.

[0052]

[0059] As illustrated, the high-entropy payload identification component 203 includes thresholds 203c that define the conditions under which the calculated entropy of a given data item is considered "high-entropy." As can be understood in light of the discussion of intrinsic and contextual entropy, in some embodiments, these thresholds 203c are based on ratios.

[0053]

[0060] As also illustrated, in some embodiments, the high-entropy payload identification component 203 includes an intrinsic entropy component 203a. In some embodiments, the intrinsic entropy component 203a analyzes the payload data based on its intrinsic entropy. Thus, in some embodiments of operation 601, determining that a payload data item has an entropy exceeding a predetermined entropy threshold includes determining that a payload data item has an intrinsic entropy exceeding a predetermined entropy threshold.

[0054]

[0061] As discussed, if the ratio of the number of bits of entropy in a data item to the total number of bits in the data item exceeds a predetermined threshold (i.e., threshold 203c), the data item has high intrinsic entropy (and therefore high entropy). Thus, in some embodiments of operation 601, determining that a payload data item has intrinsic entropy exceeding a predetermined entropy threshold involves calculating the ratio of the number of bits of entropy in the payload data item to the total number of bits in the payload data item. As also discussed, in some embodiments, the compression ratio of a data item is used to determine whether a data item has low intrinsic entropy (i.e., a relatively high compression ratio) or high intrinsic entropy (i.e., a relatively low compression ratio). Thus, in some embodiments of operation 601, determining that a payload data item has intrinsic entropy exceeding a predetermined entropy threshold involves calculating the compression ratio of the payload data item.

[0055]

[0062] As also illustrated, in some embodiments, the high-entropy payload identification component 203 includes a contextual entropy component 203b. In some embodiments, the contextual entropy component 203b analyzes the payload data based on its contextual entropy. In some embodiments, a data item has high contextual entropy (and therefore high entropy) when the ratio of the number of times a particular value of the data item appears to the total number of times the data item appears in the collection of execution traces is less than a predetermined threshold (i.e., threshold 203c). In other embodiments, a data item has high contextual entropy (and therefore high entropy) when the ratio of the number of traces in which a particular value of the data item appears to the total number of traces in the collection of execution traces is less than a predetermined threshold (i.e., threshold 203c). Thus, in some embodiments of operation 601, determining that a payload data item has entropy above a predetermined entropy threshold includes determining that the payload data item has contextual entropy above a predetermined entropy threshold, where contextual entropy relates to a plurality of related payload data items identified from a plurality of related code execution logs.

[0056]

[0063] In some embodiments, when identifying a high-entropy payload data item in operation 601, the high-entropy payload identification component 203 utilizes the blocklist interaction component 205 to identify known high-entropy payload data from a blocklist 114, such as a blocklist received from a remote computer system via the network 401. As discussed, in some embodiments, the blocklist 114 identifies high-entropy data items by referring to code that interacted with the data item, such as code that consumed or generated the data item. Thus, in some embodiments of operation 601, determining that a payload data item has entropy exceeding a predetermined entropy threshold involves identifying the payload data item from the blocklist based at least on a reference to specific executable code (identified in operation 602) that interacted with the payload data item.

[0057]

[0064] In some embodiments, the high-entropy payload identification component 203 operates during post-processing of the code execution log data, for example, by the computer system that generated the code execution log data, or by a computer system that receives the code execution log data from another computer system. Thus, in some embodiments of operation 601, determining that a payload data item has entropy exceeding a predetermined entropy threshold includes identifying the payload data item during post-processing of the code execution log data. In other embodiments, the high-entropy payload identification component 203 operates during the generation of the code execution log data, such as during trace recording by the tracer component 110. Thus, in some embodiments of operation 601, determining that a payload data item has entropy exceeding a predetermined entropy threshold includes identifying the payload data item during the generation of the code execution log data.

[0058]

[0065] As discussed above, in operation 602, the code interaction component 204 identifies specific executable code that interacted with the payload data item. In various embodiments, this interaction may be the consumption of the payload data item (in operation 602, identifying specific executable code that interacted with the payload data item includes identifying the executable code that consumed the payload data item) or the generation of the payload data item (in operation 602, identifying specific executable code that interacted with the payload data item includes identifying the executable code that generated the payload data item). The granularity at which the code interaction component 204 identifies executable code may vary, for example, at the instruction level (in operation 602, identifying specific executable code that interacted with the payload data item includes identifying a specific executable instruction) or at the function level (in operation 602, identifying specific executable code that interacted with the payload data item includes identifying a specific function).

[0059]

[0066] The preventive action component 206 takes preventive actions to prevent the export of payload data (e.g., by the export component 207), to prevent payload data items from being included in code execution log data, and / or to add payload data items to a blocklist. As shown in Figure 6, method 600 includes operation 603 which takes action to exclude high-entropy payload data items from the record of a particular code execution. In some embodiments, operation 603 includes taking preventive action to exclude payload data items from being included in the record of a particular executable code execution.

[0060]

[0067] As described above, in some embodiments, the preventive action component 206 performs preventive actions to prevent the export of payload data. Thus, as shown in Figure 6, in some embodiments, operation 603 includes operation 603a, which prevents the export of payload data items, and the preventive action in operation 603 includes preventing the payload data items from being exported from the computer system. For example, in some embodiments, the preventive action component 206 removes high-entropy payload data items (identified by the high-entropy payload identification component 203 in operation 601) from the code execution log data when the code execution log data is exported to the remote computer system by the export component 207.

[0061]

[0068] As described above, in some embodiments, the preventative action component 206 performs preventative actions to prevent payload data items from being included in the code execution log data. Thus, as shown in Figure 6, in additional or alternative embodiments, operation 603 includes operation 603b, which prevents payload data items from being included in the code execution log data, and the preventative action in operation 603 includes preventing payload data items from being included in the code execution log data. For example, in some embodiments, the preventative action component 206 prevents high-entropy data items (identified by the high-entropy payload identification component 203 in operation 601) from being included in the code execution log data currently being generated, and / or removes those high-entropy data items from the existing code execution log data.

[0062]

[0069] In various embodiments, preventing payload data items from being included in code execution log data involves replacing the payload data items in the code execution log data with one or more of the following: (i) alternative data, (ii) one or more constraints on the payload data items, or (iii) code flow overrides relating to specific executable code. These techniques will be discussed in more detail in relation to Figures 3 and 7, which describe methods for achieving the removal of payload data from execution traces.

[0063]

[0070] As described above, in some embodiments, the preventative action component 206 performs a preventative action of adding payload data items to a blocklist. Thus, as shown in Figure 6, in additional or alternative embodiments, operation 603 includes operation 603c, which adds payload data items to a blocklist, and the preventative action in operation 603 includes adding payload data items to a blocklist by referencing specific executable code, and the blocklist is structured to prevent the payload data items from being included in code execution log data that is generated later. For example, in some embodiments, the preventative action component 206 uses the blocklist interaction component 205 to add high-entropy data items (identified by the high-entropy payload identification component 203 in operation 601) to the blocklist 114 by referencing code that interacts with those data items (identified by the code interaction component 204 in operation 602). Thus, operation 603a has the effect of preventing the high-entropy data items from being included in code execution log data that has not yet been generated.

[0064]

[0071] In some embodiments, the debug component 201 operates transiently when preventing payload data from being included in the code execution log data, thus excluding multiple instances of high-entropy payload data (including derivatives) from being included in the code execution log data. For example, in some embodiments, when the high-entropy payload identification component 203 determines that the data for a first parameter of a particular function is a high-entropy value, it also identifies any additional code locations that interact with that data (or its copies / derivatives). The preventative action component 206 then takes preventative actions for each of these identified code locations to exclude this data from being included in the code execution log data. For example, if the first parameter (or its derivatives) is later printed to the screen as a string, in some embodiments, the high-entropy payload identification component 203 identifies the code to print this string payload and to clear that string payload. In some embodiments, this is true even if there is no print routine in the recorded code path. Therefore, in some embodiments, the debug component 201 operates to transiently exclude all instances of high-entropy payload data (including its derivatives) from the code execution log data. Thus, in some embodiments of method 600, method 600 is transiently applied to exclude additional instances of payload data items or their derivatives from being included in another execution log of another executable code.

[0065]

[0072] In some embodiments, even if payload data items are prevented from being exported by the export component 207, prevented from being included in the code execution log data, and / or removed from the code execution log data, in some embodiments, the preventative action component 206 retains these payload data items separately (e.g., in persistent storage 104) and, if applicable, encrypts or otherwise protects their data time. In some embodiments, this retention allows the data time to be provided later if necessary to facilitate the analysis of the code execution log data. Thus, in some embodiments of Method 600, payload data items are retained in the computer system separately from the code execution log data.

[0066]

[0073] In particular, data security can be improved by excluding high-entropy data from the code execution log data, for example, by preventing the export of payload data items in operation 603a, by preventing payload data items from being included in the code execution log data in operation 603b, or by adding payload data items to a blocklist in operation 603c. This has the technical effect of preventing sensitive data items from being inadvertently exposed through the code execution log data. Furthermore, excluding high-entropy payload data items from the code execution log reduces the size of the code execution log data by removing some of the data, including the removal of high-entropy data that is often not easily compressible, such as reproducible execution traces 113, which has the additional technical effect of saving computing resources. For example, reducing the size of reproducible execution traces 113 saves processing resources when analyzing those traces and saves storage and network resources required to store and transmit those traces. II. Removal of payload data from execution traces

[0074] As previously mentioned, some embodiments of the debug component 109 provide, as an addition or alternative, the ability to remove payload data from the reproducible execution trace 113. These embodiments are based on the recognition that payload data often does not contribute substantially to many forms of execution trace analysis, such as code and / or data flow analysis, memory locality analysis, memory access pattern analysis, cache usage analysis, race condition analysis, buffer overflow analysis, and traditional debugging. By removing this payload data from the execution trace, these embodiments improve data security (i.e., by removing such data execution traces) and also significantly reduce the trace file size.

[0067]

[0075] Conceptually, these embodiments transform the execution trace from one that explicitly or inherently captures all inputs and outputs (i.e., payload data) to each instruction executed, to one that includes the actual code executed, information about what caused that code to be executed, and memory access patterns (i.e., memory addresses accessed). In particular, these embodiments process the execution trace to identify payload data items, such as inputs to and outputs from executable instructions and functions. For each identified payload data item, these embodiments determine the constraints imposed on the payload data item by the execution of the code that interacted with it. These embodiments then replace the values ​​of the payload data items in the execution trace with information that maintains those constraints. In some embodiments, this information includes data structured to preserve the actual executable code that interacted with the payload data item, the memory address of the payload data item, and / or the code flow affected by the payload data item (e.g., replacement values ​​for the payload data item that preserves the code flow, specifications for valid values ​​for the data item that preserves the code flow, instructions for the code path to follow, etc.).

[0068]

[0076] To further demonstrate these concepts, Figure 3 shows an example 300 of a debug component 301 (e.g., one embodiment of debug component 109) configured to remove payload data from an execution trace, including components that operate to remove payload data from the execution trace (e.g., trace interaction component 302, payload identification component 303, code interaction component 304, constraint identification component 305, payload replacement component 306, etc.). The illustrated components of debug component 301, including subcomponents, represent various functions that debug component 301 may implement or utilize according to the various embodiments described herein. However, it should be understood that the illustrated components (including their identities, subcomponents, and arrangement) are presented only as an aid to illustrating the various embodiments of debug component 301 described herein, and these components do not limit how software and / or hardware may implement the various embodiments of debug component 301 or any particular function described herein.

[0069]

[0077] The debug component 301 is described in relation to Figure 7. Figure 7 shows a flowchart of method 700 for removing payload data from an execution trace. Therefore, the following discussion will refer to methods and method operations. Method operations may be discussed in a specific order, or shown in flowcharts as being performed in a specific order, but no specific order is required unless otherwise specified, or unless an operation depends on another operation that has been completed before it is performed. In some embodiments, instructions for implementing method 700 are encoded as computer-executable instructions (e.g., debug component 301) stored in a hardware storage device (e.g., persistent storage 104) that is executable by a processor (e.g., processor 102) to cause a computer system (e.g., computer system 101) to perform method 700.

[0070]

[0078] The trace interaction component 302 interacts with execution traces, such as the replayable execution trace 113. As illustrated, the trace interaction component 302 includes a trace access component 302a (i.e., for accessing existing execution traces) and a trace modification component 302b (i.e., for modifying existing execution traces).

[0071]

[0079] The payload identification component 303 identifies payload items from the execution trace accessed by the trace access component 302a. In some embodiments, the payload identification component 303 identifies inputs to and outputs from code instructions, functions, modules, etc. In some embodiments, the payload identification component 303 also identifies the memory address (or even a range of memory addresses) corresponding to each payload item. In some embodiments, the payload identification component 303 also identifies a name or label for each payload item, such as a variable name, structure name, or class name. Referring to Figure 7, method 700 includes operation 701 to identify payload data items from the execution trace. In some embodiments, operation 701 includes identifying payload data items in one of the reproducible execution traces 113 accessed by the trace interaction component 302.

[0072]

[0080] The code interaction component 304 identifies the code that interacted with each payload data item identified by the payload identification component 303. As previously mentioned, the payload identification component 303 identifies inputs to and outputs from code instructions, functions, modules, etc. Therefore, the code interaction component 304 identifies the code of these instructions, functions, modules, etc. In some embodiments, the code interaction component 304 further identifies from which memory address this code was accessed. Looking at Figure 7, method 700 includes operation 702 which identifies a specific code that interacted with a payload data item. In some embodiments, operation 702 includes identifying a specific executable code that interacted with a payload data item identified by the payload identification component 303 in operation 701.

[0073]

[0081] In the examples of operations 701 and 702, the execution trace records the execution of a string copy function as follows:

[0074]

number

[0075] [Table 1] At this point, after the execution of the strcpy() function, these same characters are copied to another block of memory pointed to by *dest. For example, when processing this execution trace, the payload identification component 303 identifies one of the characters in the “Sample” string for each iteration of the while loop, along with the corresponding memory address for those payload items, as an input to a branch instruction (e.g., corresponding to while), an input to a memory load instruction, and an input to a memory store instruction. Correspondingly, the code interaction component 304 identifies these instructions as the code that interacted with these payload data items, along with the corresponding memory address for that code.

[0076]

[0082] The constraint identification component 305 identifies the constraints that the execution of the code identified by the code interaction component 304 imposes on the payload identified by the payload identification component 303. As shown in Figure 7, the method 700 includes an operation 703 that determines the constraints that the execution of a particular code imposes on a payload data item. In some embodiments, the operation 703 includes determining one or more constraints that the execution of a particular executable code imposes on a payload data item, based on the payload data item and the particular executable code.

[0077]

[0083] As illustrated, in some embodiments, the constraint identification component 305 comprises a code byte component 305a. As understood, the actual code that interacts with the payload data is an inherent constraint on that payload data as code input. Thus, in some embodiments, the code byte component 305a identifies the actual bytes of the executed code to include in the execution trace. In some embodiments, the code byte component 305a identifies these code bytes based on data stored at code memory addresses identified by the code interaction component 304. As shown in Figure 7, in some embodiments, operation 703 includes operation 703a that identifies code bytes. Thus, in some embodiments of operation 703, one or more constraints include one or more bytes of a particular executable code. In one example, when operating with the strcpy() example above, the code byte component 305a identifies the actual code of the strcpy() function.

[0078]

[0084] As also illustrated, in some embodiments, the constraint identification component 305 comprises a memory address component 305b. As can be understood, the location where the executable code accesses the payload data imposes a location constraint on that payload data. Thus, in some embodiments, the memory address component 305b identifies the memory address from which the payload data item was accessed for inclusion in the execution trace. As shown in Figure 7, in some embodiments, operation 703 includes operation 703b, which identifies a memory address. Thus, in some embodiments of operation 703, one or more constraints include the memory address corresponding to the payload data item. For example, when operating with the strcpy() example above, the memory address component 305b identifies the memory address of each character in the src and dest strings.

[0079]

[0085] As also illustrated, in some embodiments, the constraint identification component 305 comprises a code flow component 305c. As understood, the code flow resulting from interaction with payload data imposes constraints on the possible values ​​of the payload data that preserve the same code flow. Therefore, in some embodiments, the code flow component 305c identifies code flow constraints on the payload data for inclusion in the execution trace. As shown in Figure 7, in some embodiments, operation 703 includes operation 703c, which identifies data structured to preserve the code flow. Therefore, in some embodiments of operation 703, one or more constraints include data structured to preserve the code flow.

[0080]

[0086] In some embodiments, the code flow component 305c identifies data structured to store the code flow in the form of a replacement value for a payload data item, where the replacement value is a value that stores the appropriate code flow when replacing the original value of the payload data item. Thus, in some embodiments, operation 703c includes a replacement value for a payload data item, where the replacement value is structured to store the code flow.

[0081]

[0087] In some embodiments, the code flow component 305c selects this replacement value based on random value generation, and operation 703c includes identifying the replacement value based on random value generation. In some embodiments, when the code flow component 305c selects a replacement value based on random values, the code flow component 305c generates a random value of an appropriate data size for the payload data item (e.g., using a pseudo-random value generation technique), and then checks whether to save the code flow if the randomly generated value is used as the value for the payload data item. If the code flow is to be saved, the code flow component 305c selects that randomly generated value as the replacement value. If the code flow is not to be saved, the code flow component 305c generates and checks new random values ​​until a value is identified that will save the code flow. In particular, in some embodiments, the code flow component 305c allows the generation of a random value identical to the original value of the payload data item. For example, when operating with the strcpy() example above, the code flow component 305c generates a different random 1-byte value for each letter of the string "Sample". Here, non-null bytes (e.g., bytes other than 0x0) preserve the code flow.

[0082]

[0088] In additional or alternative embodiments, the code flow component 305c selects this replacement value based on a search from a set of available replacement values, and operation 703c includes identifying the replacement value based on a search from a set of available replacement values. In some embodiments, when the code flow component 305c selects a replacement value based on a search, the code flow component 305c selects one value from a given set of available replacement values ​​and then checks whether that value would save the code flow if used as the value of a payload data item. If the code flow would be saved, the code flow component 305c selects the selected value as the replacement value. If the code flow would not be saved, the code flow component 305c selects and checks other values ​​from the set until a value that would save the code flow is identified. In particular, in some embodiments, the code flow component 305c allows the selection of a value identical to the original value of the payload data item. In some embodiments, the set of available replacement values ​​includes values ​​that promote the compressibility of the execution trace, such as 0x0, 0xA, 0xF, etc., which contain many instances of those values. For example, when working with the strcpy() example above, the code flow component 305c generates a single-byte value for each character of the string from the set of available values, where any non-null bytes such as 0xA or 0xF preserve the code flow.

[0083]

[0089] In additional or alternative embodiments, the code flow component 305c selects this replacement value based on at least the calculation of a hash of the payload data item, and operation 703c includes generating the replacement value based on the calculation of a hash of the payload data item. In some embodiments, the code flow component 305c checks whether the code flow is saved if the generated hash is used as the replacement value for the payload data item, and if so, if the code flow component 305c selects that hash as the replacement value. Thus, in some embodiments of operation 703c, replacing the value of a payload data item in the execution trace with information that maintains one or more constraints includes replacing the value of the payload data item with a hash. In some embodiments, if the code flow is not saved if the generated hash is used as the replacement value for the payload data item, the code flow component 305c uses one of the other replacement value selection techniques discussed herein (e.g., a randomly generated value, a value selected from a set of available replacement values, etc.) and tags that replacement value with a hash. Therefore, in some embodiments of operation 703c, replacing the values ​​of payload data items in the execution trace with information that maintains one or more constraints includes tagging the replacement values ​​with a hash. For example, when working with the strcpy() example above, the code flow component 305c generates a hash for each letter of the string, where these hashes are non-null and thus preserve the code flow and are used as replacements for each letter of the string.

[0084]

[0090] In some embodiments, when the code flow component 305c selects a replacement value based on a hash, the code flow component 305c hashes the value of the payload data item, either alone or in combination with a salt. Thus, in some embodiments of operation 703c, calculating the hash of a payload data item includes applying a salt to the payload data item. In some embodiments, the code flow component 305c uses the same salt when hashing values ​​in a set of traces being analyzed for a common purpose, such as analyzing a particular bug or defect. In this way, payloads with the same value are replaced (or at least tagged) with the same hash across this entire set of traces and can therefore be correlated with one another during analysis. However, if different salts are used for other sets of traces, the overall obfuscation of the payloads across all traces is preserved, as different salts have different hashes when different salts are used.

[0085]

[0091] In additional or alternative embodiments, the code flow component 305c selects this substitution value based on the execution of a constraint solver (e.g., using the Boolean satisfiability problem (SAT) technique), and operation 703c includes identifying the substitution value based on the execution of a constraint solver on at least certain executable code. In some embodiments, when the code flow component 305c selects a substitution value based on a constraint solver, the code flow component 305c uses the constraint solver to analyze the code that interacted with the payload data item. For example, when working with the strcpy() example above, the code flow component 305c runs the constraint solver on the code that constitutes the while loop.

[0086]

[0092] In some embodiments, the code flow component 305c identifies data structured to store the code flow in the form of a specification of one or more sets of valid values ​​relating to a payload data item. Thus, in some embodiments of operation 703c, the data structured to store the code flow includes a specification of one or more sets of valid values ​​relating to a payload data item. The specification of one or more sets of valid values ​​can take various forms, such as a range of values ​​(e.g., 1 to 10), a set of values ​​(e.g., 1, 2, 4, 8, and 10), a flag (e.g., zero or non-zero), or a boundary value (e.g., less than 7). For example, when working with the strcpy() example above, the code flow component 305c specifies that each letter in the "Sample" string can be replaced with a non-null character.

[0087]

[0093] In some embodiments, the code flow component 305c identifies data structured to preserve the code flow in the form of instructions for the code path to follow. Thus, in some embodiments of operation 703c, the data structured to preserve the code flow includes instructions for the code path to follow within a particular executable code. Instructions for the code path to follow may include, for example, instructions on which branch of a control statement to choose, or instructions on whether a statement should evaluate to true or false. For example, when working with the strcpy() example above, for each letter in the "Sample" string, the code flow component 305c indicates that the while loop should continue, and for the null terminator, it indicates that the while loop should terminate. As can be understood, by specifying instructions for the code path to follow, the associated payload data can be completely omitted from the trace.

[0088]

[0094] The payload replacement component 306 performs payload data replacement based on the constraints identified by the constraint identification component 305 in operation 703. Referring to Figure 7, method 700 includes operation 704, which replaces payload data items with information that maintains the constraints. In some embodiments, operation 704 includes replacing the values ​​of payload data items in the execution trace with information that maintains one or more constraints.

[0089]

[0095] As discussed, in some embodiments, one or more constraints include actual code (code byte component 305a) that interacts with the payload data. Correspondingly, in some embodiments, the payload replacement component 306 includes a code byte component 306a that logs at least the code bytes that interacted with the payload data to the execution trace. Thus, in some embodiments of operation 704, the information maintaining one or more constraints includes one or more bytes of specific executable code. Thus, as illustrated, in some embodiments, operation 704 includes operation 704a that logs the code bytes. In some embodiments, operation 704a has the technical effect of enabling access to the executable code and facilitating execution trace analysis.

[0090]

[0096] As discussed, in some embodiments, one or more constraints include actual code (code byte component 305a) that interacts with the payload data. Correspondingly, in some embodiments, the payload replacement component 306 includes a memory address component 306b that logs at least the memory address corresponding to the payload data. Thus, in some embodiments of operation 704, the information that maintains one or more constraints includes memory addresses. Thus, as illustrated, in some embodiments, operation 704 includes operation 704b that logs memory addresses. In some embodiments, operation 704b has the technical effect of enabling memory usage analysis (e.g., code and / or data flow analysis, memory locality analysis, memory access pattern analysis, cache usage analysis, race condition analysis, buffer overflow analysis, conventional debugging, etc.) even in the absence of the original payload data.

[0091]

[0097] As discussed, in some embodiments, one or more constraints include a code flow resulting from interaction with payload data (code flow component 305c). Correspondingly, in some embodiments, the payload replacement component 306 includes a code flow component 306c that logs data structured to preserve at least the code flow. Thus, in some embodiments of operation 704, the information that maintains one or more constraints includes data structured to preserve the code flow, which may include, for example, replacement values ​​for payload data items or instructions for a code path to follow within a particular executable code. Thus, as illustrated, in some embodiments, operation 704 includes operation 704c that logs data structured to preserve the code flow. In some embodiments, operation 704c has the technical effect of replacing potentially sensitive data in the execution trace with data structured to preserve the code flow, which promotes data security. Furthermore, when the replacement data is smaller than the original payload data and / or when the replacement data has a compressible data pattern, operation 704 has the technical effect of reducing the trace file size. Therefore, since less data is processed, stored, and transferred, the efficiency of trace analysis, storage, and transfer (in terms of required processing power, computation time, storage resources, and network utilization) is improved.

[0092]

[0098] In some embodiments, similar to debug component 201, debug component 301 operates transiently when removing / replacing payload data from the replayable execution trace 113, so that multiple instances of that payload data (including derivatives) are removed / replaced from the replayable execution trace 113. For example, suppose the strcpy() function described above is a ToLower() function which includes the following:

[0093]

number

[0094]

[0099] Therefore, at least some embodiments of this specification operate to remove payload data from execution traces, which has the technical effect of promoting data security by preventing sensitive data items from being inadvertently exposed through execution traces. Furthermore, excluding payload data from execution traces can significantly increase the compression ratio of those execution traces. In any case, excluding payload data from execution traces can significantly reduce the size of the execution traces, which has the additional technical effect of saving computing resources. For example, reducing the size of execution traces saves processing resources when analyzing those execution traces, and also saves storage and network resources required when storing and transmitting execution traces.

[0095]

[0100] This disclosure discusses embodiments of using entropy analysis to prevent payload data from being included in code execution log data, and embodiments for removing payload data from reproducible execution traces. Note that these two embodiments can be implemented individually or in combination. For example, when discussing embodiments of entropy analysis, it was stated that preventing payload data items from being included in code execution log data may include replacing payload data items with one or more of the following: alternative data, constraints on payload data items, or code flow overrides. In particular, these prevention techniques are further disclosed in connection with embodiments of payload data removal. Furthermore, embodiments of payload data removal identify payload data items to be removed, and in some implementations, payload data items are identified at least partially based on entropy analysis.

[0096]

[0101] While the subject matter has been described in terms specific to structural features and / or methodological operations, it should be understood that the subject matter as defined in the attached claims is not necessarily limited to the above features or operations, or the above sequence of operations. Rather, the above features and operations are disclosed as exemplary forms of implementing the claims.

[0097]

[0102] The present invention may also be embodied in other specific forms without departing from its essential features. The embodiments described herein should be considered in all respects as illustrative only and not as limitations. Accordingly, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All modifications within the meaning and scope of the equivalents of the claims shall be encompassed within that scope. When introducing elements in the appended claims, the articles “a,” “an,” “the,” and “said” are intended to mean that there is one or more elements. The terms “equip,” “include,” and “have” are intended to be inclusive and mean that there may be additional elements other than those listed. Unless otherwise specified, the terms “set,” “superset,” and “subset” are intended to exclude empty sets; therefore, “set” is defined as a non-empty set, “superset” as a non-empty superset, and “subset” as a non-empty subset. Unless otherwise specified, the term “subset” excludes its entire superset (i.e., a superset includes at least one item not included in a subset). Unless otherwise specified, a "superset" can include at least one additional element, and a "subset" can exclude at least one element.

Claims

1. A method implemented in a computer system including a processor to prevent payload data from being included in code execution log data, The steps include determining whether a payload data item associated with code execution log data has entropy exceeding a predetermined entropy threshold, The steps include identifying specific executable code that interacted with the payload data item, The steps include taking preventative actions to exclude the payload data item from being included in the execution log of the specific executable code, and A method that includes this.

2. A method according to claim 1, wherein the step of determining that the payload data item has an entropy exceeding a predetermined entropy threshold includes the step of determining that the payload data item has an intrinsic entropy exceeding the predetermined entropy threshold.

3. The method according to claim 2, wherein the step of determining that the payload data item has an intrinsic entropy exceeding a predetermined entropy threshold is: A step of calculating the ratio between the number of bits of entropy in the payload data item and the total number of bits in the payload data item, A step of calculating the compressibility of the payload data item. A method that includes at least one of the following.

4. A method according to claim 1, wherein the step of determining that the payload data item has entropy exceeding a predetermined entropy threshold includes the step of determining that the payload data item has contextual entropy exceeding a predetermined entropy threshold, wherein the contextual entropy is relating to a plurality of related payload data items identified from a plurality of related code execution logs.

5. A method according to claim 1, wherein the step of identifying the specific executable code that interacted with the payload data item includes the step of identifying the executable code that consumed the payload data item.

6. A method according to claim 1, wherein the step of identifying the specific executable code that interacted with the payload data item includes the step of identifying the executable code that generated the payload data item.

7. A method according to claim 1, wherein the step of identifying the specific executable code that interacted with the payload data item includes the step of identifying a specific executable instruction.

8. A method according to claim 1, wherein the step of identifying the particular executable code that interacted with the payload data item includes the step of identifying a particular function.

9. A method according to claim 1, wherein the preventive action includes the step of preventing the payload data item from being exported from the computer system.

10. A method according to claim 1, wherein the preventive action includes the step of preventing the payload data item from being included in the code execution log data.

11. A method according to claim 10, wherein the step of preventing the payload data item from being included in the code execution log data includes replacing the payload data item in the code execution log data with one or more of the following: (i) alternative data; (ii) one or more constraints on the payload data item; and (iii) code flow overrides relating to the particular executable code.

12. A method according to claim 1, wherein the preventive action includes the step of adding the payload data item to a blocklist by reference to the specific executable code, the blocklist being structured to prevent the payload data item from being included in code execution log data generated later.

13. A method according to claim 1, wherein the step of determining that a payload data item has an entropy exceeding a predetermined entropy threshold includes the step of identifying the payload data item from a block list, at least on the basis of a reference to a particular executable code.

14. A method according to claim 1, wherein the step of determining that the payload data item has an entropy exceeding a predetermined entropy threshold includes the step of identifying the payload data item during post-processing of the code execution log data.

15. A method according to claim 1, which is transiently applied to prevent additional instances or derivatives of a payload data item from being included in another execution record of another executable code.

Images