Generating and signing line-of-code behavior and relation model

Abstract

To provide a method of analyzing control flow integrity based on functional line-of-code behavior and relation models.SOLUTION: A method of generating and signing line-of-code behavior and relation models is provided, the method comprising: identifying executable code for a controller; performing a functional analysis of the executable code to determine a plurality of functions associated with the executable code and a plurality of relationships between the plurality of functions; generating, based on the determined plurality of functions and plurality of relationships, a line-of-code behavior and relation model for the executable code; performing a signature operation on the generated line-of-code behavior and relation model to produce a unique signature value associated with at least one of the line-of-code behavior and relation model and a functional block of the line-of-code behavior and relation model; and linking the unique signature value to the line-of-code behavior and relation model.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Patent Application No. 62 / 823,131, filed March 25, 2019, which is incorporated by reference in its entirety.

[0002] The subject matter described herein generally relates to techniques for providing analysis and security to vehicle software and systems, as well as various other types of Internet of Things (IoT) or network-connected systems that utilize controllers, such as electronic control units (ECUs) or other controllers. For example, certain disclosed embodiments are directed to generating and signing line-of-code behavior and relationship models. These techniques may include providing a status of software functionality changes following changes to the code. Some techniques may involve identifying software interdependencies through line-of-code behavior and relationship models, matching sources of software malfunctions among disparate code sources, and / or identifying software dependencies through line-of-code behavior and relationship models. Other techniques may anticipate the impact of hardware changes using line-of-code behavior and relationship models. Additionally, some techniques may relate to matching the integrity of controller software updates or providing dynamic control flow integrity through line-of-code behavior and relationship models. As yet another example, some techniques may provide dynamic visualization of code execution through line-of-code behavior and relationship models. [Background technology]

[0003] Modern vehicles and other Internet of Things (IoT) systems often utilize many different controllers, which may require software changes from time to time. These software changes present many challenges. For example, in traditional systems, to approve software changes over the air, the controller may have a communication channel that may be vulnerable to attack, such as through the introduction of malicious software files. In some scenarios, such vulnerabilities may be amplified by a lack of authentication of software changes (e.g., updates, upgrades, patches, fixes, recalibration, configuration management, etc.) in devices such as controllers. As another example, software developers may have difficulty determining the functional effects caused by code changes that may extend beyond a single component to other components or even to the entire system. This may lead to unintended changes in the system, which in some cases may impair functionality or even put users at risk (e.g., critical components in the vehicle are compromised). In many traditional settings, pointing out differences in functional effects between pieces of software and determining the propagation effects of such differences may be resource intensive (if at all possible). Furthermore, verifying whether a software update preserves functional equivalence can be difficult to accomplish through traditional means and can require a lengthy process using large amounts of data and bandwidth to perform such a verification. Often, current methods provide developers with only a cursory understanding of the functional impact, or a line-of-code intensive display that does not highlight important functional information, making it a time- and resource-intensive process for users to understand the possible functional changes that may result from code modifications.

[0004] Traditional software analysis and security techniques are currently not equipped to address these issues. For example, they lack proper techniques for determining the functional changes introduced by new code, determining the pervasive impact of the functional changes, and ensuring functional consistency while preventing the installation of functionally disruptive, unauthorized, and / or malicious software updates. Furthermore, many current methods also do not inform software developers of functional changes, regardless of their degree of disruption.

[0005] In light of the technical shortcomings of current systems, there is a need for improved systems and methods for providing comprehensive security protection for controllers and systems. The techniques discussed below provide many technical improvements in security, efficiency, verifiability, and availability. For example, according to some techniques, the code for the controller may be functionally analyzed and a line-of-code behavior and relationship model may be generated. A signature operation may be performed on the line-of-code behavior and relationship model, which may allow for rapid assessment of the line-of-code behavior and relationship model against the code or another model without having to scrutinize the entire model.

[0006] Related advantages may result from the disclosed methods, which involve functional difference comparisons of two line-of-code behavior and relationship models. Such comparisons may result in a status and / or degree of determined functional equivalence. This information may be used by devices, systems, and / or users to make decisions regarding software changes.

[0007] The line-of-code behavior and relationship models as described herein may also enable the detection of software interdependencies. For example, according to some disclosed techniques, functional line-of-code behavior and relationship models may be analyzed in conjunction with possible software updates, etc. to identify interdependencies between different pieces of code on the same controller.

[0008] As yet another advantage, the disclosed techniques allow for identification of code or devices affected by a potential software change as well as an associated source. Using this identification, notifications can be sent to the associated source to ensure faster system or device repair.

[0009] The disclosed embodiments also relate to anticipating the impact of hardware changes. For example, a new piece of hardware may prompt an analysis process that leverages line-of-code behavior and relationship models to determine the functional equivalence status for the new piece of hardware. Based on the determined status, other responsive actions may be used to enable a more seamless implementation of the hardware into the system.

[0010] Similar to identifying software interdependencies, identifying software dependencies may also be accomplished using the disclosed techniques. For example, multiple line-of-code behavior and relationship models may be used to trace the effects of code changes throughout the system, enabling early identification of unintended consequences within the system and safe deployment of new software.

[0011] The disclosed embodiments also relate to verifying the integrity of the controller software update. For example, the line of code behavior and relationship model and / or signature value may be used by the controller to verify that the received update is legitimate and appropriate for execution. In some cases, the controller may receive only the signature value and calculate its own line of code behavior and relationship model and signature value, reducing distortion on the wireless bandwidth while still allowing the controller to be sure that the received software change will not interfere with its operation.

[0012] Additionally, some disclosed techniques enable dynamic control-flow synthesis using line-of-code behavior and relational models. For example, the line-of-code behavior and relational models may be used to build dynamic control-flow integrity models that are based on the runtime behavior of the controller and that may be deployed to the controller. In this manner, functional analysis of the runtime behavior may be used to provide continued secure operation of the controller.

[0013] Additionally, some disclosed techniques provide improved visualization of functional changes within a system or device by building code line behavior and relationship models. For example, visual representations of code line behavior and relationship models may be displayed and may dynamically change based on user interactions, code changes, device changes, and the like. Such representations may simplify information that would otherwise be time and resource intensive to analyze. Summary of the Invention [Means for solving the problem]

[0014] Some disclosed embodiments describe non-transitory computer-readable media, systems, and methods for using a line-of-code behavior and relationship model. For example, in an exemplary embodiment, the non-transitory computer-readable media may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for generating and signing a line-of-code behavior and relationship model. The operations may include identifying executable code for a controller, performing a functional analysis of the executable code to determine a plurality of functions and a plurality of relationships between the plurality of functions associated with the executable code, generating a line-of-code behavior and relationship model for the executable code based on the determined plurality of functions and relationships, performing a signature operation on the generated line-of-code behavior and relationship model to generate a unique signature value associated with at least one of the line-of-code behavior and relationship model or a functional block of the line-of-code behavior and relationship model, and linking the unique signature value to the line-of-code behavior and relationship model.

[0015] According to a further embodiment, the operations further include assigning a unique signature value to the executable code.

[0016] According to a further embodiment, the operations further include transmitting the line of code behavior and relationship model along with the assigned signature value to a remote device.

[0017] According to a further embodiment, the executable code is a software change delta file.

[0018] According to a further embodiment, the signature value is a hash value.

[0019] According to a further embodiment, the step of generating the line of code behavior and relationship model is performed through a machine learning process.

[0020] According to a further embodiment, the machine learning process is a statistical classification process.

[0021] According to a further embodiment, the machine learning process is a dynamic analysis process.

[0022] According to a further embodiment, the machine learning process includes determining a sequence of functions associated with the executable code.

[0023] According to a further embodiment, the machine learning process includes determining a relationship between at least two of the features of the sequence.

[0024] Further disclosed embodiments include a method for generating and signing a line-of-code behavior and relationship model, which may include identifying an executable code for a controller, performing a functional analysis of the executable code to determine a plurality of functions and a plurality of relationships between the plurality of functions associated with the executable code, generating a line-of-code behavior and relationship model for the executable code based on the determined plurality of functions and relationships, performing a signature operation on the generated line-of-code behavior and relationship model to generate a unique signature value associated with at least one of the line-of-code behavior and relationship model or a functional block of the line-of-code behavior and relationship model, and linking the unique signature value to the line-of-code behavior and relationship model.

[0025] According to a further embodiment, the method further comprises assigning a unique signature value to the executable code.

[0026] According to a further embodiment, the method further comprises transmitting the line of code behavior and relationship model together with the assigned signature value to a remote device.

[0027] According to a further embodiment, the executable code is a software change delta file.

[0028] According to a further embodiment, the unique signature value is a cryptographic nonce number.

[0029] According to a further embodiment, the controller is a virtual controller.

[0030] According to a further embodiment, the controller is an electronic control unit (ECU) of the vehicle.

[0031] According to a further embodiment, linking the unique signature values ​​comprises compressing the relationship model.

[0032] According to a further embodiment, the signing operation is based on the number of functions or at least one type of function associated with the executable code.

[0033] According to a further embodiment, the signing operation is based on the number of relations or a function associated with at least one of the relations.

[0034] In another exemplary embodiment, a non-transitory computer-readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for determining software functionality changes using a line of code behavior and relationship model. The operations may include identifying a first portion of executable code and a second portion of executable code, accessing the first line of code behavior and relationship model representing execution of a function of the first portion of executable code, constructing a second line of code behavior and relationship model representing execution of a function of the second portion of executable code based on the second portion of executable code, performing a functional difference comparison of the first line of code behavior and relationship model and the second line of code behavior and relationship model, determining a status of functional equivalence between the first portion of executable code and the code portion of executable code based on the functional difference comparison, and generating a report identifying a status of functional equivalence based on the determined differences.

[0035] According to a further embodiment, the functional equivalence status includes an equivalence or non-equivalence status.

[0036] According to a further embodiment, the functional equivalence status includes a degree of equivalence.

[0037] According to a further embodiment, the operations further include determining that the degree of equivalence does not reach a threshold and generating a prompt based on determining that the degree of equivalence does not reach a threshold.

[0038] According to a further embodiment, the comparison includes determining whether the functionality of the first portion of the executable code falls within an operational envelope related to at least one of CPU cycles, memory requirements, speed of execution, or functionality relationships.

[0039] According to a further embodiment, at least one of the execution of the functions of the first portion of the executable code or the execution of the functions of the second portion of the executable code is execution on a physical controller.

[0040] According to a further embodiment, at least one of the execution of the functions of the first portion of the executable code or the execution of the functions of the second portion of the executable code is execution on a virtualized controller.

[0041] According to a further embodiment, the functional difference comparison is based on at least one of differences in response times, sequences of function execution, or memory leakage.

[0042] According to a further embodiment, if the result of the functional difference comparison exceeds a threshold value, the operations further include determining an estimated probability of downtime based on the difference.

[0043] According to a further embodiment, the estimated probability of a downtime is expressed as a probability of the downtime within a defined time period.

[0044] According to a further embodiment, the operations further include linking at least one of the functions of the second portion of the executable code to at least a segment of the second portion of the executable code.

[0045] According to a further embodiment, the accessed line of code behavior and relationship model was generated according to a machine learning process.

[0046] According to a further embodiment, the operations further include determining, based on the functional difference comparison, that a third portion of the executable code is dormant.

[0047] According to a further embodiment, the first or second line of code behavior and relationship model is dynamically generated.

[0048] According to a further embodiment, the first or second line of code behavior and relationship model is statically generated.

[0049] According to a further embodiment, the report further identifies at least one instance of functionality drift.

[0050] Further disclosed embodiments include a method for determining software functionality changes using a line of code behavior and relationship model, which may include identifying a first portion of executable code and a second portion of executable code, accessing a first line of code behavior and relationship model representing execution of a function of the first portion of executable code, constructing a second line of code behavior and relationship model representing execution of a function of the second portion of executable code based on the second portion of executable code, performing a functional difference comparison of the first line of code behavior and relationship model and the second line of code behavior and relationship model, determining a status of functional equivalence between the first portion of executable code and the code portion of executable code based on the functional difference comparison, and generating a report identifying a status of functional equivalence based on the determined differences.

[0051] According to a further embodiment, the functional equivalence status includes an equivalence or non-equivalence status.

[0052] According to a further embodiment, the comparison includes determining whether the functionality of the first portion of the executable code falls within an operational envelope related to at least one of CPU cycles, memory requirements, speed of execution, or functionality relationships.

[0053] According to a further embodiment, the accessed line of code behavior and relationship model was generated according to a machine learning process.

[0054] In another exemplary embodiment, a non-transitory computer-readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for identifying software interdependencies based on a functional line of code behavior and relationship model. The operations may include identifying a first portion of executable code associated with a first controller, accessing a functional line of code behavior and relationship model representing functionality of the first portion of executable code and a second portion of executable code, determining that the second portion of executable code is interdependent with the first portion of executable code based on the functional line of code behavior and relationship model, and generating a report that identifies the first portion of executable code and the second portion of executable code that are interdependent based on the determined interdependencies.

[0055] According to a further embodiment, the operations further include identifying a first signature that uniquely identifies the first portion of the executable code and a second signature that uniquely identifies a second portion of the executable code.

[0056] According to a further embodiment, the first and second portions of the executable code are implemented on a virtualized controller.

[0057] According to a further embodiment, a second portion of the executable code is associated with the first controller.

[0058] According to a further embodiment, a second portion of the executable code is associated with a second controller.

[0059] According to a further embodiment, the first and second controllers are part of the same device.

[0060] According to a further embodiment, the device is at least part of a vehicle.

[0061] According to a further embodiment, the operations further include determining a functional impact of the second portion of the executable code on the first portion of the executable code.

[0062] According to a further embodiment, a first sensitivity value is associated with a first portion of the executable code and a second sensitivity value is associated with a second portion of the executable code, and the functional impact is based on the first or second sensitivity value.

[0063] According to a further embodiment, the functional impact is included in the generated report.

[0064] According to a further embodiment, the operations further include generating a visual representation of the determined interdependencies.

[0065] According to a further embodiment, the operations further include determining that the functional impact exceeds a threshold, and the visual depiction is based on the determination that the functional impact exceeds the threshold.

[0066] According to a further embodiment, the visual representation includes visual elements of the determined interdependencies, a visual element of a first portion of the executable code, a visual element of a second portion of the executable code, and a visual element of another portion of the executable code.

[0067] Further disclosed embodiments include a method for identifying software interdependencies based on a functional line of code behavior and relationship model, which may include identifying a first portion of executable code associated with a first controller, accessing a functional line of code behavior and relationship model representing functionality of the first portion of executable code and a second portion of executable code, determining that the second portion of executable code is interdependent with the first portion of executable code based on the functional line of code behavior and relationship model, and generating a report that identifies the first portion of executable code and the second portion of executable code that are interdependent based on the determined interdependencies.

[0068] According to a further embodiment, the method further includes identifying a first signature that uniquely identifies the first portion of the executable code and a second signature that uniquely identifies the second portion of the executable code.

[0069] According to a further embodiment, a second portion of the executable code is associated with the first controller.

[0070] According to a further embodiment, a second portion of the executable code is associated with a second controller.

[0071] According to a further embodiment, the method further includes determining a functional impact of the second portion of the executable code on the first portion of the executable code.

[0072] According to a further embodiment, a first sensitivity value is associated with a first portion of the executable code and a second sensitivity value is associated with a second portion of the executable code, and the functional impact is based on the first or second sensitivity value.

[0073] According to a further embodiment, the functional impact is included in the generated report.

[0074] In another exemplary embodiment, a non-transitory computer-readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for identifying a source of a software-based malfunction. The operations may include identifying a potential software malfunction in a system, the system having a plurality of sets of code associated with a plurality of different software sources, accessing a line of code behavior and relationship model that represents execution of functions of the sets of code, identifying sets of code that are determined to have a potential to cause the potential software malfunction, at least in part, based on the line of code behavior and relationship model, and determining a source identifier for the identified sets of code.

[0075] According to a further embodiment, a plurality of code sets are associated with at least one controller of the system.

[0076] According to a further embodiment, the accessed line of code behavior and relationship models are dynamically generated based on data associated with real-time operation of at least one controller.

[0077] According to a further embodiment, the line of code behavior and relationship model represents the execution of the functionality of the identified set of code.

[0078] According to a further embodiment, the multiple sets of code are developed by multiple different software developers.

[0079] According to a further embodiment, a number of different software developers each have a unique source identifier.

[0080] According to a further embodiment, the operations further include transmitting a report of the potential software malfunction to a remote source associated with the identified source identifier.

[0081] According to a further embodiment, the identification of potential software malfunctions within the system is based on recent software changes to components of the system.

[0082] According to a further embodiment, the software changes were implemented on the components using a delta file.

[0083] According to a further embodiment, the operations further include sending a report of the potential software malfunction to a remote source associated with the identified source identifier, wherein the delta file is associated with a unique identifier, and the unique identifier is included in the report.

[0084] According to a further embodiment, the operations further include reverting the software on the component by unlinking the delta file from the current software on the component.

[0085] According to a further embodiment, the system is a virtual system.

[0086] Further disclosed embodiments include a method for identifying a source of a software-based malfunction, which may include identifying a potential software malfunction in a system having a plurality of sets of code associated with a plurality of different software sources, accessing a line of code behavior and relationship model representing execution of functions of the sets of code, identifying a set of code that is determined to be causing the potential software malfunction, at least in part, based on the line of code behavior and relationship model, and determining a source identifier for the identified set of code.

[0087] According to a further embodiment, a plurality of code sets are associated with at least one controller of the system.

[0088] According to a further embodiment, the accessed line of code behavior and relationship models are dynamically generated based on data associated with real-time operation of at least one controller.

[0089] According to a further embodiment, the line of code behavior and relationship model represents the execution of the functionality of the identified set of code.

[0090] According to a further embodiment, the multiple sets of code are developed by multiple different software developers.

[0091] According to a further embodiment, a number of different software developers each have a unique source identifier.

[0092] According to a further embodiment, the operations further include transmitting a report of the potential software malfunction to a remote source associated with the identified source identifier.

[0093] According to a further embodiment, the identification of potential software malfunctions within the system is based on a delta file executed within the system.

[0094] In another exemplary embodiment, a non-transitory computer-readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for analyzing hardware change impact based on at least one functional line-of-code behavior and relationship model. The operations may include identifying a new hardware component associated with the system, accessing a first line-of-code behavior and relationship model representing execution of a function using the new hardware component, accessing a second line-of-code behavior and relationship model representing execution of the function on a previous hardware component of the system, performing a functional difference comparison of the first line-of-code behavior and relationship model and the second line-of-code behavior and relationship model, determining a status of functional equivalence between the new hardware component and the previous hardware component based on the functional difference comparison, and generating a report identifying a status of functional equivalence based on the determined differences.

[0095] According to a further embodiment, the second line of code behavior and relationship model was dynamically generated based on data associated with real-time operation of the previous hardware component.

[0096] According to a further embodiment, the first line of code behavior and relationship model was generated based on data associated with simulated operation of the new hardware component.

[0097] According to a further embodiment, the new hardware component is a controller.

[0098] According to a further embodiment, the system is a vehicle and the controller is an electronic control unit (ECU).

[0099] According to a further embodiment, the operations further include determining that the new hardware component is not authorized based on the determined difference.

[0100] According to a further embodiment, the operations further include blocking operation of the new hardware component based on determining that the new hardware component is unauthorized.

[0101] According to a further embodiment, the controller is a first controller and the operations further include determining that the at least one hardware component is a second controller dependent on the first controller.

[0102] According to a further embodiment, the previous hardware component is to be replaced by a new hardware component.

[0103] According to a further embodiment, the operations further include determining that at least one hardware component is interdependent on the new hardware component.

[0104] According to a further embodiment, the operations further include accessing a third line of code behavior and relationship model, the third model representing execution of the function on the at least one dependent hardware component and the previous hardware component; generating a fourth line of code behavior and relationship model, the fourth model representing execution of the function on the at least one dependent hardware component and the new hardware component; performing a functional difference comparison of the third model and the fourth model; determining changes in functional equivalence in the system based on the functional difference comparison; and generating a report identifying the changes based on the determined differences.

[0105] Further disclosed embodiments include a method for analyzing hardware change impact based on at least one functional line-of-code behavior and relationship model, which may include identifying a new hardware component associated with a system, accessing a first line-of-code behavior and relationship model representing execution of a function using the new hardware component, accessing a second line-of-code behavior and relationship model representing execution of the function on a previous hardware component of the system, performing a functional difference comparison of the first line-of-code behavior and relationship model and the second line-of-code behavior and relationship model, determining a status of functional equivalence between the new hardware component and the previous hardware component based on the functional difference comparison, and generating a report identifying the status of functional equivalence based on the determined differences.

[0106] According to a further embodiment, the second line of code behavior and relationship model was dynamically generated based on data associated with real-time operation of the previous hardware component.

[0107] According to a further embodiment, the first line of code behavior and relationship model was generated based on data associated with simulated operation of the new hardware component.

[0108] According to a further embodiment, the operations further include determining that the new hardware component is not authorized based on the determined difference.

[0109] According to a further embodiment, the operations further include blocking operation of the new hardware component based on determining that the new hardware component is unauthorized.

[0110] According to a further embodiment, the controller is a first controller and the operations further include determining that the at least one hardware component is a second controller dependent on the first controller.

[0111] According to a further embodiment, the previous hardware component is to be replaced by a new hardware component.

[0112] According to a further embodiment, the operations further include determining that at least one hardware component is interdependent on the new hardware component.

[0113] According to a further embodiment, the operations further include accessing a third line of code behavior and relationship model, the third model representing execution of the function on the at least one dependent hardware component and the previous hardware component; generating a fourth line of code behavior and relationship model, the fourth model representing execution of the function on the at least one dependent hardware component and the new hardware component; performing a functional difference comparison of the third model and the fourth model; determining changes in functional equivalence in the system based on the functional difference comparison; and generating a report identifying the changes based on the determined differences.

[0114] In another exemplary embodiment, a non-transitory computer-readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for identifying software dependencies based on a functional line of code behavior and relationship model. The operations may include accessing a first line of code behavior and relationship model representing execution of a function of a first portion of executable code, the first portion of executable code being associated with a first symbol, detecting changes to the first portion of executable code, constructing a second line of code behavior and relationship model representing execution of a function of the modified first portion of executable code based on the modified first portion of executable code, determining a dependency between (i) the modified first portion of executable code or a first symbol and (ii) a second symbol based on the constructed second model, and generating a report that identifies the dependency based on the determined difference.

[0115] According to a further embodiment, the second symbol is at least one of a variable, a buffer, a function, a call, an object, or a segment of code.

[0116] According to a further embodiment, the operations further include determining an impact on a second symbol caused by the modified first portion of the executable code, and the report further identifies the impact.

[0117] According to a further embodiment, a first sensitivity value is associated with a first portion of the executable code and a second sensitivity value is associated with a second symbol, and the impact is based on the first or second sensitivity value.

[0118] According to a further embodiment, the first portion of the executable code is configured to execute on a first controller and the second symbol is associated with a second controller.

[0119] According to a further embodiment, the operations further include determining the dependency by running a second model remotely from the first and second controllers.

[0120] According to a further embodiment, the first and second controllers are part of a group of electronic control units (ECUs) in the vehicle.

[0121] According to a further embodiment, the dependency comprises a strength of association between the first symbol and the second symbol.

[0122] According to a further embodiment, the strength of the association is based on the frequency with which the first symbol interacts with the second symbol.

[0123] According to a further embodiment, the strength of the association is based on the first portion of the executable code being configured to call or modify the second symbol.

[0124] According to a further embodiment, the operations further include generating a visual representation of the determined dependencies.

[0125] Further disclosed embodiments include a method for identifying software dependencies based on a functional line of code behavior and relationship model, which may include the steps of: accessing a first line of code behavior and relationship model representing execution of a function of a first portion of executable code, the first portion of executable code being associated with a first symbol; detecting changes to the first portion of executable code; constructing a second line of code behavior and relationship model representing execution of a function of the modified first portion of executable code based on the modified first portion of executable code; determining a dependency between (i) the modified first portion of executable code or a first symbol and (ii) a second symbol based on the constructed second model; and generating a report that identifies the dependency based on the determined difference.

[0126] According to a further embodiment, the second symbol is at least one of a variable, a buffer, a function, a call, an object, or a segment of code.

[0127] According to a further embodiment, the operations further include determining an impact on a second symbol caused by the modified first portion of the executable code, and the report further identifies the impact.

[0128] According to a further embodiment, a first sensitivity value is associated with a first portion of the executable code and a second sensitivity value is associated with a second symbol, and the impact is based on the first or second sensitivity value.

[0129] According to a further embodiment, the first portion of the executable code is configured to execute on a first controller and the second symbol is associated with a second controller.

[0130] According to a further embodiment, the first and second controllers are part of a group of electronic control units (ECUs) in the vehicle.

[0131] According to a further embodiment, the dependency comprises a strength of association between the first symbol and the second symbol.

[0132] According to a further embodiment, the strength of the association is based on the frequency with which the first symbol interacts with the second symbol.

[0133] According to a further embodiment, the strength of the association is based on the first portion of the executable code being configured to call or modify the second symbol.

[0134] In another exemplary embodiment, a non-transitory computer-readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for analyzing software delta changes based on a functional line-of-code behavior and relationship model. The operations may include identifying a prompt for changing a first version of code on a controller to a second version of code, constructing a line-of-code behavior and relationship model representing execution of a function of the controller based on the second version of code based on the identified prompt, performing a signature operation on the generated line-of-code behavior and relationship model to generate a signature value, and transmitting the signature value to the controller, where the controller is configured to compare the signature value to a calculated signature value that the controller is configured to calculate based on the second version of code, and determine whether to verify the second version of code based on the comparison.

[0135] According to a further embodiment, the prompt comprises a delta file.

[0136] According to a further embodiment, the controller is further configured to execute a second version of the code on the controller based on the verification.

[0137] According to a further embodiment, the controller is further configured to prevent execution of the second version of the code on the controller based on the verification.

[0138] According to a further embodiment, the controller is further configured to notify a remote source associated with the second version of the code based on the verification.

[0139] According to a further embodiment, the second version of the code is deployed subsequent to the first version of the code.

[0140] According to a further embodiment, the line of code behavior and relationship model is a first line of code behavior and relationship model, and calculating the calculated signature value includes constructing a second line of code behavior and relationship model representing execution of a function of the controller based on a second version of the code based on the identified prompt.

[0141] According to a further embodiment, the calculated signature value is calculated by using a signature operation.

[0142] According to a further embodiment, at least one of the first or second line of code behavior and relationship models are dynamically generated based on data associated with real-time operation of the controller.

[0143] According to a further embodiment, the first and second line of code behavior and relationship models are dynamically generated based on data associated with real-time operation of the controller, the data being limited based on a group of parameters set remotely from the controller.

[0144] According to a further embodiment, the signature operation is based on an identifier of the controller.

[0145] According to further embodiments, the signature calculation is based on the controller type, functionality, software version, sensitivity value, age, or processing capacity.

[0146] Further disclosed embodiments include a method for analyzing software delta changes based on a functional line-of-code behavior and relationship model. The method may include identifying prompts for changing a first version of code on a controller to a second version of code, constructing a line-of-code behavior and relationship model representing execution of a function of the controller based on the second version of code based on the identified prompts, performing a signature operation on the generated line-of-code behavior and relationship model to generate a signature value, and transmitting the signature value to the controller, where the controller is configured to compare the signature value with a calculated signature value that the controller is configured to calculate based on the second version of code, and determine whether to verify the second version of code based on the comparison.

[0147] According to a further embodiment, the prompt comprises a delta file.

[0148] According to a further embodiment, the controller is further configured to execute a second version of the code on the controller based on the verification.

[0149] According to a further embodiment, the line of code behavior and relationship model is a first line of code behavior and relationship model, and calculating the calculated signature value includes constructing a second line of code behavior and relationship model representing execution of a function of the controller based on a second version of the code based on the identified prompt.

[0150] According to a further embodiment, the calculated signature value is calculated by using a signature operation.

[0151] According to a further embodiment, at least one of the first or second line of code behavior and relationship models are dynamically generated based on data associated with real-time operation of the controller.

[0152] According to a further embodiment, the first and second line of code behavior and relationship models are dynamically generated based on data associated with real-time operation of the controller, the data being limited based on a group of parameters set remotely from the controller.

[0153] According to further embodiments, the signature calculation is based on the controller type, functionality, software version, sensitivity value, age, or processing capacity.

[0154] In another exemplary embodiment, a non-transitory computer-readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for analyzing control flow integrity based on a functional line of code behavior and relationship model. The operations may include receiving data based on runtime operation of a controller, building a line of code behavior and relationship model representing execution of a function on the controller based on the received data, building a dynamic control flow integrity model based on the line of code behavior and relationship model, the dynamic control flow integrity model being configured for enforcement by the controller in real time, and deploying the dynamic control flow integrity model to the controller.

[0155] According to a further embodiment, the controller is configured to detect a request to execute code on the controller and compare the requested execution to the dynamic control flow integrity model.

[0156] According to a further embodiment, the controller is configured to deny execution of code on the controller if the requested execution violates a dynamic control flow integrity model.

[0157] According to a further embodiment, the controller is configured to generate an alert if the required execution violates the dynamic control flow integrity model.

[0158] According to a further embodiment, the operations further include identifying software changes to the controller, and the line of code behavior and relationship model is constructed based on the identified software changes.

[0159] According to a further embodiment, the controller is a first controller and the data is further based on a runtime operation of a second controller.

[0160] According to a further embodiment, the operations are performed periodically according to a period based on a sensitivity value associated with the controller.

[0161] According to a further embodiment, the received data includes a plurality of data sets associated with different runtime operations, and the operations further include applying a machine learning process to the plurality of data sets to generate analysis data, and the line of code behavior and structure of the relational model are based on the analysis data.

[0162] According to a further embodiment, the operations further include performing a signature operation on the constructed line-of-code behavior and relationship model to generate a signature value, and deploying a dynamic control flow integrity model to the controller using the signature value.

[0163] According to a further embodiment, the controller is configured to compare the signature value to a calculated signature value that the controller is configured to calculate based on the received data, and to determine based on the comparison whether to verify the dynamic control flow integrity model.

[0164] Further disclosed embodiments include a method for analyzing control flow integrity based on a functional line-of-code behavior and relational model, which may include receiving data based on runtime operation of a controller, building a line-of-code behavior and relational model representing execution of a function on the controller based on the received data, building a dynamic control flow integrity model based on the line-of-code behavior and relational model, the dynamic control flow integrity model configured for enforcement by the controller in real time, and deploying the dynamic control flow integrity model to the controller.

[0165] According to a further embodiment, the controller is configured to detect a request to execute code on the controller and compare the requested execution to the dynamic control flow integrity model.

[0166] According to a further embodiment, the controller is configured to deny execution of code on the controller if the requested execution violates a dynamic control flow integrity model.

[0167] According to a further embodiment, the controller is configured to generate an alert if the required execution violates the dynamic control flow integrity model.

[0168] According to a further embodiment, the operations further include identifying software changes to the controller, and the line of code behavior and relationship model is constructed based on the identified software changes.

[0169] According to a further embodiment, the controller is a first controller and the data is further based on a runtime operation of a second controller.

[0170] According to a further embodiment, the operations are performed periodically according to a period based on a sensitivity value associated with the controller.

[0171] According to a further embodiment, the received data includes a plurality of data sets associated with different runtime operations, and the operations further include applying a machine learning process to the plurality of data sets to generate analysis data, and the line of code behavior and structure of the relational model are based on the analysis data.

[0172] According to a further embodiment, the operations further include performing a signature operation on the constructed line-of-code behavior and relationship model to generate a signature value, and deploying a dynamic control flow integrity model to the controller using the signature value.

[0173] According to a further embodiment, the controller is configured to compare the signature value to a calculated signature value that the controller is configured to calculate based on the received data, and to determine based on the comparison whether to verify the dynamic control flow integrity model.

[0174] In another exemplary embodiment, a non-transitory computer readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for visualizing and configuring a controller function sequence. The operations may include identifying at least one executable code segment associated with the controller, analyzing the at least one executable code segment to determine at least one function and at least one functional relationship associated with the at least one code segment, building a software functionality code line behavior and relationship model that visually depicts the determined at least one function and at least one functional relationship, displaying the software functionality code line behavior and relationship model in a user interface, receiving a first input in the user interface, and animating the code line behavior and relationship model in response to the received first input to visually depict execution of the at least one executable code segment on the controller, receiving a second input in the user interface, and animating updates to the code line behavior and relationship model in response to the received second input.

[0175] According to a further embodiment, the operations further include determining an expected functional behavior of the controller and an actual functional behavior of the controller based on the analysis, and displaying, in a user interface, a visual indicator of the functional behavior corresponding to execution of the at least one executable code segment relative to the expected functional behavior.

[0176] According to a further embodiment, the operations further include determining a degree of deviation between the expected functional behavior and the actual functional behavior, estimating a probability of downtime for the controller based on the degree of deviation, and displaying an indication of the probability of downtime in a user interface.

[0177] According to a further embodiment, the operations further include accessing executable code configured to execute the software modification on the controller.

[0178] According to a further embodiment, the operations further include transmitting the alert to a remote device.

[0179] According to a further embodiment, animating the line of code behavior and relationship model to visually depict the execution of the at least one executable code segment includes highlighting a visual element of at least one function associated with the at least one code segment.

[0180] According to a further embodiment, the second input is associated with a code change on the controller.

[0181] According to a further embodiment, the controller is an electronic control unit (ECU) of the vehicle.

[0182] According to a further embodiment, the controller is a virtual controller.

[0183] According to a further embodiment, the code changes are represented by a delta file that is configured to change the code on the controller.

[0184] According to a further embodiment, the delta file is configured to change code on the controller from a first version of the code to a second version of the code.

[0185] Further disclosed embodiments include a method for visualizing and configuring controller function sequences, which may include identifying at least one executable code segment associated with a controller, analyzing the at least one executable code segment to determine at least one function and at least one functional relationship associated with the at least one code segment, building a software functionality code line behavior and relationship model visually depicting the determined at least one function and at least one functional relationship, displaying the software functionality code line behavior and relationship model in a user interface, receiving a first input in the user interface, and animating the code line behavior and relationship model in response to the received first input to visually depict execution of the at least one executable code segment on the controller, receiving a second input in the user interface, and animating updates to the code line behavior and relationship model in response to the received second input.

[0186] According to a further embodiment, the operations further include determining an expected functional behavior of the controller and an actual functional behavior of the controller based on the analysis, and displaying, in a user interface, a visual indicator of the functional behavior corresponding to execution of the at least one executable code segment relative to the expected functional behavior.

[0187] According to a further embodiment, the operations further include determining a degree of deviation between the expected functional behavior and the actual functional behavior, estimating a probability of downtime for the controller based on the degree of deviation, and displaying an indication of the probability of downtime in a user interface.

[0188] According to a further embodiment, the operations further include accessing executable code configured to execute the software modification on the controller.

[0189] According to a further embodiment, the operations further include transmitting the alert to a remote device.

[0190] According to a further embodiment, animating the line of code behavior and relationship model to visually depict the execution of the at least one executable code segment includes highlighting a visual element of at least one function associated with the at least one code segment.

[0191] According to a further embodiment, the second input is associated with a code change on the controller.

[0192] According to a further embodiment, the code changes are represented by a delta file that is configured to change the code on the controller.

[0193] According to a further embodiment, the delta file is configured to change code on the controller from a first version of the code to a second version of the code.

[0194] Aspects of the disclosed embodiments may include a tangible computer readable medium storing software instructions that, when executed by one or more processors, are configured and capable of implementing and performing one or more of the methods, operations, and equivalents consistent with the disclosed embodiments. Aspects of the disclosed embodiments may also be implemented by one or more processors configured as special purpose processors based on the software instructions that are programmed with logic and instructions that, when executed, perform one or more operations consistent with the disclosed embodiments. The present specification also provides, for example, the following items: (Item 1) 1. A non-transitory computer readable medium comprising instructions that, when executed by at least one processor, cause the at least one processor to perform operations for generating a line of code behavior and relationship model and signing the line of code behavior and relationship model, the operations comprising: identifying executable code for a controller; performing a functional analysis of the executable code to determine a number of functions associated with the executable code and a number of relationships between the number of functions; generating a line of code behavior and relationship model for the executable code based on the determined functions and relationships; performing a signature operation on the generated line-of-code behavior and relationship model to generate a unique signature value associated with at least one of the line-of-code behavior and relationship model or a functional block of the line-of-code behavior and relationship model; linking said unique signature value to said line of code behavior and relationship model; 16. A non-transitory computer readable medium comprising: (Item 2) 2. The non-transitory computer-readable medium of claim 1, wherein the operations further include assigning the unique signature value to the executable code. (Item 3) 3. The non-transitory computer-readable medium of claim 2, wherein the operations further include transmitting the line of code behavior and relationship model along with the assigned signature value to a remote device. (Item 4) 2. The non-transitory computer-readable medium of claim 1, wherein the executable code is a software change delta file. (Item 5) Item 1, wherein the signature value is a hash value. (Item 6) 2. The non-transitory computer-readable medium of claim 1, wherein the step of generating the line of code behavior and relationship model is performed through a machine learning process. (Item 7) 7. The non-transitory computer-readable medium of claim 6, wherein the machine learning process is a statistical classification process. (Item 8) 7. The non-transitory computer-readable medium of claim 6, wherein the machine learning process is a dynamic analysis process. (Item 9) 7. The non-transitory computer-readable medium of claim 6, wherein the machine learning process includes determining a sequence of functions associated with the executable code. (Item 10) 7. The non-transitory computer-readable medium of claim 6, wherein the machine learning process includes determining a relationship between at least two of the features of the sequence. (Item 11) 1. A computer-implemented method for generating a line-of-code behavior and relationship model and signing the line-of-code behavior and relationship model, the method comprising: identifying executable code for a controller; performing a functional analysis of the executable code to determine a number of functions associated with the executable code and a number of relationships between the number of functions; generating a line of code behavior and relationship model for the executable code based on the determined functions and relationships; performing a signature operation on the generated line-of-code behavior and relationship model to generate a unique signature value associated with at least one of the line-of-code behavior and relationship model or a functional block of the line-of-code behavior and relationship model; linking said unique signature value to said line of code behavior and relationship model; 4. A computer-implemented method comprising: (Item 12) Item 12. The computer-implemented method of item 11, further comprising assigning the unique signature value to the executable code. (Item 13) Item 12. The computer-implemented method of item 11, further comprising transmitting the line of code behavior and relationship model along with the assigned signature value to a remote device. (Item 14) Item 12. The computer-implemented method of item 11, wherein the executable code is a software change delta file. (Item 15) Item 12. The computer-implemented method of item 11, wherein the unique signature value is a cryptographic nonce number. (Item 16) Item 12. The computer-implemented method of item 11, wherein the controller is a virtual controller. (Item 17) Item 12. The computer-implemented method of item 11, wherein the controller is a vehicle electronic control unit (ECU). (Item 18) Item 12. The computer-implemented method of item 11, wherein linking the unique signature values ​​includes compressing the relationship model. (Item 19) Item 12. The computer-implemented method of item 11, wherein the signing operation is based on a number of functions associated with the executable code or at least one type of the functions. (Item 20) Item 12. The computer-implemented method of item 11, wherein the signing operation is based on the number of relations or a function associated with at least one of the relations.

[0195] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments as claimed. [Brief description of the drawings]

[0196] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments and, together with the description, serve to explain the disclosed principles.

[0197] [Figure 1A] FIG. 1A illustrates an example pictorial representation of a controller network for providing analysis and security to controllers consistent with an embodiment of the present disclosure.

[0198] [Figure 1B] FIG. 1B illustrates an example pictorial representation of a controller consistent with an embodiment of the present disclosure.

[0199] [Figure 1C] FIG. 1C illustrates an example pictorial representation of a security provider system consistent with an embodiment of the present disclosure.

[0200] [Diagram 2] FIG. 2 illustrates an example pictorial representation of a set of models with corresponding information tables, consistent with an embodiment of the present disclosure.

[0201] [Diagram 3] FIG. 3 illustrates an example pictorial representation of a line of code behavior and relationship model consistent with an embodiment of the present disclosure.

[0202] [Figure 4] FIG. 4 illustrates an example pictorial representation of an interface for analyzing code behavior, consistent with an embodiment of the present disclosure.

[0203] [Diagram 5] FIG. 5 illustrates an example pictorial representation of delta file software changes on a controller, consistent with an embodiment of the present disclosure.

[0204] [Figure 6]FIG. 6 depicts a flowchart of an exemplary process for generating and signing a line-of-code behavior and relationship model consistent with an embodiment of the present disclosure.

[0205] [Figure 7] FIG. 7 depicts a flowchart of an exemplary process for determining software functionality changes using line-of-code behavior and relationship models, consistent with embodiments of the present disclosure.

[0206] [Figure 8] FIG. 8 depicts a flowchart of an exemplary process for identifying software interdependencies based on functional line-of-code behavior and relationship models, consistent with an embodiment of the present disclosure.

[0207] [Figure 9] FIG. 9 depicts a flowchart of an exemplary process for identifying a source of a software-based malfunction or error consistent with an embodiment of the present disclosure.

[0208] [Figure 10] FIG. 10 depicts a flowchart of an example process for analyzing hardware change impact based on functional code line behavior and relationship models, consistent with an embodiment of the present disclosure.

[0209] [Figure 11] FIG. 11 depicts a flowchart of an exemplary process for identifying software dependencies based on functional line-of-code behavior and relationship models, consistent with embodiments of the present disclosure.

[0210] [Figure 12A] FIG. 12A depicts a flowchart of an example process for managing software delta changes using a functional line-of-code behavior and relationship model, consistent with embodiments of the present disclosure.

[0211] [Figure 12B]FIG. 12B depicts a flowchart of an example process for analyzing software delta changes based on functional code line behavior and relationship models, consistent with embodiments of the present disclosure.

[0212] [Figure 13] FIG. 13 depicts a flowchart of an exemplary process for analyzing control flow integrity based on functional code line behavior and relational models, consistent with embodiments of the present disclosure.

[0213] [Figure 14] FIG. 14 depicts a flowchart of an exemplary process for visualizing and configuring controller function sequences consistent with an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0214] Reference will now be made in detail to the exemplary embodiments disclosed herein, examples of which are illustrated in the accompanying drawings. Whenever convenient, the same reference numbers will be used throughout the drawings to refer to the same or similar parts. The disclosed embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosed embodiments. It is to be understood that other embodiments may be utilized and changes may be made without departing from the scope of the disclosed embodiments. Accordingly, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

[0215] FIG. 1A illustrates an example pictorial representation of a system 10, which may include system 100. System 100 may be maintained by a security provider, a software developer, an entity associated with developing or improving computer software, or any combination of these entities. System 100 may include a security provider 102, which may be a single device or a combination of devices, and is described in more detail with respect to FIG. 1C. Security provider 102 may communicate with any number of network resources, such as network resources 104a, 104b, and / or 104c. The network resources may be databases, supercomputers, general purpose computers, special purpose computers, virtual computing resources, or any other data storage or processing resources.

[0216] The system 10 may also include any number of controller systems, such as controller systems 108a, 108b, and 108c. The controller systems may be, for example, a home security system, a parking facility sensor system, a vehicle, an inventory monitoring system, a connected home appliance, a telephone device, a network routing device, a smart power grid system, a drone or other unmanned vehicle, a hospital monitoring system, or any other Internet of Things (IoT) system. The controller systems may include controllers arranged in a local area network (LAN), a wide area network (WAN), or any other communication network arrangement. Furthermore, each controller system may include any number of controllers. For example, the exemplary controller system 108a includes controllers 110a, 112a, and 114a, which may have the same or different functionality or purpose. These controllers are further discussed through the description of the exemplary controller 114a, discussed with respect to FIG. 1B. The controller systems 108a, 108b, and 108c may connect to the system 100 through connections 106a, 106b, and 106c, respectively. System 100 may also connect to remote system 103, which may include any number of computing devices (including, for example, a personal desktop computer), through connection 106d. Remote system 103 may be associated with a code creator, a physical component and / or device (e.g., controller) manufacturer, a system (e.g., vehicle) manufacturer, or another entity associated with developing and / or deploying the software. Connection 106 may be a communication channel, which may include a bus, a cable, a wireless (e.g., radio) communication channel, a radio-based communication channel, a local area network (LAN), the Internet, a wireless local area network (WLAN), a wide area network (WAN), a cellular communication network, or any Internet Protocol (IP)-based communication network and the like. Connections 106a, 106b, 106c, and 106d may be of the same type or different types.

[0217] Any combination of components of system 10 may perform any number of steps of the example processes discussed herein consistent with the disclosed example embodiments.

[0218] FIG. 1B illustrates an electronic control unit (ECU) (e.g., Bosch TM , Delphi Electronics TM , Continental TM , Denso TM Automotive controllers such as those manufactured by companies such as Skyworks TM , Qorvo TM , Qualcomm TM , NXP Semiconductors TM 1 illustrates an example pictorial representation of a controller 114a, which may be a non-automotive controller such as an IoT controller manufactured by Automotive, Inc. The controller 114a may be configured (e.g., through a program 126) to perform a single function (e.g., a braking function in a vehicle) or multiple functions. The controller 114a may perform any number of steps of the example processes discussed herein consistent with the disclosed example embodiments.

[0219] The controller 114a may include a memory space 116 and a processor 118. The memory space 116 may be a single memory component or multiple memory components. Such memory components may include electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. For example, the memory space 116 may include any number of hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), and the like. The memory space 116 may include one or more storage devices configured to store instructions that can be used to perform functions related to the disclosed embodiments by the process 118. For example, the memory space 116 may be configured with one or more software instructions, such as software programs 126 or code segments, that, when executed by the processor 118, perform one or more operations (e.g., operations discussed in connection with the figures below). The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, memory space 116 may include a single program or multiple programs that implement the functions of system 10. Memory space 116 may also store data used by one or more software programs (e.g., data related to ECU functions, data obtained during operation of the vehicle, or other data).

[0220] In an embodiment, the memory space 116 may store software executable by the processor 118 to perform one or more methods, such as those discussed below. The software may be implemented via various programming techniques and languages, such as C or MISRA-C, ASCET, Simulink, Stateflow, and various others. Furthermore, it should be emphasized that the techniques disclosed herein are not limited to automotive embodiments. Various other IoT environments, such as smart home appliances, network security or monitoring equipment, smart utility meters, connected sensor devices, parking facility sensors, and many more, may also use the disclosed techniques. In such an embodiment, the memory space 116 may store software based on various programming techniques and languages, such as C, C++, PHP, Java, JavaScript, Python, and various others.

[0221] The processor 118 may include one or more dedicated processing units, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), graphical processing units, or various other types of processors or processing units coupled with the memory space 116.

[0222] The controller 114a may also include a communication interface 120 that may allow remote devices to interact with the controller 114a. The communication interface 120 may include an antenna or a wired connection to allow communication to or from the controller 114a. For example, an external device (such as the controller 114b, the controller 116a, the security provider 102, or any other device capable of communicating with the controller 114a) may send code to the controller 114a instructing the controller 114a to perform a certain operation, such as modifying software stored in the memory space 116.

[0223] The controller 114a may also include a power supply 122, which may be an AC / DC converter, a DC / DC converter, a regulator, or a battery internal to the physical housing of the controller 114a, and may provide power to the controller 114a to enable its components to function. In some embodiments, the power supply 122 may be external to the physical housing of the controller (i.e., may not be included as part of the controller 114a itself) and may provide power to multiple controllers (e.g., all of the controllers in the controller system 108a).

[0224] The controller 114a may also include input / output devices (I / O) 124 that may be configured to enable a user or device to interact with the controller 114a. For example, the I / O 124 may include at least one of a wired and / or wireless network card / chipset (e.g., WiFi-based, cellular-based, etc.), an antenna, a display (e.g., graphical display, text display, etc.), an LED, a router, a touch screen, a keyboard, a microphone, a speaker, a tactile device, a camera, a button, a dial, a switch, a knob, a transceiver, an input device, an output device, or another I / O device configured to perform or enable a user to perform any number of steps of the methods of the disclosed embodiments as further discussed below.

[0225] 1C illustrates an exemplary pictorial representation of security provider 102, which may be a single device or multiple devices. In the embodiment shown, security provider 102 includes a user device 128, which may be a computer, a server, a mobile device, a special purpose computer, or any other computing device that may enable a user to perform any number of steps of the methods of the disclosed embodiments as further discussed below. For example, user device 128 may include a processor 136, which may be configured to execute instructions stored in memory 138.

[0226] The user device 128 may also be connected to a database 130, which may be an instance of a network resource, such as network resource 104a. The database 130 may store data for use within the methods of the disclosed embodiments as discussed further below. For example, the database 130 may maintain any number of models consistent with the disclosed embodiments. The database 130 may include any number of disk drives, servers, server arrays, server blades, memory, or any other medium capable of storing data. The database 130 may be configured in a number of ways, including as a text database, a centralized database, a distributed database, a hierarchical database, a relational database (e.g., SQL), an object-oriented database, or in any other configuration suitable for storing data. The database 130 is shown within the security provider 102, but may also exist outside of it, such as a remote cloud computing platform.

[0227] In some embodiments, the user device 128 may connect to a communication interface 132, which may be similar to the communication interface 120 and / or the I / O 124. For example, the communication interface 132 may include at least one of a wired and / or wireless network card / chipset (e.g., WiFi-based, cellular-based, etc.), an antenna, a display (e.g., graphical display, text display, etc.), an LED, a router, a touch screen, a keyboard, a mouse, a microphone, a speaker, a tactile device, a camera, a button, a dial, a switch, a knob, a transceiver, an input device, an output device, or another device configured to perform or enable a user to perform any number of steps of the methods of the disclosed embodiments as discussed further below. The communication interface 132 may also enable the user device 128 to connect to other devices, such as other devices within the security provider 102, other devices within the system 100, and / or devices external to the system 100, such as the controller 114a. In some embodiments, the communications interface 132 (e.g., an antenna) may connect to the database 130, which may allow devices other than the user device 128 (e.g., a controller external to the system 100) to communicate with the database 130.

[0228] The security provider 102 may also include a display 134, which may be connected to the user device 128. The display 134 may include a liquid crystal display (LCD), an in-plane switching liquid crystal display (IPS-LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, an active matrix organic light emitting diode (AMOLED) display, a cathode ray tube (CRT) display, a plasma display panel (PDP), a digital light processing (DLP) display, or any other display capable of connecting to a user device and portraying information to a user. The display 134 may display graphical interfaces, interactable graphical elements, animations, dynamic graphical elements, and any other visual elements such as those discussed with respect to FIG. 14, among others.

[0229] Figure 2 illustrates an example pictorial representation of a set of models with corresponding information tables and code portions. Any of these example models may include, among others, a line of code behavior and relationship model (e.g., code line behavior and relationship model 30) as discussed with respect to Figure 3. The example embodiment in Figure 2 depicts model 202, which includes, of which are parts, model 208 and model 214. Models 202, 208, and 214 may model code portions (e.g., code for execution on a controller) 204, 210, and 216, respectively. As an example, model 202 may model computer code (e.g., code portion 204) configured to coordinate the operation of an ECU associated with turning a rack and pinion of a vehicle, and model 208 and / or model 214 may model computer code (e.g., code portions 210 and / or 216) configured to add or remove functions or relationships or otherwise modify the capabilities of the initial computer code modeled by model 202 (e.g., adding a feature for communication with a blind spot monitor to prevent the rack and pinion from turning when the blind spot monitor detects an object in the path of the vehicle). Any of these example models may be generated as discussed with respect to FIG. 6, among others.

[0230] FIG. 2 also illustrates code portion information tables 200, 206, and 212 associated with models 202, 208, and 214, respectively. The code portion information tables may contain information for each individual model and / or code portion and may be labeled with different block numbers and / or dates associated with the model and / or code portion (e.g., the date the associated model or code portion was created, modified, deployed, etc.). In some embodiments, the code portion information tables may hold a nonce or any other number that is generated such that it may be used only once within a given system. The nonce may be generated using information associated with the model and / or code portion, such as a sequence of code, a combination of functions, a combination of functional relationships, the type of device to which the model or code portion is associated, the time the code portion was analyzed, or any other information that may be unique to the model and / or code portion.

[0231] In some embodiments, the code portion information table may hold hash values ​​and / or predecessor value hash values. Any of these hash values ​​may have been generated according to a hash function, which is described in more detail with respect to FIG. 6. The hash values ​​may uniquely identify the model and / or its underlying code portion. The predecessor value hash values ​​may identify the model and / or code portion previously associated (e.g., a previous version) with which the information table is associated. In this manner, an identifying link may be created between subsequent changes to the software such that changes may be tracked from a code perspective and a functional perspective, allowing deeper analysis and rollback of software deployment. Note that while the term "hash" is used to describe this information in the code portion information table, any unique value may be used as the hash value and / or predecessor value hash value, which may or may not be generated by a hash function.

[0232] FIG. 3 illustrates an exemplary pictorial representation of a line of code behavior and relationship model 30 that may be generated by a processor (e.g., a processor in a user device 128) according to a process (e.g., process 600). The line of code behavior and relationship model 30 may be represented in data and stored on a storage medium such as a database 130 or memory space 116. The line of code behavior and relationship model may relate to any amount of code (e.g., one line of code, multiple lines of code, a program, etc.). In some embodiments, the line of code behavior and relationship model may be created or modified through analysis of code configured for execution on a controller (e.g., offline analysis at the security provider 102 through simulating device behavior, etc., which may be based on real-time “online” behavior). The line of code behavior and relationship model may be used “online” by applying real-time (or in some embodiments, simulated) controller operation to the model to demonstrate the functionality of the code on the controller. The term "lines of code" is not necessarily limited to literally lines of code, and may include, instead of or in addition to lines of code, symbols (discussed below), symbolic relationships (also discussed below), compiled code, non-compiled code, software packages (e.g., for software updates), instruction sets, and / or any software whose functionality or behavior can be analyzed.

[0233] The code line behavior and relationship model 30 may describe any number of symbols, such as symbol 300, symbol 302c, symbol 306b, etc. A symbol may represent and / or store some piece of information, including a variable, a buffer, a function, a call, an object, a segment of code, a controller to which the symbol is associated, a system to which the symbol is associated, or any other information related to the functional impact of the code associated with the symbol. In some embodiments, a symbol may include a functional block, which may describe a functional profile of a segment of code. The functional profile may be developed through manual user input and / or machine observed (e.g., through simulation) behavior. In some embodiments, the code line behavior and relationship model 30 may be stochastic, deterministic, steady state, dynamic, sustained, discrete, local, etc. In some embodiments, the code line behavior and relationship model 30 may include a function call graph for the code (e.g., based on gprof, OpenPAT, pprof, etc.).

[0234] As shown in FIG. 3 by the arrows between the symbols, symbols may affect each other (i.e., they have a symbol relationship). As an example, symbol 302d may represent a buffer that is called by a function represented by symbol 304b in a process to update a variable represented by symbol 306a. Although the arrows in this exemplary diagram are shown moving from left to right, any combination of symbol relationships (e.g., dependencies, interdependencies, etc.) between the symbols is possible. Symbol relationships may be unidirectional or bidirectional between the symbols. Symbol relationships may also represent recursive or recurrent relationships between the symbols. In some embodiments, a symbol relationship may affect another symbol relationship in addition to or instead of affecting another symbol.

[0235] FIG. 4 illustrates an exemplary pictorial representation of an interface 40 for analyzing code behavior, which may be displayed, for example, on display 134. Interface 40 may be displayed according to a program on a device, such as a program on user device 128 or one of programs 126. The visual representations displayed by interface 40 may be based on processes, such as those discussed with respect to FIGS. 6-14. In some embodiments, the visual representations displayed on interface 40 may relate to a particular controller, controller system type, system type, code portion, and / or code line behavior and relationship models. Interface 40 may display information statically (e.g., using fixed inputs, such as data from a controller) or dynamically (e.g., using inputs that change in real time, such as real-time data from a controller). In some embodiments, a user may be able to change the statically displayed information by selecting a different fixed input. For example, interface 40 may display a slider bar along which a user may move a slider to select a time point that corresponds to a particular input, such as data related to the behavior of a controller at a particular time point. In some embodiments, the input may cause interface 40 to animate a sequence of frames showing changes in controller action over time. For example, a user of user device 128 may interact with interface 40 using communications interface 132.

[0236] The interface 40 may include a symbolic relationship interface 400 that may visually depict symbolic relationships that may be represented by the line of code behavior and relationship model 30, as discussed above. In some embodiments, the symbolic relationship interface 400 may display graphical user interface (GUI) elements 410. The GUI elements 410 may represent symbols, such as those discussed with respect to FIG. 3, among others. In some embodiments, the symbolic relationship interface 400 may display symbolic relationships between the GUI elements 410, as shown by the illustrative black lines connecting these elements in the diagram. In some embodiments, the GUI elements 410 and / or symbolic relationships may have any combination of color, text, animation, shading, shape, position, size, graphical elements (e.g., a red X mark), or any other visual aspect capable of conveying information to the user visual interface 40. For example, as shown in FIG. 4, the GUI elements 410 have a variable type of shading that may indicate that a symbol associated with a particular GUI element 410 is inactive, active, or malfunctioning. In some embodiments, the symbol relationship interface 400 may display information related to the symbols and / or the underlying codes of the symbol relationships, such as the percentage of the code used. The information in the symbol relationship interface 400 may be displayed statically or dynamically, as discussed above.

[0237] The interface 40 may include other interfaces, such as a resource interface 402, a functional behavior interface 404, and a software state interface 406. The resource interface 402 may depict current, past, or future resource usage associated with a device and / or system. For example, the resource interface 402 may depict current usage of CPU, memory, and / or network bandwidth. In some embodiments, the resource interface 402 may depict statistical information related to resource usage, average levels of such CPU usage, or historical variance in network bandwidth usage. In some embodiments, the resource interface 402 may depict data derived from resource usage and / or other information, which may be predictive. For example, the resource interface 402 may depict a probability of downtime of a device, system, etc. (e.g., as shown in FIG. 4). The information in the resource interface 402 may be displayed statically or dynamically, as discussed above.

[0238] Interface 40 may include a functional behavior interface 404 that may depict functional behaviors associated with the symbols and / or symbol relationships depicted in symbol relationship interface 400. In some embodiments, functional behavior interface 404 may depict changes in functional behavior over time, which may be indicated in a variety of ways, including as a line graph (e.g., with lines forming an operational envelope as "expected," as shown in FIG. 4), a bar graph, dynamic coloring elements (e.g., with intensity of color traits indicating further deviation of behavior from the expected envelope), any combination of these, and / or any visual indicator that may change over time. The information in functional behavior interface 404 may be displayed statically or dynamically, as discussed above.

[0239] The interface 40 may also include a software state interface 406, which may include a GUI element 408. In some embodiments, the software state interface 406 may depict a current state of the software that may be represented in the symbolic relationship interface 400 and / or associated with code on a device (e.g., a controller). For example, the software state interface 406 may depict the original software installed on the controller and any number of subsequent changes to that software. Such changes may be part of a configuration management process and may include, but are not limited to, updates, rollbacks, deletions, additions, recalibrations, parameter alterations, and / or any other changes to the software for the device. The GUI element 408, which may be included within the software state interface 406, may cause changes to the visual representations, code, and / or line of code behavior and relationship models in the interface 40 in response to receiving an input. For example, the GUI element 408 may change the code and / or corresponding line of code behavior and relationship models to an updated version in response to receiving an input. User interactions with visual representations that may be displayed on the interface 40 are discussed further with respect to FIG. 14, among others. The information in the software status interface 406 may be displayed statically or dynamically, as discussed above.

[0240] 5 illustrates an exemplary pictorial representation of delta file software changes on controller 114a. Software on the controller (e.g., original software 502) may change over time, which may be accomplished through storing delta files (e.g., delta file 504) in memory space 116. At different times, different delta files may be stored in or removed from memory space 116 and / or different delta files may be currently implemented by software on controller 114a. For example, at time t1, delta file 504 may be stored in memory space 116 and currently implemented by original software 502 (as indicated by the arrow in FIG. 5). At another point in time T3, delta file 508 (e.g., a software update that may be part of a configuration management process) may be stored in memory space 116 and currently implemented by original software 502 (as indicated by the arrow in FIG. 5). At yet another point in time T4, the software on the controller 114a may change (eg, roll back) from the implementation of the delta file 508 to the implementation of the previous delta file 506.

[0241] The combination of the software (e.g., original software 502) and any number of delta files (including zero delta files) may be modeled by a line of code behavior and relationship model. In some embodiments, memory space 116 may also store a line of code behavior and relationship model and / or a unique identifier, either or both of which may be associated with the original software 502 and / or the delta files (e.g., delta file 504). In these embodiments, the line of code behavior and relationship model and / or the unique identifier may be part of the delta file itself.

[0242] 6 illustrates an example process 600 for generating and signing a line-of-code behavior and relationship model. According to the above embodiments, the process 600 may be implemented within the system 10 depicted in FIG. 1 or any type of IoT network environment. For example, the process 600 may be performed by a processor (e.g., processor 136) and / or other components (e.g., database 130) of the security provider 102, or by any computing device or IoT system.

[0243] In step 602, process 600 may identify code, which may be executable code, that may be configured for execution on a physical controller (e.g., a vehicle's ECU, an IoT controller, etc.). In some embodiments, process 600 may identify code that is configured for execution on a virtual controller or other implementation, execution on a personal computing device, and / or code that is not configured to execute. In some embodiments, executable code may include, by way of example, software change (e.g., update, patch, rollback, delete, modify, recalibrate, parameter modification, etc.) delta files. In some embodiments, code may be identified when it is received at a device (e.g., user device 128), for example, when the code is typed into user device 128 by a user or when it is received transmitted from another device (e.g., controller 114a).

[0244] At step 604, process 600 may perform a functional analysis of code, such as the code received at step 602, which may determine the number of functions associated with the code and / or the number of relationships between the number of functions. In some embodiments, performing the functional analysis may involve analyzing the received code for known segments (e.g., functions, variables, etc., with determined functional effects) and / or unknown segments. In some embodiments, unknown segments may have functional effects classified by a user (e.g., through input at security provider 102, which may update information in database 130). In some embodiments, the functional analysis may involve simulating the code in a physical or virtual computing environment and determining the functional effects. In some embodiments, the code may be divided according to the functional effects of the segments and / or the functional relationships between the segments.

[0245] At step 606, process 600 may generate a line of code behavior and relationship model, which may be an instance of line of code behavior and relationship model 30 discussed above. In some embodiments, the line of code behavior and relationship model may be generated based on any number of functions and relationships determined by the functional analysis at step 604. In some embodiments, the line of code behavior and relationship model may be generated through a machine learning process, which may include a statistical classification process, a dynamic analysis process, determining a sequence of functions associated with a segment or segments of code, and / or determining a relationship between at least two of the functions in the sequence.

[0246] At step 608, process 600 may perform a signature operation on the generated line of code behavior and relationship model. The signature operation may include a hash operation, a cryptographic function, and / or any signature algorithm. For example, the signature may be generated according to an algorithm such as SHA-256, MD6, Fast Hash, Universal One-Way Hash Function, or others. The signature operation may generate a unique signature value associated with the line of code behavior and relationship model, the symbol, the controller, and / or the system. In some embodiments, the unique signature value may include a hash value and / or a cryptographic nonce number. In some embodiments, the signature operation may be based on the number of symbols associated with a segment or segments of code, at least one type of the symbols, the number of relationships in the line of code behavior and relationship model, the configuration of the relationships in the line of code behavior and relationship model, the number of symbols associated with at least one relationship, and / or any other characteristic of the line of code behavior and relationship model.

[0247] At step 610, process 600 may link the unique signature value (e.g., the value generated at step 608) to a line of code behavior and relationship model (such as the line of code behavior and relationship model generated at step 606 or an existing line of code behavior and relationship model). Linking the unique signature value may include generating a file having both the unique signature value and the line of code behavior and relationship model, writing the unique signature value to a field of the line of code behavior and relationship model, embedding the unique signature value in the line of code behavior and relationship model, and / or creating a notation in the data indicating that the unique signature value is associated with the line of code behavior and relationship model. In some embodiments, process 600 may assign a unique signature value to a segment or segments of code (e.g., a delta file) with which the line of code behavior and relationship model may be associated (e.g., when the line of code behavior and relationship model was generated based on a segment or segments of code). In some embodiments, linking the unique signature value to the line of code behavior and relationship model may include compressing the line of code behavior and relationship model, which may occur at any point in the linking process (e.g., at the end). In some embodiments, process 600 may transmit the line of code behavior and relationship model along with the assigned signature value to a remote device (e.g., controller 114a), which may occur before or after step 610.

[0248] 7 depicts an exemplary process 700 for generating and signing a line-of-code behavior and relationship model. According to the above embodiments, the process 700 may be implemented within the system 10 depicted in FIG. 1 or any type of IoT network environment. For example, the process 700 may be performed by a processor (e.g., processor 136) and / or other components (e.g., database 130) of the security provider 102, or by a computing device or IoT system.

[0249] In step 702, the process 700 may identify a first portion of code and a second portion of code. One or both of the first and second portions of code may be executable code that may be for implementation or execution on a physical controller (e.g., an ECU that may be of a vehicle), a virtual controller, a personal computing device, and / or may be code that is not configured to execute. For example, at least one of the execution of the functions of the first portion of code or the execution of the functions of the second portion of code may be execution on a physical or virtualized controller. In some embodiments, the first portion of code may correspond to a version of software that may be currently deployed and / or running on the device, or that precedes the second portion of code. Additionally, the second portion of code may correspond to a software change (e.g., recalibration) that may be intended for a device that currently has the first portion of code. Identifying the first and / or second portion of the code may include generating the first and / or second portion of the code, receiving the first and / or second portion of the code, and / or reading the first and / or second portion of the code from a storage medium (e.g., memory space 116, a storage medium of the remote system 103, memory 138, database 130, etc.).

[0250] At step 704, process 700 may access a first line of code behavior and relationship model, which may represent the execution of the functionality of the first portion of code. This model may be stored on a storage device (e.g., database 130) accessible to the device (e.g., user device 128) performing process 700. In some embodiments, the first line of code behavior and relationship model may be an instance of line of code behavior and relationship model 30 discussed above. For example, the first line of code behavior and relationship model may be line of code behavior and relationship model 30, which models symbols and symbol relationships associated with the first portion of code. In some embodiments, the accessed line of code behavior and relationship model may have been generated according to a machine learning process, consistent with other disclosed embodiments.

[0251] In step 706, process 700 may build a second line of code behavior and relationship model based on the second portion of the executable code, which may represent execution of a function of the second portion of the code. In some embodiments, the first line of code behavior and relationship model may be line of code behavior and relationship model 30, which may model symbols and symbol relationships associated with the second portion of the code. In some embodiments, process 700 may link at least one function of the second portion of the code to at least one segment of the second portion of the code.

[0252] In some embodiments, at least one of the first or second line of code behavior and relationship models may be dynamically generated (e.g., generated using real-time data received from a device operating using the first or second portion of code). For example, the security provider 102 may receive real-time operation information from a controller and / or controller system. Such dynamic generation may be performed using, among other things, the steps discussed with respect to FIG. 13. In other embodiments, the first or second line of code behavior and relationship models may be statically generated (e.g., using existing code that is not based on real-time operation).

[0253] In step 708, the process 700 may perform a functional difference comparison of the first and second line-of-code behavior and relationship models. In some embodiments, performing the functional difference comparison may involve comparing all or a portion of the line-of-code behavior and relationship models that may be associated with the first and second line-of-code behavior and relationship models. In addition to or instead of comparing the line-of-code behavior and relationship models 30, the process 700 may compare unique identifiers or other identifying information associated with the first and second line-of-code behavior and relationship models, respectively. In some embodiments, the functional difference comparison may include determining whether the functionality of the first portion of the executable code falls within an operational envelope related to at least one of CPU cycles, memory requirements, speed of execution, or functionality relationships. In some embodiments, the functional difference comparison may be based on at least one of differences (e.g., between the first and second line-of-code behavior and relationship models) in response time, sequence of function execution, or memory leakage. Response time may be determined, for example, based on a measured time for a processor to respond to a message (e.g., a request for a response, a ping, or a real-time message). A sequence of function executions may be represented by a machine learning process that determines a stored sequence, an average of previous function sequences, or an expected function sequence. Memory leakage may be indicated, for example, as memory content that should not be deleted from memory but has been deleted, or memory content that should be deleted but has not been deleted.

[0254] In some embodiments, process 700 may determine that the third portion of the code is dormant (e.g., performs minimal actions, is never used, is obsolete, is redundant, is inefficient, is part of a previous software change, etc.). This determination may be triggered based on the functional difference comparison of step 708.

[0255] In step 710, process 700 may determine a functional equivalence status, which may include a functional equivalence status between the first and second line-of-code behavior and relationship models. In some embodiments, the functional equivalence status may include an equivalence or non-equivalence status and / or a degree of equivalence, which may be used in step 716. The functional equivalence status may be based on the comparison performed in step 708. For example, the comparison in step 708 may result in a degree of functional equivalence between the first and second line-of-code behavior and relationship models, which may be expressed in various ways. As a further example, such a degree of functional equivalence may include a percentage of equivalence (e.g., 75% equivalence), a determination of equivalence of a particular portion of the first and second line-of-code behavior and relationship models (e.g., 99% of the symbols between the models are equivalent, the symbol "X-1" in the first model is only 80% equivalent to the modified symbol "X-1" in the second model, etc.). In some scenarios, process 700 may proceed directly from step 710 to step 712, for example, if equivalence status is determined in step 710. Process 700 may proceed to step 716 and / or step 718, in some cases, after performing step 710.

[0256] In step 712, process 700 may generate a report of the functional equivalence status, which may include the status determined in step 710, the degree of functional equivalence, or any other information related to the functional similarities or differences between the first and second line of code behavior and relationship models.

[0257] At step 714, process 700 may send a report of the status of functional equivalence, which may include the report generated at step 712. In some embodiments, the report may identify at least one instance of functionality drift, which may have been determined, for example, at steps 708 or 710. In some embodiments, the report may be sent from the device performing process 700 (e.g., user device 128) to a separate device (e.g., network resource 104a, remote system 103, etc.). In some embodiments, the separate device may be a device associated with the first and / or second lines of code behavior and relationship models (e.g., a device that provided the code underlying the first and / or second models, a device of a provider of the code underlying the first and / or second models, a device of a manufacturer of a component, device, or system for which the first and / or second pieces of code are intended).

[0258] In step 716, process 700 may determine whether the degree of functional equivalence (e.g., the degree of functional equivalence determined in step 710) meets a threshold. The nature of the threshold may take a variety of forms, including percentage equivalence between the first and second line of code behavior and relationship models, percentage equivalence between certain portions of the first and second line of code behavior and relationship models (e.g., between significant portions of code within the first and second portions), or any other quantification of equivalence between the first and second portions of code or between the first and second line of code behavior and relationship models. In some embodiments, for example, if the result of the functional difference comparison exceeds a threshold, process 700 may determine an estimated probability of downtime (e.g., of the device for which the second portion of code is intended) based on the determined difference, which may be expressed as a probability of downtime within a defined period of time.

[0259] In some embodiments, the threshold may be set in the system 100 or the remote system 103. For example, in some implementations, a set of regulations or specifications may determine the threshold for permitted differences in code functionality. One example may be approval-type rules issued by the United Nations Economic Commission for Europe. These rules may, for example, dictate the threshold for software functionality deviations permitted for over-the-air software changes (updates, rollbacks, modifications, etc.). In some situations, the threshold may be 0% (i.e., no deviation in functionality is permitted for over-the-air changes), while in other situations, the threshold may be higher. Similar regulations and rules may determine when an IoT controller (e.g., electronic device controller, industrial controller, mechanical device controller, home appliance controller, etc.) is permitted to receive over-the-air software changes. In this manner, the disclosed techniques can comply with government or industry regulations in an efficient and secure manner, allowing permitted over-the-air changes and not allowing unacceptable changes with significant functional differences. The determined degree of functional equivalence may dictate further steps taken by the process 700. For example, if the determined degree of functional equivalence meets the threshold, process 700 may proceed to step 712, and if the determined degree of functional equivalence does not meet the threshold, process 700 may proceed to step 718.

[0260] In step 718, process 700 may generate a prompt, which may be based on the determination made in step 710 and / or step 716. In some embodiments, the prompt may include a warning, a degree of functional equivalence, or any other information determined as part of process 700. In some embodiments, the prompt may tag the second portion of the code, the second line of code behavior and relationship model, and / or a unique identifier. Tagging may include labeling the code, model, and / or identifier as unusable, malicious, buggy, or otherwise inappropriate for use on the device. In some embodiments, tagging may involve disabling the code and / or sending a notification to the device to not allow the code to run.

[0261] 8 depicts an example process 800 for identifying software interdependencies based on functional code line behavior and relationship models. According to the above embodiments, the process 800 may be implemented within the system 10 depicted in FIG. 1 or any type of IoT network environment. For example, the process 800 may be performed by a processor (e.g., processor 136) and / or other components (e.g., database 130) of the security provider 102, or by a computing device or IoT system.

[0262] In step 802, process 800 may identify a first portion of code that may be associated with a controller. For example, the first portion of code may be implemented or configured to run on a physical controller (e.g., ECU), a virtual controller, a personal computing device, and / or may not be configured to run. In some embodiments, the first portion of code may correspond to software that may be currently deployed and / or running on the device (e.g., controller), or may correspond to a software change (e.g., an update, fix, patch, modification, removal, recalibration, parameter modification, etc., any of which may be part of a configuration management process). In some embodiments, the first portion of code may be associated with a sensitivity value, which may be a value describing the importance of the first portion of code to the device and / or system with which it is associated. Thus, the sensitivity value may be based on the software including the first portion of the code being executed on the device, the frequency with which the first portion of the code is used, the level of importance of the device with which the first portion of the code is associated to the overall system (e.g., an ECU that controls a braking function may have a higher level of importance than an ECU that controls an air conditioning fan speed), the number of dependencies or interdependencies the first portion of the code has, or any other measure of the degree of involvement the first portion of the code has with the device and / or system. Although the first portion of the code is discussed here as being associated with the first sensitivity value, other portions of the code, symbols, and / or individual devices (e.g., controllers) may also be associated with sensitivity values, as will be discussed further with respect to other embodiments. Identifying the first portion of the code may include generating the first portion of the code, receiving the first portion of the code, and / or retrieving the first portion of the code from a storage medium (e.g., memory space 116, a storage medium of remote system 103, memory 138, database 130, etc.).

[0263] In step 804, process 800 may access a functional line of code behavior and relationship model, which may represent the functionality of a portion of the code (e.g., the portion of the code identified in step 802). In some embodiments, the accessed functional line of code behavior and relationship model may be code line behavior and relationship model 30 and may model symbols and symbol relationships associated with the first portion of the code. In some embodiments, accessing the functional line of code behavior and relationship model may include generating a functional line of code behavior and relationship model, receiving a functional line of code behavior and relationship model, and / or reading a functional line of code behavior and relationship model from a storage medium (e.g., memory space 116, a storage medium of remote system 103, memory 138, database 130, etc.).

[0264] In step 806, process 800 may determine a second portion of code, which may include software changes (e.g., updates) for the controller. For example, like the first portion of code, the second portion of code may be implemented or configured to run on a physical controller (e.g., ECU), a virtual controller, a personal computing device, and / or may not be configured to run. In some embodiments, a sensitivity value is associated with the second portion of code (such as the sensitivity value discussed in step 802). In some embodiments, the second portion of code may be associated with the same device (e.g., controller) as the first portion of code. In some embodiments, the first portion of code may be associated with a first controller and the second portion of code may be associated with a second controller, where both the first and second controllers may be part of the same device or system (e.g., at least part of a vehicle, a building, a network, etc.). Determining the second portion of the code may include generating the second portion of the code, receiving the second portion of the code (e.g., from the remote system 103), and / or reading the second portion of the code from a storage medium (e.g., memory space 116, a storage medium of the remote system 103, memory 138, database 130, etc.).

[0265] At step 808, process 800 may determine interdependencies. For example, process 800 may determine that the second portion of code is interdependent with the first portion of code. In some embodiments, the first and second portions of code may be associated with the same device (e.g., a controller) such that the interdependencies are internal to the device. In some embodiments, this determination may be based on functional line-of-code behavior and relationship models (e.g., the model accessed in step 804, the model associated with the first portion of code, the model associated with the second portion of code, etc.). The interdependencies may be determined by comparing symbols or symbol relationships of two different line-of-code behavior and relationship models.

[0266] In some embodiments, determining the interdependencies may include determining the functional impact of a first portion of code on a second portion of code. For example, process 800 may determine status and / or functionality changes associated with interdependent portions of code (e.g., according to process 700 or other processes discussed herein). As an example, a change to one portion of code may result in a functional change in other portions of code (e.g., associated with the same device), and process 800 may determine the nature of each functional change in the other portions (e.g., degree of functional equivalence) to the extent any exists. Process 800 may also determine the type of interdependency (e.g., one-way interdependency, two-way interdependency, interdependency affecting a critical portion of code, interdependency affecting a non-critical portion of code, etc.) and / or the strength of the interdependency (e.g., number of symbols affected, frequency of impact on symbols, potential or actual amount of change to symbols, etc.). In some embodiments, the functional impact may be based on a sensitivity value associated with a first portion of the code (i.e., a first sensitivity value) and a sensitivity value associated with a second portion of the code (i.e., a second sensitivity value). In some embodiments, process 800 may determine that the functional impact exceeds a threshold. As discussed above, the threshold may be dynamically set (e.g., based on a machine learning process) or statically set (e.g., set manually or based on government regulations that define the permitted degree of functional difference).

[0267] In some embodiments, process 800 may identify a first signature that uniquely identifies a first portion of code and a second signature that uniquely identifies a second portion of code. Process 800 may link the signatures together (e.g., in a cross-reference or lookup table), which may account for interdependencies in a useful compact format.

[0268] In step 810, process 800 may generate a report. In some embodiments, the report may be based on the determined interdependencies and / or may identify interdependent portions of the code (e.g., the first and second portions of the code of steps 802 and 806). The report may identify the type and / or strength of the interdependencies (e.g., as discussed with respect to step 808). The report may include functional impacts, such as the functional impacts determined in step 808.

[0269] In some embodiments, process 800 may generate a visual representation of the determined interdependency. For example, the visual representation may show the interdependency in a graphical representation of the two lines of code behavior and relationship model. In some embodiments, the visual representation may be the same as or similar to that shown in symbolic relationship interface 400. The visual representation may include visual elements of the determined interdependency, visual elements of the first portion of the code, visual elements of the second portion of the code, and / or visual elements of other portions of the code. In some embodiments, the visual representation may be based on a determination that the functional impact exceeds a threshold (e.g., the visual representation may show the degree to which the functional impact exceeds a threshold, the visual representation may be displayed only if the functional impact exceeds a threshold, etc.).

[0270] 9 depicts an example process 900 for identifying a source of a software-based malfunction or error. According to the above embodiments, the process 900 may be implemented within the system 10 depicted in FIG. 1 or another type of IoT network environment. For example, the process 900 may be performed by a processor (e.g., processor 136) and / or other components (e.g., database 130) of the security provider 102, or by a computing device or IoT system.

[0271] In step 902, process 900 may identify a potential or actual software malfunction. In some embodiments, the identified potential or actual software malfunction may be associated with multiple different software sources (e.g., devices, software developers, etc.), may have multiple code sets, may be associated with a system (e.g., occurring within). For example, the multiple code sets may have been developed by multiple different software developers, may be associated with different devices that generated the code sets, may be associated with different geographies, etc. In some embodiments, the multiple code sets may be associated with at least one controller (e.g., ECU) of the system (e.g., vehicle). In some embodiments where the multiple code sets are associated with different software developers, each of the multiple different software developers may have a unique source identifier, and each code set may be associated with one of the unique source identifiers. As with all embodiments discussed herein, the system is not necessarily limited to a physical system, but may instead include a virtual system.

[0272] The code sets may also be associated with different functions. For example, one code set may be associated with controlling one operation in the system (e.g., steering in a vehicle), while another code set may be associated with controlling a different operation in the system (e.g., blind spot detection). In some embodiments, the code sets may be interdependent (e.g., as discussed with respect to FIG. 11).

[0273] In step 904, process 900 may access a line of code behavior and relationship model, which may represent the execution of the functions of the set of code. In some embodiments, the accessed line of code behavior and relationship model may represent only a single set of code. In some embodiments, the line of code behavior and relationship model may represent the execution of the functions of the set of code identified in step 906. In some embodiments, the accessed line of code behavior and relationship model may have been dynamically generated based on data associated with real-time operation of at least one device (e.g., a controller). After performing step 904, process 900 may proceed to step 906 and / or step 914.

[0274] In step 906, process 900 may identify a set of code. The set of code may be identified based on the line of code behavior and relationship model, and the set of code may be determined to have or have caused, at least in part, the potential to cause a software malfunction. For example, process 900 may analyze the line of code behavior and relationship model (e.g., through simulation of operation using real-time operation data, etc.) to determine a set of code or a portion of a set of code that is associated with a potential or actual software malfunction.

[0275] In some embodiments, multiple sets of code may be associated with a potential or actual software malfunction. In these scenarios, the multiple sets of code may be interdependent on each other (i.e., if within the same device).

[0276] In step 908, process 900 may determine a code set identifier, which may be a source identifier for the identified code set (e.g., an identifier indicating the device or software developer that generated the identified code set, an identifier indicating the device with which the code set is associated, etc.).

[0277] In step 910, process 900 may generate a report of the potential or actual software malfunction. The report of the potential or actual software malfunction may include an estimated duration of downtime, an identifier of the devices and / or systems potentially or actually affected by the potential or actual software malfunction, a number of devices and / or systems potentially or actually affected by the potential or actual software malfunction, an indication of the significance of the malfunction (e.g., based on the type of devices and / or systems affected, the level of impact of the potential or actual software malfunction, etc.).

[0278] In step 912, the process 900 may send a report of the potential or actual software malfunction to a remote source (eg, the remote system 103), which may be associated with the identified source identifier.

[0279] In step 914, the process 914 may identify a delta file. This step may be important in some embodiments, such as where the identification of a potential software malfunction (e.g., in a system) may be based on a recent software change to a component (e.g., a controller). For example, the identification of a potential software malfunction may result from a software change that has been implemented or is planned to be implemented on the component using a delta file. In some embodiments, such as where a delta file is associated with an identified malfunction, the delta file may be associated with a unique identifier, which may be included in the report, which may enable improved responsiveness actions, such as in step 916.

[0280] In step 916, the process 900 may implement a responsive action. Such a responsive action may be taken in response to the identified malfunction. For example, the process 900 may revert software on a component (e.g., a controller) that is associated with the identified malfunction by unlinking the delta file from the current software on the component. Unlinking the delta file may involve any number of different actions, including changing a pointer in memory (e.g., memory space 116 as shown in FIG. 5), deleting the delta file, changing a unique identifier associated with the delta file, sending software changes to the controller, and / or performing an action at the controller to implement a version of the software without implementing the unlinked delta file. Various other responsive actions may also be taken, such as sending a notification to a remote device (e.g., an infotainment screen in the controller's vehicle that is associated with the delta file), generating and / or sending a report such as those discussed with respect to steps 910 and 912, pausing operation on the component, reverting software on components that depend on the component with which the identified malfunction is associated, pausing operation on dependent controllers, etc.

[0281] FIG. 10 depicts an example process 1000 for analyzing hardware change impact based on functional code line behavior and relationship models. According to the above embodiments, the process 1000 may be implemented within the system 10 depicted in FIG. 1 or any type of IoT network environment. For example, the process 1000 may be performed by a processor (e.g., processor 136) and / or other components (e.g., database 130) of the security provider 102, or by any computing device or IoT system. In some embodiments, the process 1000 may be initiated when the system determines that a new hardware component is operating or attempting to operate the system.

[0282] In step 1002, process 1000 may identify a new hardware component that may be associated with (e.g., is a part of) the system. In some embodiments, the new hardware component may be a controller, and in even more specific embodiments, the new hardware component may be an ECU in the vehicle (i.e., the system). In some embodiments, the new hardware component may be configured, selected, prepared, etc. to replace a previous hardware component.

[0283] In step 1004, process 1000 may access a first line of code behavior and relationship model that may represent the execution of the function in the system using the new hardware component. The first line of code behavior and relationship model may have been generated based on data associated with a simulated operation of the new hardware component. In some embodiments, process 1000 may also access a second line of code behavior and relationship model that may represent the execution of the function on a previous hardware component of the system. The second line of code behavior and relationship model may have been dynamically generated based on data associated with real-time operation of the previous hardware component.

[0284] In some embodiments, accessing the functional line of code behavior and relationship model may include generating the functional line of code behavior and relationship model, receiving the functional line of code behavior and relationship model, and / or reading the functional line of code behavior and relationship model from a storage medium (e.g., memory space 116, a storage medium of remote system 103, memory 138, database 130, etc.).

[0285] In step 1006, the process 1000 may perform a functional difference comparison, which may include comparing the first line-of-code behavior and relationship model to the second line-of-code behavior and relationship model.

[0286] In step 1008, process 1000 may determine a status of functional equivalence, which may be based on the functional difference comparison performed in step 1006. In some embodiments, the status of functional equivalence may include a status of functional equivalence between the new hardware component and the previous hardware component. In some embodiments, step 1008 may be similar to step 710 in process 700, where one or both of the new and previous hardware components have associated portions of code and / or line-of-code behavior and relationship models. In some embodiments, process 1000 may determine that there is or is not a functional difference between the new hardware component and the previous hardware component (and / or the corresponding portions of the code and / or line-of-code behavior and relationship models).

[0287] At step 1010, process 1000 may generate a functional equivalence status report, which may be a report that identifies the functional equivalence status determined in step 1008. In some embodiments, the report may be based on determined differences between the new hardware component and the previous hardware component (and / or corresponding portions of the code and / or line of code behavior and relationship models), which may have been determined in step 1008.

[0288] In step 1012, process 1000 may send a report of the status of functional equivalence, which may include the report generated in step 1012. In some embodiments, the report may identify at least one instance of functionality drift, which may have been determined, for example, in steps 1008 or 1010. In some embodiments, the report may be sent from the device performing process 1000 (e.g., user device 128) to a separate device (e.g., network resource 104a, remote system 103, etc.). In some embodiments, the separate device may be associated with the new and / or previous hardware components (and / or the corresponding portions of the code and / or code line behavior and relationship models). For example, the separate device may be associated with the manufacturer of the code writer for the new and / or previous hardware components.

[0289] In step 1014, process 1000 may determine whether the degree of functional equivalence (e.g., the degree of functional equivalence determined in step 1008) satisfies a threshold. The nature of the threshold may take a variety of forms, including percentage equivalence between the new and previous hardware components, percentage equivalence between certain portions of the first and second lines of code behavior and relationship models associated with the new and previous hardware components (e.g., between significant portions of code within the first and second portions), or any other quantification of equivalence between the new and previous hardware components. As discussed above, the threshold may be static or dynamic in nature.

[0290] Process 1000 may also make other determinations that may be based on the new hardware component. For example, in some embodiments, when the result of the functional difference comparison exceeds a threshold, for example, process 1000 may determine an estimated probability of downtime (e.g., of the new hardware component, components that depend on the new hardware component, etc.) based on the determined difference, which may be expressed as a probability of downtime within a defined period of time. In some embodiments, such as those in which the new hardware component is a controller, process 1000 may also determine that at least one hardware component, which may be another controller, depends on the new hardware component. In still other embodiments, process 1000 may determine that at least one hardware component (e.g., a component within a controller) is interdependent with the new hardware component (e.g., another component of the same controller).

[0291] Process 1000 may also take action upon determining that a component depends on a previous hardware component. For example, process 1000 may access a line of code behavior and relationship model that may represent the execution of a function on at least one dependent hardware component and the previous hardware component. Additionally, process 1000 may generate a line of code behavior and relationship model that represents the execution of a function on at least one dependent hardware component and the new hardware component. Regardless of whether these two line of code behavior and relationship models were generated as part of process 1000, process 1000 may perform a functional difference comparison of these two models. Process 1000 may also determine changes in functional equivalence within the system (e.g., functional differences identified for the dependent component), which may be based on the functional difference comparison. In some embodiments, process 1000 may generate a report that identifies such changes, which may be based on the determined differences.

[0292] In some embodiments, such as those in which functional differences are determined, process 1000 may determine that the new hardware component is not approved, which may be based on the determined differences (e.g., if the degree of functional equivalence does not meet a threshold).

[0293] In some embodiments, the threshold may be set in system 100 or remote system 103. The determined degree of functional equivalence may dictate further steps taken by process 1000. For example, if the determined degree of functional equivalence meets the threshold, process 1000 may proceed to step 1010, and if the determined degree of functional equivalence does not meet the threshold, process 1000 may proceed to step 1016. As discussed above, in some embodiments, the threshold is static (e.g., defined by government or industry regulations or rules), while in other embodiments, it is dynamic (e.g., based on a machine learning process).

[0294] In step 1016, process 1000 may generate a prompt, which may be based on the determination made in step 1008 and / or step 1014. In some embodiments, the prompt may include a warning, a degree of functional equivalence, or any other information determined as part of process 1000. Process 1000 may block operation of the new hardware component, which may be based on a determination that the new hardware component is not authorized. For example, the prompt may tag the new hardware component, a portion of code associated with the new hardware component, a second line of code behavior and relationship model associated with the new hardware component, and / or a unique identifier. Tagging may include labeling (e.g., in software) code, models, components, and / or identifiers as unusable, malicious, buggy, or otherwise inappropriate for use in the system. In some embodiments, tagging may involve disabling code and / or sending a notification to the system to not allow installation of the new component. Other tagging actions may include those discussed with respect to FIG. 7.

[0295] FIG. 11 depicts an example process 1100 for identifying software dependencies based on functional code line behavior and relationship models. According to the above embodiments, the process 1100 may be implemented within the system 10 depicted in FIG. 1 or any type of IoT network environment. For example, the process 1100 may be performed by a processor (e.g., processor 136) and / or other components (e.g., database 130) of the security provider 102, or by any computing device or IoT system. In some embodiments, the process 1100 may be initiated when the system determines that a new hardware component is operating or attempting to operate the system.

[0296] In step 1102, process 1100 accesses a first line of code behavior and relationship model that may represent the execution of a function of a first portion of code (e.g., executable code that may be configured to run on a controller). In some embodiments, the first portion of code may be associated with a first symbol, which may be at least one of a variable, a buffer, a function, a call, an object, and / or a segment of code, and may have any other characteristic of a symbol, as discussed in other embodiments. The first portion of code may also be associated with a sensitivity value (such as the sensitivity values ​​discussed with respect to FIG. 8, among others).

[0297] In step 1104, process 1100 may detect changes to a first portion of the code. The changes to the portion of the code may include code changes implemented in a physical controller, a virtual controller, simulated changes made by a user, and / or code changes in any other device.

[0298] In step 1106, process 1100 may build a second line of code behavior and relationship model that may represent the execution of the functionality of the modified first portion of the executable code. In some embodiments, the structure of the second line of code behavior and relationship model may be based on the modified first portion of the executable code.

[0299] In step 1108, the process 1100 may determine dependencies. In some embodiments, this may include dependencies between either the modified first portion of the executable code or the first symbol and a second symbol. The second symbol may be at least one of a variable, a buffer, a function, a call, an object, and / or a segment of code, and may have any other characteristics of a symbol as discussed in other embodiments. The second symbol may also be associated with a sensitivity value (such as the sensitivity value discussed with respect to FIG. 8, among others). In some embodiments, the dependencies may be based on a constructed second model. The dependencies may also be determined remotely by running a second line-of-code behavior and relationship model remotely from the first and second controllers (e.g., controllers associated with the first portion of the code and the second symbol, respectively). In embodiments where the process 1100 concerns at least one controller, such controller may be part of a group of electronic control units (ECUs) in the vehicle.

[0300] Process 1100 may also determine information related to dependencies. For example, process 1100 may determine an impact on a second symbol caused by a modified first portion of code, which may be based on a sensitivity value (e.g., a sensitivity value associated with the modified first portion of code and the second symbol). In some embodiments, the dependency may include a strength of association between a first symbol and a second symbol, which may be based on how often the first symbol interacts with the second symbol, that the first portion of executable code is configured to call or modify the second symbol, the number of symbols affected, the frequency of the impact on the symbols, the amount of potential or actual changes to the symbols, etc. In some embodiments, the second symbol may be associated with a controller (e.g., a second controller, with which the first portion of code is potentially associated with the first controller). In some embodiments, process 1100 may determine a status and / or change of functionality associated with the interdependent portions of code (e.g., according to process 700 or other processes discussed herein). For example, a change to one portion of code may result in a functional change in other portions of the code (e.g., code on other devices), and process 1100 may determine the nature of each functional change in the other portions (e.g., the degree of functional equivalence), to the extent any exists. As an illustrative example, changing a first portion of the code for a camera on a vehicle may affect the function of a self-parking feature, which may involve other ECUs, such as one that controls steering. In other words, in some embodiments, such as those in which a system includes multiple devices, a controller (or other device) whose code has not changed may still change and suffer a change in functionality based on changes in other devices.

[0301] In step 1110, process 1100 may generate a report. In some embodiments, the report may be based on the determined differences and / or may identify dependencies. The report may also identify multiple dependencies, for example, if a step of process 1100 is performed multiple times. In some embodiments, the report may contain additional information associated with the dependencies. For example, in an embodiment where process 1100 identifies an impact on a second symbol caused by a modified first portion of code, this impact may be included in the report. Process 1100 may also take other actions related to the determined dependencies. For example, process 1100 may generate a visual depiction of the determined dependencies, consistent with other embodiments disclosed herein.

[0302] 12A depicts an example process 1200A for managing software delta changes using a functional code line behavior and relationship model. According to the above embodiments, the process 1200A may be implemented within the system 10 depicted in FIG. 1 or any type of IoT network environment. For example, the process 1100 may be performed by a processor (e.g., processor 136) and / or other components (e.g., database 130) of the security provider 102, or by a computing device or IoT system.

[0303] In step 1202, process 1200A may identify a prompt to modify software, which may include software modification code, such as code for modifying a first version of code on a device (e.g., a controller) to a second version of code. In some embodiments, the second version of the code may be deployed (e.g., as an update) subsequent to the first version of the code. In some embodiments, the prompt may include a delta file (e.g., a delta file configured to modify software on the controller). In some embodiments, the software modification code may be code that may be configured for execution on a virtual controller or other implementation, execution on a personal computing device, and / or not configured to execute. In some embodiments, the prompt may be identified when it is received at the device (e.g., user device 128), for example, when code is typed into user device 128 by a user, or when a transmission from another device (e.g., remote system 103) is received.

[0304] In step 1204, process 1200A may build a line of code behavior and relationship model that may be based on the prompts identified in step 1202 and that may represent the execution of the controller's functionality based on the second version of the code.

[0305] In step 1206, process 1200A may perform a signature operation, which may be performed on the generated line-of-code behavior and relationship model and may generate a signature value. The signature operation may be similar to that described with respect to FIG. 6, among others (e.g., the signature operation may include a hash operation, an encryption function, and / or any signature algorithm). In some embodiments, the signature operation may be based on an identifier of the controller (e.g., the controller associated with the prompt to change the change software, the constructed line-of-code behavior and relationship model, etc.). The signature operation may also be based on the type, function, software version, sensitivity value, age, or processing capacity of the controller.

[0306] In step 1208, process 1200A may transmit the signature value and / or the software modification code (e.g., from step 1202). In some embodiments, the signature value and / or the software modification code may be transmitted to a controller, which may perform process 1200B in response to receiving the signature value and / or the software modification code.

[0307] 12B depicts an example process 1200B for analyzing software delta changes based on functional code line behavior and relationship models. According to the above embodiments, the process 1200A may be implemented within the system 10 depicted in FIG. 1 or any type of IoT network environment. For example, the process 1100 may be performed by a processor (e.g., processor 118) and / or other components of a controller system (e.g., controller system 108a) or by any computing device or IoT system.

[0308] In step 1210, process 1200B may receive the signature value and / or the software modification code (e.g., sent in step 1208 from security provider 102, etc.). For example, the signature value and / or the software modification code may be received by a controller (e.g., controller 114a), which may be configured to (i) compare the received signature value with a calculated signature value that the controller is configured to calculate based on the second version of the code, and (ii) determine, for example, based on the comparison, whether to verify the second version of the code, as discussed further with respect to process 1200B.

[0309] In step 1212, process 1200B may calculate a signature value. As discussed above, the signature may be generated according to a variety of different algorithms. Process 1200B may begin calculating the signature value by constructing a line of code behavior and relationship model that may be based on the identified prompt and may represent the execution of the controller's functionality based on the second version of the code. Process 1200B may perform a signature operation on the constructed line of code behavior and relationship model that may generate a calculated signature value. The signature operation may be similar or identical to that described in step 1206.

[0310] In step 1214, process 1200B may compare the received signature value with the calculated signature value.

[0311] In step 1216, process 1200B may determine whether the received signature value and the calculated signature value match, which may be based on the comparison performed in step 1214. This determination may verify the received signature value and / or the software modification file associated with the received signature value, and may direct process 1200B to step 1218 and / or step 1220.

[0312] In step 1218, process 1200B may process the software modification code, such as the software modification code received in step 1210. In some embodiments, process 1200B may execute a second version of the code on the controller based on the verification performed in step 1216. For example, if process 1200B determines that the received and calculated signature values ​​for the second version of the code match, it may proceed to execute the code and implement the second version of the code on the controller.

[0313] In step 1220, process 1200B may implement corrective actions, which may be based on the validation performed in step 1216. In some embodiments, corrective actions may be implemented once process 1200B determines that the received and calculated signature values ​​do not match. The corrective actions may include preventing execution of the second version of the code (e.g., associated with the received signature value) on the controller and notifying a remote source (e.g., remote system 103) associated with the second version of the code.

[0314] In some embodiments, the line of code behavior and relationship models involved in process 1200A and / or process 1200B may be the same or similar to the line of code behavior and relationship models from other embodiments. For example, at least one of the line of code behavior and relationship models constructed in step 1204 or step 1212 may have been dynamically generated based on data associated with real-time operation of the controller. In some embodiments, this data may be limited (e.g., data from a particular time frame, from a particular set of devices, from a particular set of systems, sampled at a particular rate, etc.) based on a group of parameters that may be set remotely from the device (e.g., remotely from the controller for which the software change file is intended).

[0315] 13 depicts an example process 1300 for analyzing control flow integrity based on functional code line behavior and a relational model. According to the above embodiments, the process 1300 may be implemented within the system 10 depicted in FIG. 1 or any type of IoT network environment. For example, the process 1300 may be performed by a processor (e.g., processor 136) and / or other components (e.g., database 130) of the security provider 102, or by any computing device or IoT system. In some embodiments, any number of steps of the process 1300 may be performed periodically, such as according to a period based on a sensitivity value associated with a controller.

[0316] At step 1302, process 1300 may receive data that may be based on runtime operations of any number of controllers (e.g., the received data may be based on runtime operations of a first controller and a second controller). In some embodiments, such a controller (or multiple controllers) may be associated with a software change. In some embodiments, the data may include multiple data sets associated with different runtime operations. Process 1300 may also apply a machine learning process to such multiple data sets, as part of step 1302 or another step in the process, which may generate analytical data.

[0317] In step 1304 , process 1300 may perform a functional analysis, which may be performed on the data received in step 1302 .

[0318] In step 1306, process 1300 may build a line of code behavior and relationship model that may represent the execution of the function on the controller and may be based on the received data. In some embodiments, building the line of code behavior and relationship model may be based on the analysis data (e.g., generated in step 1302). In some embodiments, process 1300 may identify software changes to the controller and build the line of code behavior and relationship model based on the identified software changes. In some embodiments, process 1300 may perform a signature operation on the built line of code behavior and relationship model, which may generate a signature value.

[0319] In step 1308, the process 1300 may build a dynamic control flow integrity model that may be based on the line-of-code behavior and relationship model and that the controller may be configured to enforce in real-time.

[0320] In step 1310, process 1300 may deploy the dynamic control flow integrity model to the controller (or controllers). Deployment may include compressing the dynamic control flow integrity model, sending the dynamic control flow integrity model to the controller, sending the dynamic control flow integrity model to the system, etc. In some embodiments, the dynamic control flow integrity model may be deployed with a signature value (e.g., the signature value generated in step 1306 may be sent along with the dynamic control flow integrity model).

[0321] A controller, in which a dynamic control flow integrity model is deployed, may be configured in various ways to enable effective implementation of the dynamic control flow integrity model. For example, a controller may be configured to detect a request to execute code on the controller and compare the requested execution with the dynamic control flow integrity model. In addition, such a controller may be configured to take an action based on the comparison of the requested execution with the dynamic control flow integrity model. For example, the controller may be configured to deny execution of code on the controller if the requested execution violates the dynamic control flow integrity model. As another example, the controller may also be configured to generate an alert if the requested execution violates the dynamic control flow integrity model.

[0322] In some embodiments, the controller or other device may take action to validate the dynamic control flow integrity model. For example, the controller may be configured to compare a received signature value (e.g., received as part of the deployment) with a calculated signature value that the controller may be configured to calculate. Such a calculation may be based on the received data of step 1302 and / or data of the operation associated with the controller. In some embodiments, the controller may be configured to determine whether to validate the dynamic control flow integrity model, which may be based on a comparison of the received signature value with the calculated signature value. For example, if the two signature values ​​match, the controller may determine that the received dynamic control flow integrity model is valid and may operate according to the model. In some embodiments, a signature value may be calculated for the dynamic control flow integrity model either instead of or in addition to the step of calculating signature values ​​for the line of code behavior and relationship model. The signature value calculated for the dynamic control flow integrity model may be used in the same manner as the signature value for the line of code behavior and relationship model, as discussed herein.

[0323] 14 depicts an exemplary process 1400 for visualizing and configuring controller function sequences. According to the above embodiments, the process 1400 may be implemented within the system 10 depicted in FIG. 1 or any type of IoT network environment. For example, the process 1400 may be performed by a processor (e.g., processor 136) and / or other components (e.g., database 130) of the security provider 102, or by any computing device or IoT system. The steps of the process 1400 may involve generating information on a display, e.g., display 134.

[0324] In step 1402, process 1400 may identify at least one code segment, which may be an executable code segment associated with a controller. For example, the at least one code segment may be for implementation or execution on a physical controller (e.g., a vehicle's ECU), a virtual controller, a personal computing device, and / or may be code that is not configured to execute. In some embodiments, the code segment may include code changes, which may be represented by a delta file, configured to change code on the controller, consistent with other embodiments discussed herein.

[0325] In step 1404, process 1400 may analyze at least one code segment (e.g., the code segment identified in step 1402). In some embodiments, analyzing the code segment may involve determining at least one function and / or at least one functional relationship associated with the at least one code segment. Analyzing the code segment may also involve receiving and / or generating a line of code behavior and relationship model, a signature value, a dynamic code flow integrity model, or other similar information of the embodiments discussed herein. For example, the code segment may include a delta file configured to change the code on the controller from a first version of the code to a second version of the code.

[0326] In step 1406, process 1400 may build a software functionality code line behavior and relationship model that may visually depict information such as the determined functions and / or functional relationships (e.g., determined in step 1404). In some embodiments, the software functionality code line behavior and relationship model may be accessed only by process 1400 (e.g., in embodiments where the model has already been built). In some embodiments, the software functionality code line behavior and relationship model may be similar or identical to another model discussed in this disclosure (e.g., code line behavior and relationship model 30).

[0327] In step 1408, process 1400 may display the line of code behavior and relationship model, which may depict the software functionality. The line of code behavior and relationship model may be displayed in a user interface (e.g., interface 40, which may be displayed on display 134, for example).

[0328] At step 1410, process 1400 may receive an input, which may be typed at a user interface. For example, the input may be received by a user at a user interface or communication interface 132, which may be received at the user device 128 through an action (e.g., a mouse click, a touch screen press, a keyboard press, etc.). Such an action may be based on the interface 40, which is displayed to the user. In some embodiments, process 1400 may receive multiple user inputs, either simultaneously or sequentially. For example, process 1400 may receive a second input at the user interface (e.g., an input associated with a code change on a controller) after receiving an input at step 1410.

[0329] At step 1412, process 1400 may perform a responsive display action that may be performed in response to the input received at step 1410. In some embodiments, performing the responsive display action may include animating the displayed code line behavior and relationship model to visually depict the execution of the code segment on the controller, which may include highlighting a visual element of at least one function associated with the at least one code segment. For example, process 1400 may animate the displayed code line behavior and relationship model by animating updates in the model, which may be based on the received second input, for example. Such animation may include changing the color, text, shading, shape, position, size, graphical element (e.g., a red X mark), or any other visual aspect of the displayed visual element that may correspond to a symbol or symbol relationship, as discussed with respect to other embodiments herein. In some embodiments, a sound may also be played based on the user input (e.g., an alert sound may be played when an update based on the user input is determined to cause an error). As even more specific examples, animation may include shaking displayed visual elements, expanding some elements while shrinking others, darkening some elements while fading others, and / or any other visual manipulation that conveys information to the user.

[0330] In some embodiments, the process 1400 may perform responsive display actions based on information other than user input. For example, the process 1400 may receive data of real-time controller operation, data of historical controller operation, signature values, symbols, symbol relationships, and / or any other source of information related to code line behavior and relationship models. In some embodiments, the process 1400 may determine the expected functional behavior of the controller and the actual functional behavior of the controller, which may be based on an analysis performed as part of the process 1400 or another process discussed herein. Responsive display actions may be taken based on such a determination. For example, the process 1400 may display (e.g., in a user interface) a visual indicator of the functional behavior that corresponds to the execution of at least one executable code segment relative to the expected functional behavior. As a further example, the process 1400 may outline, shade, animate, or otherwise highlight a displayed symbol or a displayed symbol relationship whose actual symbol exhibits a functional behavior different from the expected functional behavior. In some embodiments, process 1400 may determine the degree of deviation between expected and actual functional behavior. Process 1400 may also highlight (e.g., outline, darken, animate, etc.) visual elements (e.g., symbols and / or symbol relationships) with a degree of intensity that correlates with the degree to which the functional behavior differed from the expected behavior.

[0331] The process 1400 may also estimate a probability of downtime for the controller based on the degree of deviation. In some embodiments, the process 1400 may display an indication of the probability of downtime (e.g., in a user interface).

[0332] In some embodiments, process 1400 may access code, which may be executable code, configured to execute software changes on the controller, from which a line of code behavior and relationship model may be constructed (e.g., in step 1406). In some embodiments, process 1400 may also send alerts (e.g., alerts based on received inputs, based on deviations, etc.) to a remote device.

[0333] It is to be understood that the disclosed embodiments are not necessarily limited in their application to the details of construction and arrangement of components and / or methods set forth in the following description and / or illustrated in the drawings and / or examples, which are capable of modification or of being practiced or carried out in various ways.

[0334] For example, although some embodiments are discussed in a context involving an electronic controller unit (ECU) and a vehicle, these elements need not be present in each embodiment. Although a vehicle communication system is discussed in some embodiments, other electronic systems (e.g., IoT systems) having any type of controller may also operate within the disclosed embodiments. Such variations are fully within the scope and spirit of the described embodiments.

[0335] The disclosed embodiments may be implemented in a system, method, and / or computer program product that may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the present disclosure.

[0336] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), static random access memories (SRAMs), portable compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or raised groove structures having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not itself to be construed as a ephemeral signal, such as an electric signal transmitted through a wire, or an electromagnetic wave or other freely propagating electromagnetic wave, or an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable).

[0337] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium or an external computer or storage device to an individual computing / processing device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may comprise copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the individual computing / processing device.

[0338] The computer readable program instructions for performing the operations of the present disclosure may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or object-oriented programming languages ​​such as Smalltalk, C++, or equivalent, and traditional procedural programming languages. The computer readable program instructions may be executed entirely on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or the connection may be made to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to implement aspects of the disclosure.

[0339] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0340] These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, and executed via the processor of the computer or other programmable data processing apparatus to generate a machine such that the instructions create means for implementing the function / acts specified in the block or blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored in a computer-readable storage medium that may direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions that implement aspects of the function / acts specified in the block or blocks of the flowcharts and / or block diagrams.

[0341] Computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other device such that the instructions, executed on a computer, other programmable data processing apparatus, or other device, implement the function / acts specified in a block or blocks of the flowcharts and / or block diagrams, causing a series of operational steps to be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process.

[0342] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a portion of a software program, segment, or code, which comprises one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially in parallel, or the blocks may sometimes be executed in reverse order, depending on the functionality involved. Furthermore, some blocks may be executed iteratively, and some blocks may not be executed at all. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or acts or combinations of special-purpose hardware and computer instructions.

[0343] The description of various embodiments of the present disclosure is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used in this specification is selected to best explain the principles of the embodiments, practical applications, or technical improvements over the art found in the market, and to enable those skilled in the art to understand the embodiments disclosed herein.

[0344] It is anticipated that during the life of the patent rights from this application, many related virtualization platforms, virtualization platform environments, trusted cloud platform resources, cloud-based assets, protocols, communications networks, security tokens, and authentication certificates will be developed, and the scope of these terms is intended to include a priori all such new technologies.

[0345] It should be understood that certain features of the present disclosure that are described for clarity in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the present disclosure that are described for brevity in the context of a single embodiment may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the present disclosure. Certain features that are described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiments are inoperative without those elements.

[0346] While this disclosure has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications, and variations that fall within the spirit and broad scope of the appended claims.

Claims

1. A non-transitory computer-readable medium containing instructions that, when executed by at least one processor, cause the at least one processor to perform operations for analyzing control flow integrity based on functional code line behavior and a relational model, the operations comprising: receiving data based on runtime operation of the controller; building a line-of-code behavioral and relational model representing execution of functions on the controller based on the received data; building a dynamic control flow integrity model based on the line-of-code behavior and relational model, the controller is configured to enforce in real time; deploying said dynamic control flow integrity model to said controller; 16. A non-transitory computer readable medium comprising:

2. The non-transitory computer-readable medium of claim 1, wherein the controller is configured to detect a request to execute code on the controller and compare the requested execution with the dynamic control flow integrity model.

3. The non-transitory computer-readable medium of claim 2, wherein the controller is configured to deny execution of the code on the controller if the requested execution violates the dynamic control flow integrity model.

4. The non-transitory computer-readable medium of claim 2, wherein the controller is configured to generate an alert if the requested execution violates the dynamic control flow integrity model.

5. The non-transitory computer-readable medium of claim 1, wherein the operations further include identifying software changes to the controller, and the code line behavior and relationship model is constructed based on the identified software changes.

6. The controller is a first controller, The non-transitory computer-readable medium of claim 1 , wherein the data is further based on a runtime operation of a second controller.

7. The non-transitory computer-readable medium of claim 1, wherein the operation is performed periodically according to a period based on a sensitivity value associated with the controller.

8. The non-transitory computer-readable medium of claim 1, wherein the received data includes multiple data sets associated with different runtime operations, and the operations further include applying a machine learning process to the multiple data sets to generate analysis data, and construction of the line of code behavior and relationship model is based on the analysis data.

9. The operations further comprise performing a signature operation on the constructed line-of-code behavior and relationship model to generate a signature value; and deploying the dynamic control flow integrity model to the controller using the signature value; 2. The non-transitory computer readable medium of claim 1 , comprising:

10. The non-transitory computer-readable medium of claim 9, wherein the controller is configured to compare the signature value to a calculated signature value that the controller is configured to calculate based on the received data, and determine based on the comparison whether the dynamic control flow integrity model should be verified.

11. A computer-implemented method for analyzing control flow integrity based on functional code line behavior and a relational model, the method comprising: receiving data based on runtime operation of the controller; building a line-of-code behavioral and relational model representing execution of functions on the controller based on the received data; building a dynamic control flow integrity model based on the line-of-code behavior and relational model, the controller is configured to enforce in real time; deploying said dynamic control flow integrity model to said controller; 4. A computer-implemented method comprising:

12. The computer-implemented method of claim 11, wherein the controller is configured to detect a request to execute code on the controller and compare the requested execution to the dynamic control flow integrity model.

13. The computer-implemented method of claim 12, wherein the controller is configured to deny execution of the code on the controller if the requested execution violates the dynamic control flow integrity model.

14. The computer-implemented method of claim 12, wherein the controller is configured to generate an alert if the requested execution violates the dynamic control flow integrity model.

15. The computer-implemented method of claim 12, wherein the operations further include identifying software changes to the controller, and the code line behavior and relationship model is constructed based on the identified software changes.

16. The controller is a first controller, The computer-implemented method of claim 12 , wherein the data is further based on runtime operations of a second controller.

17. The computer-implemented method of claim 12, wherein the operation is performed periodically according to a period based on a sensitivity value associated with the controller.

18. The computer-implemented method of claim 12, wherein the received data includes a plurality of data sets associated with different runtime operations, the operations further including applying a machine learning process to the plurality of data sets to generate analytical data, and the construction of the line of code behavior and relationship model is based on the analytical data.

19. The operation further comprises: performing a signature operation on the constructed line-of-code behavior and relationship model to generate a signature value; deploying the dynamic control flow integrity model to the controller using the signature value; The computer-implemented method of claim 12 , comprising:

20. The computer-implemented method of claim 19, wherein the controller is configured to compare the signature value to a calculated signature value that the controller is configured to calculate based on the received data, and determine based on the comparison whether the dynamic control flow integrity model should be verified.

Images