Patent Description:
In recent years, malware detection of JAR/class files, that have not yet been cataloged, require the extraction of key features to be analyzed. Decompilation of these files is needed to obtain the data for some of the features included in those files, but current methods are too slow for real-time use.

<CIT> relates to detecting malware variants by comparing class files in suspect application packages with class files in known malware families based on metadata stored in the class files.

<CIT> relates to dynamic detection method of Andrews malware based on machine learning. <CIT> relates to malicious software detection device including a decompilation module that decompiles an input application software installation package and obtain the decompilation file.

These features are useful in the development of malicious machine learning models that allow for static detection of JAR/class files in real-time.

The figures are not to scale. In general, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts. As used in this patent, stating that any part (e.g., a layer, film, area, region, or plate) is in any way on (e.g., positioned on, located on, disposed on, or formed on, etc.) another part, indicates that the referenced part is either in contact with the other part, or that the referenced part is above the other part with one or more intermediate part(s) located therebetween. Connection references (e.g., attached, coupled, connected, and joined) are to be construed broadly and may include intermediate members between a collection of elements and relative movement between elements unless otherwise indicated. As such, connection references do not necessarily infer that two elements are directly connected and in fixed relation to each other. Stating that any part is in "contact" with another part means that there is no intermediate part between the two parts. Although the figures show layers and regions with clean lines and boundaries, some or all of these lines and/or boundaries may be idealized. In reality, the boundaries and/or lines may be unobservable, blended, and/or irregular.

When attempting to use machine learning models to classify instructions (e.g., JAR files, class files, etc.), a blocking issue for performing such classification in real-time is that decompilation is often necessary. However, decompilation of instructions can be a slow process that prevents malware tools from being used in real-time. Example methods and apparatus disclosed herein seek to use partial decompilation of instructions to extract the features as input(s) for use with a malware detection model. The example partial decompilation methods and apparatus can be used in the context of a machine learning model used to classify and detect malicious instructions. This process is orders of magnitude faster than previously available tools and enables real-time identification of malicious instructions.

Java Archive files, or JAR files, are used to aggregate files, such as class and non-class files, into one location for application software distribution and/or library distribution on the Java platform. These JAR files are compressed versions of class files, audio files, text files, image files, directories, etc. and can be used for tasks such as lossless data compression, archiving, decompression, and archive unpacking. In examples disclosed herein, a class file is a component of a JAR file that represents a class. In examples disclosed herein, a non-class file is a component of a JAR file that is not a class file.

Artificial intelligence (AI), including machine learning (ML), deep learning (DL), and/or other artificial machine-driven logic, enables machines (e.g., computers, logic circuits, etc.) to use a model to process input data to generate an output based on patterns and/or associations previously learned by the model via a training process. For instance, the model may be trained with data to recognize patterns and/or associations and follow such patterns and/or associations when processing input data such that other input(s) result in output(s) consistent with the recognized patterns and/or associations.

Many different types of machine learning models, machine learning algorithms, and/or machine learning architectures exist. In examples disclosed herein, a Neural Network machine learning architecture is used. In general, machine learning models/algorithms/architectures that are suitable to use in the example approaches disclosed herein will enable classification of inputs belonging to a particular class (e.g., malicious or benign). However, any other past, present, and/or future types of machine learning models/algorithms/architectures could additionally or alternatively be used such as, for example, a decision tree architecture, a tree hybrid/ensemble architecture, a Gradient Boosted Tree architecture, a Random Forest architecture, a Logistic Regression architecture, a Support Vector Machine (SVM) architecture, a convolutional Neural Network (NN) architecture.

In general, implementing a ML/AI system involves two phases, a learning/training phase and an inference phase. In the learning/training phase, a training algorithm is used to train a model to operate in accordance with patterns and/or associations based on, for example, training data. In general, the model includes internal parameters that guide how input data is transformed into output data, such as through a series of nodes and connections within the model to transform input data into output data. Additionally, hyperparameters are used as part of the training process to control how the learning is performed (e.g., a learning rate, a number of layers to be used in the machine learning model, etc.). Hyperparameters are defined to be training parameters that are determined prior to initiating the training process.

Different types of training may be performed based on the type of ML/AI model and/or the expected output. For example, supervised training uses inputs and corresponding expected (e.g., labeled) outputs to select parameters (e.g., by iterating over combinations of select parameters) for the ML/AI model that reduce model error. As used herein, labelling refers to an expected output of the machine learning model (e.g., a classification, an expected output value, etc.) Alternatively, unsupervised training (e.g., used in deep learning, a subset of machine learning, etc.) involves inferring patterns from inputs to select parameters for the ML/AI model (e.g., without the benefit of expected (e.g., labeled) outputs).

Training is performed using training data. In examples disclosed herein, the training data originates from locally generated data. Because supervised training is used, the training data is labeled. Labeling is applied to the training data by machine learning model users once the data has been scanned for malware using preexisting malware detectors.

Once training is complete, the model is deployed for use as an executable construct that processes an input and provides an output based on the network of nodes and connections defined in the model. The model may then be executed to classify an instruction (e.g., as malicious or benign).

Once trained, the deployed model may be operated in an inference phase to process data. In the inference phase, data to be analyzed (e.g., live data) is input to the model, and the model executes to create an output. This inference phase can be thought of as the AI "thinking" to generate the output based on what it learned from the training (e.g., by executing the model to apply the learned patterns and/or associations to the live data). In some examples, input data undergoes pre-processing before being used as an input to the machine learning model. Moreover, in some examples, the output data may undergo post-processing after it is generated by the AI model to transform the output into a useful result (e.g., a display of data, an instruction to be executed by a machine, etc.).

In some examples, output of the deployed model may be captured and provided as feedback. By analyzing the feedback, an accuracy of the deployed model can be determined. If the feedback indicates that the accuracy of the deployed model is less than a threshold or other criterion, training of an updated model can be triggered using the feedback and an updated training data set, hyperparameters, etc., to generate an updated, deployed model.

<FIG> is a schematic illustration of an example system <NUM> constructed in accordance with teachings of this disclosure for instruction decompilation. The example system <NUM> of <FIG> includes a computing device <NUM>, a user interface <NUM>, an instruction analyzer <NUM>, an instruction datastore <NUM>, and a central server <NUM>.

The example computing device <NUM> is any computing device, that can include but is not limited to, a desktop, a laptop, a tablet, a smart phone, etc. that executes instructions. The example computing device <NUM> includes a user interface <NUM>, an instruction analyzer <NUM>, and an instruction datastore <NUM>.

The example user interface <NUM> of the illustrated example of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s), DSP(s), etc. The user interface <NUM> enables the instruction analyzer <NUM> to prompt a user when a malicious file is detected and allows the user to determine the instructions that need to be analyzed by the instruction analyzer <NUM>.

The example instruction analyzer <NUM> of the illustrated example of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s), DSP(s), etc. the instruction analyzer <NUM> decompiles selected instructions to be analyzed for malicious content. The instruction analyzer <NUM> may be prompted by a user through the user interface <NUM> to initialize the decompilation and analysis process of the instructions and may also output results to the user through the user interface <NUM>.

The example instruction datastore <NUM> is implemented by any memory, storage device and/or storage disc for storing data such as, for example, flash memory, magnetic media, optical media, solid state memory, hard drive(s), thumb drive(s), etc. Furthermore, the data stored in the example instruction datastore <NUM> may be in any data format such as, for example, binary data, comma delimited data, tab delimited data, structured query language (SQL) structures, etc. While, in the illustrated example, the instruction datastore <NUM> is illustrated as a single device, the example instruction datastore <NUM> and/or any other data storage devices described herein may be implemented by any number and/or type(s) of memories. The example instruction datastore enables storage of instructions and any corresponding instruction features, values, and/or identifiers. The example instruction datastore may, in some examples, store machine learning model training and processing data and/or instructions.

The example central server <NUM> is a server that communicates via a network such as, for example, the Internet, to provide instructions that may be executed at the computing device <NUM>. That is, the example central server <NUM> provides instructions for implementing the instruction analyzer <NUM> of the computing device <NUM> to enable the computing device to analyze instructions stored in the instruction datastore <NUM>. In examples disclosed herein, the instructions provided to the computing device <NUM> are executable instructions that may be directly executed at the computing device <NUM>. However, in some examples, the instructions are provided as part of a software development kit (SDK), application programming interface (API) to an intermediary party (e.g., a manufacturer, an app developer) to enable the intermediary party to create (e.g., design, develop, compile, etc.) executable instructions (e.g., an application, firmware, etc.) to be executed at the computing device <NUM>. In some examples, machine learning models may be provided from the central server <NUM> to the instruction analyzer <NUM>.

<FIG> is a block diagram representing an example system for analyzing and decompiling instruction files. The example instruction analyzer <NUM> of <FIG> includes an instruction accessor <NUM>, a file extractor <NUM>, a non-class file storage device <NUM>, a class file storage device <NUM>, a class feature unpacker <NUM>, a constant pool address generator <NUM>, a class feature storage device <NUM>, a class feature identifier <NUM>, a feature value identifier <NUM>, a feature matrix generator <NUM>, a machine learning model processor <NUM>, a machine learning model trainer <NUM>, a machine learning model memory <NUM>, and a malware remediator <NUM>.

The instruction accessor <NUM> of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s) DSP(s), etc. The instruction accessor <NUM> may implement a means for accessing instruction files, or any other related file and/or document, from another data sending or data storage device.

The file extractor <NUM> of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s) DSP(s), etc. The file extractor <NUM> of <FIG> extracts instructions, or any other related file and/or document, once they are received by the instruction accessor <NUM>. The file extractor <NUM> may implement a means for extracting the class and non-class files from the instructions.

The non-class file storage device <NUM> and the class file storage device <NUM> of <FIG> are implemented by any memory, storage device and/or storage disc for storing data such as, for example, flash memory, magnetic media, optical media, solid state memory, hard drive(s), thumb drive(s), etc. Furthermore, the data stored in the example non-class file storage device <NUM> and class file storage device <NUM> may be in any data format such as, for example, binary data, comma delimited data, tab delimited data, structured query language (SQL) structures, etc. While, in the illustrated example, the example non-class file storage device <NUM> and class file storage device <NUM> are illustrated as single devices, the example non-class file storage device <NUM> and the example class file storage device <NUM> and/or any other data storage devices described herein may be implemented by any number and/or type(s) of memories. The non-class file storage device <NUM> may implement the means for storing non-class file features extracted from the instruction set by the file extractor <NUM>. The class file storage device <NUM> may implement the means for storing class files extracted from the instruction set by the file extractor <NUM>. In examples disclosed herein, the non-class file storage device <NUM> stores the non-class file features that are extracted via the file extractor <NUM> and the class file storage device <NUM> stores the class files that are extracted via the file extractor <NUM>.

The class feature unpacker <NUM> of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s) DSP(s), etc. The class feature unpacker <NUM> may implement a means for unpacking a class feature from a class file included in an instruction set. Unpacking class features may additionally or alternatively be implemented by block <NUM> of <FIG> and includes the constant pool address generator <NUM> and the class feature identifier <NUM>.

The constant pool address generator <NUM> of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s) DSP(s), etc. The example constant pool address generator <NUM> may implement means for generating a constant pool address table, from the class features, including a plurality of constant pool blocks, based on constant pool types, through an iterative process.

The class feature identifier <NUM> of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s) DSP(s), etc. The class feature identifier <NUM> may implement a means for determining values for each constant pool block based on a constant pool type and storing the determined values as a class file feature set.

In examples disclosed herein, the class feature identifier <NUM> processes each constant pool block, from the constant pool address table, based on constant pool type. Constant pool types include, but are not limited to, class, string, method reference, dynamic invocation, and/or other constant pool address types. Processed constant pool type blocks are obtained and values are added such as, for example, class names, strings, Java identifiers, and/or any other programmable language identifier(s). Constant pool blocks are processed in a way to remove unnecessary elements, store relevant bits of information, account for Java decoration, and/or any other method to make processing more efficient.

The feature value identifier <NUM> of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s) DSP(s), etc. The feature value identifier <NUM> may implement a means for obtaining raw feature values from a class file feature set and non-class file features. The feature value identifier <NUM> obtains (e.g., extracts) the raw feature values from the class file feature sets and mines feature values from those class file feature sets. This includes obtaining raw features from the non-class file features previously extracted by the file extractor <NUM>. The means for obtaining feature values from raw features may additionally or alternatively be implemented by block <NUM> of <FIG>.

The feature matrix generator <NUM> of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s) DSP(s), etc. The feature matrix generator <NUM> may implement a means for generating a matrix based on the obtained raw features that correspond to the instruction set. The means for generating the feature matrix may additionally or alternatively be implemented by block <NUM> of <FIG>.

The example machine learning model processor <NUM> of the illustrated example of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s) DSP(s), etc. The machine learning model processor <NUM> applies a machine learning model to decompiled instructions for malware analysis. The machine learning model processor <NUM> may implement the means for applying the machine learning model to the matrix to determine whether a second JAR file is malicious. In this example, the machine learning model is applied to the generated feature matrix created by the feature matrix generator <NUM>. The machine learning model processor <NUM> analyzes the matrix and determines scores based on matrix values that correspond to selected instructions. The scores are compared with threshold(s), that are determined by the machine learning model trainer <NUM> before the model is applied and the instructions are returned to the user through the user interface <NUM> as either malicious, benign, or unknown. The machine learning model may additionally or alternatively be implemented by the instructions represented by the flowchart of <FIG>.

The example machine learning model trainer <NUM> of the illustrated example of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s) DSP(s), etc. The machine learning model trainer <NUM> trains a machine learning model based on labeled inputs that have expected, or known, outputs. The machine learning model trainer <NUM> may implement the means for training the machine learning model based on generated matrices and a threshold value. In examples disclosed herein, labeled instructions are used during the machine learning model training phase. The labeled instructions are analyzed by the instruction analyzer <NUM> and threshold values are determined based on the comparison of the input instructions to the output classifications (e.g., malicious, benign, or unknown). Training may additionally or alternatively be implemented by block <NUM> of <FIG>. In examples disclosed herein, training is performed using stochastic gradient descent. However, any other approach to training a machine learning model may additionally or alternatively be used.

The example machine learning model memory <NUM> of the illustrated example of <FIG> is implemented by any memory, storage device, and/or storage disc for storing data such as, for example, flash memory, magnetic media, optical media, solid state memory, hard drive(s), thumb drive(s), etc. Furthermore, the data stored in the example machine learning model memory <NUM> may be in any data format such as, for example, binary data, comma delimited data, tab delimited data, structured query language (SQL) structures, etc. While, in the illustrated example, the machine learning model memory <NUM> is illustrated as a single device, the example machine learning model memory <NUM> and/or any other data storage devices described herein may be implemented by any number and/or type(s) of memories. In the illustrated example of <FIG>, the example machine learning model memory <NUM> stores one or more machine learning models that enable the machine learning model processor <NUM> to process input an input feature matrix to classify instructions associated with the feature matrix as benign or malicious.

The malware remediator <NUM> of the illustrated example of <FIG> is implemented by a logic circuit such as, for example, a hardware processor. However, any other type of circuitry may additionally or alternatively be used such as, for example, one or more analog or digital circuit(s), logic circuits, programmable processor(s), ASIC(s), PLD(s), FPLD(s), programmable controller(s), GPU(s), DSP(s), etc. The example malware remediator <NUM>, in response to detection of malware, performs a responsive action. The responsive action may include, for example, deleting the data identified to be malware, quarantining the data (e.g., preventing execution of the data), alerting a user, alerting a system administrator, etc..

While an example manner of implementing the instruction analyzer <NUM> of <FIG> is illustrated in <FIG>, one or more of the elements, processes and/or devices illustrated in <FIG> may be combined, divided, rearranged, omitted, eliminated and/or implemented in any other way. Further, the example instruction accessor <NUM>, the example file extractor <NUM>, the example class feature unpacker <NUM>, the example constant pool address generator <NUM>, the example class feature identifier <NUM>, the example feature value identifier <NUM>, the example feature matrix generator <NUM>, the example machine learning model processor <NUM>, the example machine learning model trainer <NUM>, the example malware remediator <NUM>, and/or, more generally, the example instruction analyzer <NUM> of <FIG> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example instruction accessor <NUM>, the example file extractor <NUM>, the example class feature unpacker <NUM>, the example constant pool address generator <NUM>, the example class feature identifier <NUM>, the example feature value identifier <NUM>, the example feature matrix generator <NUM>, the example machine learning model processor <NUM>, the example machine learning model trainer <NUM>, the example malware remediator <NUM>, and/or, more generally, the example instruction analyzer <NUM> of <FIG> could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)).

When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example, instruction accessor <NUM>, the example file extractor <NUM>, the example class feature unpacker <NUM>, the example constant pool address generator <NUM>, the example class feature identifier <NUM>, the example feature value identifier <NUM>, the example feature matrix generator <NUM>, the example machine learning model processor <NUM>, the example machine learning model trainer <NUM>, the example malware remediator <NUM>, and/or, more generally, the example instruction analyzer <NUM> of <FIG> is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, the example instruction analyzer <NUM> of <FIG> may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes and devices. As used herein, the phrase "in communication," including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events.

Flowcharts representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the instruction analyzer <NUM> of <FIG> and/or <NUM> are shown in <FIG>, <FIG>, <FIG>, <FIG> and/or <NUM>. The machine-readable instructions may be one or more executable programs or portion(s) of an executable program for execution by a computer processor such as the processor <NUM> shown in the example processor platform <NUM> discussed below in connection with <FIG>. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor <NUM>, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example programs are described with reference to the flowcharts illustrated in <FIG>, <FIG>, <FIG>, <FIG> and/or <NUM>, many other methods of implementing the example instruction analyzer <NUM> may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware.

The machine-readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data (e.g., portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine-readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers). The machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc. in order to make them directly readable, interpretable, and/or executable by a computing device and/or other machine. For example, the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement a program such as that described herein.

In another example, the machine readable instructions may be stored in a state in which they may be read by a computer, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc. in order to execute the instructions on a particular computing device or other device. In another example, the machine-readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine-readable instructions and/or the corresponding program(s) can be executed in whole or in part. Thus, the disclosed machine-readable instructions and/or corresponding program(s) are intended to encompass such machine-readable instructions and/or program(s) regardless of the particular format or state of the machine-readable instructions and/or program(s) when stored or otherwise at rest or in transit.

The machine-readable instructions described herein can be represented by any past, present, or future instruction language, scripting language, programming language, etc. For example, the machine-readable instructions may be represented using any of the following languages: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift, etc..

As mentioned above, the example processes of <FIG>, <FIG>, <FIG>, <FIG> and/or <NUM> may be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

<FIG> is a flowchart representative of machine-readable instructions which may be executed to implement the example instruction analyzer <NUM> of <FIG>. The example process <NUM> of <FIG> begins when the instruction accessor <NUM> is initialized and an instruction is accessed. (Block <NUM>). Such initialization may occur, for example, at the direction of a user, at the startup of the computing device <NUM>, as part of a file system scan, when instructions are not functioning properly, when new instructions are installed and/or downloaded, etc..

The file extractor <NUM> extracts the non-class, core features from the instructions. (Block <NUM>). These features include, but are not limited to, for example, signature status, access flags, mime types, etc. The extracted features are stored in the non-class file storage device <NUM> to later be accessed when generating the final instruction feature matrix. (Block <NUM>).

The class files from the instructions are extracted by the file extractor <NUM>. (Block <NUM>). The class files are stored in the class file storage <NUM>, which can be an internal or external memory such as a hard drive, disk, etc. (Block <NUM>).

The class feature unpacker <NUM> unpacks the class file features that include, but are not limited to, file size, valid starting block data, and/or other extractable instruction features and is described below in connection with the illustrated flowchart of <FIG>. (Block <NUM>). The class feature unpacker contains the constant pool address generator <NUM> and the class feature identifier <NUM> and stores the processed class file features as class file feature sets.

The feature value identifier <NUM> mines, or processes, the class file feature sets for the raw feature values. (Block <NUM>). The feature matrix generator <NUM> generates a matrix from the raw feature values, that were extracted from the class and non-class files, corresponding to the accessed instruction. (Block <NUM>).

<FIG> is a flowchart representative of example machine readable instructions which may be executed to implement the example instruction analyzer <NUM> of <FIG> to unpack class file features from class files and store them as class file feature sets. The example process <NUM> of the illustrated example of <FIG> begins when the class files from the class file storage <NUM> are accessed by the class feature unpacker <NUM>. (Block <NUM>). The class feature unpacker <NUM> unpacks the key class file features. (Block <NUM>). The constant pool address generator <NUM> takes the key class file features and uses an iterative process, described below in connection with the illustrated example of <FIG>, to divide and/or group the class file features into constant blocks based on their constant block type. (Block <NUM>).

The class feature identifier <NUM> processes the newly formed constant blocks for each constant pool type. (Block <NUM>). The blocks are obtained by the class feature identifier <NUM> and values are added such as, for example, class names, strings, Java identifiers, and/or any other programmable language identifier(s). (Block <NUM>). The class feature identifier <NUM> stores the processed class file feature values in the class feature storage <NUM> as sets to prevent duplicate entries and/or any other reason to make processing more efficient. (Block <NUM>).

<FIG> is a flowchart representative of example machine readable instructions which may be executed to implement the example instruction analyzer <NUM> of <FIG> to generate a constant pool address through an iterative process. The example process <NUM> of the illustrated example of <FIG> begins when the constant pool address generator <NUM> sets a constant pool segment address to a temporary address, in this example, i. (Block <NUM>). Meta information is accessed from the constant pool segment at the temporary address i (e.g., block <NUM>) and the constant pool address generator <NUM> determines the type and size of the file features (Block <NUM>).

The file features are added to the constant pool address table by the constant pool address generator <NUM> according to the discovered constant pool type. (Block <NUM>). The constant pool generator <NUM> increments the address i by the size of each new entry. (Block <NUM>). If there are more features to be added to the constant pool address table once the address has been incremented (e.g., block <NUM> returns a result of NO), the constant pool address generator <NUM> determines the type and size of the file features at the newly incremented address i. Once the file features have been added to the constant pool address table (e.g., block <NUM> returns the result YES), the constant pool address generator <NUM> terminates the example process <NUM> of <FIG>.

<FIG> is a flowchart representative of example machine readable instructions which may be executed to implement the example machine learning model processor <NUM> of <FIG> to classify unknown instructions and label those instructions as benign, malicious, or unknown. The example process of <FIG> may be executed as part of a file and/or system scan, may be executed in response to execution (and/or a request to execute) an instruction file (e.g., a JAR file), may be executed in response to a user request, etc. The example process <NUM> of the illustrated example of <FIG> begins when the machine learning model processor <NUM> accesses instructions (e.g., a JAR file) to be analyzed. (Block <NUM>). The instruction analyzer <NUM> analyzes the accessed instructions and produces an instruction feature matrix. (Block <NUM>). An example approach for implementing the analysis of the instructions to generate the feature matrix is described above in connection with <FIG>. The machine learning model processor <NUM> processes the instruction feature matrix using a machine learning model stored in the machine learning model memory <NUM> to generate a score. (Block <NUM>). In examples disclosed herein, the score indicates whether the instructions associated with the feature matrix are malicious, benign, etc. Training of the model used by the machine learning model processor <NUM> is described in further detail below in connection with <FIG>.

Upon generation of the score by the machine learning model processor <NUM>, the malware remediator <NUM> determines whether malware has been detected. (Block <NUM>). In some examples, malware is detected when the generated score meets or exceeds a threshold confidence score (e.g., a <NUM>% likelihood that the data is malware). If malware has not been detected (e.g., block <NUM> returns a result of NO), the malware remediator <NUM> identifies the accessed instructions as benign (or unknown). (Block <NUM>). In some examples, a record of the classification of the instructions is stored. Storing a record may, in some examples, enable future requests for a classification of the instructions to be replied to without the need to re-process the instructions using the example process of <FIG>. The example process <NUM> of <FIG> then terminates, but may be re-executed in connection with subsequent requests to analyze instructions.

If malware has been detected (e.g., block <NUM> returns a result of YES), the example malware remediator <NUM> identifies the instructions as malicious (Block <NUM>), and performs a responsive action. (Block <NUM>). In some examples, malware is detected when a confidence score meets or exceeds the threshold confidence score (e.g., a <NUM>% likelihood that the data is malware). In examples disclosed herein, the responsive action performed by the example malware remediator <NUM> (at block <NUM>), may include deleting the instructions data, quarantining the instructions (e.g., preventing execution of the instructions), alerting a user, alerting a system administrator, etc..

<FIG> is a flowchart representative of example machine readable instructions which may be executed to implement the example machine learning model trainer <NUM> of <FIG> to train a machine learning model using labeled instructions. The example process <NUM> of the illustrated example of <FIG> begins when the machine learning model trainer <NUM> accesses the labeled instructions. (Block <NUM>). The instruction analyzer <NUM> then analyzes the known instructions and generates a feature matrix corresponding to each instruction. (Block <NUM>). An example approach for implementing the analysis of the instructions is described above in connection with <FIG>. In examples disclosed herein, a feature matrix is created for each labeled instruction set.

The machine learning model trainer <NUM> causes the machine learning model processor <NUM> to process the feature matrices for the labeled instructions using a machine learning model. (Block <NUM>). In examples disclosed herein, the model is stored in the machine learning model memory <NUM>. In some examples, (e.g., when first training a machine learning model) the model is initialized by the machine learning model trainer <NUM>. In some examples, the model may be initialized by contacting the central server <NUM> to obtain an initial model, enabling further training to be performed more efficiently at the instruction analyzer <NUM>.

The example machine learning model trainer <NUM> reviews the output of the machine learning model processor <NUM> to determine an amount of error of the machine learning model. (Block <NUM>). For example, the machine learning model trainer <NUM> reviews the outputs of the machine learning model processor <NUM> to determine whether the outputs from the model, when processing the feature matrices, match the expected malicious/benign labels included in the training data. That is, an amount of error of the model is calculated to quantify the accuracy of the model.

The example machine learning model trainer <NUM> determines whether to continue training. (Block <NUM>). In examples disclosed herein, the example machine learning model trainer <NUM> determines whether to continue training based on whether the calculated amount of error meets or exceeds a threshold amount of error. For example, training may be performed until, for example, the calculated amount of error is below the threshold amount of error. To continue training (e.g., in response to block <NUM> returning a result of YES), the example machine learning model trainer <NUM> adjusts parameters of the machine learning model stored in the machine learning memory <NUM>. (Block <NUM>). In some examples, the amount of adjustment to the parameters of the machine learning model is based on the calculated amount of error. Control then proceeds to block <NUM>, where the process of blocks <NUM> through <NUM> is repeated until the calculated amount of error is less than the threshold amount of error (e.g., until block <NUM> returns a result of NO). The example process <NUM> of <FIG> then terminates, but may be later re-executed to perform subsequent training.

<FIG> is a block diagram of an example processor platform <NUM> structured to execute the instructions of <FIG>, <FIG>, <FIG>, <FIG> and/or <NUM> to implement the instruction analyzer <NUM> of <FIG> and/or <NUM>. The processor platform <NUM> can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, or any other type of computing device.

For example, the processor <NUM> can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor implements the example instruction accessor <NUM>, the example file extractor <NUM>, the example class feature unpacker <NUM>, the example constant pool address generator <NUM>, the example class feature identifier <NUM>, the example feature value identifier <NUM>, the example feature matrix generator <NUM>, the example machine learning model processor <NUM>, the example machine learning model trainer <NUM>, the example malware remediator <NUM>, and/or, more generally, the example instruction analyzer <NUM> of <FIG>.

The volatile memory <NUM> may be implemented by Synchronous Dynamic Random-Access Memory (SDRAM), Dynamic Random-Access Memory (DRAM), RAMBUS® Dynamic Random-Access Memory (RDRAM®) and/or any other type of random-access memory device.

The input device(s) can be implemented by, for example, a keyboard, a button, a mouse, and/or a touchscreen.

The output devices <NUM> can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube display (CRT), an in-place switching (IPS) display, a touchscreen, etc.), a tactile output device, and/or a printer.

The machine executable instructions <NUM> of <FIG>, <FIG>, <FIG>, <FIG> and/or <NUM> may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable non-transitory computer readable storage medium such as a CD or DVD. In the illustrated example of <FIG>, the example mass storage device <NUM> implements the example instruction datastore <NUM>, the example non-class file storage <NUM>, the example class file storage <NUM>, the example class feature storage <NUM>, and/or the example machine learning model memory <NUM>.

From the foregoing, it will be appreciated that example methods, apparatus and articles of manufacture have been disclosed that enable malware detection using instruction file decompilation. The disclosed methods, apparatus and articles of manufacture improve the efficiency of using a computing device by enabling a faster detection of JAR/class file malware using JAR/class file decompilation. In this manner, malware can be detected orders of magnitude faster than current tools and allows for real-time use. The disclosed methods, apparatus and articles of manufacture are accordingly directed to one or more improvement(s) in the functioning of a computer.

Claim 1:
At least one computer-readable medium comprising instructions that, when executed, cause at least one processor to at least:
unpack a class feature from a class file (<NUM>) included in an instruction set;
generate a constant pool address table (<NUM>), from the class features, including a plurality of constant pool blocks, based on constant pool type, through an iterative process (<NUM>);
determine values for each constant pool block based on constant pool type and store the determined values as a class file feature set (<NUM>);
obtain raw feature values from a class file feature set and non-class file features; and
generate a matrix based on raw features that correspond to the instruction set.