DE102021210328A1 - MEMORY-USE-BASED DETECTION OF INFRINGEMENTS INTO A SYSTEM - Google Patents

Abstract

A first aspect of the present disclosure relates to a computer-implemented method for detecting intrusion into a system, comprising recording memory usage information upon execution of at least a portion of software of the system; checking whether the memory usage information deviates from a reference memory usage information predetermined for the at least part of the software; and evaluating the software as tampered with if the verification is positive.A second aspect of the present disclosure relates to a computer-implemented method for recording and storing reference memory usage information for software in a system, comprising recording reference memory usage information upon execution of at least a portion of the software and storing reference memory usage information for the at least a portion of the software in the system. A third aspect of the present disclosure relates to a system configured to perform the methods of the present disclosure.

Description

State of the art

Systems, especially embedded systems, can be security relevant and should be secured against intrusion. Embedded systems may include hardware, such as an electronic calculator, and software, both of which are incorporated (“embedded”) in a technical context. Embedded systems can be designed - by means of hardware and/or software - for example to monitor, control and/or regulate another technical system such as a vehicle or an engine control of the vehicle. If intrusion into a system is not detected, the system and possibly the further technical system can be manipulated in an undesirable and/or impermissible manner.

The increasing number of electronic control units in (mechatronic) systems as well as the increasing digitization or interoperability of electronic control units can lead to more and more interfaces of the system (e.g. a multimedia interface in the vehicle) and thus to an ever-increasing attack surface for possible intrusion. Intrusion detection systems (IDS) are being developed to detect and, if possible, prevent intrusion.

Embedded systems, especially electronic control units, can be designed restrictively. For example, the functionality of embedded systems can be determined or certified according to specifications and/or standards. In contrast to e.g. systems such as general-purpose computers with general-purpose operating systems, the functionality of embedded systems can be implemented by a (smaller) variety of routines. A method for detecting an intrusion into the system can then include, for example, recording the power consumption and/or its time profile when a routine is executed and comparing it with a reference power consumption or reference profile. Deviations in such a comparison may indicate that the routine has been tampered with (in the meantime). Intrusion into the system can thus be detected and appropriate measures initiated. However, measuring the current during the execution of routines requires dedicated additional hardware and is therefore associated with additional costs.

Disclosure of Invention

A first general aspect of the present disclosure relates to a computer-implemented method for detecting intrusion into a system. The method includes recording memory usage information upon execution of at least a portion of software of the system. The method further comprises checking whether the memory usage information deviates from a reference memory usage information predetermined for the at least part of the software. The method further includes evaluating the software as tampered with if the testing is positive. The method may include initiating at least one action if the software has been determined to be tampered with.

A second general aspect of the present disclosure relates to a computer-implemented method for recording and storing reference memory usage information for software in the system. The method includes recording reference memory usage information upon execution of at least a portion of the software. The method further includes storing the reference memory usage information for the at least a portion of the software in the system.

The predetermined reference memory usage information for the at least part of the software in the method for detecting intrusion into the system according to the first general aspect (or an embodiment thereof) may be according to the method for recording and storing the reference memory usage information for software in the system according to the second general aspect (or an embodiment thereof). A third general aspect of the present disclosure relates to a system arranged to use the computer-implemented method for detecting system intrusion of the first general aspect (or an embodiment thereof) and/or the computer-implemented method for recording and storage of reference memory usage information for software in the system according to the second general aspect (or an embodiment thereof).

A fourth general aspect of the present disclosure relates to a computer program arranged for the computer-implemented method for detecting system intrusion according to the first general aspect (or an embodiment thereof) and/or the computer-implemented method for recording and storing reference memory usage information for software in the system according to the second general aspect (or an embodiment thereof). A fifth general aspect of the present disclosure relates to a computer-readable medium or signal carrying the computer stores and/or contains a program according to the fourth general aspect.

A sixth general aspect of the present disclosure relates to a computer system configured to execute the computer program according to the fourth general aspect.

The methods proposed in this disclosure are directed to detecting intrusions into the system. If an intrusion is detected, at least one (counter)measure can be initiated, which is aimed, for example, at preventing the intrusion and/or informing a superordinate electronic control unit.

The methods can be particularly advantageous for restrictively designed systems. A restrictively designed system can, for example, be an embedded system (with software), where the functionality and/or its implementation are subject to (strict) rules. These rules can be specified, for example, by a specification and/or a standard. A rule can be, for example, that memory must not be allocated dynamically (e.g. via malloc in C). In this case, for example, fixed memory addresses are written into the programming code of the software ("hardcoding"). Furthermore, the software can, for example, comprise a (smaller) number of well-defined routines. The focus on restrictively designed systems can only represent an insignificant limitation, since security-relevant systems in particular are often restrictively designed.

Checking whether the memory usage information differs from reference memory usage information predetermined for the at least part of the software (e.g. for a routine of the software) includes a comparison of the memory usage information recorded when the at least part of the software is executed with that for the at least part of the software predetermined reference memory usage information (previously also recorded e.g. under standard conditions). As a result, when the at least one part of the software is executed, it can be checked whether the at least one part of the software corresponds to the part intended for the software or whether it has been manipulated, for example, by external (programming) code. Intrusion detection can be very accurate and therefore reliable. This can improve the security of the system. Furthermore, the detection of intrusions can take place in the system itself (“host-based”) and does not depend, for example, on other systems connected to the system and/or a network.

In contrast to a prior art detection of intrusion based on current consumption and/or its history, which is based on additional sensor hardware for the current measurement in the system, the methods proposed in this disclosure do not necessarily require additional hardware in the system . The recording (also: logging) of the memory usage information when executing at least part of the software of the system and/or the recording of the associated reference memory usage information can be implemented exclusively in the software. A software change can be more cost-effective than a hardware upgrade.

Furthermore, a system (e.g. an electronic control unit in a vehicle field) can also be adapted subsequently - for example by updating the software and without hardware expansion - in such a way that the methods proposed in this disclosure can be used in the system. This means that systems can also be secured against intrusion at a later date.

When recording the memory use information/reference memory use information and/or when checking whether the memory use information deviates from reference memory use information predetermined for the at least part of the software, the computing effort and/or the memory requirements can be adjusted in a targeted manner. For example, the computing effort and the memory requirements can be reduced both when recording and when comparing by not recording and/or comparing the complete memory addresses, but instead only recording and/or comparing specific bits of the memory addresses. Further possibilities are disclosed in the detailed description. In principle, a reduction in the computing effort through such possibilities can be accompanied by a lower accuracy of the comparison of memory use information and reference memory use information and thus with a lower accuracy of the detection of intrusions. However, such possibilities do not necessarily affect the accuracy of the recognition. In particular in systems designed to be restrictive, the memory usage information and the reference memory usage information can have a high level of redundancy for the comparison, which can be reduced without significantly impairing the accuracy of the intrusion detection. An error (false positive or false negative) when detecting intrusion, for example, can then be very unlikely. In any case, you can depending on the software or depending on the routine of the software, an optimum between efficiency and accuracy can be (searched for and) set.

For checking whether the memory usage information deviates from reference memory usage information predetermined for the at least part of the software, it can be advantageous if the memory addresses in the memory usage information and the reference memory usage information each have an absolute meaning. On the other hand, an absolute meaning can be dispensable if, for example, relative differences in the memory addresses are compared over time.

character list

• 1 Figure 12 schematically illustrates a computer-implemented method for detecting intrusion into a system.
• 2 Figure 12 schematically illustrates a computer-implemented method for recording and storing reference memory usage information for software in a system.
• 3 Figure 12 schematically illustrates an embodiment of the computer-implemented method for detecting intrusion into a system.
• 4 FIG. 12 schematically illustrates a system configured to perform the computer-implemented methods of this disclosure.
• 5 visualizes an example software track as an example of memory usage information.

Detailed description

The methods proposed in this disclosure are directed to detecting intrusions into the system 300 .

The system 300 can be a technical system. For example, the system can be an embedded system. The embedded system may include hardware such as an electronic calculator (computer) and (implemented) software, both of which are incorporated (“embedded”) in a technical context. By means of hardware and/or software, the embedded system can at least be designed to monitor, control and/or regulate another technical system. Alternatively or additionally, the embedded system can be designed to receive data and/or signals. Alternatively or additionally, the embedded system can be designed to process data and/or signals. Alternatively or additionally, the embedded system can be designed to send data and/or signals.

The (additional) technical system can be a mechatronic system, for example. The (further) technical system can, for example, be a vehicle or a technical (sub)system within the vehicle (e.g. an engine control). Alternatively or additionally, the (further) technical system can be a robot or a technical (sub)system within the robot. Alternatively or additionally, the (further) technical system can be an industrial plant or a technical (sub)system within the industrial plant. Alternatively or additionally, the (further) technical system can be a technical system of networked and/or remotely controllable devices such as a smart home (e.g. thermal control).

For example, the system and/or its software may be designed to be restrictive. For example, the system and/or its software may be restricted by a specification and/or standard. This can prevent, for example, the system software from being able to be expanded by any applications, functionalities and/or interfaces. Furthermore, the software can, for example, comprise a (smaller) number of well-defined routines. The restrictiveness of the system 300 may improve intrusion detection according to the methods 100, 200 proposed in this disclosure.

A computer-implemented method 100 for detecting intrusion into a system 300 is disclosed.

The method 100, shown schematically in 1 12, comprises recording 110 memory usage information upon execution (ie, during execution) of at least a portion of software of the system 300. The at least a portion of the software may be, for example, a routine of the software. The software (and optionally the system 300) can be designed to record 110 the memory usage information when the at least part of the software is executed. A hardware extension is not necessarily required. The memory usage information may include a time series of data.

The method 100 further comprises checking 120 whether the memory usage information deviates from a reference memory usage information predetermined for the at least part of the software. Checking 120 can (unlike in 1 and 3 shown) already take place during the recording 110 at least on the basis of the already recorded 110 data for the memory usage information. In fact, checking 120 can occur substantially (ie, with a small time delay) in parallel with recording 110 . If an intrusion is detected, the shorter the time delay, the quicker action can be taken.

The method 100 further comprises assessing 130 the software as manipulated if the verification 120 is positive, i.e. if the memory usage information deviates from a reference memory usage information predetermined for the at least part of the software. If the software is evaluated as tampered with 130, a breach into the system 300 can be detected.

The method 100 may further include initiating 140 at least one action if the software has been assessed 130 as tampered with. The at least one measure may be designed to prevent or stop intrusion into the system 300, for example. For this purpose, for example, the remaining execution of the at least part of the software can be stopped. Alternatively or additionally, the at least one measure can be designed, for example, to transmit detected intrusions to a higher-level electronic control unit and/or a cloud backend (for further testing).

The method 100 may further include evaluating 150 the software as not tampered with if the verification 120 fails. In this case, there is a high probability of no intrusion into the system.

The memory usage information can deviate from the reference memory usage information predetermined for the at least part of the software if the memory usage information and the reference memory usage information predetermined for the at least part of the software meet a predetermined criterion. The predetermined criterion can be designed in such a way that slight discrepancies between the memory use information and the associated reference memory use information are not evaluated as discrepancies.

umfassen, d.h. SBI kann von RSBI abweichen, wenn eine Norm der Differenz von SBI und RSBI (in dem normierten Vektorraum) größer als δ ist. δ >_ 0 ist hier ein Maß dafür, wie sehr SBI und RSBI voneinander abweichen müssen, um eine Abweichung festzustellen. Im Falle, dass SBI = A und RSBI = A' jeweils laufende Mittelwerte A, A' sind, kann das vorbestimmte Kriterium zum Beispiel die Ungleichung $$\left|A-A\text{'}\right|>\delta$$

umfassen. Im Falle, SBI = T und RSBI = T' Softwarespuren T, T' sind, kann das vorbestimmte Kriterium zum Beispiel die Ungleichung $${\displaystyle \sum _{i=1}^n\left|T_i-T_i^{\text{'}}\right|>\delta }$$

umfassen, wobei T_i, T_i' Koordinaten der Softwarespuren T, T und n die Länge der Softwarespuren T, T sein können.For example, the memory usage information SBI and the associated reference memory usage information RSBI can each be a mathematical object in one and the same normalized vector space. SBI and RSBI can, for example, be time series of the same length and the same time intervals in a vector space spanned by the memory addresses. The predetermined criterion can then, for example, be the inequality $$\left|SBI-RSBI\right|>\delta$$

ie SBI may deviate from RSBI if a norm of the difference of SBI and RSBI (in the normed vector space) is greater than δ. δ >_ 0 is a measure of how much the SBI and RSBI must differ from each other in order to detect a deviation. For example, in case SBI = A and RSBI = A' are respectively running averages A, A', the predetermined criterion can be the inequality $$\left|A-A\text{'}\right|>\delta$$

include. For example, in case SBI = T and RSBI = T' are software traces T, T', the predetermined criterion can be the inequality $${\displaystyle \sum _{i=1}^n\left|T_i-T_i^{\text{'}}\right|>\delta }$$

include, where T _i , T _i 'coordinates of the software tracks T, T and n the length of the software tracks T, T can be.

A computer-implemented method 200 for recording and storing reference memory usage information for software in the system 300 is also disclosed which intrusion is excluded, to record and store. The method 200 can be carried out, for example, during the initial set-up of the system 300 and/or during a reinitialization, for example after a software update. The method 200 is shown schematically in 2 illustrated.

The method 200 includes recording 210 reference memory usage information upon execution (i.e., during execution) of at least a portion of the software. The method 200 may include executing the at least a portion of the software. The procedure for recording 210 the reference memory usage information can correspond to the procedure for recording 110 the memory usage information in the method 100 . This allows the memory usage information and the reference memory usage information to be more comparable.

The method 200 further includes storing 220 the reference storage usage information tion for the at least a portion of the software in the system 300. The storing 220 may (unlike in 2 and 3 shown) already take place during the recording 210 at least on the basis of the already recorded 210 data for the reference memory usage information. In fact, the storing 220 can occur essentially (ie with a small time delay) in parallel with the recording 210 . The storage 220 of the reference memory usage information can be, for example, in a memory of the system, in particular in a non-volatile memory of the system 300 (in 4 not shown), take place. In the case of special security requirements, the reference memory usage information can be stored, for example, in a read-only memory.

The predetermined reference memory usage information for the at least a portion of the software in the method 100 for detecting intrusions into the system 300 may be generated and/or adjusted after the method 200 for recording and storing the reference memory usage information for software in the system 300. An adjustment may be necessary, for example, after a software update-related reinitialization. The linking of the methods 100, 200 is shown schematically in 3 shown.

The memory usage information for the at least a portion of the software may include at least a time series of memory addresses in a memory of the system 300 that are executed, read, and/or written when the at least a portion of the software is executed. Alternatively or additionally, the reference memory usage information for the at least a portion of the software may include at least one time series of memory addresses in a memory of the system 300

The memory usage information for the at least a portion of the software may be a software track. Alternatively or additionally, the reference storage usage information for the at least part of the software can be a software track.

Alternatively or additionally, the memory usage information for the at least a portion of the software may include (or be a running average of the software track) a running average of a software track. Alternatively or additionally, the reference memory usage information for the at least a portion of the software may include (or be a running average of the software track) a running average of a software track. For example, the software track running average may be based on a Hamming weight of memory addresses. The Hamming weight can be equivalent to the Hamming distance of each memory address from the zero memory address. When representing memory addresses in binary, the Hamming weight is equivalent to the bit sum. Running averages may be beneficial to reduce memory requirements and/or computational effort (e.g., in testing 120).

Alternatively or additionally, the memory usage information for the at least part of the software may include (or be) a software track that is restricted to a predetermined selection of bits or bytes of the memory addresses. Alternatively or additionally, the reference memory usage information for the at least a portion of the software may include (or be) a software track that is restricted to a predetermined selection of bits or bytes of the memory addresses. The predetermined selection of bits may include, for example, bits 0, 2, 8, 10, and 24 of 32-bit memory addresses. For example, in another example, the predetermined selection may include bytes 0 and 3 of 32-bit memory addresses. Only one bit or only one byte can also be selected. It can be advantageous to consider characteristic bits/bytes of the memory addresses in the predetermined selection. For example, redundancy in the memory usage information and/or the reference memory usage information can be reduced by a (non-trivial) predetermined selection of the bits or bytes of the memory addresses. The (non-trivial) predetermined selection of the bits or bytes of the memory addresses can reduce the memory requirements and/or the computing effort (e.g. already during recording 110, 210). They can also reduce noise.

A software trace may include at least one time series of memory addresses in a memory of the system 300 that are executed when the at least a portion of the software is executed. Alternatively or additionally, the software track (or another software track) may include at least one time series of memory addresses in the memory of the system 300 that are read upon execution of the at least part of the software. Alternatively or additionally, the (further) software track (or yet another software track) can comprise at least one time series of memory addresses in the memory of the system 300, which are written to when the at least part of the software is executed. For example, the memory addresses can be expressed numerically by a bit or byte sequence (eg, 0x717000). If, for example, the software track only includes memory addresses for write access (or only memory addresses for read access), the memory requirement and/or the computing effort (e.g. already when recording 110, 210). The values of the time series of memory addresses can, for example, be extended by an attribute from "Instruction", "Read" and "Write". In graphic representations, memory addresses for instructions can be shown, for example, as black dots (over time). Alternatively or additionally memory addresses that have been read during execution can be represented in graphs, for example as green dots (above the time).Alternatively or additionally, memory addresses that have been written to during execution can be represented in graphs, for example as red dots (above the time) are displayed.

The software track can - but does not have to - include a time series of all memory addresses that are executed, read and/or written when the at least part of the software is executed. An example software track is in 5 visualized. Shown are the memory addresses that contain instructions that have been executed in the execution of the at least part of the software at a given point in time. Also shown are the memory addresses that have been read during the execution of the at least part of the software at a particular point in time (here, however, also in black).

For example, the recording 110 of memory usage information upon execution of the at least a portion of the system's software may be restricted to a predetermined set of instructions (e.g., only method calls or specific method calls). Alternatively or additionally, the recording 210 of the reference memory usage information when executing the at least part of the software can be restricted to a predetermined selection of instructions (e.g. only method calls or specific method calls), for example. As a result, the memory requirement and/or the computing effort can be further reduced.

Alternatively or additionally, for example the recording 110 of the memory usage information when executing the at least part of the software of the system can be restricted to a predetermined selection of memory addresses and/or memory address ranges (e.g. specific memory address ranges for peripheral devices). Alternatively or additionally, for example the recording 210 of the reference memory usage information when executing the at least part of the software can be limited to a predetermined selection of memory addresses and/or memory address ranges (e.g. specific memory address ranges for peripheral devices). As a result, the memory requirement and/or the computing effort can be further reduced.

A lower memory requirement for the memory usage information and/or the reference memory usage information can advantageously also result in less computing effort when recording 110, 210 and/or when checking 120 whether the memory usage information deviates from reference memory usage information predetermined for the at least part of the software. For the comparison during testing 120, it may prove advantageous if the memory usage information for the at least part of the software and the reference memory usage information for the at least part of the software are of the same type, i.e. e.g. mathematical objects, at least for this at least part of the software in one and the same space.

The memory usage information for the at least a portion of the software may include at least one piece of memory usage independent information. As an alternative or in addition, the reference memory use information for the at least one part of the software can (likewise) include at least one piece of memory use-independent information. The memory use-independent information can be designed/suitable for detecting intrusions into the system more reliably and thus better. Checking 120 whether the memory usage information deviates from the reference memory usage information predetermined for the at least part of the software (or the predetermined criterion) may further comprise analyzing the memory usage-independent information in the memory usage information and/or the reference memory usage information.

The at least one memory usage independent piece of information may include, for example, an elapsed real time for the execution of the at least a portion of the software. Alternatively or additionally, the at least one memory use-independent information can include at least one status value for a predetermined register of a processor of the system. Alternatively or additionally, the at least one piece of memory use-independent information can include memory content for at least one predetermined memory address of the memory of the system 300. As an alternative or in addition, the at least one item of information that is independent of memory use can include at least one date, optionally at least one status value, of a predetermined peripheral device. Alternatively or additionally, the at least one piece of memory-use-independent information can include incoming network data from a network in which the system 300 is integrated. Alterna Alternatively or additionally, the at least one piece of memory use-independent information may include at least one item of operating system information (for an operating system of the system 300). The at least one piece of operating system information can include, for example, a status value for the system, open file handles, number of running processes, number of open ports and/or much more.

A system 300 configured to perform the computer-implemented method 100 for detecting intrusion into the system 300 is further disclosed. The system 300 can thus be secured against intrusion according to the computer-implemented method 100 for detecting intrusions into the system 300 . Alternatively or additionally, the system 300 may be further configured to perform the computer-implemented method 200 for recording and storing reference memory usage information for software in the system 300 . The system 300 can thus (also) be secured against intrusion according to the computer-implemented method 200 for recording and storing reference memory usage information for software in the system 300 . The system 300 is shown schematically in 4 shown. The system 300 may include at least one memory. For example, the system 300 may include memory, which may be, for example, volatile memory. The memory addresses of the memory usage information or the reference memory usage information can relate to memory addresses of the main memory. Alternatively or additionally, the system 300 may include non-volatile memory that may be used, for example, for storing reference memory usage information of the at least a portion of the software.

A computer program configured to execute the computer-implemented method 100 for detecting intrusion into the system 300 is also disclosed. Alternatively or additionally, the computer program (or another computer program) may be configured to execute the computer-implemented method 200 for recording and storing the reference memory usage information for software in the system 300. The computer program (and/or the further computer program) can be in an interpretable or in a compiled form, for example. It can (also in parts) be loaded into the RAM of a control unit or computer for execution, e.g. as a bit or byte sequence.

Also disclosed is a computer-readable medium or signal storing and/or containing the computer program (and/or the further computer program). For example, the medium may comprise one of RAM, ROM, EPROM, HDD, SDD, ... on which the signal is stored.

A computer system designed to execute the computer program (and/or the further computer program) is also disclosed. The computer system may be system 300. In particular, the computer system can include at least one processor and at least one main memory (e.g. RAM, ...). Furthermore, the computer system can include a memory (e.g. HDD, SDD, ...). The computer system includes a server in a network (e.g. Internet, ...).

Claims (14)

A computer-implemented method (100) for detecting intrusion into a system (300), comprising: - recording (110) memory usage information upon execution of at least a portion of software of the system (300); - checking (120) whether the memory usage information deviates from reference memory usage information predetermined for the at least part of the software; - evaluating (130) the software as manipulated if the checking (120) is positive. Method (100) according to claim 1 , comprising: - initiating (140) at least one action if the software has been evaluated as manipulated (130). Method (100) according to claim 1 or 2 , wherein the at least a portion of the software of the system (300) is a routine of the software. The method (100) of any preceding claim, wherein the memory usage information differs from the reference memory usage information predetermined for the at least some portion of the software if the memory usage information and the reference memory usage information predetermined for the at least some portion of the software meet a predetermined criterion. Method (100) according to any one of the preceding claims, comprising: - evaluate (150) the software as not tampered with if the checking (120) is negative. A computer-implemented method (200) for recording and storing reference memory usage information for software in a system (300), comprising: - recording (210) reference memory usage information upon execution of at least one part of the software; - storing (220) the reference memory usage information for the at least part of the software in the system (300). Method (100) according to any one of Claims 1 until 5 , wherein the predetermined reference memory usage information for the at least a portion of the software according to the method (200) of recording and storing reference memory usage information for software in the system (300). claim 6 is produced. Method (100, 200) according to one of the preceding claims, wherein the memory usage information for the at least part of the software and/or the reference memory usage information for the at least part of the software comprises at least one time series of memory addresses in a memory of the system (300) which executed, read and/or written upon execution of the at least part of the software. A method (100, 200) according to any one of the preceding claims, wherein the memory usage information for the at least part of the software and/or the reference memory usage information for the at least part of the software is a software track. Method (100, 200) according to any one of Claims 1 until 8th , wherein at least one of the memory usage information for the at least a portion of the software and the reference memory usage information for the at least a portion of the software is a running average of a software track, optionally wherein the running average is based on a Hamming weight of memory addresses. Method (100, 200) according to any one of Claims 1 until 8th , wherein at least one of the memory usage information for the at least a portion of the software and the reference memory usage information for the at least a portion of the software is a software track restricted to a predetermined selection of bits or bytes of the memory addresses. Method (100, 200) according to any one of claims 9 until 11 , wherein a software track comprises at least one time series of memory addresses in a memory of the system (300) which are executed, read and/or written when the at least part of the software is executed. Method (100, 200) according to claim 11 , wherein the memory usage information for the at least a portion of the software and/or the reference memory usage information for the at least a portion of the software comprises at least one piece of memory usage independent information, wherein the at least one memory usage independent piece of information includes one or more of: - an elapsed real time for the execution of the at least one part of the software; - at least one status value for a predetermined register of a processor of the system (300); - memory content for at least one predetermined memory address of the memory of the system (300); - at least one datum, optionally at least one status value, of a predetermined peripheral device; - Incoming network data from a network in which the system (300) is integrated; and/or - at least one item of operating system information; includes. A system (300) adapted to: - the computer-implemented method (100) for detecting intrusion into the system (300) according to any one of Claims 1 until 5 or 7 until 13 ; and/or - the computer-implemented method (200) for recording and storing reference memory usage information for software in the system (300). claim 6 or 8th until 13 ; to execute.

Images