A method, device, apparatus and readable storage medium for out-of-boundary detection

Abstract

This application provides an out-of-bounds detection method, apparatus, device, and readable storage medium. The method is applied to bytecode files, which include at least one method. The method includes: obtaining detection indication information for a first method, the detection indication information including a detection offset parameter, a first length corresponding to multiple bytecode instructions in the first method, and a first bytecode instruction corresponding to the detection offset parameter. The at least one method includes the first method, and the first bytecode instruction is an undetected bytecode instruction among the multiple bytecode instructions. If the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length, the detection offset parameter is updated according to the instruction length. This method can perform pre-run verification of bytecode files, effectively ensuring the safe and stable operation of the corresponding application on electronic devices.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method, apparatus, device and readable storage medium for detecting boundary crossings. Background Technology

[0002] The stable operation of an application depends on the proper management of bytecode files. In order to prevent system crashes and information leaks caused by potential risks such as illegal memory access and malicious code injection during the operation of the application on electronic devices, it is necessary to provide a method to verify bytecode files before execution to ensure that the application runs safely and stably on electronic devices. Summary of the Invention

[0003] This application provides a method, apparatus, device, and readable storage medium for out-of-bounds detection, which can verify bytecode files before execution. Verified bytecode files can effectively ensure that the corresponding application runs safely and stably on electronic devices.

[0004] To achieve the above objectives, this application adopts the following technical solution:

[0005] Firstly, this application provides an out-of-bounds detection method applied to bytecode files, wherein the bytecode file includes at least one method, and the out-of-bounds detection method includes:

[0006] Obtain detection indication information for the first method, the detection indication information including a detection offset parameter, a first length corresponding to multiple bytecode instructions in the first method, and a first bytecode instruction corresponding to the detection offset parameter, the at least one method including the first method, and the first bytecode instruction being an undetected bytecode instruction among the multiple bytecode instructions;

[0007] If the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length, then the detection offset parameter is updated according to the instruction length.

[0008] Based on the out-of-bounds detection method provided in this application, if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length, it can be determined that the first bytecode instruction has not exceeded the bounds, i.e., the first bytecode instruction has passed the out-of-bounds detection. Then, the detection offset parameter is updated using the instruction length of the first bytecode instruction, so that the updated detection offset parameter corresponds to the next bytecode instruction among multiple bytecode instructions. If the sum of the instruction length of the next bytecode instruction and the updated detection offset parameter is less than the first length, then the next bytecode instruction has also not exceeded the bounds. In other words, the above method can determine the out-of-bounds status of the first bytecode instruction by comparing the sum of the detection offset parameter and the instruction length of the first bytecode instruction with the first length (i.e., the total instruction length) of multiple bytecode instructions in the first method. By continuously updating the detection offset parameter, out-of-bounds status of each bytecode instruction in the first method can be detected. Especially for methods without terminating bytecode instructions, this method can effectively avoid potential risks such as illegal memory access and malicious code injection, ensuring that the bytecode file is verified before execution, thereby guaranteeing the safe and stable operation of the application on electronic devices.

[0009] Optionally, updating the detection offset parameter according to the instruction length includes: updating the detection offset parameter according to the instruction length to obtain the updated detection offset parameter.

[0010] It should be understood that the updated detection offset parameter can be equal to the sum of the detection offset parameter and the instruction length of the first bytecode instruction.

[0011] In one possible implementation of the first aspect, if the sum of the detection offset parameter and the instruction length is greater than the first length, a first prompt message is displayed, which indicates that the first bytecode instruction has exceeded the bounds.

[0012] It should be understood that if the sum of the detection offset parameter and the instruction length corresponding to the first bytecode instruction is greater than the first length, then it can be determined that the first bytecode instruction is out of bounds. In this case, it is not necessary to consider whether the first bytecode instruction is the last bytecode instruction among multiple bytecode instructions, nor is it necessary to consider the specific instruction type of the first bytecode instruction. The out-of-bounds situation of the first bytecode instruction can be directly judged, which effectively speeds up the out-of-bounds detection speed of multiple bytecode instructions in the first method, further speeds up the out-of-bounds detection speed of at least one method in the bytecode file, and improves the out-of-bounds detection efficiency.

[0013] Optionally, the first prompt message can be an error message or an out-of-bounds prompt message.

[0014] In one possible implementation of the first aspect, the method further includes: if the first bytecode instruction is not a bytecode instruction that satisfies a preset condition, and the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length, then displaying a second prompt message, the second prompt message being used to indicate that the first bytecode instruction has exceeded the bounds.

[0015] It should be understood that if the sum of the detection offset parameter and the instruction length of the first bytecode instruction equals the first length, and the first bytecode instruction is not a bytecode instruction that meets the preset conditions, then it can be determined that the first bytecode instruction is out of bounds. For example, suppose the first bytecode instruction is not a bytecode instruction that meets the preset conditions. If the sum of the instruction length of the first bytecode instruction and the detection offset parameter is exactly equal to the first length, that is, the updated detection offset parameter equals the first length, it indicates that the first bytecode instruction is the last bytecode instruction in the first method. However, since the first bytecode instruction is not a bytecode instruction that meets the preset conditions, it can be determined that the first bytecode instruction is out of bounds.

[0016] In one possible implementation of the first aspect, the method further includes: if the first bytecode instruction is a bytecode instruction that satisfies a preset condition, and the first bytecode instruction is the last bytecode instruction among the plurality of bytecode instructions, then displaying a third prompt message when the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length, the third prompt message being used to indicate that the first bytecode instruction has not exceeded the boundary.

[0017] It should be understood that, based on the above possible implementation methods, that is, the updated detection offset parameter is exactly equal to the first length, at this time, the first bytecode instruction is an unconditional transfer instruction (such as a termination instruction or a jump instruction), indicating that the first bytecode instruction has not exceeded the bounds. Since the first bytecode instruction is the last bytecode instruction in the first method, the bounds of the first method have also been detected, and it can be determined that the first method has not exceeded the bounds.

[0018] In one possible implementation of the first aspect, the bytecode instruction that satisfies the preset conditions includes an unconditional jump instruction.

[0019] Optionally, in Java programming code, unconditional jump instructions may include direct jump instructions or termination instructions, etc.

[0020] In one possible implementation of the first aspect, bytecode instructions that do not meet the preset conditions include conditional jump instructions and bytecode instructions that are executed sequentially in the first method.

[0021] Optionally, in Java programming code, conditional jump instructions can include if instructions, if...else instructions, while instructions, or for instructions, etc.

[0022] Secondly, this application provides an out-of-bounds detection device applied to a bytecode file, the bytecode file including at least one method, the out-of-bounds detection device comprising:

[0023] The acquisition module is used to acquire detection indication information of the first method. The detection indication information includes a detection offset parameter, a first length corresponding to multiple bytecode instructions in the first method, and a first bytecode instruction corresponding to the detection offset parameter. The at least one method includes the first method, and the first bytecode instruction is an undetected bytecode instruction among the multiple bytecode instructions.

[0024] An update module is configured to update the detection offset parameter according to the instruction length if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length.

[0025] In one possible implementation of the second aspect, if the sum of the detection offset parameter and the instruction length is greater than the first length, a first prompt message is displayed, which is used to indicate that the first bytecode instruction has exceeded the bounds.

[0026] In one possible implementation of the second aspect, the device further includes:

[0027] The first prompt module is used to display a second prompt message if the first bytecode instruction is not a bytecode instruction that meets a preset condition, and the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length. The second prompt message is used to indicate that the first bytecode instruction has exceeded the bounds.

[0028] In one possible implementation of the second aspect, the device further includes:

[0029] The second prompt module is used to display a third prompt message if the first bytecode instruction is a bytecode instruction that meets a preset condition and is the last bytecode instruction among the plurality of bytecode instructions, and the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length. The third prompt message is used to indicate that the first bytecode instruction has not exceeded the boundary.

[0030] In one possible implementation of the second aspect, the bytecode instruction that satisfies the preset conditions includes an unconditional jump instruction.

[0031] In one possible implementation of the second aspect, bytecode instructions that do not meet the preset conditions include conditional jump instructions or bytecode instructions that are executed sequentially in the first method.

[0032] Thirdly, embodiments of this application provide an electronic device comprising: one or more processors; one or more memories; and one or more computer programs; wherein the one or more computer programs are stored in the one or more memories, and the one or more computer programs include instructions that, when executed by the electronic device, cause the electronic device to perform the methods as described in the first aspect and any possible implementation thereof.

[0033] Fourthly, this application provides a chip system including a processor that executes a computer program stored in a memory to implement the methods in the first aspect and any possible implementation thereof.

[0034] Fifthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of the first aspect and any possible implementation thereof.

[0035] In a sixth aspect, this application provides a computer program product including computer instructions that, when executed on an electronic device, cause the electronic device to perform the methods of the first aspect and any possible implementation thereof.

[0036] The technical effects of the second to sixth aspects provided in this application can be found in the technical effects of the various possible implementations of the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0037] Figure 1 and Figure 2 This is a schematic diagram illustrating a scenario to which the boundary detection method provided in this application is applicable.

[0038] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0039] Figure 4 This is a flowchart illustrating a boundary detection method provided in an embodiment of this application.

[0040] Figure 5 This is a schematic diagram illustrating a scenario where bytecode instructions correspond to detection offset parameters, provided in an embodiment of this application.

[0041] Figure 6 This is a schematic diagram illustrating another scenario where bytecode instructions correspond to detection offset parameters, provided as an embodiment of this application.

[0042] Figure 7 This is a schematic diagram illustrating a scenario in which out-of-bounds detection is performed sequentially on each bytecode instruction in the first method based on the detection offset parameter, as provided in an embodiment of this application.

[0043] Figure 8 The flowchart corresponds to a boundary detection method provided in the embodiments of this application.

[0044] Figure 9 This is a schematic diagram of the structure of a boundary crossing detection device provided in an embodiment of this application. Detailed Implementation

[0045] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings and related embodiments. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0046] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0047] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0048] The out-of-bounds detection method provided in this application embodiment can be applied to the verification process of bytecode files.

[0049] For example, such as Figure 1 and Figure 2 The diagram illustrates a scenario where the boundary crossing detection method provided in this application is applicable. See also... Figure 1 During the development and deployment process, application developers can compile the application's source code files into binary files, or bytecode files, using a code runtime environment (such as a virtual machine). Then, they package the bytecode files and other files (such as application-related images, audio, and video) into an application installation package and publish the package to the application platform. See also... Figure 2 After the application installation package is released to the application platform, users can download the corresponding application installation package from the platform. Once downloaded, the code execution environment on the electronic device parses the package to obtain bytecode files. It then follows the instructions in the bytecode files to drive the application's installation and execution, ultimately displaying the corresponding application icon on the electronic device (e.g., a mobile phone). See also... Figure 2 The dashed section shown represents the bytecode file verification process, which can refer to the process after the code execution environment in the electronic device parses the application installation package to obtain the bytecode file, and before the code execution environment drives the application to install and run according to the instructions in the bytecode file.

[0050] In addition to the above Figure 2 Beyond the application scenarios shown, bytecode file verification can also be performed in application updates or upgrades, or in scenarios where bytecode files from unknown sources are run on electronic devices, etc. This application does not impose any limitations on these scenarios.

[0051] In some embodiments, the boundary detection method provided in this application can be applied to electronic devices. Electronic devices may include, but are not limited to, personal computers (PCs), smartphones, netbooks, tablets, smart cameras, wearable devices, handheld computers, smart TVs, personal digital assistants (PDAs), portable multimedia players (PMPs), projection devices, smart screen devices, augmented reality (AR) / virtual reality (VR) devices, mixed reality (MR) devices, in-vehicle devices, smart screens, cloud servers, televisions, or motion-sensing game consoles in human-computer interaction scenarios. This application does not impose any limitations on the specific type of electronic device.

[0052] See Figure 3 This is a schematic diagram of the hardware structure of an electronic device 300 provided in this application. The electronic device 300 may include a processor 310, an external memory interface 320, an internal memory 331, a universal serial bus (USB) interface 330, a charging management module 340, a power management module 341, a battery 342, antenna 1, antenna 2, a mobile communication module 350, a wireless communication module 360, an audio module 370, a speaker 370A, a receiver 370B, a microphone 370C, a headphone jack 370D, a sensor module 380, buttons 390, a motor 391, an indicator 392, a camera 393, a display screen 394, and a subscriber identification module (SIM) card interface 395, etc. The sensor module 380 may include a pressure sensor 380A, a gyroscope sensor 380B, a barometric pressure sensor 380C, a magnetic sensor 380D, an accelerometer sensor 380E, a distance sensor 380F, a proximity light sensor 380G, a fingerprint sensor 380H, a temperature sensor 380J, a touch sensor 380K, an ambient light sensor 380L, a bone conduction sensor 380M, etc.

[0053] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 300. In other embodiments of this application, the electronic device 300 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0054] For example, when the electronic device 300 is a mobile phone or a tablet computer, it may include all the components shown in the figure, or it may include only some of the components shown in the figure.

[0055] Processor 310 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. The different processing units may be independent devices or integrated into one or more processors.

[0056] The controller can be the nerve center and command center of the electronic device 300. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0057] The processor 310 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 310 is a cache memory. This memory can store instructions or data that the processor 310 has just used or that are used repeatedly. If the processor 310 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 310, and thus improves the efficiency of the system.

[0058] In some embodiments, the processor 310 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0059] The charging management module 340 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 340 receives charging input from the wired charger via a USB interface 330. In some wireless charging embodiments, the charging management module 340 receives wireless charging input via the wireless charging coil of the electronic device 300. While charging the battery 342, the charging management module 340 can also supply power to the electronic device via the power management module 341.

[0060] The power management module 341 connects the battery 342, the charging management module 340, and the processor 310. The power management module 341 receives input from the battery 342 and / or the charging management module 340, providing power to the processor 310, internal memory 331, external memory interface 320, display screen 394, camera 393, and wireless communication module 360. The power management module 341 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance).

[0061] In some other embodiments, the power management module 341 may also be located within the processor 310. In still other embodiments, the power management module 341 and the charging management module 340 may also be located in the same device.

[0062] The wireless communication function of electronic device 300 can be realized through antenna 1, antenna 2, mobile communication module 350, wireless communication module 360, modem processor and baseband processor, etc.

[0063] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 300 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0064] The mobile communication module 350 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G on the electronic device 300. The mobile communication module 350 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 350 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 350 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1.

[0065] In some embodiments, at least some functional modules of the mobile communication module 350 may be disposed in the processor 310. In some embodiments, at least some functional modules of the mobile communication module 350 and at least some modules of the processor 310 may be disposed in the same device.

[0066] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 370A, receiver 370B, etc.) or displays images or videos through a display screen 394. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 310 and may be housed in the same device as the mobile communication module 350 or other functional modules.

[0067] The wireless communication module 360 ​​can provide solutions for wireless communication applications on the electronic device 300, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 360 ​​can be one or more devices integrating at least one communication processing module. The wireless communication module 360 ​​receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 310. The wireless communication module 360 ​​can also receive signals to be transmitted from processor 310, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0068] In some embodiments, antenna 1 of electronic device 300 is coupled to mobile communication module 350, and antenna 2 is coupled to wireless communication module 360, enabling electronic device 300 to communicate with networks and other devices via wireless communication technology. Wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. GNSS can include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0069] Electronic device 300 implements display functions through a GPU, a display screen 394, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 394 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 310 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0070] The display screen 394 is used to display images, videos, etc., such as various display interfaces in the embodiments of this application. The display screen 394 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Miniled LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 300 may include one or N display screens 194, where N is a positive integer greater than 1.

[0071] Electronic device 300 can achieve shooting function through ISP, camera 393, video codec, GPU, display 394 and application processor.

[0072] The external storage interface 320 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 300. The external memory card communicates with the processor 310 through the external storage interface 320 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0073] Internal memory 331 can be used to store executable program code, including instructions. Processor 310 executes various functional applications and data processing of electronic device 300 by running the instructions stored in internal memory 331. Internal memory 331 may include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function (such as sound playback, image playback, etc.). The data storage area may store data created during the use of electronic device 300 (such as audio data, phonebook, etc.).

[0074] In addition, the internal memory 331 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0075] Electronic device 300 can implement audio functions through audio module 370, speaker 370A, receiver 370B, microphone 370C, headphone jack 370D, and application processor.

[0076] The out-of-bounds detection method provided in this application embodiment will be described below with reference to the corresponding flowchart. It should be noted that the essence of out-of-bounds detection is to determine the execution range of the first bytecode instruction, that is, to determine whether the execution of the currently detected bytecode instruction exceeds a predefined bytecode region. The predefined bytecode region can also be called a legal range or legal area, which can refer to the bytecode region from the position of the first bytecode instruction to the position of the last bytecode instruction. In other words, if the execution of the currently detected bytecode instruction does not exceed the predefined bytecode region, it can be determined that the currently detected bytecode instruction has not exceeded the bounds; conversely, if the execution of the currently detected bytecode instruction exceeds the predefined bytecode region, it can be determined that the currently detected bytecode instruction has exceeded the bounds.

[0077] See Figure 4 This is a flowchart illustrating an out-of-bounds detection method 400 provided in an embodiment of this application. Before introducing the method 400 provided in this application, a brief description of the execution entity involved in the embodiments of this application is given. The above-mentioned out-of-bounds detection method 400 can be executed by an electronic device, or by a module applied in an electronic device (e.g., a processor, chip, chip system, or etc.), or by a logic module or software capable of implementing all or part of the functions of the electronic device. In some embodiments, the above-mentioned out-of-bounds detection method 400 can also be executed by other tools (e.g., a verifier) ​​used to inspect bytecode files. It is easy to understand that other tools used to inspect bytecode files can also be set in the electronic device.

[0078] See Figure 4 The boundary detection method 400 provided in this application embodiment may include the following steps S410 to S420, and each step is described in detail below.

[0079] Step S410: Obtain detection indication information of the first method. The detection indication information includes detection offset parameters, the first length corresponding to multiple bytecode instructions in the first method, and the first bytecode instruction corresponding to the detection offset parameters.

[0080] It should be understood that the first method, also known as the target method or the method to be tested, refers to any one of the at least one methods included in the bytecode file. For example, in C language programming code, the first method can be any function used to implement the corresponding functions; in Java language programming code, the first method can be a code module used to implement the various functions, that is, a Method or Function.

[0081] The first length can refer to the total instruction length of all bytecode instructions in the first method.

[0082] It should be understood that different bytecode instructions may have different instruction lengths. In some embodiments, the instruction length value corresponding to different bytecode instructions can be queried through a preset bytecode instruction database or data table. Based on this, the instruction length corresponding to each bytecode instruction in the first method can be obtained separately, and the first length can be determined accordingly.

[0083] In one example, in Java programming code, the first length can be used to indicate the size of the list of bytecode instructions in the first method.

[0084] The first bytecode instruction, also known as the currently detected bytecode instruction, as the name suggests, can refer to the bytecode instruction being detected among multiple bytecode instructions. In other words, the first bytecode instruction can be the bytecode instruction that has not yet been detected among the multiple bytecode instructions corresponding to the first method.

[0085] The detection offset parameter can be a parameter corresponding to the currently detected bytecode instruction. Parameters such as `loop` or `insn_offset` can be used to represent the detection offset parameter. In this embodiment, the value of the detection offset parameter can be used to indicate the offset position information (or position information) of the first bytecode instruction (or the currently detected bytecode instruction) in the first method. For example, assuming the detection offset parameter has a value of 3, then based on the value of 3, the offset position of the currently detected bytecode instruction in the first method can be determined to be 3.

[0086] In some embodiments, the initial value of the detection offset parameter can be preconfigured. For example, the initial value of the detection offset parameter can be preconfigured to 0 or 1. When the initial value of the detection offset parameter is 0 or 1, the detection offset parameter can be used to indicate the first bytecode instruction in the first method.

[0087] In some examples, the initial value of the pre-configured detection offset parameter can be less than the first length corresponding to multiple bytecode instructions in the first method.

[0088] In some embodiments, the number of values ​​corresponding to the detection offset parameter corresponds to the number of bytecode instructions in the first method.

[0089] For example, assuming the first method includes six bytecode instructions, code1, code2, code3, code4, code5, and code6, and using insn_offset to represent the detection offset parameter, then see... Figure 5The six values ​​of insn_offset can be used to indicate the six bytecode instructions in the first method. In other words, in this example, the number of values ​​corresponding to the detection offset parameter is 6, and the number of bytecode instructions in the first method is also 6. That is, the number of values ​​of the detection offset parameter is the same as the number of bytecode instructions in the first method.

[0090] Specifically, see Figure 5 The first bytecode instruction code1 in the first method can be indicated by insn_offset[1], where insn_offset[1] can indicate that the specific value of the detection offset parameter insn_offset is 1; similarly, the second bytecode instruction code2 in the first method can be indicated by insn_offset[2]; the third bytecode instruction code3 in the first method can be indicated by insn_offset[3]; the fourth bytecode instruction code4 in the first method can be indicated by insn_offset[4]; the fifth bytecode instruction code5 in the first method can be indicated by insn_offset[5]; and the sixth bytecode instruction code6 in the first method can be indicated by insn_offset[6].

[0091] In one example, when the initial value of the detection offset parameter is 0, and the instruction length of each bytecode instruction in the first method is 1 byte (B), the maximum value of the detection offset parameter can be one less than the number of bytecode instructions in the first method. For instance, assuming N represents the number of bytecode instructions in the first method (that is, the first method includes N bytecode instructions), and n represents the detection offset parameter, then when the initial value of the detection offset parameter is 0, and the instruction length of each bytecode instruction is 1B, the value of the detection offset parameter n can include 0, 1, 2, ..., N-1, where n and N are both positive integers. The maximum value of the detection offset parameter n is N-1, which differs from the number of bytecode instructions N in the first method by 1.

[0092] In another example, when the initial value of the detection offset parameter is 1, and the instruction length of each bytecode instruction in the first method is 1B, the maximum value of the detection offset parameter can be equal to the number of bytecode instructions in the first method. For example, assuming N represents the number of bytecode instructions in the first method (that is, the first method includes N bytecode instructions), and n represents the detection offset parameter, then when the initial value of the detection offset parameter is 1, and the instruction length of each bytecode instruction is 1B, the value of the detection offset parameter can include 1, 2, 3, ..., N, where n and N are both positive integers. The maximum value of the detection offset parameter n is N, which is equal to the number of bytecode instructions N in the first method.

[0093] It should be noted that the above example is based on the assumption that each of the six bytecode instructions has an instruction length of 1 byte. If the instruction length of each bytecode instruction is not 1 byte, then the value of the detection offset parameter for the other bytecode instructions (excluding the first bytecode instruction, code1) needs to be determined based on the instruction length of each bytecode instruction. In other words, during the out-of-bounds detection process, the specific value of the detection offset parameter is related to the instruction length of each bytecode instruction in the first method.

[0094] For example, see Figure 6 Assuming the detection offset parameter is represented by insn_offset, and the initial value of the detection offset parameter insn_offset is 0, and the instruction length of each bytecode instruction in the first method is 1B, then insn_offset[0] can be used to indicate the first bytecode instruction code1 in the first method; based on the instruction length of the first bytecode instruction code1 being 1B, insn_offset[1] can be used to indicate the second bytecode instruction code2 in the first method; based on the instruction length of the second bytecode instruction code2 being 1B, insn_offset[2] can be used to indicate the third bytecode instruction code3 in the first method; based on the instruction length of the third bytecode instruction code3 being 1B, insn_offset[3] can be used to indicate the fourth bytecode instruction code4 in the first method; similarly, based on the instruction length of the fourth bytecode instruction code4 being 1B, insn_offset[4] can be used to indicate the fifth bytecode instruction code5 in the first method; based on the instruction length of the fifth bytecode instruction code5 being 1B, insn_offset[5] can be used to indicate the sixth bytecode instruction code6 in the first method.

[0095] Based on the above Figure 6 In the example described, if the instruction length of the first four bytecode instructions in the first method is 1B and the instruction length of the fifth bytecode instruction code5 is 5B, then insn_offset[9] can be used to indicate the sixth bytecode instruction code6 in the first method.

[0096] It's not difficult to understand that the detection offset parameter can also be viewed as a loop variable, the number of which is related to the number of bytecode instructions in the first method. Each iteration of this loop variable yields a corresponding value for the detection offset parameter. During this process, the specific value obtained by the detection offset parameter is related to the instruction length of the currently detected bytecode instruction.

[0097] In some embodiments, the detection indication information may further include a first offset parameter of the first method in the bytecode file. The first offset parameter can be used to indicate the position information of the first method in the bytecode file (e.g., offset position information or index position information). Therefore, the first bytecode instruction in the bytecode file can also be directly determined based on the first offset parameter and the detection offset parameter.

[0098] Based on the foregoing Figure 6 In the example described above, assuming the first offset parameter is represented by begin_offset, during the out-of-bounds detection process of the bytecode file, the position of the first method in the bytecode file can be determined by the first offset parameter begin_offset, and the position of the first bytecode instruction in the first method can be determined by the detection offset parameter. For example, when the value of the first offset parameter begin_offset is 0, and the value of the detection offset parameter is also 0 (i.e., insn_offset[0]), the first bytecode instruction can be determined to be the first bytecode instruction code1 in the first method based on the first offset parameter begin_offset and the detection offset parameter insn_offset.

[0099] Step S420: If the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length, then update the detection offset parameter according to the instruction length of the first bytecode instruction.

[0100] It should be understood that if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length, it indicates that the currently detected first bytecode instruction has not exceeded the bounds, and it can be determined that the currently detected first bytecode instruction has passed the bounds detection. Based on this, the detection offset parameter can be updated according to the instruction length of the currently detected first bytecode instruction.

[0101] See, as an example rather than a limitation. Figure 7 Assume the first method includes 6 bytecode instructions: code1, code2, code3, code4, code5, and code6. The instruction lengths of these 6 bytecode instructions are 1B, 2B, 1B, 1B, 1B, and 1B respectively. When the detection offset parameter insn_offset is 0, it indicates that the first bytecode instruction being detected is... Figure 7The first bytecode instruction, code1, has a length of 1B, which determines the length of the currently detected first bytecode instruction to be 1B. Based on the length of each of the six bytecode instructions, the first length is determined to be 7B. Therefore, the sum of the detection offset parameter insn_offset (0) and the length of the first bytecode instruction code1 is 1 (0 + 1 = 1). This means the sum of insn_offset and the length of the first bytecode instruction code1 is less than the first length of 7. Therefore, it can be determined that the currently detected first bytecode instruction is not out of bounds; that is, the first bytecode instruction code1 in the first method is not out of bounds. In this case, the value of the detection offset parameter insn_offset can be updated based on the instruction length of the first bytecode instruction code1 (1B).

[0102] In some embodiments, the updated detection offset parameter can be the sum of the detection offset parameter and the instruction length of the first bytecode instruction. Based on the foregoing Figure 7 In the example described, the value of the detection offset parameter insn_offset after being updated based on the instruction length of the first bytecode instruction code1 is 1, i.e., insn_offset[1].

[0103] It is easy to understand that the updated detection offset parameter can indicate the next bytecode instruction among multiple bytecode instructions in the first method. For example, see... Figure 7 If the detection offset parameter, before the update, indicates that the first bytecode instruction being detected is the first bytecode instruction code1, then the updated detection offset parameter can indicate... Figure 7 The second bytecode instruction code2 in the first method shown is the first bytecode instruction indicating the updated detection offset parameter. Figure 7 The second bytecode instruction in the sequence is code2. In other words, the first bytecode instruction indicated by the updated detection offset parameter is the next bytecode instruction following the first bytecode instruction indicated before the detection offset parameter was updated.

[0104] It's easy to understand that, in the first method where the initial value of the detection offset parameter starts from 0, the updated value of the detection offset parameter can be the sum of the instruction lengths of the bytecode instructions that have already completed out-of-bounds detection. Based on the foregoing Figure 7For example, the updated detection offset parameter has a value of 1, i.e., insn_offset[1]. The bytecode instruction that has completed the out-of-bounds detection is the first bytecode instruction code1, and the instruction length of the first bytecode instruction code1 is 1B. The updated detection offset parameter has the same value as the instruction length of the first bytecode instruction code1. For another example, suppose the updated detection offset parameter has a value of 3, i.e., insn_offset[3]. At this time, the bytecode instructions that have completed the out-of-bounds detection include the first bytecode instruction code1 and the second bytecode instruction code2. The instruction length of the first bytecode instruction code1 is 1B, and the instruction length of the second bytecode instruction code2 is 2B. The sum of the instruction lengths of the two bytecode instructions is 3B, which is equal to the updated detection offset parameter value of 3.

[0105] As is easily understood, updating the detection offset parameter can further determine whether each bytecode instruction exceeds a predefined memory region. If the bytecode instruction exceeds the predefined memory region, the detection offset parameter will not be able to accurately indicate the next bytecode instruction corresponding to the bytecode instruction that has completed the detection. Conversely, if the bytecode instruction does not exceed the predefined memory region, the detection offset parameter can accurately indicate the next bytecode instruction corresponding to the bytecode instruction that has completed the detection. Therefore, based on the above method, not only is the instruction execution range of each bytecode instruction in the first method determined, but also the memory access range of each bytecode instruction in the first method, further improving the accuracy of out-of-bounds detection.

[0106] In some embodiments, if the sum of the detected offset parameter and the instruction length of the first bytecode instruction is greater than the first length, a first prompt message can be displayed, which is used to indicate that the first bytecode instruction has exceeded the bounds.

[0107] For example, the above might have been modified due to malicious code injection. Figure 7 In the example described, the source code corresponding to the first bytecode instruction `code1` is modified from a 1-byte instruction to another 8-byte instruction. Therefore, the sum of the detection offset parameter `insn_offset` (value 0) and the instruction length of the first bytecode instruction `code1` is 8 (i.e., 0 + 8 = 8). Since the sum of the detection offset parameter `insn_offset` and the instruction length of the first bytecode instruction `code1` is greater than the first length of 7, it can be determined that the first bytecode instruction `code1` has exceeded its bounds. In this case, a first warning message indicating that the first bytecode instruction `code1` has exceeded its bounds can be displayed on the electronic device to indicate that the bytecode instruction or its corresponding bytecode file may have encountered problems such as illegal memory access or malicious code injection.

[0108] Optionally, the first message can be an error message or an out-of-bounds message. For example, "Out of bounds, cannot access!" or "false", etc.

[0109] In some embodiments, if the first bytecode instruction is not a bytecode instruction that meets the preset conditions, and the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length, a second prompt message can be displayed. The second prompt message is used to indicate that the first bytecode instruction has exceeded the bounds.

[0110] It should be understood that bytecode instructions that meet preset conditions can include unconditional jump instructions. Unconditional jump instructions are a type of bytecode instruction among control jump instructions that can change the order of program execution without relying on conditional judgments.

[0111] For example, in Java programming code, unconditional jump instructions can include direct jump instructions and termination instructions. Examples include the `jump` instruction or the `return` instruction. In the source code, the `return` instruction can be `return.void` or `return xxx`, etc.

[0112] In this embodiment of the application, bytecode instructions that do not meet the preset conditions may include conditional jump instructions or bytecode instructions that are executed sequentially in the first method.

[0113] It should be understood that conditional jump instructions are a type of bytecode instruction within control jump instructions. Compared to unconditional jump instructions, conditional jump instructions can change the execution order of the program if a condition is met. A conditional jump instruction can mean that if a condition is met, the bytecode instruction after the jump is executed; otherwise, if the condition is not met, the next bytecode instruction is executed sequentially. For example, in Java programming code, conditional jump instructions can include if instructions, if...else instructions, while instructions, or for instructions, etc.

[0114] In the first method, the bytecode instructions executed sequentially can be understood as bytecode instructions that, during the execution of the source code corresponding to the first method, can continue to execute the next bytecode instruction after the current bytecode instruction has been executed.

[0115] For example, in Java programming code, sequentially executed bytecode instructions may include load and store bytecode instructions (such as iload or istore instructions), operation bytecode instructions (such as iadd or isub instructions), or object creation and access bytecode instructions (such as new or getfield instructions), and so on.

[0116] It's easy to understand that if the first bytecode instruction is a conditional jump instruction or a bytecode instruction executed sequentially in the first method, then if the sum of the offset parameter and the instruction length of the first bytecode instruction equals the first length, it can be determined that the first bytecode instruction is the last bytecode instruction in the first method. However, since the first bytecode instruction is a conditional jump instruction or a sequentially executed bytecode instruction, the next bytecode instruction will continue to be executed after the first bytecode instruction is executed. This contradicts the first instruction, and in this case, it can be determined that the first bytecode instruction is out of bounds.

[0117] In some embodiments, if the first bytecode instruction is a bytecode instruction that meets preset conditions and is the last bytecode instruction among multiple bytecode instructions, then a third prompt message can be displayed if the sum of the offset parameter and the instruction length of the first bytecode instruction is equal to the first length. The third prompt message is used to indicate that the first bytecode instruction has not exceeded the bounds.

[0118] It should be understood that if the first bytecode instruction is an unconditional jump instruction and is also the last bytecode instruction in the first method, and if the sum of the detection offset parameter and the instruction length of the first bytecode instruction equals the first length, then after the bytecode instruction detection is completed, there are no undetected bytecode instructions in the first method. Therefore, it can be determined that the first bytecode instruction has not exceeded its bounds, and consequently, the first method corresponding to the first bytecode instruction has also not exceeded its bounds. In this case, a third prompt message can be displayed on the electronic device to indicate that the first bytecode instruction has not exceeded its bounds and / or the first method has not exceeded its bounds.

[0119] For example, suppose the first bytecode instruction is a termination instruction, such as a return instruction. When this termination instruction is executed, the first method will stop running and return control of the code execution to the caller. That is, the code execution environment will no longer read or execute subsequent bytecode instructions. Therefore, if the first bytecode instruction is the last bytecode instruction in the first method, and the sum of the offset parameter and the instruction length of the first bytecode instruction equals the first length, it means that the execution of this bytecode instruction has not exceeded the first length, and it can be determined that the first bytecode instruction has not gone out of bounds.

[0120] It should be noted that if the first bytecode instruction is a bytecode instruction that meets the preset conditions, then if the sum of the offset parameter and the instruction length of the first bytecode instruction is less than or equal to the first length, it can be determined that the first bytecode instruction is not out of bounds; if the sum of the offset parameter and the instruction length of the first bytecode instruction is greater than the first length, it can be determined that the first bytecode instruction is out of bounds, and / or a first prompt message indicating that the first bytecode instruction is out of bounds can be displayed.

[0121] See Figure 7 Assuming the first method includes 6 bytecode instructions, namely code1, code2, code3, code4, code5, and code6, the instruction lengths corresponding to the above 6 bytecode instructions are 1B, 2B, 1B, 1B, 1B, and 1B respectively. The detection offset parameter is represented by insn_offset. When the initial value of insn_offset is 0, it indicates the first bytecode instruction code1, that is, insn_offset[0] corresponds to code1. In the process of performing out-of-bounds detection on each bytecode instruction in the first method, it can be determined that insn_offset[1] corresponds to c ode2, insn_offset[3] corresponds to code3, insn_offset[4] corresponds to code4, insn_offset[5] corresponds to code5, and insn_offset[6] corresponds to code6. code6 is the last bytecode instruction in the first method. If the bytecode instruction is a bytecode instruction that meets the preset conditions, the sum of the instruction length of code6 (1B) and the value of the detection offset parameter insn_offset (6) (1+6=7) is equal to the first length of 7 of the 6 bytecode instructions in the first method. Therefore, it can be determined that code6 has not exceeded the boundary.

[0122] In one possible scenario, if the first bytecode instruction is a direct jump instruction, such as a `jump` instruction, then whether the direct jump instruction is out of bounds can be determined based on the jump offset information corresponding to the direct jump instruction and the position information of the direct jump instruction in the first method. The jump offset information corresponds to the instruction length of the direct jump instruction and can be determined based on the encoded bytes carried by the first bytecode instruction or the log information during the compilation (or parsing) of the bytecode file; the position information of the direct jump instruction in the first method can be determined based on the detection offset parameter. For example, if the sum of the values ​​corresponding to the jump offset information and the position information of the direct jump instruction is greater than the first length of the multiple bytecode instructions corresponding to the first method, then it can be determined that the direct jump instruction is out of bounds; conversely, if the sum of the values ​​corresponding to the jump offset information and the position information of the direct jump instruction is less than or equal to the first length of the multiple bytecode instructions corresponding to the first method, then it can be determined that the direct jump instruction is not out of bounds.

[0123] In other embodiments, if the first bytecode instruction is a bytecode instruction that meets preset conditions, and the first bytecode instruction is the last bytecode instruction among multiple bytecode instructions, then the third prompt information may not be displayed if the sum of the offset parameter and the instruction length of the first bytecode instruction is equal to the first length.

[0124] For example, in Figure 2 In the bytecode file verification scenario shown, if the first bytecode instruction is a bytecode instruction that meets the preset conditions and is the last bytecode instruction among multiple bytecode instructions, and if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length, then the third prompt message can be omitted, and the application corresponding to the bytecode file can be directly installed and run.

[0125] Based on the above Figure 4 The boundary detection method 400 shown is as follows: Figure 8 The diagram shown is a flowchart of a boundary detection method provided in an embodiment of this application. (See also...) Figure 8 The method may include:

[0126] Step 1: Obtain the detection indication information from the first method.

[0127] Step 2: If multiple bytecode instructions in the first method have not been traversed, update the detection offset parameter according to the instruction length.

[0128] It should be understood that the fact that multiple bytecode instructions were not fully traversed in the first method can be interpreted as the existence of bytecode instructions that have not yet undergone out-of-bounds detection. The process of updating the detection offset parameter based on the instruction length may include: if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length, then the detection offset parameter is updated based on the instruction length of the first bytecode instruction.

[0129] Step 3: If the updated offset parameter is greater than the first length, then the first bytecode instruction is out of bounds.

[0130] It is not difficult to understand that the updated detection offset parameter can refer to the sum of the detection offset parameter and the instruction length of the first bytecode instruction.

[0131] Step 4: If the updated detection offset parameter is not greater than the first length, and the first bytecode instruction is a bytecode instruction that meets the preset conditions, then update the detection offset parameter according to the instruction length, so as to use the updated detection offset parameter to perform out-of-bounds detection on the next bytecode instruction of the currently detected bytecode instruction.

[0132] It should be understood that "the updated detection offset parameter is not greater than the first length" can be interpreted as "the updated detection offset parameter is less than or equal to the first length".

[0133] When the first bytecode instruction is a bytecode instruction that meets the preset conditions, and the first bytecode instruction is the last bytecode instruction among multiple bytecode instructions, if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length, then it can be determined that the first method has not exceeded the bounds.

[0134] Step 5: If the first bytecode instruction is not a bytecode instruction that meets the preset conditions, and the updated detection offset parameter is equal to the first length, then it can be determined that the first bytecode instruction is out of bounds.

[0135] Based on steps four and five above, it can be concluded that if the detected offset parameter is less than the first length after the update, the detected offset parameter can be updated directly according to the instruction length of the first bytecode instruction. Figure 8 For details regarding the first method, detection indication information, command length, detection offset parameters, and first length in the flowchart shown, please refer to the aforementioned documentation. Figure 4 The descriptions in the embodiments described herein will not be repeated here.

[0136] Based on the out-of-bounds detection method provided in this application, if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length, it can be determined that the first bytecode instruction has passed the out-of-bounds detection, i.e., the first bytecode instruction has not exceeded the bounds. In other words, based on the above method, the out-of-bounds status of the first bytecode instruction can be determined by comparing the sum of the detection offset parameter and the instruction length of the first bytecode instruction with the first length (i.e., the total instruction length) of multiple bytecode instructions in the first method. Then, the detection offset parameter is updated using the instruction length of the first bytecode instruction, so that the updated detection offset parameter corresponds to the next bytecode instruction among the multiple bytecode instructions. If the instruction length of the next bytecode instruction and the updated detection offset parameter are less than the first length, then the next bytecode instruction has also not exceeded the bounds. By repeating this process, out-of-bounds status of each bytecode instruction in the first method can be detected. Especially for methods without terminating bytecode instructions, this method can effectively avoid potential risks such as illegal memory access and malicious code injection, ensuring that the bytecode file is verified before execution, thereby guaranteeing the safe and stable operation of the application on electronic devices.

[0137] It should be noted that the out-of-bounds detection method provided in this application embodiment can not only effectively detect out-of-bounds situations of methods without termination bytecode instructions or bytecode instructions in bytecode files; but also can detect out-of-bounds situations of every bytecode instruction in the bytecode file. Compared with the method of detecting out-of-bounds situations of some bytecode instructions, it further improves the comprehensiveness and accuracy of out-of-bounds detection.

[0138] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0139] The boundary detection methods provided in the above embodiments Figure 9This is a schematic block diagram of a boundary crossing detection device 900 provided in an embodiment of this application. Figure 9 The boundary detection device 900 shown may include an acquisition module 910 and an update module 920.

[0140] The acquisition module 910 is used to acquire detection indication information of the first method. The detection indication information includes a detection offset parameter, a first length corresponding to multiple bytecode instructions in the first method, and a first bytecode instruction corresponding to the detection offset parameter. The at least one method includes the first method, and the first bytecode instruction is a bytecode instruction that has not been detected among the multiple bytecode instructions.

[0141] The update module 920 is used to update the detection offset parameter according to the instruction length if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length.

[0142] In some embodiments, if the sum of the detection offset parameter and the instruction length is greater than the first length, a first prompt message is displayed, which indicates that the first bytecode instruction has exceeded the bounds.

[0143] In some embodiments, the apparatus further includes:

[0144] The first prompt module is used to display a second prompt message if the first bytecode instruction is not a bytecode instruction that meets a preset condition, and the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length. The second prompt message is used to indicate that the first bytecode instruction has exceeded the bounds.

[0145] In some embodiments, the apparatus further includes:

[0146] The second prompt module is used to display a third prompt message if the first bytecode instruction is a bytecode instruction that meets a preset condition and is the last bytecode instruction among the plurality of bytecode instructions, and the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length. The third prompt message is used to indicate that the first bytecode instruction has not exceeded the boundary.

[0147] In some embodiments, the bytecode instructions that meet the preset conditions include unconditional jump instructions.

[0148] In some embodiments, bytecode instructions that do not meet the preset conditions include conditional jump instructions or bytecode instructions that are executed sequentially in the first method.

[0149] It should be understood that the description of the device embodiments can refer to the relevant descriptions of the various method embodiments above. Their implementation principles and technical effects are similar to those of the method embodiments above, and will not be repeated here.

[0150] Figure 9 The "module" of the boundary detection device 900 shown can be implemented in hardware, software, or by hardware executing corresponding software. For example, the "module" can refer to an application-specific integrated circuit (ASIC), electronic circuits, a processor (e.g., a shared processor, a proprietary processor, or a group processor) and memory for executing one or more software or firmware programs, combined logic circuits, and / or other suitable components that support the described functions.

[0151] Based on the methods provided in the above embodiments, this application also provides the following:

[0152] This application provides a computer program product, which includes a program that, when run by an electronic device, causes the electronic device to perform the methods shown in the above embodiments.

[0153] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods shown in the above embodiments.

[0154] This application provides a chip including a memory and a processor. The processor executes a computer program stored in the memory to control the electronic device to perform the methods shown in the various embodiments above.

[0155] It should be understood that the processor mentioned in the embodiments of this application can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0156] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0157] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. In the above embodiments, the descriptions of each embodiment have different focuses; parts not described in detail or recorded in a certain embodiment can be referred to in the relevant descriptions of other embodiments.

[0158] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0159] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0160] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0161] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0162] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a large-screen device, a recording medium, a computer memory, a read-only memory, a random access memory, an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0163] Finally, it should be noted that the above description is only a specific implementation of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the protection scope of this application.

Claims

1. A boundary crossing detection method, characterized in that, Applied to bytecode files, the bytecode files including at least one method, the out-of-bounds detection method including: Obtain detection indication information for the first method, the detection indication information including a detection offset parameter, a first length corresponding to multiple bytecode instructions in the first method, and a first bytecode instruction corresponding to the detection offset parameter, the at least one method including the first method, and the first bytecode instruction being an undetected bytecode instruction among the multiple bytecode instructions; If the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length, then the detection offset parameter is updated according to the instruction length.

2. The boundary crossing detection method according to claim 1, characterized in that, If the sum of the detection offset parameter and the instruction length is greater than the first length, a first prompt message is displayed, which indicates that the first bytecode instruction has exceeded the bounds.

3. The boundary crossing detection method according to claim 1 or 2, characterized in that, The method further includes: If the first bytecode instruction is not a bytecode instruction that meets the preset conditions, and the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length, then a second prompt message is displayed. The second prompt message is used to indicate that the first bytecode instruction has exceeded the bounds.

4. The boundary crossing detection method according to any one of claims 1 to 3, characterized in that, The method further includes: If the first bytecode instruction is a bytecode instruction that meets preset conditions, and the first bytecode instruction is the last bytecode instruction among the plurality of bytecode instructions, then a third prompt message is displayed if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is equal to the first length. The third prompt message is used to indicate that the first bytecode instruction has not exceeded the boundary.

5. The boundary crossing detection method according to claim 3 or 4, characterized in that, The bytecode instructions that meet the preset conditions include unconditional jump instructions.

6. The boundary crossing detection method according to any one of claims 3-5, characterized in that, Bytecode instructions that do not meet the preset conditions include conditional jump instructions or bytecode instructions that are executed sequentially in the first method.

7. A boundary crossing detection device, characterized in that, Applied to bytecode files, the bytecode files including at least one method, the out-of-bounds detection device comprising: The acquisition module is used to acquire detection indication information of the first method. The detection indication information includes a detection offset parameter, a first length corresponding to multiple bytecode instructions in the first method, and a first bytecode instruction corresponding to the detection offset parameter. The at least one method includes the first method, and the first bytecode instruction is an undetected bytecode instruction among the multiple bytecode instructions. An update module is configured to update the detection offset parameter according to the instruction length if the sum of the detection offset parameter and the instruction length of the first bytecode instruction is less than the first length.

8. An electronic device, characterized in that, The electronic device is configured to perform the method as described in any one of claims 1 to 6.

9. A chip system, characterized in that, The chip system includes a processor that executes a computer program stored in a memory to implement the method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 6.

Images