Detecting security risks in binary software code

Abstract

Systems, methods, and software can be used to detect security risks in binary software code. In some aspects, a computer-implemented method includes: receiving, at an electronic device, a set of binary software code to be loaded onto the electronic device; disassembling, by the electronic device, the set of binary software code into a set of assembly code; determining, by the electronic device, a number of occurrences of assembly instructions in the set of assembly code; and determining, by the electronic device, whether the set of binary software code presents a security risk based on the number of occurrences of the assembly instructions.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 148,692, filed October 1, 2018, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the detection of security risks in binary software code. Background Art

[0004] In some cases, software services can be provided by executable binary software code. Binary software code is computer software in binary format. Computer software can be application software, system software (e.g., operating system or device driver), or components thereof. Binary software code can also be referred to as binary program code, executable code, or object code. Summary of the Invention

[0005] Therefore, a method, an apparatus, a computer-readable medium, and a computer program are provided as detailed in the following claims. Attached Figure Description

[0006] Figure 1 This is a schematic diagram illustrating an example communication system for detecting security risks in binary software code based on its implementation.

[0007] Figure 2 This is a schematic diagram illustrating an example electronic device 102 that detects security risks in binary software code according to an implementation.

[0008] Figure 3 It is based on the high-level architecture diagram of the implemented computing system.

[0009] Figure 4 This is a flowchart illustrating an example method for detecting security risks in binary software code based on an implementation.

[0010] In each of the accompanying drawings, the same reference numerals and symbols indicate the same elements. Detailed Implementation

[0011] Electronic devices can receive sets of binary software code to be installed on and executed on the electronic device. These sets of binary software code can be binary software code of a software program, a portion of a software program, or multiple software programs. In some cases, sets of binary software code can contain security risks. Security risks can include malicious code that could harm a user's device, expose user information, or a combination thereof. Security risks can also include software code that is vulnerable to malicious attacks.

[0012] In some cases, binary software code sets can be received during sideloading. Sideloading refers to receiving software from a source that is not managed by the electronic device's supplier or operating system. For example, binary software code sets can be sideloaded onto an electronic device via file transfer from a USB-connected drive, a memory storage device (such as a memory card or disk), a Bluetooth-connected device, or a WiFi-connected device. Binary software code sets can also be sideloaded onto an electronic device by downloading from websites other than the app store of the electronic device's operating system. In some cases, sideloaded software code can be packaged in Android Package (APK) format or iPhone Application (IPA) format.

[0013] Because side-loaded software code is not received from trusted sources such as app stores, it may pose a higher security risk than software code downloaded through app stores. For example, the binary code of side-loaded software can be modified by a malicious attacker to change the software's functionality. For instance, the binary code can be patched to circumvent licensed features by inserting junk routines or no-op (NOP) instructions. If this modified binary code is installed on and runs on an electronic device, it can pose a security risk to the device.

[0014] In some implementations, electronic devices can determine whether a binary software code set poses a security risk based on the frequency and pattern analysis of one or more assembly instructions. The frequency and location of these assembly instructions can indicate that the binary software code set has been modified in its binary format and therefore poses a security risk. The electronic device can output a notification indicating the security risk and prevent the modified binary software code from being installed on the electronic device. Figures 1-4 The associated descriptions provide additional details about these implementations.

[0015] Figure 1 This is a schematic diagram illustrating an example communication system 100 for detecting security risks in binary software code according to an implementation. At a high level, the example communication system 100 includes an electronic device 102 and a security server 120 communicatively coupled to a network 110.

[0016] Security server 120 represents an application, application set, software, software module, hardware, or any combination thereof that can be configured to manage the detection of security risks to binary software code. In some cases, security server 120 may be part of an Enterprise Mobility Management (EMM) server that manages applications and devices associated with an enterprise connected to electronic device 102. The EMM server can install, update, and manage licenses for enterprise applications. In some cases, the EMM server may be located at the enterprise's premises, behind a firewall, or a combination thereof. In some cases, the EMM server may be configured to provision enterprise services in the cloud. In some implementations, the security server may receive, send, and update assembly instructions associated with one or more compilers to electronic device 102, and receive notifications from electronic device 102 indicating that the binary software code set has security risks. Figures 2-4 The associated descriptions provide additional details about these implementations.

[0017] Electronic device 102 refers to an electronic device that receives a binary software code set and determines whether the binary software code set poses a security risk based on search results of one or more assembly instructions. Figures 2-4 The associated descriptions provide additional details about these implementations.

[0018] Example communication system 100 includes network 110. Network 110 represents an application, application set, software, software module, hardware, or combination thereof that can be configured to send data messages between entities in system 100. Network 110 may include a wireless network, a wired network, the Internet, or a combination thereof. For example, network 110 may include one or more radio access networks (RANs), a core network (CN), and the Internet. The RAN may include one or more radio access technologies. In some implementations, the radio access technology may be Global System for Mobile Communications (GSM), the provisional standard (IS-95), the Universal Mobile Telecommunications System (UMTS), CDMA2000 (Code Division Multiple Access), Evolved Universal Mobile Telecommunications System (E-UMTS), Long Term Evolution (LTE), Advanced LTE, 5G, or any other radio access technology. In some instances, the core network may be an Evolved Packet Core (EPC).

[0019] The Radio Access Array (RAN) is a part of a wireless telecommunications system that implements radio access technologies such as UMTS, CDMA2000, 3GPP LTE, 3GPP LTE-A, and 5G. In many applications, the RAN includes at least one base station. A base station can be a radio base station capable of controlling all or at least some of the radio-related functions of a fixed part of the system. Base stations can provide radio interfaces for communication with mobile devices within their coverage area or cell. Base stations can be distributed across the cellular network to provide wide coverage areas. Base stations communicate directly with one or more mobile devices, other base stations, and one or more core network nodes.

[0020] although Figure 1 The elements are shown as various component parts, sections, or modules that implement various features and functions; however, these elements may instead include numerous submodules, third-party services, components, libraries, etc., where appropriate. Furthermore, the features and functions of various components may be combined into fewer components where appropriate.

[0021] Figure 2 This is a schematic diagram 200 illustrating an example electronic device 102 for detecting security risks in binary software code according to an implementation. Electronic device 102 includes a processing unit 262, a communication subsystem 266, a user interface 268, and a memory 264. Electronic device 102 may include additional, different, or fewer features where appropriate.

[0022] Example processing unit 262 may include one or more processing components (alternatively referred to as a "processor" or "central processing unit" (CPU)) configured to execute one or more instructions related to one or more of the processes, steps, or actions described above, in conjunction with one or more implementations disclosed herein. In some implementations, processing unit 262 may be configured to generate control information (such as measurement reports) or respond to received information (such as control information from network nodes). Processing unit 262 may also include other auxiliary components, such as random access memory (RAM) and read-only memory (ROM).

[0023] Example communication subsystem 266 can be configured to provide wireless or wired communication for data or control information provided by processing unit 262. Communication subsystem 266 may include, for example, one or more antennas, receivers, transmitters, local oscillators, mixers, and digital signal processing (DSP) units. In some implementations, communication subsystem 266 may support multiple-input multiple-output (MIMO) transmission. In some implementations, the receiver in communication subsystem 266 may be an advanced receiver or a baseline receiver. The two receivers may utilize the same, similar, or different receiver processing algorithms.

[0024] Example user interface 268 may include one or more of the following: a display or touchscreen display (e.g., a liquid crystal display (LCD), light-emitting diode (LED), organic light-emitting diode (OLED), or microelectromechanical system (MEMS) display), a keyboard or keypad, a trackball, a speaker, or a microphone. In some cases, user interface 268 may be used to output notifications indicating that a binary software code set has security risks, and to receive user input regarding whether to install a binary software code set that has security risks. Figure 4 The associated description provides additional details of these implementations. User interface 268 may also include I / O interfaces, such as a Universal Serial Bus (USB) interface.

[0025] Example memory 264 may be a computer-readable storage medium on electronic device 102. Examples of memory 264 include volatile and non-volatile memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, and others. Memory 264 may store the operating system (OS) of electronic device 102 and various other computer-executable software programs to perform one or more of the processes, steps, or actions described above.

[0026] Memory 264 may store applications, data, operating systems, and extensions for electronic device 102. As illustrated, memory 264 stores software security analyzer 220. Software security analyzer 220 represents software configured to perform the following operations: disassemble binary software code sets into assembly code sets, search for one or more assembly instructions in the assembly code sets, and determine whether the binary software code sets pose a security risk. Figure 4 The associated descriptions provide additional details about these implementations. The software security analyzer 220 may be a component or extension of the operating system of the electronic device 102. The software security analyzer 220 may also be application software installed on the electronic device 102.

[0027] Memory 264 includes one or more memory spaces 210 for executable software. The executable software may include operating system software or application software that can be executed on electronic device 102. If software security analyzer 220 determines that the binary software code set poses a security risk, then software security analyzer 220 can prevent the binary software code set from being moved into memory space 210. In some cases, software security analyzer 220 may be stored in one of the memory spaces 210 for executable software.

[0028] Turning to a general description, electronic device 102 may include, but is not limited to, any of the following: endpoint, computing device, mobile device, mobile electronic device, user device, mobile station, user station, portable electronic device, mobile communication device, wireless modem, wireless terminal, or other electronic device. Examples of endpoints may include mobile devices, IoT (Internet of Things) devices, EoT (Internet of Things) devices, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, personal computers (PCs), pagers, portable computers, portable gaming devices, wearable electronic devices, health / medical / fitness devices, cameras, vehicles, or other mobile communication devices having components for communicating voice or data via a wireless communication network. Vehicles may include motor vehicles (e.g., cars, automobiles, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aerial vehicle systems, drones, helicopters, etc.), spacecraft (e.g., space shuttles, spacecraft, space capsules, space stations, satellites, etc.), vessels (e.g., boats, small boats, hovercraft, submarines, etc.), rail vehicles (e.g., trains, trams, etc.), and other types of vehicles, including any combination of any of the foregoing vehicles, whether currently existing or subsequently developed. Wireless communication networks may include wireless links via at least one of licensed and unlicensed spectrum. The term "mobile device" may also refer to any hardware or software component that can terminate a communication session with a user. Furthermore, the terms "user equipment," "UE," "user equipment device," "user agent," "UA," "user equipment," and "mobile device" may be used interchangeably herein.

[0029] although Figure 2 The elements are shown as various component parts, sections, or modules that implement various features and functions; however, these elements may instead include numerous submodules, third-party services, components, libraries, etc., where appropriate. Furthermore, the features and functions of various components may be combined into fewer components where appropriate.

[0030] Figure 3 The diagram illustrates a high-level architecture of a computer 302 coupled to a network 350. The described illustrations are merely one possible implementation of the described subject matter and are not intended to limit this disclosure to the single described implementation. Those skilled in the art will understand that the described components can be connected, combined, or used in alternative ways consistent with this disclosure.

[0031] Network 350 supports communication between computer 302 and other devices. In some cases, a user (e.g., an administrator) can access computer 302 from a remote network. In these or other cases, network 350 can be a wireless or wired network. In some cases, a user can access computer 302 locally. In these or other cases, network 350 can also be a memory conduit, hardware connection, or any internal or external communication path between components.

[0032] Computer 302 includes a computing system configured to execute the algorithms described in this disclosure. For example, computer 302 can be used to implement... Figure 1 The security server 120 is shown in the diagram. In some cases, the algorithm may be implemented as executable computational code (e.g., C / C++ executable code). Alternatively or in combination, the algorithm may be implemented as an application (e.g., Excel). In some cases, computer 302 may include a standalone Linux system running batch applications. In some cases, computer 302 may include a mobile or personal computer running applications.

[0033] Computer 302 may include input devices (such as keypad, keyboard, touch screen, microphone, voice recognition device or other device that can accept user information), and / or output devices that convey information (including digital data, visual and / or audio information) associated with the operation of computer 302, or a GUI.

[0034] Computer 302 can be used as a client, network component, server, database, or other persistent device. In some implementations, one or more components of computer 302 can be configured to operate within a cloud-based environment.

[0035] At a higher level, computer 302 is an electronic computing device operable for receiving, sending, processing, storing, or managing data and information. According to some implementations, computer 302 may also include or be communicatively coupled to application servers, email servers, web servers, cache servers, streaming data servers, business intelligence (BI) servers, and / or other servers.

[0036] Computer 302 can receive requests from client applications (e.g., executed on user devices) via network 350 and respond to the received requests by processing them in appropriate software applications. Additionally, requests can also be sent to computer 302 from internal users (e.g., from a command console or by another suitable access method), external or third parties, other automation applications, and any other suitable entity, individual, system, or computer.

[0037] Each component of computer 302 can communicate using system bus 303. In some implementations, any and / or all components (hardware and / or software) of computer 302 can interface with each other and / or interface with interface 304 via system bus 303 using application programming interfaces (APIs) 312 and / or service layer 313. API 312 may include specifications for routines, data structures, and object classes. API 312 may be computer language-independent or computer language-dependent and refers to a complete interface, a single function, or even a set of APIs. Service layer 313 provides software services to computer 302. The functionality of computer 302 can be accessible to all service consumers using the service layer. Software services (such as those provided by service layer 313) provide reusable, defined business functionality through defined interfaces. For example, the interface may be software written in JAVA, C++, or other suitable languages, providing data in Extensible Markup Language (XML) format or other suitable formats. Although illustrated as an integrated component of computer 302, alternative implementations may illustrate API 312 and / or service layer 313 as independent components in relation to other components of computer 302. Furthermore, any or all portions of API 312 and / or service layer 313 may be implemented as a sub-module or sub-submodule of another software or hardware module without departing from the scope of this disclosure.

[0038] Computer 302 includes interface 304. Although in Figure 3 The interface 304 is illustrated as a single interface, but two or more interfaces 304 may be used depending on the specific needs, configuration, or implementation of the computer 302. Interface 304 is used by the computer 302 to communicate with other systems (whether illustrated or not) connected to the network 350 in a distributed environment. Generally, interface 304 includes software and / or hardware-coded logic appropriately combined and operable for communicating with the network 350. More specifically, interface 304 may include software supporting one or more communication protocols associated with the communication, enabling the hardware of the network 350 or the interface to operate for communicating physical signals.

[0039] Computer 302 includes processor 305. Although in Figure 3 The computer 302 is illustrated as a single processor 305, but two or more processors may be used depending on the specific needs, configuration, or implementation of the computer 302. Generally, processor 305 executes instructions and manipulates data to perform operations of the computer 302. In some cases, processor 305 may include a data processing device.

[0040] Computer 302 also includes memory 306 for storing data for computer 302. Although in Figure 3The memory 306 is illustrated as a single memory unit, but two or more memories may be used depending on the specific needs, configuration, or implementation of the computer 302. Although the memory 306 is illustrated as an integrated component of the computer 302, in alternative implementations, the memory 306 may be external to the computer 302.

[0041] Application 307 includes an algorithmic software engine that provides functionality based on the specific needs, configuration, or implementation of computer 302. Although illustrated as a single application 307, application 307 can be implemented as multiple applications 307 on computer 302. Furthermore, although illustrated as integrated into computer 302, in alternative implementations, application 307 can be external to computer 302.

[0042] There may be any number of computers 302 associated with or outside of system 300 and communicating via network 350. Furthermore, the terms "client," "user," and other suitable terms may be used interchangeably where appropriate without departing from the scope of this disclosure. Moreover, this disclosure contemplates the possibility that a number of users may use one computer 302, or that one user may use multiple computers 302.

[0043] Figure 4 This is a flowchart illustrating an example method 400 for detecting security risks in binary software code, based on an implementation. Method 400 can be implemented by an electronic device (e.g., Figure 1 The method 400 shown is implemented using the electronic device 102. The method 400 can also be implemented using additional, fewer, or different entities. Furthermore, the method 400 can be implemented using additional, fewer, or different operations, which can be performed in the shown order or in a different order.

[0044] Example method 400 begins at 410, where a binary software code set is received at the electronic device. The binary software code set can be binary software code of application software, system software (e.g., an operating system or device driver), or components thereof. In some cases, the binary software code set can be downloaded to the electronic device via a network. Alternatively or in combination, the binary software code set can be transferred locally to the electronic device, for example, from a Universal Serial Bus (USB) drive.

[0045] At 420, the binary software code set is disassembled. In some cases, whether the binary software code set is disassembled for security risk analysis can be configured. For example, an electronic device can be configured to disassemble and analyze the binary software code set based on one or more characteristics of the binary software code set. Examples of characteristics can include type (application software or system software) and source (vendor or developer). Therefore, the electronic device can determine the characteristics of the binary software code set and then determine whether to disassemble and analyze the binary software code set based on the configuration. The configuration can be set by the following: the manufacturer of the electronic device or the operating system of the electronic device, security extensions or security applications running on the electronic device, the enterprise administrator of the electronic device, the user of the electronic device, or a combination thereof.

[0046] In one example, the characteristics could include how the binary software code set was received. For instance, an electronic device could determine whether the binary software code set was received via a side-loading operation. Side-loaded software bypasses the security checks of the app store associated with the electronic device's operating system, and can therefore pose additional security risks. Thus, if the electronic device determines that the binary software code set was received via a side-loading operation, it can determine whether to initiate the disassembly and subsequent analysis of the binary software code set.

[0047] In some cases, if an electronic device determines that a binary software code set has been received via a sideloading operation, the electronic device can generate a notification and send it to the EMM server managing the electronic device. In response, the EMM server can send a command to the electronic device to notify it whether to continue the disassembly step. Alternatively or in combination, a security profile can be installed on the electronic device. The security profile can be sent and updated by the EMM server. The security profile may include a policy indicating whether to analyze the security risks of the sideloaded binary software code. The electronic device can then continue disassembling the binary software code set according to the policy in the security profile.

[0048] The binary software code assembly is disassembled into an assembly code assembly. Unlike software source code, assembly code is low-level code specific to the computing architecture of the electronic device. In some cases, the electronic device disassembles the binary software code assembly based on its metadata. Examples of metadata may include the computing architecture, the compiler used to compile the source code version of the binary software code assembly, or a combination thereof. In some implementations, some or all of this metadata may be received in the same file as the binary software code assembly, for example, in the header, or in a separate file, for example, in the manifest. Alternatively or in combination, the electronic device may analyze the binary software code assembly to determine this metadata.

[0049] At position 430, the electronic device determines the frequency of assembly instructions within the assembly code set. In some cases, the electronic device can scan the assembly code set to search for one or more specific assembly instructions. These specific assembly instructions can be associated with security risks. For example, No-Operation (NOP) instructions can be used for memory alignment purposes. However, malicious attackers can also use NOP instructions to patch the assembly code to add, remove, or change the functionality of the software. For example, in NOP slide (or NOP sled, NOP ramp) operations, malicious attackers can use a sequence of NOP instructions to branch the program to different memory locations. Therefore, the electronic device can search the assembly code set for NOP instructions to identify security risks. NOP instructions can have different opcodes for different computing architectures. For example, in the Intel x86 computing architecture, the opcode for a NOP instruction can be 0x90. In the ARM A32 computing architecture, the opcode for a NOP instruction can be 0x00000000. Therefore, in some implementations, the electronic device can search for the opcode corresponding to the computing architecture of the electronic device to find NOP instructions in the assembly code. In some cases, a list of assembly instructions associated with security risks may be stored on an electronic device. Examples of assembly instructions associated with security risks, besides NOPs, may include routines that differ from those typically generated by a compiler. Examples of routines not typically generated by a compiler may include payloads of assembly instructions that do not cause any state change. These routines can perform a cancellation of the state change by using instructions that revert the state change to its original state. In one example, a sequence of instructions may perform a series of tasks, such as "add one to a register" followed by "subtract one from a register." Therefore, in one embodiment of this disclosure, a security risk can be identified if there are detected addition and subtraction instructions with the same occurrence count (such as 100 addition instructions and 100 subtraction instructions). In some cases, the list may also include one or more sequences of assembly instructions associated with security risks. Examples of sequences of assembly instructions associated with security risks may include sequences for copying the same value to a register. In some cases, sequences of assembly instructions including instructions that make system calls may also be associated with security risks. In some cases, each compiler may generate a set of assembly instructions or a sequence of assembly instructions. The set of assembly instructions or the sequence of assembly instructions may be stored on an electronic device. Therefore, as previously discussed, electronic devices can identify the compiler used to compile the source code version of the binary software code set, and search for assembly instructions or sequences of assembly instructions not included in the stored set or sequence of assembly instructions corresponding to the compiler.

[0050] In some implementations, in addition to determining the number of times an assembly instruction associated with a security risk occurs, the electronic device can also determine the location of each occurrence of the assembly instruction associated with a security risk.

[0051] At point 440, the electronic device determines whether the binary software code set poses a security risk based on the frequency of occurrences of assembly instructions. In some cases, a high number of assembly instruction occurrences can indicate the presence of a security risk. For example, NOP instructions are generally used in memory alignment and can therefore be used a limited number of times within a piece of software. In one example, a software application might have two or three NOP instructions in its assembly code. On the other hand, a malicious attacker using NOP instructions to modify software could use them dozens or hundreds of times. Therefore, the electronic device can determine whether the frequency of NOP instructions in the assembly code set exceeds a threshold. If the frequency of NOP instructions is determined to exceed the threshold, then the electronic device can determine that the binary software code set poses a security risk.

[0052] Alternatively or in combination, whether a binary software code set poses a security risk can be determined based on the location of assembly instructions associated with that risk. For example, in unmodified software, NOP instructions typically appear at the beginning of the software. Therefore, if an electronic device determines that a NOP instruction appears in the middle or later part of the assembly code set, then the electronic device can determine that the binary software code set poses a security risk.

[0053] In some cases, the expected range of occurrences of these assembly instructions, their expected locations, or combinations thereof, may depend on the compiler used to compile the source code version of the binary software code set. Therefore, as previously discussed, the electronic device can determine the compiler used to compile the source code version of the binary software code set. The electronic device can compare the occurrences and locations of these assembly instructions determined at step 430 with the expected ranges and locations associated with the compiler to determine whether the binary software code set poses a security risk.

[0054] In some cases, the expected range of occurrences of these assembly instructions for different compilers, the expected locations of these assembly instructions, or combinations thereof, can be configured by: the manufacturer of the electronic device or the operating system of the electronic device, security extensions or security applications executed on the electronic device, the enterprise administrator or user of the electronic device, or any combination thereof. Alternatively or additionally, the security server may send and update the expected range of occurrences of these assembly instructions for different compilers, the expected locations of these assembly instructions, or combinations thereof, to the electronic device.

[0055] At point 450, in response to determining that the binary software code set has a security risk, the electronic device generates a notification indicating that the binary software code set has a security risk. In some cases, the notification may indicate any combination of the name, frequency, or location of the discovered assembly instructions that have a security risk. In some cases, the notification may also indicate that the binary software code set has violated one or more security standards. For example, by including assembly instructions or sequences of assembly instructions different from the set or sequence of assembly instructions generated by the compiler used to compile a version of the source code set of the binary software code set, the binary software code set may violate the relevant microprocessor without Interlocking Pipeline Stage (MIPS), Manufacturer Standardization Society (MSS), or International Organization for Standardization (ISO) standards. In some cases, the electronic device may output the notification, send the notification to a security server, or a combination thereof.

[0056] At 460, in response to determining that the binary software code set poses a security risk, the electronic device prevents the binary software code set from being installed on the electronic device. In some cases, the electronic device may prevent the transfer of the binary software code set to allocated memory space on the electronic device used to store executable software, thus preventing the binary software code set from being installed. Alternatively or additionally, the electronic device may remove the binary software code set that poses a security risk. In some cases, in response to determining that the binary software code set poses a security risk, the electronic device may output a user prompt on the electronic device, which may indicate that the binary software code set poses a security risk and request user input to indicate whether the binary software code set can be installed. In response, the electronic device may continue to install or remove the binary software code set based on the received user input.

[0057] The implementation of the subject matter and functional operations described herein can be achieved in the form of digital electronic circuits, in tangibly embodied computer software or firmware, in computer hardware including the structures disclosed herein and their structural equivalents, or a combination of one or more of these. The implementation of the subject matter described herein can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transient computer storage medium for operation by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, the program instructions can be encoded on artificially generated propagated signals, such as machine-generated electrical, optical, or electromagnetic signals, generated to encode information for transmission to a suitable receiver device for execution by the data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of these.

[0058] The terms "data processing apparatus," "computer," or "electronic computer equipment" (or their equivalents as understood by one of ordinary skill in the art) refer to data processing hardware and include all kinds of means, devices, and machines for processing data, including, by way of example, programmable processors, computers, or multiple processors or computers. The apparatus may also be or include special-purpose logic circuitry, such as a central processing unit (CPU), a field-programmable gate array (FPGA), or an application-specific integrated circuit (ASIC). In some implementations, the data processing apparatus and / or special-purpose logic circuitry may be hardware-based and / or software-based. The apparatus may optionally include code that creates an execution environment for computer programs, such as code constituting processor firmware, a protocol stack, a data management system, an operating system, or a combination of one or more of these. This disclosure contemplates the use of the data processing apparatus with or without a conventional operating system (e.g., LINUX, UNIX, WINDOWS, MAC OS, ANDROID, IOS, or any other suitable conventional operating system).

[0059] Computer programs (which may also be referred to or described as programs, software, software applications, modules, software modules, scripts, or code) can be written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and can be deployed in any form, including as standalone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. Computer programs may, but do not need to, correspond to files in a file system. Programs can be stored in portions of files containing other programs or data (e.g., one or more scripts stored in a markup language document), in single files dedicated to the program under discussion, or in multiple co-located files (e.g., files storing portions of one or more modules, subroutines, or code). Computer programs can be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected by a communications network. Although portions of programs illustrated in the various figures are shown as separate modules implementing various features and functions through various objects, methods, or other processes, programs may instead include numerous subroutines, third-party services, components, libraries, etc., where appropriate. Conversely, the features and functions of various components may be combined into a single component where appropriate.

[0060] The processes and logic flows described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform functions by manipulating input data and generating output. The processes and logic flows can also be executed by special-purpose logic circuitry (e.g., a CPU, FPGA, or ASIC), and the apparatus can also be implemented as special-purpose logic circuitry (e.g., a CPU, FPGA, or ASIC).

[0061] A computer suitable for executing computer programs can be based on a general-purpose microprocessor or a special-purpose microprocessor, both, or any other type of CPU. Generally, the CPU receives instructions and data from read-only memory (ROM) or random access memory (RAM), or both. The basic elements of a computer are a CPU for executing or running instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices (e.g., disks, magneto-optical disks, or optical disks) for storing data, or operatively coupled to, receiving data from, or transferring data to, or both of these mass storage devices. However, a computer does not need to have such devices. Furthermore, a computer can be embedded in another device (to name just a few, e.g., a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a Universal Serial Bus (USB) flash drive)).

[0062] Computer-readable media (transient or non-transient) used for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, by way of example, semiconductor memory devices (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM, DVD+ / -R, DVD-RAM, and DVD-ROM discs. Memory can store a variety of objects or data, including caches, classes, frames, applications, backup data, artifacts, web pages, web page templates, database tables, repositories storing business and / or dynamic information, and any other suitable information including any parameters, variables, algorithms, instructions, rules, constraints, or references to them. Additionally, memory may include any other suitable data, such as logs, policies, security or access data, report files, and others. Processors and memory can be supplemented by or incorporated into dedicated logic circuitry.

[0063] To provide interaction with the user, the implementation of the subject matter described in this specification can be implemented on a computer having a display device for displaying information to the user (e.g., a CRT (cathode ray tube), LCD (liquid crystal display), LED (light emission diode), or plasma monitor) and a keyboard and pointing device (e.g., a mouse, trackball, or trackpad) through which the user can provide input to the computer. Input can also be provided to the computer using a touchscreen, such as a pressure-sensitive tablet computer surface, a multi-touchscreen using capacitive or electro-sensing, or other types of touchscreens. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including auditory input, voice input, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending web pages to a web browser on the user's client device in response to a request received from a web browser.

[0064] The term "graphical user interface" or "GUI" can be used in the singular or plural to describe one or more graphical user interfaces and each display of a specific graphical user interface. Therefore, a GUI can represent any graphical user interface, including but not limited to a web browser, a touchscreen, or a command-line interface (CLI) that processes information and effectively presents the results of that information to the user. Generally, a GUI may include multiple user interface (UI) elements, some or all of which are associated with a web browser, such as interactive fields, drop-down lists, and buttons operable by the business suite user. These and other UI elements may be related to or represent the functionality of the web browser.

[0065] Although this disclosure contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope that may be claimed, but rather as a description of features that may be specific to a particular implementation of a particular invention. In the context of separate multiple implementations, certain features described in this disclosure may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented separately or in any suitable sub-combination in multiple implementations. Furthermore, although features may be described above as functioning in certain combinations and even initially claimed in this way, one or more features from a claimed combination may, in some cases, be removed from that combination, and the claimed combination may involve sub-combinations or variations thereof.

[0066] Specific implementations of the subject matter have been described. Other implementations, modifications, and arrangements of the described implementations are within the scope of the following claims, as will be apparent to those skilled in the art. Although the operations are depicted in a specific order in the drawings or claims, this should not be construed as requiring such operations to be performed in the specific order shown or in a sequential order, or requiring all illustrated operations to be performed to achieve the desired result (some operations may be considered optional). In some cases, multitasking or parallel processing (or a combination of multitasking and parallel processing) may be advantageous and performed where deemed appropriate.

[0067] Furthermore, the separation or integration of the various system modules and components described above should not be construed as requiring such separation or integration in all implementations, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[0068] Therefore, the above description of the example implementation does not limit or restrict this disclosure. Other changes, substitutions, and modifications are possible without departing from the spirit and scope of this disclosure.

[0069] Additionally, any of the following claimed implementations are considered applicable to at least one computer-implemented method; a transient or non-transient computer-readable medium storing computer-readable instructions for performing the computer-implemented method; and a computer system including computer memory interoperably coupled to a hardware processor configured to perform the computer-implemented method or instructions stored on the computer-readable medium.

Claims

1. A computer-implemented method, comprising: Receive the set of binary software code to be loaded onto the electronic device; The electronic device disassembles the binary software code set into an assembly code set; The electronic device determines the frequency of occurrence of assembly instructions in the assembly code set that are associated with security risks; The electronic device determines the location of each occurrence of the assembly instruction in the assembly code set that is associated with the security risk; The electronic device determines the compiler used to compile the source code version of the binary software code set; as well as The electronic device compares the number of occurrences of the assembly instructions and their determined locations with the expected range of occurrences and their corresponding expected locations associated with the compiler to determine whether the binary software code set contains the security risk.

2. The method according to claim 1, wherein the assembly instruction is a no-operation (NOP) instruction.

3. The method according to claim 1, further comprising: In response to determining that the binary software code set has the security risk, measures are taken to prevent the binary software code set from being installed on the electronic device.

4. The method according to claim 1, further comprising: In response to determining that the binary software code set has the security risk, a notification indicating that the binary software code set has the security risk is generated.

5. The method according to claim 1, further comprising: It is determined that the binary software code set is received during the sideloading operation; and The disassembly is executed in response to determining that the binary software code set has been received during the sideloading operation.

6. An electronic device, comprising: At least one hardware processor; as well as One or more computer-readable storage media coupled to the at least one hardware processor and storing program instructions for execution by the at least one hardware processor, wherein the program instructions, when executed, cause the at least one hardware processor to perform operations including: Receive the set of binary software code to be loaded onto the device; Disassemble the binary software code set into an assembly code set; Determine the frequency of occurrence of assembly instructions in the assembly code set that are associated with security risks; Determine the location of each occurrence of the assembly instruction in the assembly code set that is associated with the security risk; Determine the compiler used to compile the source code version of the binary software code set; and The number of occurrences of the assembly instructions and their determined locations are compared with the expected range of occurrences associated with the compiler and their corresponding expected locations to determine whether the binary software code set contains the security risk.

7. The electronic device according to claim 6, wherein the assembly instruction is a no-operation (NOP) instruction.

8. The electronic device according to claim 6, wherein the operation further comprises: In response to determining that the binary software code set has the security risk, measures are taken to prevent the binary software code set from being installed on the electronic device.

9. The electronic device according to claim 6, wherein the operation further comprises: In response to determining that the binary software code set has the security risk, a notification indicating that the binary software code set has the security risk is generated.

10. The electronic device according to claim 6, further comprising: It is determined that the binary software code set is received during the sideloading operation; and The disassembly is executed in response to determining that the binary software code set has been received during the sideloading operation.

11. One or more non-transient computer-readable media, including instructions that, when executed, cause an electronic device to perform operations, the operations including: Receive the set of binary software code to be loaded onto the electronic device; Disassemble the binary software code set into an assembly code set; Determine the frequency of occurrence of assembly instructions in the assembly code set that are associated with security risks; Determine the location of each occurrence of the assembly instruction in the assembly code set that is associated with the security risk; Identify the compiler used to compile the source code version of the binary software code set; as well as The number of occurrences of the assembly instructions and their determined locations are compared with the expected range of occurrences associated with the compiler and their corresponding expected locations to determine whether the binary software code set contains the security risk.

12. One or more non-transient computer-readable media according to claim 11, wherein the assembly instructions are no-operation (NOP) instructions.

13. The operation further comprises: one or more non-transient computer-readable media according to claim 11. In response to determining that the binary software code set has the security risk, measures are taken to prevent the binary software code set from being installed on the electronic device.

14. The operation further comprises: one or more non-transient computer-readable media according to claim 11. In response to determining that the binary software code set has the security risk, a notification indicating that the binary software code set has the security risk is generated.

15. The operation further comprises: one or more non-transient computer-readable media according to claim 11. It is determined that the binary software code set is received during the sideloading operation; and The disassembly is executed in response to determining that the binary software code set has been received during the sideloading operation.

Images