Software type detection method and apparatus, terminal device, and storage medium
By extracting multiple features from software data and combining them with various machine learning models for classification, the problems of low accuracy and high maintenance costs in software type detection are solved, achieving efficient software type identification.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- EAST CHINA JIAOTONG UNIVERSITY
- Filing Date
- 2024-10-15
- Publication Date
- 2026-05-12
AI Technical Summary
Existing technologies for software type detection have low accuracy and high maintenance costs, are difficult to resist zero-day attacks, and require continuous updates to the feature database.
By extracting opcode features, text features, permission features, and image features from software data, and using random forest, Naive Bayes, multilayer perceptron, and VGG16 models for classification, and combining multiple classification results with the KAN model, the software type is determined.
It improves the accuracy and robustness of software type detection, reduces maintenance costs, and avoids the need to update the feature library.
Smart Images
Figure CN118965354B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a software type detection method, apparatus, terminal device, and storage medium. Background Technology
[0002] In recent years, with the development of the internet industry, various software programs have emerged. Some of these programs may disguise themselves as other software to mislead users. These programs are highly deceptive and may cause harm to users.
[0003] Currently, these disguised software programs are typically detected using rule-based and signature-based methods. This approach heavily relies on known malware signature databases, requiring matching software behavior with known characteristics for detection. This not only results in inaccurate classification but also makes them vulnerable to zero-day attacks—attacks that exploit undiscovered or unpatched vulnerabilities. Furthermore, this method requires continuous updates to the signature database, leading to high maintenance costs. Therefore, improving the accuracy of software type detection while reducing maintenance costs has become a pressing technical challenge. Summary of the Invention
[0004] This application provides a software type detection method, apparatus, terminal device, and storage medium, which can solve the technical problems of low accuracy and high maintenance cost of software type detection in the prior art.
[0005] In a first aspect, embodiments of this application provide a software type detection method, including:
[0006] Obtain software data of the software under test;
[0007] From the software data, software features of the software under test are extracted, wherein the software features include opcode features, text features, permission features and image features;
[0008] Based on the software characteristics, the software under test is classified to obtain multiple classification results for the software under test;
[0009] Based on the multiple classification results, the composite software characteristics of the software under test are determined;
[0010] Based on the characteristics of the composite software, the software type of the software under test is determined.
[0011] Further, extracting the software features of the software under test from the software data includes:
[0012] Extract the file opcode data of the software under test from the software data;
[0013] The file opcode data is deredundant to obtain clean file opcode data;
[0014] The opcode data of the clean file is vectorized to obtain the opcode features of the software under test.
[0015] Further, extracting the software features of the software under test from the software data includes:
[0016] Extract the text information of the software under test from the software data;
[0017] The text information is segmented into words, and the segmented text information is then subjected to noise reduction processing to obtain software keywords;
[0018] The software keywords are processed into text vectors to obtain the text features of the software under test.
[0019] Further, extracting the software features of the software under test from the software data includes:
[0020] The software permission parsing library is used to parse the target format file in the software data to obtain the permissions requested by the software under test.
[0021] The requested permissions are vectorized using a preset encoding method to obtain the permission characteristics of the software under test.
[0022] Further, extracting the software features of the software under test from the software data includes:
[0023] Extract multiple target images in a preset format from the software data;
[0024] Based on the image information of each target image, the corresponding target images are filtered to obtain multiple retained target images;
[0025] The multiple retained target images are formatted to obtain multiple standard images;
[0026] The aforementioned standard images are identified as image features of the software under test.
[0027] Furthermore, acquiring the software data of the software under test includes:
[0028] The application package file of the software under test is obtained by using a preset data transmission protocol.
[0029] The application package file is decompiled to obtain the software data of the software under test.
[0030] Furthermore, after determining the software type of the software under test based on the composite software characteristics, the method further includes:
[0031] The type probability distribution of the software under test is input into a preset large language model to obtain a test report of the software under test;
[0032] The probability distribution of the type and the detection report are integrated to obtain a comprehensive detection report of the software under test.
[0033] Secondly, embodiments of this application provide a software type detection device, including:
[0034] The acquisition unit is used to acquire software data of the software under test.
[0035] The extraction unit is used to extract software features of the software under test from the software data, wherein the software features include opcode features, text features, permission features and image features;
[0036] A classification unit is used to classify the software under test according to the software characteristics, and obtain multiple classification results of the software under test;
[0037] The first determining unit is used to determine the composite software features of the software under test based on the multiple classification results.
[0038] The second determining unit is used to determine the software type of the software under test based on the composite software characteristics.
[0039] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.
[0040] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.
[0041] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.
[0042] The beneficial effects of this application embodiment compared with the prior art are as follows: by extracting software features including operation code features, text features, permission features and image features from software data, classifying the software according to these features to obtain multiple classification results, determining composite software features based on multiple classification results, and finally determining the software type based on composite software features, it can solve the defect of low detection accuracy caused by using a single data type in related technologies, which helps to improve the detection accuracy and robustness, and does not require updating the feature library, which helps to reduce maintenance costs. Attached Figure Description
[0043] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0044] Figure 1 This is a flowchart illustrating the implementation of a first embodiment of a software type detection method provided in this application.
[0045] Figure 2 This is a flowchart illustrating the implementation of a second embodiment of a software type detection method provided in this application.
[0046] Figure 3 This is a flowchart illustrating the implementation of a third embodiment of a software type detection method provided in this application.
[0047] Figure 4 This is a structural block diagram of a software type detection device provided in an embodiment of this application;
[0048] Figure 5 This is a structural block diagram of a software type detection device provided in an embodiment of this application. Detailed Implementation
[0049] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0050] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.
[0051] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0052] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."
[0053] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0054] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0055] Please see Figure 1 , Figure 1 This document illustrates a flowchart of a first embodiment of a software type detection method provided in this application, comprising:
[0056] Step S10: Obtain the software data of the software under test.
[0057] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, or an electronic device, software type detection device, computer, tablet computer, etc., capable of performing the above functions. The following uses a software type detection device as an example to illustrate this embodiment and the subsequent embodiments.
[0058] Understandably, the software under test can be software whose type needs to be determined through testing. Software data can refer to information used, processed, and stored within a software system. This data can be in various forms, including text, numbers, images, audio, video, etc.
[0059] Step S20: Extract the software features of the software under test from the software data.
[0060] The software features include opcode features, text features, permission features, and image features.
[0061] Understandably, software features reflect the attributes and functions of software. Opcode features can be features extracted from the software's opcodes. An opcode is a part of the instruction set used to specify commands that the computer performs specific operations. It is the core of machine language instructions and is usually used in conjunction with operands to perform operations such as arithmetic operations, data transfer, or logical judgments. Text features can be features extracted from the software's text information. Permission features can be features extracted from the software's permission information. Image features can be features extracted from the software's image data.
[0062] Step S30: Based on the software characteristics, classify the software under test to obtain multiple classification results for the software under test.
[0063] Understandably, the software under test is classified according to each software feature, and the classification result corresponding to each software feature is obtained.
[0064] Step S40: Determine the composite software features of the software under test based on the multiple classification results.
[0065] It is understandable that composite software features can be features obtained by splicing together the results of various classifications.
[0066] Step S50: Determine the software type of the software under test based on the composite software characteristics.
[0067] In one example, the software type detection device acquires software data of the software under test. It extracts opcode features from the opcodes, permission features from the permission information, text features from the text information, and image features from the image data. The opcode features are input into a Random Forest algorithm for classification, yielding a first classification result. The text features are input into a Naive Bayes model for classification, yielding a second classification result. The permission features are input into a Multi-Layer Perceptron (MLP) model for classification, yielding a third classification result. The image features are input into a VGG16 model for classification, yielding a fourth classification result. The first, second, third, and fourth classification results are concatenated to obtain a 4*5 (five-class example) feature vector corresponding to the software under test; this feature vector is the composite software feature. This feature vector is then input into a trained LAN model to obtain the software type of the software under test, which includes: legitimate software, disguised software, entertainment software, movie / video software, music software, and office software, etc.
[0068] In another example, a software type detection device acquires an opcode feature dataset, a text feature dataset, a permission feature dataset, and an image feature dataset. These datasets are divided into training, validation, and test sets in a 7:2:1 ratio. A random forest algorithm is trained on the training set containing the opcode features. After a set number of training iterations, the trained model is validated using the validation set. Once validation is successful, the accuracy is tested on the test set. After passing the test, the resulting random forest algorithm is used for classification. Random forest is an ensemble learning method that improves classification accuracy and stability by constructing multiple decision trees and aggregating their predictions. Random forest reduces overfitting risk by introducing randomness and optimizes feature selection by evaluating the importance of each feature. Random forest exhibits high classification performance and robustness when dealing with complex features and datasets. A Naive Bayes model is trained on the training, validation, and test sets corresponding to the text feature dataset to obtain a Naive Bayes model for classification. Naive Bayes is a simple probabilistic classifier based on Bayes' theorem and the assumption of conditional independence of features. Although its assumption (features are independent) rarely holds true in practical applications, Naive Bayes classifiers still exhibit good performance in many cases and are computationally efficient. A Multi-Layer Perceptron (MLP) is trained using the training, validation, and test sets corresponding to a permission feature dataset to obtain a MLP model for classification. A Multi-Layer Perceptron (MLP) is a feedforward artificial neural network model consisting of an input layer, one or more hidden layers, and an output layer. It is trained using the backpropagation algorithm and can learn complex nonlinear mappings. MLP classifiers perform well in handling classification problems involving multiple complex features and interactions, and their classification performance can be improved through automatic feature learning. A VGG16 model is trained using the training, validation, and test sets corresponding to an image feature dataset to obtain a VGG16 model for classification. VGG16 is a classic deep convolutional neural network that achieves excellent performance in tasks such as image classification through a simple and unified network structure that stacks small-sized convolutional kernels and pooling layers. In this solution, VGG16 can be used to extract and analyze image information from Android software, helping to identify its features and patterns.
[0069] In another example, a software type detection device acquires a composite software feature dataset, which is then divided into a training set, a validation set, and a test set in a 7:2:1 ratio. The concatenated composite software features are mapped to a 1 x 20 feature vector through a fully connected layer. This vector is then input into the meta-model KAN for training, yielding the final output model. Specifically, the input feature vector passes through two KANLayer layers. Each KANLayer consists of basis functions (univariate functions), spline functions (bivariate functions), and linear combinations of the two. The output is then processed by the SiLU activation function. Finally, it passes through a Symbolic_KANLayer to obtain the final output. The SiLU activation function is an improvement on Sigmoid and ReLU. SiLU is unbounded with a bounded lower bound, smooth, and non-monotonic, and can be considered a smooth ReLU activation function. KAN is an alternative to a multilayer perceptron (MLP) inspired by the Kolmogorov-Arnold representation theorem. Unlike MLP nodes (“neurons”) which have fixed activation functions, KANs have learnable activation functions on their edges (“weights”). Smaller KAN networks can achieve or exceed the accuracy of larger MLPs in data fitting problems. This embodiment uses KANs as a meta-model to effectively integrate the prediction results of multiple base models, thereby improving the overall detection accuracy. Compared to traditional MLP meta-models, KANs have fewer model parameters, thus reducing computational costs and resource requirements.
[0070] In some optional implementations, step S10 can be achieved by the following steps: obtaining the application package file of the software under test through a preset data transmission protocol; decompiling the application package file to obtain the software data of the software under test.
[0071] It is understandable that the preset data transmission protocol can be a pre-defined communication protocol used to transmit software data.
[0072] In one example, taking Android software as the test subject, the software type detection device obtains the Android application package (APK) file by directly uploading the APK file, downloading a URL, or downloading a QR code. The device checks the file extension of the uploaded file. Once the extension indicates that the file is an APK, data transmission is performed via HTTPS, employing packet verification and transport layer encryption (SSL / TLS) to ensure data integrity and security. Transport layer security protocols, such as SSL (Secure Sockets Layer) and TLS (Transport Layer Security), encrypt data during transmission, preventing eavesdropping or tampering. The device then decompiles the APK file, obtaining a file reflecting the internal structure of the original APK file (AndroidManifest.xml) and Smali opcodes. The AndroidManifest file contains important application information and metadata, such as basic application information (package, version information, etc.), permission information, components (such as Activity, Service, BroadcastReceiver, and ContentProvider), and their configurations. Opcodes are bytecode instructions in Android applications that run on the Dalvik virtual machine (before Android 5.0) or ART (Android 5.0 and later). Each opcode represents a specific operation, such as load, store, compute, or branch.
[0073] In some optional implementations, after step S50, the method further includes: inputting the type probability distribution of the software under test into a preset large language model to obtain a detection report of the software under test; and integrating the type probability distribution and the detection report to obtain a comprehensive detection report of the software under test.
[0074] In one example, the software type detection device inputs the type probability distribution of the discrimination results into a preset large language model. Using preset input text, it obtains a detection report output by the preset large language model. The preset input text can include: 1. Parsing time; 2. The analyzed APK file name, app name, and APK size; 3. The probability of classifying the APK into each category based on text features, permission features, image features, and opcode features; and the category and probability of combining all four features. Write a report based on the above. The report title should be: XXX Analysis Report. Do not use asterisks (*) as subheadings; use Arabic numerals for all subheadings. Note: Do not use symbols like # or *. Use Python-docx to integrate the type probability distribution with the text content of the detection report and export it as a comprehensive detection report in Microsoft Word (.docx) format. Python-docx is a Python library based on openXML for automating the creation and modification of Microsoft Word (.docx) documents. It also allows setting thresholds to determine the clarity of the classification; if the classification is clear, the information of the detected software is updated in the black / white list of the database. If the classification is unclear, it is added to the system's gray list for subsequent manual detection by the system administrator.
[0075] The method provided in this embodiment extracts software features from software data, including operation code features, text features, permission features, and image features. Based on these features, the software is classified to obtain multiple classification results. Then, based on the multiple classification results, composite software features are determined. Finally, the software type is determined based on the composite software features. This method can solve the defect of low detection accuracy caused by using a single data type in related technologies, which helps to improve the detection accuracy and robustness. Moreover, it does not require updating the feature library, which helps to reduce maintenance costs.
[0076] In optional implementations of various embodiments of this application, step S20 may include the following steps: steps S201 to S203. Wherein, Figure 2 The flowchart illustrates the implementation of the second embodiment of the software type detection method provided in this application.
[0077] Step S201: Extract the file opcode data of the software under test from the software data.
[0078] It is understandable that file opcode data can be data composed of opcodes.
[0079] Step S202: Perform redundancy removal processing on the file opcode data to obtain clean file opcode data.
[0080] It is understandable that clean file opcode data can be the data obtained by removing redundant numbers from the file opcode.
[0081] Step S203: Vectorize the pure file opcode data to obtain the opcode features of the software under test.
[0082] In one example, the software type detection device extracts file opcode data from the software data, removes redundant numbers from the file opcode data, and obtains clean file opcode data. The opcodes in the clean file opcode data are then vectorized using one-hot encoding to obtain the opcode features of the software under test.
[0083] In some optional implementations, step S20 above can also be implemented by the following steps: extracting text information of the software under test from the software data; performing word segmentation on the text information and noise reduction on the segmented text information to obtain software keywords; and performing text vectorization on the software keywords to obtain the text features of the software under test.
[0084] It is understandable that text information can refer to text data processed and displayed in a software system. This data can include: user interface text: buttons, menus, labels, prompts, etc., used for user interaction; help documentation: user manuals, online help, FAQs, etc., providing operation guidelines and support; log information: system-generated operation logs, error reports, etc., recording the software's operating status and abnormal situations; input and output data: text data entered by the user in the software (such as forms, comments, etc.) and text results output by the software (such as reports, notifications, etc.).
[0085] In one example, the lxml library is used to parse the decompiled XML file and extract its text information. lxml is a C-based XML and HTML parsing library widely used in Python. In this solution, lxml can quickly parse XML files and extract text as needed. The jieba word segmentation tool is used to perform precise Chinese-English word segmentation on the extracted text information and remove stop words to obtain software keywords, reducing noise in the text and improving the accuracy and efficiency of subsequent text analysis. jieba is a widely used word segmentation tool developed in Python, offering various segmentation modes, including precise mode, full mode, and search engine mode. Then, the software type detection device extracts software keywords using the TF-IDF method and performs text vectorization to construct the text features of the software under test. TF-IDF (Term Frequency-Inverse Document Frequency) is a commonly used text feature extraction method that measures the importance of a word in text. Specifically, a higher TF-IDF value indicates a higher frequency of the word in the text and a lower frequency in the entire dataset, thus better representing the theme and sentiment of the text. By calculating the Tfidf value of each word and converting it into a vector, this scheme can obtain a vector space model that reflects the topic of the text.
[0086] The method proposed in this embodiment obtains the opcode features of the software under test by vectorizing the file opcode, and then determines the classification result of the software under test based on the opcode features, which helps to improve the accuracy of software type detection.
[0087] In optional implementations of various embodiments of this application, step S20 may further include the following steps: steps S21 to S22. Wherein, Figure 3 The flowchart illustrates the implementation of the third embodiment of the software type detection method provided in this application.
[0088] S21: Parse the target format file in the software data using the software permission parsing library to obtain the requested permissions of the software under test.
[0089] It's understandable that a software permission resolution library is a database used to resolve software permissions. Requesting permissions refers to software requesting permissions granted by the system.
[0090] S22: The requested permissions are vectorized using a preset encoding method to obtain the permission features of the software under test.
[0091] In one example, taking Android software as an example, the lxml library is used to parse the XML file to obtain the permissions requested by the Android software. These permissions include: android.permission.INTERNET (allows the application to open network sockets), android.permission.WRITE_EXTERNAL_STORAGE (allows the application to write to external storage), android.permission.ACCESS_NETWORK_STATE (allows the application to access network information), android.permission.ACCESS_WIFI_STATE (allows the application to access Wi-Fi network information), android.permission.READ_LOGS (allows the application to read low-level system log files), android.permission.READ_PHONE_STATE (allows the application to access phone status), and android.permission.RECORD_AUDIO (allows the application to record audio), etc. Then, the software type detection device vectorizes the requested permissions using one-hot encoding, writing each permission as an independent vector for subsequent machine learning processing to obtain the permission characteristics of the software under test. One-hot encoding, also known as one-hot coding, uses an N-bit state register to encode N states.
[0092] In some optional implementations, step S20 above can also be implemented by the following steps: extracting multiple target images in a preset format from the software data; filtering the corresponding target images according to the image information of each target image to obtain multiple retained target images; formatting the multiple retained target images to obtain multiple standard images; and determining the multiple standard images as image features of the software under test.
[0093] In one example, the software type detection device identifies multiple target images in PNG, JPG, and JPEG formats by matching file extensions. These target images are then filtered. Considering that images with very small files may contain limited information, this approach uses rules to filter images larger than 50KB, resulting in multiple retained target images. This ensures the input images have sufficient quality and detail, thereby improving recognition accuracy. The software type detection device then converts the retained target images to RGB format and standardizes the input image size to 256*256, resulting in multiple standard images. These standard images are identified as image features of the software under test, ensuring consistency in the input images and enabling subsequent models to more accurately learn and recognize features within the images.
[0094] In another example, the Django framework can be used to connect to a MySQL database and build a platform webpage. This platform webpage is then deployed to a server, establishing a cloud database to record blacklists, whitelists, and graylists of Android software. The software type detection device compares the package name (package_name) and application name (app_name) of the software under test to check if the software is recorded in the system's existing blacklist, whitelist, or graylist.
[0095] The method proposed in this embodiment vectorizes the permission requests of the software under test to obtain the permission features of the software under test. Based on the permission features, the software type of the software under test is determined. This method can integrate data features from different sources to detect the software under test, thereby obtaining the type of the software under test, which helps to improve the accuracy and generalization ability of software type detection.
[0096] Please see Figure 4 , Figure 4 This is a structural block diagram of a software type detection device 400 provided in an embodiment of this application. In this embodiment, the software type detection device includes units used for executing... Figures 1-3 The steps in the corresponding embodiments. Please refer to the details. Figures 1-3 as well as Figures 1-3 The relevant descriptions in the corresponding embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown. See also... Figure 4 The software type detection device 400 includes:
[0097] Acquisition unit 401 is used to acquire software data of the software under test;
[0098] Extraction unit 402 is used to extract software features of the software under test from the software data, wherein the software features include operation code features, text features, permission features and image features;
[0099] The classification unit 403 is used to classify the software under test according to the software characteristics to obtain multiple classification results of the software under test;
[0100] The first determining unit 404 is used to determine the composite software features of the software under test based on the multiple classification results.
[0101] The second determining unit 405 is used to determine the software type of the software under test based on the composite software characteristics.
[0102] As an embodiment of this application, the extraction unit 402 is further configured to extract the file opcode data of the software under test from the software data; perform redundancy removal processing on the file opcode data to obtain clean file opcode data; and perform vectorization processing on the clean file opcode data to obtain the opcode features of the software under test.
[0103] As an embodiment of this application, the extraction unit 402 is further configured to extract text information of the software under test from the software data; perform word segmentation processing on the text information, and perform noise reduction processing on the segmented text information to obtain software keywords; and perform text vectorization processing on the software keywords to obtain text features of the software under test.
[0104] As an embodiment of this application, the extraction unit 402 is further configured to parse the target format file in the software data through a software permission parsing library to obtain the application permission of the software under test; and to vectorize the application permission through a preset encoding method to obtain the permission features of the software under test.
[0105] As an embodiment of this application, the extraction unit 402 is further configured to extract multiple target images of a preset format from the software data; filter the corresponding target images according to the image information of each target image to obtain multiple retained target images; format the multiple retained target images to obtain multiple standard images; and determine the multiple standard images as image features of the software under test.
[0106] As an embodiment of this application, the acquisition unit 401 is further configured to acquire the application package file of the software under test through a preset data transmission protocol; and to decompile the application package file to obtain the software data of the software under test.
[0107] As an embodiment of this application, the second determining unit 405 is further configured to input the type probability distribution of the software under test into a preset large language model to obtain a detection report of the software under test; and to integrate the type probability distribution and the detection report to obtain a comprehensive detection report of the software under test.
[0108] The apparatus provided in this embodiment extracts software features, including operation code features, text features, permission features, and image features, from software data. Based on these features, it classifies the software to obtain multiple classification results, then determines composite software features based on the multiple classification results, and finally determines the software type based on the composite software features. This can solve the defect of low detection accuracy caused by using a single data type in related technologies, which helps to improve the detection accuracy and robustness. Moreover, it does not require updating the feature library, which helps to reduce maintenance costs.
[0109] It should be understood that, Figure 4 In the structural block diagram of the software type detection device shown, each unit is used to perform... Figures 1-3 The steps in the corresponding embodiments, and for Figures 1-3 The steps in the corresponding embodiments have been explained in detail in the above embodiments. Please refer to them for details. Figures 1-3 as well as Figures 1-3 The relevant descriptions in the corresponding embodiments will not be repeated here.
[0110] Figure 5 This is a structural block diagram of a terminal device provided in another embodiment of this application. For example... Figure 5 As shown, the terminal device 500 of this embodiment includes: a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501, such as a program for a software type detection method. When the processor 501 executes the computer program 503, it implements the steps in the various embodiments of the software type detection methods described above, for example... Figure 1 Steps S10 to S50 are shown. Alternatively, the processor 501 executes the above-described steps when executing computer program 503. Figure 4 The functions of each unit in the corresponding embodiments, for example, Figure 4 For details on the functions of the acquisition unit 401 to the second determination unit 405 shown, please refer to [link / reference]. Figure 4 The relevant descriptions in the corresponding embodiments are not repeated here.
[0111] For example, computer program 503 can be divided into one or more units, one or more of which are stored in memory 502 and executed by processor 501 to complete this application. The one or more units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of computer program 503 in terminal device 500. For example, computer program 503 can be divided into an acquisition unit, an extraction unit, a classification unit, a first determination unit, and a second determination unit, with the specific functions of each unit as described above.
[0112] The terminal device may include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art will understand that... Figure 5 This is merely an example of terminal device 500 and does not constitute a limitation on terminal device 500. It may include more or fewer components than shown, or combine certain components, or different components. For example, a turntable terminal device may also include input / output terminal devices, network access terminal devices, buses, etc.
[0113] The processor 501 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.
[0114] The memory 502 can be an internal storage unit of the terminal device 500, such as a hard disk or RAM of the terminal device 500. The memory 502 can also be an external storage terminal device of the terminal device 500, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the terminal device 500. Furthermore, the memory 502 can include both internal storage units and external storage terminal devices of the terminal device 500. The memory 502 is used to store computer programs and other programs and data required by the turntable terminal device. The memory 502 can also be used to temporarily store data that has been output or will be output.
[0115] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0116] If an integrated module is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. This computer-readable storage medium can be non-volatile or volatile. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the contents of a computer-readable storage medium may be appropriately added to or subtracted from the contents as required by the legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, a computer-readable storage medium may not include electrical carrier signals and telecommunication signals.
[0117] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A software type detection method, characterized in that, The method includes: Obtain software data of the software under test; From the software data, software features of the software under test are extracted, wherein the software features include opcode features, text features, permission features and image features; Based on the software characteristics, the software under test is classified to obtain multiple classification results for the software under test; Based on the multiple classification results, the composite software features of the software under test are determined. The multiple classification results include a first classification result obtained by inputting the opcode features into a random forest algorithm for classification, a second classification result obtained by inputting the text features into a Naive Bayes model for classification, a third classification result obtained by inputting the permission features into a multilayer perceptron for classification, and a fourth classification result obtained by inputting the image features into a VGG16 model for classification. Based on the composite software characteristics, determine the software type of the software under test; The step of determining the composite software characteristics of the software under test based on the multiple classification results includes: The first classification result, the second classification result, the third classification result, and the fourth classification result are concatenated to obtain the feature vector corresponding to the software to be detected, and the feature vector is determined as the composite software feature. The method further includes: A composite software feature dataset is obtained and divided into a training set, a validation set, and a test set. The concatenated composite software features are mapped to feature vectors through a fully connected layer. The feature vectors are then input into the meta-model KAN for training to obtain the final output model. The composite software features are then input into the output model to obtain the software type output by the output model. The acquisition of software data for the software under test includes: The application package file of the software under test is obtained by using a preset data transmission protocol. The application package file is decompiled to obtain the software data of the software under test; The obtained application package file of the software under test includes: The system obtains the APK file of the Android software by directly uploading the APK file, downloading the URL, or downloading the QR code; it detects the file extension of the uploaded file, and after the extension indicates that the file is an APK file, it transmits the data through the HTTPS protocol; it decompiles the APK file to obtain the AndroidManifest file and opcodes that reflect the internal structure of the original APK file. The AndroidManifest file contains the application's basic information, permission information, components, and configuration. Extracting opcode features includes: Extract the file opcode data of the software under test from the software data; perform redundancy removal processing on the file opcode data to obtain clean file opcode data; perform vectorization processing on the clean file opcode data to obtain the opcode features of the software under test.
2. The method as described in claim 1, characterized in that, Extracting software features of the software under test from the software data includes: Extract the text information of the software under test from the software data; The text information is segmented into words, and the segmented text information is then subjected to noise reduction processing to obtain software keywords; The software keywords are processed into text vectors to obtain the text features of the software under test.
3. The method as described in claim 1, characterized in that, Extracting software features of the software under test from the software data includes: The software permission parsing library is used to parse the target format file in the software data to obtain the permissions requested by the software under test. The requested permissions are vectorized using a preset encoding method to obtain the permission characteristics of the software under test.
4. The method as described in claim 1, characterized in that, Extracting software features of the software under test from the software data includes: Extract multiple target images in a preset format from the software data; Based on the image information of each target image, the corresponding target images are filtered to obtain multiple retained target images; The multiple retained target images are formatted to obtain multiple standard images; The aforementioned standard images are identified as image features of the software under test.
5. The method according to any one of claims 1-4, characterized in that, After determining the software type of the software under test based on the composite software characteristics, the method further includes: The type probability distribution of the software under test is input into a preset large language model to obtain a test report of the software under test; The probability distribution of the type and the detection report are integrated to obtain a comprehensive detection report of the software under test.
6. A software type detection device, characterized in that, The software type detection device includes: The acquisition unit is used to acquire software data of the software under test. The extraction unit is used to extract software features of the software under test from the software data, wherein the software features include opcode features, text features, permission features and image features; A classification unit is used to classify the software under test according to the software features, and obtain multiple classification results of the software under test. The multiple classification results include a first classification result obtained by inputting the opcode features into a random forest algorithm for classification, a second classification result obtained by inputting the text features into a Naive Bayes model for classification, a third classification result obtained by inputting the permission features into a multilayer perceptron for classification, and a fourth classification result obtained by inputting the image features into a VGG16 model for classification. The first determining unit is used to determine the composite software features of the software under test based on the multiple classification results. The second determining unit is used to determine the software type of the software under test based on the composite software characteristics. The first determining unit is further configured to concatenate the first classification result, the second classification result, the third classification result and the fourth classification result to obtain the feature vector corresponding to the software to be detected, and to determine the feature vector as a composite software feature; The second determining unit is further configured to acquire a composite software feature dataset, divide the composite software feature dataset into a training set, a validation set, and a test set; map the concatenated composite software features into feature vectors through a fully connected layer, input the feature vectors into the meta-model KAN for training, obtain the final output model, input the composite software features into the output model, and obtain the software type output by the output model. The acquisition unit is further configured to: acquire the application package file of the software under test through a preset data transmission protocol; decompile the application package file to obtain the software data of the software under test; acquire the APK file of the Android software by directly uploading the APK file, downloading the URL, or downloading the QR code; detect the file extension of the uploaded file, and after the file extension indicates that the file is an APK file, transmit the data through the HTTPS protocol; decompile the APK file to obtain the AndroidManifest file and opcodes reflecting the internal structure of the original APK file, wherein the AndroidManifest file contains the application's basic information, permission information, components, and configuration; The extraction unit is further configured to extract file opcode data of the software under test from the software data; perform redundancy removal processing on the file opcode data to obtain clean file opcode data; and perform vectorization processing on the clean file opcode data to obtain the opcode features of the software under test.
7. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 5.
8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 5.