A simulator detection method and system based on multi-dimensional feature fusion

Abstract

The application discloses a simulator detection method and system based on multi-dimensional feature fusion, and relates to the technical field of simulator detection.The method comprises the following steps: collecting static feature information of a to-be-detected device; reading a memory mapping file of a device process in a preset time window, obtaining memory address allocation states at each moment to form a time sequence data set; then, an address space evolution sequence is constructed, and an address space category is constructed through category theory modeling; an address evolution functor is obtained through a functor construction algorithm; regularity marks are generated through a natural transformation detection algorithm; topological structure analysis and homology calculation are performed on the address space category to generate address space complexity features; and the static feature information, the regularity marks and the address space complexity features are integrated through a multi-layer fusion strategy, and simulator detection results are output through layer-by-layer screening and judgment.The method improves the anti-avoidance capability and robustness of detection through a complementary and cooperative system of static verification, dynamic rules and topological complexity.

Description

Technical Field

[0001] This application relates to the field of simulator detection technology, and in particular to a simulator detection method and system based on multi-dimensional feature fusion. Background Technology

[0002] Emulators, as tools that can simulate the operating state of target devices in non-native hardware environments, are widely used in application development and testing, multi-account operation, and automated script execution. However, the virtualization characteristics of emulators also bring certain risks. In areas such as internet platform operation, financial risk control, and content security, some entities exploit the ability of emulators to tamper with system configurations and circumvent hardware binding to carry out malicious registration, fake traffic generation, credit fraud, and illegal marketing, posing challenges to the security risk control, operational management, and user rights protection of internet platforms.

[0003] Current simulator detection technologies primarily rely on static feature detection. This involves reading the device's system configuration file to obtain information such as device model, manufacturer, and CPU architecture, and then comparing this information with a pre-defined simulator feature library to make a judgment. However, in actual combat, simulators can use sophisticated tools to modify hardware identifiers and manufacturer information in their configuration files, and even simulate sensor data from real devices. This allows them to replicate the static features of real devices, resulting in a high rate of simulator evasion.

[0004] In addition, to address the shortcomings of static detection, leading platforms have begun to adopt dynamic feature detection technology. However, there are still certain limitations in practical applications. On the one hand, existing dynamic solutions mostly focus on shallow features of a single dimension, such as memory page allocation frequency and process creation interval, which are prone to misjudgment due to fluctuations in real device scenarios. On the other hand, existing technologies lack in-depth analysis of the temporal evolution and topological structure of dynamic features, making it impossible to quantify the essential differences between real devices and simulators, resulting in poor detection performance in multi-process concurrent scenarios.

[0005] Therefore, how to accurately distinguish between simulators and real devices by integrating static features with dynamic features of memory address allocation in simulator detection systems, which addresses the problems of easily tampered static features and superficial dynamic feature analysis, has become a technical problem that urgently needs to be solved to improve the anti-evasion capability and accuracy of detection and meet the needs of Internet security risk control. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this application provides a simulator detection method and system based on multi-dimensional feature fusion.

[0007] Firstly, this application provides a simulator detection method based on multi-dimensional feature fusion, including:

[0008] Collect static feature information of the device under test, including at least one of system attribute information, hardware architecture information, sensor configuration status and functional integrity verification results;

[0009] The memory-mapped files of the process of the device under test are periodically read within a preset time window to obtain the memory address allocation status at each time point, forming a time-series dataset; based on the time-series dataset, an address space evolution sequence is constructed; the address space evolution sequence is modeled using category theory to construct an address space category;

[0010] Based on the address space scope, the address evolution functor of the current running instance is obtained through the functor construction algorithm; the address evolution functors of multiple running instances are obtained, and the natural transformation detection algorithm is used to determine whether there is a natural transformation between the address evolution functors, and a regularity marker is generated.

[0011] Perform topological analysis on the address space domain, calculate algebraic topological invariants using a homology computation algorithm, and generate address space complexity features;

[0012] Based on the static feature information, regularity markers, and address space complexity features, a multi-layer fusion strategy is used to filter and determine the results layer by layer, and the simulator detection results are output.

[0013] Optionally, the system attribute information includes device identifier, device model and manufacturer information, and the simulator identifier is identified based on preset rules; the hardware architecture information is obtained by parsing the system CPU information file to obtain the processor model, and the architecture type is determined by combining the application binary interface; the sensor configuration status is obtained by verifying the existence of predefined key physical sensors; the functional integrity verification result is obtained by detecting the device's response capability to preset system intent actions.

[0014] Optionally, the step of periodically reading the memory-mapped file of the process of the device under test within a preset time window to obtain the memory address allocation status at each time point and form a time-series dataset includes:

[0015] Set the sampling period and total duration, and define the range of the preset time window;

[0016] Within a preset time window, at intervals of the sampling period, the system's underlying interface is called to read the memory-mapped file of the process in the device under test;

[0017] For each sampling time, the memory-mapped file is parsed to extract memory region information;

[0018] The memory region information of all processes at the same time is integrated into the memory address allocation status at that time, and arranged in the order of timestamps to form a time-series dataset.

[0019] Optionally, constructing the address space evolution sequence based on the time-series dataset includes:

[0020] Define the memory address allocation status corresponding to each timestamp in the time series dataset as an address space object;

[0021] By comparing address space objects at adjacent sampling times, the addition, release, and attribute changes of memory regions are identified and integrated into transformation relationships;

[0022] By sequentially connecting all address space objects and their corresponding transformation relationships in chronological order, an address space evolution sequence is formed that continuously records the address space state transition process.

[0023] Optionally, the address space evolution sequence is modeled using category theory to construct address space categories, including:

[0024] The set of objects in the address space evolution sequence is taken as the category. The transformation relationship between adjacent address space objects is defined as the set of morphisms in the category. Each morphism corresponds to the mapping from the address space object in the previous time step to the address space object in the next time step.

[0025] Define the composition rule for morphisms: if there exists a morphism from the first address space object to the second address space object and a morphism from the second address space object to the third address space object, the composition of the two morphisms is a morphism from the first address space object to the third address space object.

[0026] Set an identity morphism, and for each address space object, there exists a self-mapping morphism, with the transformation relationship being empty;

[0027] Address space categories are constructed using object sets, morphism sets, composition rules, and identity morphisms.

[0028] Optionally, based on the address space scope, the address evolution functor of the currently running instance is obtained through a functor construction algorithm, including:

[0029] Define the time series scope, the object is each sampling moment within a preset time window, and the morphism is the sequential relationship between adjacent sampling moments;

[0030] Construct an address evolution functor to map the objects in the time series category to the address space objects at the corresponding time in the address space category, and map the morphisms of the time series category to the transformation relationship morphisms between the corresponding address space objects;

[0031] Verify that the structure-preserving properties of the address evolution functor and the mapping relationship of the identity morphism hold, and obtain the address evolution functor of the current running instance.

[0032] Optionally, the step of determining whether natural transformations exist between the address evolution functors using a natural transformation detection algorithm and generating regularity markers includes:

[0033] Select multiple running instances under the same scenario and obtain their respective address evolution functors;

[0034] For any two address evolution functors, check if there exists a family of morphisms, each corresponding to the same point in time, connecting the address space objects mapped by the two address evolution functors;

[0035] Verify whether the family morphism satisfies the natural transformation condition, that is, whether the commutation graph formed by the transformation relationship morphism of any two time points and the time point sequence between them is valid;

[0036] In response to the existence of a family of morphisms that satisfy the natural transformation condition, it is determined that there is a natural transformation between two address evolution functors;

[0037] The proportion of natural transformations among multiple address evolution functors is statistically analyzed. If the proportion exceeds a preset threshold, a high regularity marker is generated; otherwise, a low regularity marker is generated.

[0038] Optionally, topological analysis is performed on the address space domain, and algebraic topological invariants are calculated using a homology computation algorithm to generate address space complexity features, including:

[0039] Objects within the address space are used as topological vertices, and morphisms are used as directed edges connecting the vertices to construct a topological graph structure.

[0040] Based on the aforementioned topological graph structure, the geometric structure features are analyzed using a homology calculation algorithm to calculate the rank of the zero-dimensional homology group, the one-dimensional homology group, and the two-dimensional homology group.

[0041] Betti numbers and Euler characteristic numbers are extracted as algebraic topological invariants and integrated into address space complexity features.

[0042] Optionally, the step of filtering and judging layer by layer through a multi-layer fusion strategy and outputting the simulator detection results includes:

[0043] The static feature layer performs preliminary screening based on static feature information. If there is a simulator identifier in the system attribute information, or inconsistencies in the hardware architecture information verification, or the configuration of key physical sensors is missing and the functional integrity verification fails, it is determined to be a simulator and the detection result is output.

[0044] The evolutionary pattern layer distinguishes devices whose static feature information is not determined by combining regularity labels. If the label is marked as highly regular, it is determined as a simulator and the detection result is output; if the label is marked as low regularity, it is not determined for the time being and enters the topological complexity layer.

[0045] The topology complexity layer compares the address space complexity features of devices marked as having low regularity with a preset benchmark range of real device complexity. If the address space complexity features are lower than the lower limit of the benchmark range, the device is identified as a simulator and the detection result is output. If the address space complexity features are within the benchmark range, the device is identified as a real device and the detection result is output.

[0046] Secondly, this application provides a simulator detection system based on multi-dimensional feature fusion, comprising:

[0047] The acquisition module is used to acquire static feature information of the device under test, including at least one of system attribute information, hardware architecture information, sensor configuration status and functional integrity verification results;

[0048] The module is used to periodically read the memory-mapped files of the process of the device under test within a preset time window, obtain the memory address allocation status at each time point, and form a time-series dataset; based on the time-series dataset, construct an address space evolution sequence; perform category theory modeling on the address space evolution sequence to construct an address space category;

[0049] The first generation module is used to obtain the address evolution functor of the current running instance based on the address space scope through a functor construction algorithm; obtain the address evolution functors of multiple running instances, determine whether there is a natural transformation between the address evolution functors through a natural transformation detection algorithm, and generate regularity markers.

[0050] The second generation module is used to perform topological structure analysis on the address space category, calculate algebraic topological invariants through a homology calculation algorithm, and generate address space complexity features.

[0051] The output module is used to filter and determine the simulator detection results layer by layer based on the static feature information, regularity markers and address space complexity features through a multi-layer fusion strategy.

[0052] Compared with existing technologies, the static features collected in this application verify the authenticity of the device through multiple dimensions, reducing the risk of evasion caused by the tampering of static information and improving the basic reliability of detection.

[0053] By periodically reading memory-mapped files to construct a time-series dataset and combining category theory to model the evolution sequence of the address space, the temporal changes in memory address allocation are transformed into quantifiable address space categories. This breaks through the limitations of existing shallow feature analysis in dynamic detection, uncovers the temporal evolution patterns of memory allocation, and identifies the core differences in dynamic behavior between real devices and simulators.

[0054] By generating regularity markers through natural transformation detection, the evolutionary differences between the non-periodic fluctuations of real devices and the stable temporal patterns of simulators are distinguished. Through topology analysis and cohomology calculation, the abstract address space topology features are transformed into quantifiable algebraic topology invariants, distinguishing the essential differences in topology between real devices and simulators. This effectively reduces the false positive rate in complex scenarios such as multi-process concurrency, and solves the shortcoming of existing technologies that are difficult to quantify topology features.

[0055] A multi-layered fusion strategy is adopted to screen and judge layer by layer, integrating static features, regularity markers and address space complexity features to form a complementary and synergistic system of static verification, dynamic regularity and topological complexity. This effectively resists the dual evasion methods of static tampering and dynamic simulation, and improves the detection's anti-evasion capability and overall robustness. Attached Figure Description

[0056] Figure 1 A flowchart illustrating a simulator detection method based on multidimensional feature fusion, provided for embodiments of this application;

[0057] Figure 2 A flowchart for constructing address space categories provided in this application embodiment;

[0058] Figure 3 A flowchart illustrating the multi-layer fusion strategy provided in the embodiments of this application;

[0059] Figure 4 This is a schematic diagram of a simulator detection system based on multidimensional feature fusion, provided as an embodiment of this application. Detailed Implementation

[0060] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0061] See Figure 1 The diagram shows a flowchart of a simulator detection method based on multi-dimensional feature fusion provided in an embodiment of this application. The method includes steps S101 to S105, wherein:

[0062] S101, Collect static feature information of the device under test, including at least one of system attribute information, hardware architecture information, sensor configuration status and functional integrity verification results;

[0063] S102, periodically read the memory mapping file of the process of the device to be detected within a preset time window, obtain the memory address allocation status at each time, and form a time series dataset; based on the time series dataset, construct an address space evolution sequence; perform category theory modeling on the address space evolution sequence to construct an address space category;

[0064] S103, based on the address space category, obtain the address evolution functor of the current running instance through the functor construction algorithm; obtain the address evolution functors of multiple running instances, and determine whether there is a natural transformation between the address evolution functors through the natural transformation detection algorithm, and generate regularity markers;

[0065] S104, Perform topological analysis on the address space category, calculate algebraic topological invariants through homology calculation algorithm, and generate address space complexity features;

[0066] S105, based on the static feature information, regularity markers and address space complexity features, the simulator detection results are output by filtering and judging layer by layer through a multi-layer fusion strategy.

[0067] It should be noted that this application describes the detection of Android emulators in detail, with the core technical solutions including static feature acquisition, address space category modeling, functor construction, natural transformation detection, and multi-layer fusion judgment. It can also be adapted to the detection of other types of emulators. The system attribute feature library, memory-mapped file reading interface, hardware architecture adaptation rules, and real device complexity benchmark range can be adjusted according to the operating system of the target emulator without making substantial modifications to the core algorithm logic.

[0068] Regarding the above S101:

[0069] By collecting static inherent characteristics of the Android device under test from multiple dimensions, and combining system attributes, hardware architecture, sensors, and functional integrity through collaborative verification logic, the authenticity of the device is initially screened.

[0070] System attribute information includes device identifier, device model, and manufacturer information, and emulator identifiers are identified based on preset rules. Specifically, first, the context instance of the Android device to be detected is obtained. Based on this instance, the underlying interfaces of the Android system are called to collect the core system attributes and communication-related information of the Android device. The device fingerprint, device model, manufacturer name, product name, brand, and device identifier are directly read through the Android system's Build class. Simultaneously, the phone manager instance is obtained through the system service function Context.getSystemService, and the network operator name is obtained by calling the function to obtain the network operator name from this instance, which is then converted to lowercase. All collected information is integrated to form a system attribute dataset.

[0071] Subsequently, preset Android emulator feature filtering rules were established, and a feature library including Android emulator-specific identifiers was created. Specific rules include: device fingerprints starting with "generic" or including keywords such as "vbox" or "test-keys"; device models including keywords such as "google_sdk", "Emulator", or "Android SDK built for x86"; manufacturer names including the keyword "Genymotion"; brands starting with "generic" and device identifiers starting with "generic", product names equal to "google_sdk", and network operator names being "android".

[0072] The collected system attribute data is compared precisely with the above rules one by one. If any rule is matched, the device is directly marked as an "Android emulator" and will then enter the review process. If no rule is matched, all original attribute data is recorded for subsequent cross-validation with other features.

[0073] The hardware architecture information is obtained by parsing the Android system CPU information file to obtain the processor model, and then combining this with the application binary interfaces supported by the Android system to determine the architecture type. Specifically, CPU core information is extracted using file parsing. The " / proc / cpuinfo" file is read by creating a file read stream, and then the file content is read line by line by encapsulated into a buffered read stream object. During the reading process, it is checked whether each line of data contains the keywords "model name" or "Hardware". If a match is found, the line of data is extracted as the original CPU model information and the reading is terminated. If the reading process encounters situations such as a non-existent file, restricted permissions, or abnormal input / output, the exception is captured and the original CPU model information is recorded as an empty value.

[0074] Next, the function in the system build class is called to obtain the list of supported application binary interfaces. The first element is taken as the main architecture type of the device. Common types include "arm64-v8a", "armeabi-v7a", "x86" and "x86-64".

[0075] Based on a dual screening logic involving CPU model and architecture type, the system first checks whether the original CPU model information includes PC processor-specific keywords such as "Genuine Intel(R)", "Intel(R) Core(TM)", "Intel(R) Pentium(R)", "Intel(R) Xeon(R)", "AMD", or "placeholder". If these are included, it is directly identified as a PC architecture. If these keywords are not included, the system further checks whether the main architecture type is "x86" or "x86-64". If both are met, it is also identified as a PC architecture. Since the CPU architecture of real Android devices is mostly ARM series, and PC architecture is a high-frequency characteristic of emulators, if it is identified as a PC architecture, the device is marked as an "Android emulator", and the CPU model, main architecture type, and determination criteria are recorded. If it is not identified as a PC architecture, the relevant original data is retained for subsequent verification.

[0076] The sensor configuration status is obtained by verifying the existence of predefined key physical sensors on the Android device. Sensor configuration status detection primarily focuses on the light sensor, a common feature of mobile devices and difficult for emulators to simulate at low cost. Based on the passed context instance, a system service function is called to obtain the sensor manager instance. If the sensor manager instance is empty, the light sensor is directly determined to be missing; if the sensor manager instance is not empty, the function to obtain the default sensor for that instance is called to obtain the light sensor object. If the obtained light sensor object is empty, the device is explicitly marked as an Android emulator.

[0077] If the light sensor object is obtained, its functions for obtaining the manufacturer and accuracy can be called to retrieve parameters such as manufacturer name and accuracy. This verifies whether the parameters are within the normal range of a real hardware sensor, thus eliminating invalid sensors that have been fraudulently registered. Simultaneously, other core sensors such as gravity sensors and gyroscopes can also be verified. If multiple core sensors are missing or have abnormal parameters, the device is marked as an "Android emulator." All sensor detection results are recorded in detail, including sensor presence status, manufacturer information, and accuracy parameters.

[0078] The functional integrity verification selects the dialing function of an Android device, which requires no dangerous permissions and is a core communication function of the device, as the verification target. A dialing intent is constructed based on a context instance. The intent data is set to a dialing format, such as "tel:123456," using the intent action function, and the intent action is specified as activating the dialing interface. Subsequently, the packet sensor instance is obtained by calling the context instance's packet sensor acquisition function, and the instance's parsing activity function is called to check if the device has a default application component capable of handling the dialing intent. The default application matching parameter is used to limit and match default applications, preventing third-party applications from affecting the detection results. If the parsing activity function returns empty, it indicates that the device cannot normally activate the dialing function, and it is marked as "Android emulator"; if it returns non-empty component information, it indicates that the dialing function is available, and the functional integrity verification result is recorded as passed.

[0079] Based on the above system attribute detection, hardware architecture detection, sensor detection, and functional integrity verification results, a comprehensive screening and judgment is performed using OR logic. If the system attribute matches the emulator identifier, or the detection is a PC architecture, or the light sensor is missing, or the dialing function is unavailable, as long as any one of these conditions is met, the device is initially determined to be an "Android emulator". If none of the conditions are met, it is determined to be "no suspected features found".

[0080] Subsequently, the raw collected data, verification process data, and judgment results from various dimensions are integrated to form static feature comprehensive data. This data includes key information such as system attribute matching details, CPU model, main architecture type, PC architecture judgment results, light sensor presence status and parameters, dialing function verification results, and suspected marker status. The data is traceable and can support cross-validation for subsequent dynamic feature detection. Finally, the process is connected. If it is initially determined to be an "Android emulator," the static feature comprehensive data is passed to step S105 to participate in the final judgment of the multi-layer fusion strategy; if it is determined to be "no suspected features found," the static feature comprehensive data is passed to step S102 to perform deep detection in combination with dynamic features.

[0081] Regarding S102:

[0082] In practice, the sampling parameters are first configured, setting the total duration and sampling period of the preset time window. Combining the dynamic changes in memory allocation between the Android emulator and the real device, the total duration covers memory fluctuations in typical scenarios such as application startup, background operation, and resource loading. The sampling period balances fine-grained capture of memory changes with device performance load, and can be adjusted according to the performance level of the Android device being tested. If the device is a low-performance terminal, the sampling period can be appropriately increased to reduce resource consumption; if it is a high-performance device, the period can be shortened to improve data accuracy.

[0083] After the parameters are configured, the start time of the time window is recorded by the system clock function, and the end time is calculated, which is the sum of the start time and the total duration, to determine the range of the time window.

[0084] Within a preset time window, memory-mapped file read operations are performed according to the sampling period. First, all active process identifiers of the Android device to be tested are obtained. By reading the names of subdirectories under the system's " / proc" directory, the "status" file under each subdirectory is traversed, the "state" field is parsed, and processes with a status of running or sleeping are selected as active processes, while zombie processes and stopped processes are excluded.

[0085] For each active process, a memory-mapped file path is constructed as " / proc / [process ID] / maps", where "[process ID]" is replaced with the actual process ID. System file reading functions, such as Android's file input stream functions, are invoked to read the file content according to the sampling period. If a process terminates during sampling (i.e., the file does not exist), the process's termination timestamp is recorded, and reading from it ceases.

[0086] For each sampling moment, i.e., the execution moment of each read operation, the acquired memory-mapped file content is parsed to extract memory region information. Each line of data in the memory-mapped file corresponds to a memory region, with the format "start address-end address, permissions, offset, device identifier, inode, path".

[0087] During parsing, the file content is split line by line. Each line of data is processed, and the start and end addresses are extracted using "-" as separators. Hexadecimal strings are converted to decimal integers. Permission fields are extracted and parsed as read, write, execute, private, or shared attributes. The mapping type is determined based on the path field: if the path is empty, it is an anonymous mapping; if the path is a specific file path, it is a file mapping. The identifier associated with the current process is the process identifier. The parsing results of all active processes at the same sampling time are summarized, including start and end addresses, memory permissions, mapping types, and process identifiers, to form the memory address allocation status at that moment.

[0088] Finally, the system clock function records the timestamp of each sampling moment, and the memory address allocation status at each moment is arranged in ascending order of timestamp to construct a time-series dataset. The time-series dataset is stored in a list structure, where each element is a dictionary including a timestamp and a list of memory states. Each sub-element in the memory state list corresponds to the parsing result of a memory region. Lightweight processing is required during storage; for example, permission attributes are converted into binary identifiers, with read, write, execute, and private each corresponding to specific identifier values. Combined permissions are represented by summation, reducing the dataset's space footprint.

[0089] An address space evolution sequence is constructed based on a time-series dataset. First, all memory address allocation states in the time-series dataset are traversed and sorted by timestamp. The memory address allocation state corresponding to each timestamp is defined as an address space object. Each address space object includes the memory region information of all active processes at that moment, including the start address, end address, memory permissions, mapping type, process identifier, and corresponding timestamp.

[0090] Next, in chronological order of timestamps, address space objects at two adjacent sampling times are selected and recorded as the preceding and succeeding objects. These are then compared to identify the transformation relationship.

[0091] During the comparison, the process identifier and the start and end addresses of the memory region are used as the joint matching criteria. If a memory region exists only in the subsequent object and not in the preceding object, it is determined to be a new change; if it exists only in the preceding object and not in the subsequent object, it is determined to be a release change; if the memory region exists in both the preceding and subsequent objects, but the memory permissions, mapping type, and other attributes have changed, it is determined to be an attribute change change, and the original attributes before the change and the new attributes after the change are recorded; if the identifier and attributes of the memory region do not change in either the preceding or subsequent object, it is determined to be no change.

[0092] All transformation results of each pair of adjacent address space objects, including the specific details of addition, release, and attribute changes, are integrated into the transformation relationship between the two. All address space objects and their corresponding transformation relationships are sequentially linked in order of timestamp to form an address space evolution sequence that continuously records the address space state transition process. Each node in the sequence is an address space object, and the connection between nodes is the corresponding transformation relationship.

[0093] See Figure 2 The flowchart for constructing the address space scope provided in the embodiments of this application includes:

[0094] S201, taking all address space objects in the address space evolution sequence as the set of objects in the category, and defining the transformation relationship between adjacent address space objects as the set of morphisms in the category, with each morphism corresponding to the mapping from the address space object at the previous time to the address space object at the next time.

[0095] S202, Define the composition rule of morphisms: If there exists a morphism from the first address space object to the second address space object and a morphism from the second address space object to the third address space object, the composition of the two morphisms is a morphism from the first address space object to the third address space object.

[0096] S203, Set identity morphism, for each address space object, there exists a self-mapping morphism, and the transformation relationship is empty;

[0097] S204 constructs the address space scope through object sets, morphism sets, composite rules, and identity morphisms.

[0098] In practical implementation, the address space evolution sequence is modeled using category theory to construct address space categories. First, the core components of a category are clarified. All address space objects in the address space evolution sequence are taken as the object set of the category. Each object retains its own memory region information and timestamp identifier. The transformation relationship between adjacent address space objects is defined as a set of morphisms in the category. Each morphism corresponds to the mapping from the preceding address space object to the following address space object. The morphism includes the transformation type and detailed information of the corresponding memory region.

[0099] Next, the composition rules of morphisms are defined. If there exists a first morphism from the first object to the second object and a second morphism from the second object to the third object, then the two morphisms can be combined to form a composite morphism from the first object to the third object. The mapping relationship of the composite morphism is jointly determined by the transformation relationship between the first morphism and the second morphism. For example, if the first morphism is "add memory region A" and the second morphism is "change the attribute of memory region A", then the composite morphism is "add memory region A and change the attribute". If there is a conflict between the transformation contents of the two morphisms, such as the first morphism releasing a region and the second morphism changing the attribute of that region, then the later morphism shall prevail, and the conflict resolution result shall be recorded in the composite morphism.

[0100] Then, an identity morphism is set. For each address space object in the object set, there exists a self-mapping identity morphism. The transformation relationship corresponding to this morphism is empty, that is, when an object is mapped to itself, there is no addition, release or attribute change of any memory region.

[0101] Finally, by integrating the object set, morphism set, morphism composition rules, and identity morphism, the address space category is formally constructed. Specifically, during integration, a structured data model, such as a nested dictionary model, is first constructed as the category carrier. A nested dictionary structure is used to realize the associated storage of each element. The top-level dictionary includes four core key-value pairs: "object set," "morphism set," "composite rule function," and "identity morphism set." Among them, the "object set" uses the unique identifier of the address space object, such as a combination of timestamp and process identifier, as the key, and stores the object, including memory region information and timestamp; the "morphism set" uses the source object identifier to the target object identifier as the key, and stores the transformation type of the morphism and details of the memory regions involved; the "composite rule function" receives the key-value pairs of two consecutive morphisms, automatically extracts the transformation content from the morphism set, generates a composite morphism according to preset rules, and writes it into the morphism set; the "identity morphism set" uses the object identifier as the key and stores the null transformation information of the corresponding self-mapping morphism.

[0102] Based on this, the category axioms are checked, and the associative law verification function is called. Three continuous morphisms f, g, and h are randomly selected, and the composition results of (h∘g)∘f and h∘(g∘f) are calculated respectively. If the transformation content and conflict records of the two are completely consistent, the associative law holds. The unity law verification function is called, and for any morphism f: A→B, “f∘identical morphism A” and “identical morphism B∘f” are calculated respectively. If the results are consistent with the original content of f, the unity law holds. When both checks pass, the structured data model is confirmed to be a valid address space category. Here, ∘ is the morphism composition operator in category theory.

[0103] Regarding S103:

[0104] By constructing functors, the dynamic evolution of the address space is linked to the time dimension. Then, by detecting and quantifying the evolution patterns of different running instances through natural transformations, regularity markers are generated to distinguish the dynamic differences between simulators and real devices.

[0105] Specifically, based on the address space categories constructed in step S102, the address evolution functor of the current running instance is obtained through the functor construction algorithm. The functor construction algorithm establishes a structured mapping between the two categories, namely the time series category and the address space category, maintaining the object associations and morphological composite logic of the categories, and binding the time dimension with the dynamic evolution of the address space.

[0106] Specifically, firstly, a time series category is defined, with all sampling moments within the preset time window in step S102 as the object set of the time series category, and each object is uniquely identified by its corresponding timestamp; the chronological relationship between adjacent sampling moments is defined as the morphism set of the time series category, that is, for any two consecutive sampling moments, such as moment M and moment N, where moment M is earlier than moment N, a one-way morphism from moment M to moment N is defined. This morphism only represents the logical relationship in time and does not include additional attribute information.

[0107] Next, the mapping rules of the address evolution functor are clarified. For object mapping, each time object in the time series category is mapped to the address space object with the corresponding timestamp in the address space category. That is, time M is mapped to the address space object with the same timestamp as time M in the address space category. For morphism mapping, each sequential morphism in the time series category is mapped to the transformation relationship morphism between two address space objects in the address space category. That is, the morphism from time M to time N is mapped to the transformation relationship morphism between the address space object corresponding to time M and the address space object corresponding to time N in the address space category.

[0108] Then, the structure-preserving property of the functor is verified by calling the morphic composite verification function. This function is constructed based on the morphic composite rules of the address space category in step S102 and the mapping rules of the address evolution functor in step S103. It is used to verify the "morphic composite preservation" and "identity morphic preservation" functions of the address evolution functor. Specifically, the morphic composite verification function verifies the morphisms corresponding to any three consecutive time points in the time series category, such as time M, time N, and time Q. If there is a morphism H1 from time M to time N and a morphism H2 from time N to time Q in the time series category, then the composite morphism is H1+H2. After the address evolution functor is mapped, it must satisfy the composite morphism H1'+H2' of the transformation relation morphism H1' corresponding to H1 and the transformation relation morphism H2' corresponding to H2, which is consistent with the transformation relation morphism mapped by H1+H2. At the same time, the mapping relationship of the identity morphism is verified. The self-mapping identity morphism of each object in the time series category must be mapped to the self-mapping identity morphism of the corresponding address space object in the address space category. Once the structural properties and identity morphism mapping relationship have been verified, the address evolution functor of the current running instance is considered to have been constructed.

[0109] Subsequently, the natural transformation detection algorithm is executed to determine whether natural transformations exist between the address evolution functors of multiple running instances, generating regularity markers. The natural transformation detection algorithm is an algorithm that quantifies the consistency of evolution patterns of different functors. By constructing a family of morphisms and verifying the commutation graph, it determines whether two functors can maintain the consistency of transformation associations of address space objects in the same time dimension.

[0110] Specifically, first, multiple running instances under the same scenario are selected. All running instances are in an Android system environment, with consistent application running status, system load level, total duration of the preset time window, and sampling period. For each running instance, the corresponding address evolution functor is obtained according to the functor construction process described above, forming a functor set.

[0111] To detect the natural transformation between any two functors, for any two address evolution functors in the functor set, such as functor F and functor G, a family of morphisms is constructed, denoted as the family of morphisms φ. Each morphism in this family of morphisms corresponds to the same time point and connects the address space objects mapped by functors F and G. Specifically, combining the sampling period and total duration of the preset time window, the total number of samples n within the preset time window is determined, and each sampling moment is sequentially numbered according to its chronological order. For any time object t in the time series, ... i Let i be the sequence number of the sampling time, i = 1, 2, ..., n, and let there exist a morphism φ_t in the family of morphisms φ. i The domain is the time object t mapped by the functor F. i The corresponding address space object F(t) i The codomain is the time object t mapped by the functor G.i The corresponding address space object G(t) i ).

[0112] Then, verify whether the family of morphisms satisfies the natural transformation condition. Select any two time objects t1 and t2 in the time series category, where t1 is earlier than t2, and the morphisms m between them. In the address space category, functor F maps m to the transformation relation morphism F(m), and functor G maps m to the transformation relation morphism G(m).

[0113] φ_t1 is the morphism of the object t1 at time t in the morphism family φ. Its domain is the address space object F(t1) at time t1 mapped by the functor F, and its codomain is the address space object G(t1) at time t1 mapped by the functor G. φ_t2 is the morphism of the object t2 at time t in the morphism family φ. Its domain is the address space object F(t2) at time t2 mapped by the functor F, and its codomain is the address space object G(t2) at time t2 mapped by the functor G.

[0114] Based on the above definition, a commutative graph is constructed to verify whether the composite morphism of φ_t2 and F(m) is consistent with that of G(m) and φ_t1. That is, the path from F(t1), through F(m) to F(t2), and then through φ_t2 to G(t2) has the same transformation relationship as the path from φ_t1 to G(t1), and then through G(m) to G(t2). If all time-time objects and their corresponding morphisms satisfy the above commutative graph conditions, then it is determined that there is a natural transformation between functors F and G.

[0115] Finally, the proportion of natural transformations is statistically analyzed and marked. This involves iterating through all pairwise functor pairs in the functor set and calculating the proportion of functor pairs with natural transformations to the total number of pairs. If this proportion exceeds a preset threshold, it indicates a high degree of consistency in address evolution patterns across multiple running instances, resulting in a high-regularity mark. If the proportion does not reach the preset threshold, it indicates significant differences in evolution patterns, resulting in a low-regularity mark. The preset threshold can be calibrated based on historical test data from real Android devices and emulators.

[0116] Regarding S104:

[0117] A topological analysis is performed on the address space scope. Based on the address space scope constructed in step S102, all address space objects in the address space scope are extracted as the vertex set of the topological graph. Each vertex retains the memory region information and timestamp at the corresponding time. Next, directed edges of the topological graph are defined. The transformation relationship morphism between any two address space objects in the address space scope is transformed into a directed edge. The starting point of the edge is the vertex corresponding to the preceding address space object, and the ending point is the vertex corresponding to the following address space object. The attributes of the edge include the transformation type (addition, release, and attribute change) and details of the memory regions involved, such as the process identifier and address range of the newly added region.

[0118] Based on this, the relationships between memory regions are further analyzed. For memory regions of the same process at different times, if the region at the later time has overlapping addresses or is continuously distributed with the region at the previous time, such as the termination address of the preceding region being adjacent to the starting address of the subsequent region, additional intra-process association edges are added between the corresponding vertices. For memory regions of different processes, if there is a shared memory identifier or mapping to the same file path, inter-process dependency edges are added, thereby constructing a complete topology graph including intra-process associations and inter-process dependencies.

[0119] Then, algebraic topological invariants are calculated using a homology computation algorithm. The first step is to construct a chain complex, decomposing the topological graph into chain groups according to its dimensions. The zero-dimensional chain group consists of all vertices, with each vertex corresponding to a basic chain element; the one-dimensional chain group consists of all directed edges, with each edge corresponding to a basic chain element. If there are closed regions enclosed by edges in the topological graph, a two-dimensional chain group is constructed, with each closed region corresponding to a basic chain element. Higher-dimensional chain groups can be deduced in this manner, with the highest dimension determined based on the actual topological complexity.

[0120] The second step is to define boundary operators. Specifically, for a one-dimensional chain element, its boundary operator is the difference between the starting and ending vertices, defined according to algebraic notation rules. For example, if an edge runs from vertex X to vertex Y, the boundary operator is YX. For a two-dimensional chain element, its boundary operator is the algebraic sum of all edges constituting the region in a clockwise or counterclockwise direction. For example, if a triangle is composed of edges UV, VW, and WU, the boundary operator is UV + VW - WU. Homomorphic mappings between chain groups of different dimensions are established through boundary operators.

[0121] The third step is to calculate the homology group. For the chain group of each dimension, the boundary chain group and the closed chain group are obtained through the boundary operator. The homology group of a certain dimension is the quotient group of the closed chain group and the boundary chain group of that dimension. The rank of the homology group, that is, the number of linearly independent generators, is defined as the Betti number of that dimension. The zero-dimensional Betti number represents the number of independent connected components in the topological graph, the one-dimensional Betti number represents the number of independent cycles in the graph, that is, closed paths that cannot be eliminated by the boundary operator, and the higher-dimensional Betti number represents the number of high-dimensional holes.

[0122] The fourth step is to calculate the Euler characteristic. Based on the Betti numbers of each dimension, the formula is: "Euler characteristic = zero-dimensional Betti number - one-dimensional Betti number + two-dimensional Betti number - ... + (-1)". k The "×k Vibbetti number" is calculated, where k is the highest dimension of the homology group corresponding to the topological graph, determined by the actual geometric structure of the topological graph. This value comprehensively reflects the overall complexity and connectivity of the topological structure.

[0123] Finally, address space complexity features are generated by integrating the calculated Betti numbers of various dimensions, such as zero-dimensional Betti numbers, one-dimensional Betti numbers, and Euler characteristic numbers, to form a feature vector that includes quantifiable indicators of topological complexity. The Betti numbers represent local features of the topological structure, such as the number of independent components and rings, while the Euler characteristic number reflects the overall characteristics. Simultaneously, the feature dimensions are supplemented by combining the number of vertices (i.e., the total number of address space objects), the number of edges (i.e., the total number of transformation and association relationships), and the edge density (i.e., the ratio of the number of edges to the number of vertices). The generated address space complexity features, along with the static feature synthesis data from step S101 and the regularity markers from step S103, are then fed into step S105 for final simulator detection and judgment.

[0124] Regarding S105:

[0125] See Figure 3 A flowchart of the multi-layer fusion strategy provided in the embodiments of this application includes:

[0126] The static feature layer performs preliminary screening based on static feature information. If there is a clear simulator identifier in the system attribute information, or there is a significant inconsistency in the hardware architecture information verification, or the configuration of key physical sensors is missing and the functional integrity verification fails, it is determined to be a simulator and the detection result is output.

[0127] In the evolutionary pattern layer, for devices whose static feature information is not clearly determined, the pattern markers are used to further distinguish them. In response to the marker being highly patterned, the device is determined to be a simulator and the detection result is output. In response to the marker being low patterned, no determination is made for the time being, and the device enters the topological complexity layer.

[0128] The topology complexity layer compares the address space complexity features of devices marked as having low regularity with a preset benchmark range of real device complexity. If the address space complexity features are lower than the lower limit of the benchmark range, the device is identified as a simulator and the detection result is output. If the address space complexity features are within the benchmark range, the device is identified as a real device and the detection result is output.

[0129] In practice, a layer-by-layer screening strategy of static feature layer, evolution law layer and topological complexity layer is adopted to integrate the static feature information of step S101, the regularity mark of step S103 and the address space complexity feature of step S104 to determine whether the Android device to be detected is an Android emulator or a real Android device.

[0130] Specifically, static feature layer screening is performed first. Based on the system attribute matching results, PC architecture determination results, sensor presence status, and functional verification results recorded in step S101, static feature layer determination rules are set. If there is a clear simulator identifier in the system attributes, such as detecting a preset simulator-specific keyword, or if the hardware architecture is determined to be a PC architecture without a reasonable adaptation explanation, such as a non-x86 architecture tablet device, or if the core sensors are missing and two or more core functions are unavailable in the functional integrity verification, then the Android device to be tested is directly determined to be a simulator, a detection result is generated, and the subsequent process is terminated. If none of the above conditions are met, that is, if no clear simulator identifier appears in the static features, then the device is marked as a static feature layer to be verified and enters the evolutionary rule layer for differentiation and determination.

[0131] Next, the evolutionary pattern layer is distinguished. For devices to be verified at the static feature layer, the regularity markers generated in step S103 are extracted to obtain the judgment results of high regularity markers and low regularity markers. Based on the differences in dynamic characteristics between emulators and real Android devices, emulators have more stable memory allocation patterns due to virtualization mechanisms, while real devices are more affected by hardware load and background process fluctuations, resulting in greater pattern differences. An evolutionary pattern layer judgment rule is set: if it is marked as high regularity, that is, the proportion of natural changes between address evolution functors of multiple running instances exceeds a preset threshold, it is judged as an emulator, a detection result is generated, and the process is terminated; if it is marked as low regularity, the device is marked as to be verified at the evolutionary pattern layer and enters the topology complexity layer comparison.

[0132] Finally, a topological complexity layer comparison is performed. For devices whose evolutionary patterns need to be verified, the address space complexity features generated in step S104 are extracted, including indicators such as the Betti number, Euler characteristic, and the number of vertices and edge density of the topological graph in each dimension. These features are compared with the complexity benchmark range of real Android devices. This benchmark range is determined by statistical analysis of the topological complexity features of a large number of real Android devices in the same scenario. It includes reasonable fluctuation ranges of zero-dimensional Betti number, one-dimensional Betti number, and Euler characteristic, as well as typical ranges of vertex number and edge density.

[0133] Due to their virtualization mechanism, Android emulators generally have lower core topology complexity metrics than real Android devices. Therefore, a topology complexity layer judgment rule is established: if any core metric of address space complexity is lower than the lower limit of the baseline range for real device complexity, it is judged as an emulator; if all core metrics are within the baseline range, it is judged as a real device. After completing these three layers of screening, emulator detection results are generated.

[0134] See Figure 4 The diagram illustrates a simulator detection system based on multi-dimensional feature fusion, as provided in this application embodiment, including:

[0135] The acquisition module 10 is used to acquire static feature information of the device under test, including at least one of system attribute information, hardware architecture information, sensor configuration status and functional integrity verification results;

[0136] The construction module 20 is used to periodically read the memory-mapped file of the process of the device under test within a preset time window, obtain the memory address allocation status at each time, and form a time-series dataset; based on the time-series dataset, construct an address space evolution sequence; perform category theory modeling on the address space evolution sequence to construct an address space category;

[0137] The first generation module 30 is used to obtain the address evolution functor of the current running instance based on the address space scope through a functor construction algorithm; obtain the address evolution functors of multiple running instances, determine whether there is a natural transformation between the address evolution functors through a natural transformation detection algorithm, and generate regularity markers.

[0138] The second generation module 40 is used to perform topological structure analysis on the address space category, calculate algebraic topological invariants through a homology calculation algorithm, and generate address space complexity features.

[0139] The output module 50 is used to filter and determine the simulator detection results layer by layer based on the static feature information, regularity markers and address space complexity features through a multi-layer fusion strategy.

[0140] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A simulator detection method based on multi-dimensional feature fusion, characterized in that, include: Collect static feature information of the device under test, including at least one of system attribute information, hardware architecture information, sensor configuration status and functional integrity verification results; The memory-mapped files of the process of the device under test are periodically read within a preset time window to obtain the memory address allocation status at each time point, forming a time-series dataset; based on the time-series dataset, an address space evolution sequence is constructed; the address space evolution sequence is modeled using category theory to construct an address space category; Based on the address space scope, the address evolution functor of the current running instance is obtained through the functor construction algorithm; the address evolution functors of multiple running instances are obtained, and the natural transformation detection algorithm is used to determine whether there is a natural transformation between the address evolution functors, and a regularity marker is generated. Perform topological analysis on the address space domain, calculate algebraic topological invariants using a homology computation algorithm, and generate address space complexity features; Based on the static feature information, regularity markers, and address space complexity features, a multi-layer fusion strategy is used to filter and determine the results layer by layer, and the simulator detection results are output.

2. The simulator detection method based on multi-dimensional feature fusion according to claim 1, characterized in that, The system attribute information includes device identifier, device model and manufacturer information, and the simulator identifier is identified based on preset rules; the hardware architecture information is obtained by parsing the system CPU information file to obtain the processor model, and the architecture type is determined by combining the application binary interface; the sensor configuration status is obtained by verifying the existence of predefined key physical sensors; the functional integrity verification result is obtained by detecting the device's responsiveness to preset system intent actions.

3. The simulator detection method based on multi-dimensional feature fusion according to claim 1, characterized in that, The step of periodically reading the memory-mapped file of the device process under test within a preset time window to obtain the memory address allocation status at each time point and form a time-series dataset includes: Set the sampling period and total duration, and define the range of the preset time window; Within a preset time window, at intervals of the sampling period, the system's underlying interface is called to read the memory-mapped file of the process in the device under test; For each sampling time, the memory-mapped file is parsed to extract memory region information; The memory region information of all processes at the same time is integrated into the memory address allocation status at that time, and arranged in the order of timestamps to form a time-series dataset.

4. The simulator detection method based on multi-dimensional feature fusion according to claim 3, characterized in that, The construction of the address space evolution sequence based on the time-series dataset includes: Define the memory address allocation status corresponding to each timestamp in the time series dataset as an address space object; By comparing address space objects at adjacent sampling times, the addition, release, and attribute changes of memory regions are identified and integrated into transformation relationships; By sequentially connecting all address space objects and their corresponding transformation relationships in chronological order, an address space evolution sequence is formed that continuously records the address space state transition process.

5. The simulator detection method based on multi-dimensional feature fusion according to claim 1, characterized in that, The evolution sequence of the address space is modeled using category theory to construct address space categories, including: The set of objects in the address space evolution sequence is taken as the category. The transformation relationship between adjacent address space objects is defined as the set of morphisms in the category. Each morphism corresponds to the mapping from the address space object in the previous time step to the address space object in the next time step. Define the composition rule for morphisms: if there exists a morphism from the first address space object to the second address space object and a morphism from the second address space object to the third address space object, the composition of the two morphisms is a morphism from the first address space object to the third address space object. Set an identity morphism, and for each address space object, there exists a self-mapping morphism, with the transformation relationship being empty; Address space categories are constructed using object sets, morphism sets, composition rules, and identity morphisms.

6. The simulator detection method based on multi-dimensional feature fusion according to claim 5, characterized in that, Based on the aforementioned address space scope, the address evolution functor of the current running instance is obtained through a functor construction algorithm, including: Define the time series scope, the object is each sampling moment within a preset time window, and the morphism is the sequential relationship between adjacent sampling moments; Construct an address evolution functor to map the objects in the time series category to the address space objects at the corresponding time in the address space category, and map the morphisms of the time series category to the transformation relationship morphisms between the corresponding address space objects; Verify that the structure-preserving properties of the address evolution functor and the mapping relationship of the identity morphism hold, and obtain the address evolution functor of the current running instance.

7. The simulator detection method based on multi-dimensional feature fusion according to claim 1, characterized in that, The step of determining whether natural transformations exist between the address evolution functors using a natural transformation detection algorithm and generating regularity markers includes: Select multiple running instances under the same scenario and obtain their respective address evolution functors; For any two address evolution functors, check if there exists a family of morphisms, each corresponding to the same point in time, connecting the address space objects mapped by the two address evolution functors; Verify whether the family morphism satisfies the natural transformation condition, that is, whether the commutation graph formed by the transformation relationship morphism of any two time points and the time point sequence between them is valid; In response to the existence of a family of morphisms that satisfy the natural transformation condition, it is determined that there is a natural transformation between two address evolution functors; The proportion of natural transformations among multiple address evolution functors is statistically analyzed. If the proportion exceeds a preset threshold, a high regularity marker is generated; otherwise, a low regularity marker is generated.

8. The simulator detection method based on multi-dimensional feature fusion according to claim 1, characterized in that, Perform topological analysis on the address space domain, calculate algebraic topological invariants using a homology computation algorithm, and generate address space complexity features, including: Objects within the address space are used as topological vertices, and morphisms are used as directed edges connecting the vertices to construct a topological graph structure. Based on the aforementioned topological graph structure, the geometric structure features are analyzed using a homology calculation algorithm to calculate the rank of the zero-dimensional homology group, the one-dimensional homology group, and the two-dimensional homology group. Betti numbers and Euler characteristic numbers are extracted as algebraic topological invariants and integrated into address space complexity features.

9. The simulator detection method based on multi-dimensional feature fusion according to claim 1, characterized in that, The process of filtering and judging layer by layer through a multi-layer fusion strategy and outputting simulator detection results includes: The static feature layer performs preliminary screening based on static feature information. If the system attribute information contains a simulator identifier, or there is an inconsistency in the hardware architecture information verification, or the configuration of key physical sensors is missing and the functional integrity verification fails, it is determined to be a simulator and the detection result is output. The evolutionary pattern layer distinguishes devices whose static feature information is not determined by combining regularity labels. If the label is marked as highly regular, it is determined as a simulator and the detection result is output; if the label is marked as low regularity, it is not determined for the time being and enters the topological complexity layer. The topology complexity layer compares the address space complexity features of devices marked as having low regularity with a preset benchmark range of real device complexity. If the address space complexity features are lower than the lower limit of the benchmark range, the device is identified as a simulator and the detection result is output. If the address space complexity features are within the benchmark range, the device is identified as a real device and the detection result is output.

10. A simulator detection system based on multi-dimensional feature fusion, used to implement the simulator detection method based on multi-dimensional feature fusion as described in any one of claims 1-9, characterized in that, include: The acquisition module is used to acquire static feature information of the device under test, including at least one of system attribute information, hardware architecture information, sensor configuration status and functional integrity verification results; The module is used to periodically read the memory-mapped files of the process of the device under test within a preset time window, obtain the memory address allocation status at each time point, and form a time-series dataset; based on the time-series dataset, construct an address space evolution sequence; perform category theory modeling on the address space evolution sequence to construct an address space category; The first generation module is used to obtain the address evolution functor of the current running instance based on the address space scope through a functor construction algorithm; obtain the address evolution functors of multiple running instances, determine whether there is a natural transformation between the address evolution functors through a natural transformation detection algorithm, and generate regularity markers. The second generation module is used to perform topological structure analysis on the address space category, calculate algebraic topological invariants through a homology calculation algorithm, and generate address space complexity features. The output module is used to filter and determine the simulator detection results layer by layer based on the static feature information, regularity markers and address space complexity features through a multi-layer fusion strategy.

Images