Method for obtaining features for inference of malicious applications, computing device and recording medium thereof

Abstract

A method for obtaining features for inferring a malicious app according to the present invention comprises: a first step of determining whether an app is malicious based on an installation file (APK) of an app installed on a mobile phone having Android as an operating system; a second step of extracting files related to malicious activity from the installation file of the app if it is determined to be malicious in the first step; and a third step of extracting features related to malicious activity from the files extracted in the second step.

Description

Technology Field

[0001] The present invention relates to a method for preventing voice phishing, and more specifically, to a method for analyzing a malicious app by statically analyzing selected files (source code) of the malicious app to extract and store functions related to malicious behavior, and generating training data for an artificial intelligence model for inferring the malicious app. Background Technology

[0003] Smishing is a type of voice phishing that refers to the hacking of mobile phones using text messages. It describes a financial crime that occurs when a malicious app is automatically installed upon clicking a website address (URL) in a text message or social network service message sent by a hacker.

[0004] Smishing has constantly evolved driven by its high profitability, and despite being a widely known type of crime, it is causing increasingly large financial losses while creating victims of all ages and genders.

[0005] Such smishing is used as a means to install voice phishing apps (or malicious apps) on users' mobile phones through voice phishing attacks.

[0006] Malicious apps used in smishing interfere with a victim's attempts to verify whether a call is a voice phishing attempt by manipulating the victim's incoming calls or visited websites to redirect them to the criminal. To detect smishing, it is necessary to analyze and identify the parts where these functions are implemented at the source code level; however, existing methods struggle to detect malicious apps for the following reasons.

[0007] First, to analyze the source code, it is necessary to obtain the Java code related to malicious activity. However, access is difficult because the files defining internal classes and functions (methods) are encrypted.

[0008] Secondly, the actual malicious APK is contained within the compressed file, appearing as if it were part of the Android app's resource files. The classes.dex file, located at the top level of the app, appears to be a normal file without any malicious activity; however, it actually serves the role of loading files and data necessary to induce the user to install the actual malicious APK after the initial app installation by disguising it as the installation of additional features. Reaching this section for more accurate source code analysis presents difficulties, as it requires decrypting the encrypted compressed file beforehand.

[0009] Third, as SDK versions are updated and detection technologies advance, the techniques used in voice phishing are continuously modifying application functions to bypass them. For example, if an antivirus app is installed on a user's device, it can scan the app and forcibly stop or delete it. Therefore, to address this, it is necessary to analyze malicious voice phishing apps at the source code level and continuously accumulate relevant data. The problem to be solved

[0011] The present invention was conceived against this technical background and aims to neutralize existing and modern voice phishing techniques that deceive victims by generating features regarding the behavior of malicious apps through static analysis of malicious apps installed on mobile phone terminals and using them for detection. means of solving the problem

[0013] A method for obtaining features for inferring a malicious app according to the present invention comprises: a first step of determining whether an app is malicious based on an installation file (APK) of an app installed on a mobile phone having Android as an operating system; a second step of extracting files related to malicious activity from the installation file of the app if it is determined to be malicious in the first step; and a third step of extracting features related to malicious activity from the files extracted in the second step.

[0014] In the first step above, whether the app is malicious is based on the filename of a dex file with the extension dex included in the installation file, provided that the filename of the dex file is named in a form different from the filename of the dex file included in the installation file of a normal app, or provided that the filename of the dex file includes the filename of the dex file included in the installation file of a normal app, provided that additional characters or symbols are included.

[0015] In the second step above, the files associated with the malicious activity obtain a dex file with the extension dex and features for inferring a malicious app extracted from within the res directory.

[0016] The Dex file of the malicious app is encrypted, and a service that decrypts the Dex file is found through the Android Manifest file. If the key value is specified as a string value, the Dex file is decrypted using the string value, or the unencrypted Dex file included in the installation file of the malicious app is decompiled to obtain the source code, and the decryption key value of the encrypted Dex file is obtained by tracing the variables of the decryption source in the obtained source code.

[0017] In addition, if a nested APK file is found in the res directory extracted from the APK file of the aforementioned malicious app, the decryption process described above is repeated.

[0018] The aforementioned malicious activity is related to permissions that are not requested by the legitimate app.

[0019] The above features are a combination of at least two of the following: package name, application name, file size, manifest information, URL information, encryption information, signature information, source code related to malicious activity, library file, SDK version of nested APK, and C2 information.

[0020] In addition, another embodiment of the present invention discloses a recording medium having a program coded in a computer-readable language that records the above-described method, and a computing device for computing. Effects of the invention

[0022] According to the present invention, app information and behavior-related data can be extracted and big data accumulated. In addition, the collected data can be applied to machine learning / deep learning-based voice phishing app detection technology. Brief explanation of the drawing

[0024] FIG. 1 is a flowchart of a method for obtaining features for inferring a malicious app of the present invention. Figure 2 is an example of a database built on a user's mobile phone when a malicious app is installed. FIG. 3 is a block diagram of a computational device according to the present invention. Specific details for implementing the invention

[0025] Embodiments of the present invention will be described in detail below with reference to the drawings. However, detailed descriptions of known functions or configurations that may obscure the essence of the present invention in the following description and the attached drawings are omitted. Additionally, throughout the specification, the term 'comprising' a component means that, unless specifically stated otherwise, it does not exclude other components but may include additional components.

[0026] Additionally, terms such as first, second, etc. may be used to describe various components, but said components should not be limited by said terms. said terms may be used for the purpose of distinguishing one component from another component. For example, without departing from the scope of the present invention, the first component may be named the second component, and similarly, the second component may be named the first component.

[0027] The terms used in this invention are used merely to describe specific embodiments and are not intended to limit the invention. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this application, terms such as "comprising" or "comprising" are intended to specify the existence of the described features, numbers, steps, actions, components, parts, or combinations thereof, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0028] Unless specifically defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the present invention pertains. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this application.

[0030] The present invention decompiles a voice phishing app installed on an Android smartphone to prevent voice phishing (telephone financial fraud), extracts functions (or features) related to malicious acts, and stores them. Here, "malicious acts" refers to acts including obtaining specific information from a mobile phone, setting or restricting specific functions, intercepting calls, making calls to specific numbers, or transmitting data to a specific server in order to cause financial damage to the user of the mobile phone.

[0031] In this invention, files related to voice phishing are selected from the internal files of a voice phishing app (or malicious app), and functions related to malicious activities, such as adding specific permissions, viewing call logs, intercepting phone numbers, making and receiving calls to voice phishing numbers, and changing the call screen, are extracted through static analysis (source code) of the selected files. Generally, such malicious activities are related to permissions that are not requested by a legitimate app.

[0032] In addition, the extracted functions and the actual code containing those functions can be stored in a repository after extraction and used for future analysis of voice phishing apps, and this can be used for feature generation for machine learning / deep learning-based voice phishing app detection.

[0033] The present invention relates to a mobile phone equipped with an Android operating system, and the following description explains how the invention is implemented based on Android.

[0035] The method for generating training data for an artificial intelligence model from a malicious app disclosed in the present invention comprises: a first step (S10) of determining whether an app is malicious based on an installation file (APK) of an app installed on a mobile phone equipped with an Android OS as disclosed in FIG. 1; a second step (S20) of extracting files necessary for analysis (inside the dex and res directories) from the installation file of the app if it is determined to be a malicious app in the first step; a third step (S30) of extracting features related to malicious behavior from the files extracted in the second step; and a fourth step (S40) of generating training data to be used for learning an artificial intelligence model based on the features extracted in the third step.

[0036] In the present invention, whether an app is malicious can be determined based on a Dex file (with the extension .dex) that defines the functions of the app and is included in the APK, which is the installation file of the app. Dex files included in the installation file of a normally functioning app are generally named as 'classes.dex', but malicious apps often include additional characters or symbols in their filenames, even while including the filename of a normal app such as 'classes.dex'. For example, a malicious app uses a filename such as 'secret-classes.dex', which is similar to the Dex filename of a normal app, 'classes.dex', but differs in some way.

[0037] In the first step (S10) of the present invention, taking these points into consideration, the installation files of apps installed on a mobile phone are examined, and an app having a modified form of some of the filenames of the DeX files is determined to be a malicious app, and files for static analysis of the app are collected from the installation files.

[0039] In the first step (S10), if the app is determined to be a malicious app, files necessary for analysis are extracted (S20). Files necessary for analysis related to the malicious app exist inside the Dex file or inside the res directory.

[0040] Therefore, in this step (S20), the encrypted dex file can be decrypted to obtain the necessary file (S20-1), or the necessary file can be obtained from within the res directory (S20-2).

[0042] [Decryption of encrypted DEX file (S20-1)]

[0043] Dex files identified as malicious apps are generally encrypted. Therefore, for analysis, the decryption key must be found and replaced with an unencrypted file. The decryption key can be obtained through the following two methods.

[0044] First, find the service that decrypts the corresponding DEX file through the Android Manifest file, and if the key value is specified as a string value, decrypt it using the string value.

[0045] Secondly, legitimate installation files (APKs) contain an internal DEX file named 'classes.dex'. Malicious APK files also contain a legitimate 'classes.dex' file in addition to the malicious 'secret-classes.dex'; this file defines actions unrelated to malicious behavior and performs the operation of decrypting the 'secret-classes.dex' file. Since the 'classes.dex' file is not encrypted, the Java source code can be examined using a decompiler (e.g., JEB). Through this, one can locate the Java code within 'classes.dex' corresponding to the service that decrypts the 'secret-classes.dex' file and find the variable that stores the key value. The code performing the decryption utilizes JNI (Java Native Interface). This is typically defined in a library file (such as 'dn_ssl.so') with the .so extension, and by tracing the variable to find the key value, the encrypted 'secret-classes.dex' file can be decrypted.

[0047] [Inside res directory (S20-2)]

[0048] Inside the res directory extracted from the malicious app's APK file, there are files such as the following designed to disguise themselves as a voice phishing app.

[0049] a) Fake voice call connection file (.mp3 extension)

[0050] b) Fake webpage resource files (.html, .jpeg, .png, etc.)

[0051] c) Fake icon file

[0052] d) A hidden (nested) APK file (.apk) responsible for the actual malicious activity

[0054] If d) exists among the above files, the files necessary for analysis must be extracted by decompressing, so the Manifest file and the encrypted secret-classes.dex file are extracted from the nested APK file.

[0055] The encrypted secret-classes.dex file of the nested APK file can be decrypted using the same method described in Step S20-1 to obtain files related to malicious activities necessary for analysis.

[0056] To explain this in more detail, it is as follows.

[0057] After decrypting the encrypted files, all Dex files encrypted inside the malicious APK file being analyzed are replaced with the decrypted Dex files.

[0058] Then, the Java code can be analyzed by decompiling the APK file using the JEB Android tool. During static analysis, the source code related to the following malicious behavior is extracted.

[0059] Malicious apps often disguise themselves as delivery or financial apps and request permissions that legitimate apps would not ask for. Below are examples of the requested permissions.

[0060] - android.permission.READ_CALL_LOG (Read call history)

[0061] - android.permission.WRITE_CALL_LOG (Write call log)

[0062] - android.permission.READ_CONTACTS (Read phonebook)

[0063] - android.permission.WRITE_CONTACTS (Write phone book)

[0064] - android.permission.READ_PHONE_NUMBERS (Read phone numbers Android 10)

[0065] - android.permission.READ_PHONE_STATE (Read device information Android 10)

[0066] - android.permission.CALL_PHONE (outgoing)

[0067] - android.permission.ANSWER_PHONE_CALLS (receive)

[0069] These permissions are defined in the Android Manifest file within the APK file that actually performs the malicious activity, and there is no reason for them to be defined in a legitimate financial or transportation-related app. Additionally, the permissions primarily used to evade detection after the victim has installed the malicious app are as follows.

[0070] - android.permission.REQUEST_INSTALL_PACKAGES

[0071] - android.permission.REQUEST_DELETE_PACKAGES

[0073] Among the above permissions, the android.permission.REQUEST_INSTALL_PACKAGES permission is requested from the user when the malicious app is initially installed, and it requests the victim to install APKs related to malicious activities.

[0074] The android.permission.REQUEST_DELETE_PACKAGES permission exists to forcibly delete security-related apps (e.g., antivirus apps) already installed on the victim's mobile phone.

[0076] In addition to the above permissions, the present invention extracts various permissions for voice phishing activities through static analysis, and the following may be further included.

[0078] - User View Overlay Transformation (User Device Screen Manipulation)

[0079] A function (method) for setting a user view overlay within a malicious app is defined to modify the call screen of the user's device during incoming or outgoing calls. For example, if a victim calls a public institution, the malicious app swaps the public institution's phone number with a voice phishing scammer's phone number that is predefined within the app, passes the swapped number and the name of the public institution as arguments to an overlay modification function, and the modified information is displayed on the user's device screen.

[0081] - Caller ID interception

[0082] When a malicious app is installed on a user's device, it establishes a database that stores the phone numbers and names of organizations to be swapped. If a victim attempts to call a specific organization's phone number, the app retrieves the replacement number from the database and attempts to make the call using an Intent such as `android.intent.action.DIAL`. Additionally, it accesses the phonebook via `contentResolver` and deletes the number just called from `(CallLog.Calls.CONTENT_URI)`.

[0084] - Intercepting incoming numbers

[0085] Similar to caller ID interception, the call connection screen (view overlay) is disguised as a legitimate number. This is accompanied by the disguise of the phonebook and call log records. To facilitate interception, the numbers of the impersonated organization and the voice phishing perpetrator are stored in a repository (either in the form of a database or via SharedPreference). When a voice phishing perpetrator calls a victim, the malicious app operates in the background to monitor the call; consequently, the user's screen displays a screen that has been swapped with a phone number from an organization that appears legitimate. The relevant permission is android.permission.BIND_INCALL_SERVICE, which monitors the device's call status using the android.telecom.InCallService.

[0087] - Creating a data file for number interception

[0088] Upon installation of a malicious app, a database is constructed as a preparatory step for the tasks mentioned above. When infected by a malicious app, the C2 server transmits a configuration file to the victim's device in the form of an encrypted string; by default, it is encrypted using AES / CBC / PKCS7Padding, and decrypting it yields a JSON-formatted database configuration file. After reading the configuration and constructing the database, preparations for malicious activities are completed. An example of such a database is shown in Fig. 2.

[0090] - Phonebook manipulation (viewing and updating)

[0091] If number swapping is possible through the function of intercepting outgoing and incoming phone numbers, the victim's call log and phonebook can be manipulated. The malicious app obtains permission to view and modify the victim's phonebook through android.permission.READ_CONTACTS and android.permission.WRITE_CONTACTS. It then uses Contacts.People.CONTENT_URI to insert the voice phishing perpetrator's number into the phonebook.

[0092] When the victim receives a call, they modify their phonebook to save the voice phishing scammer's number in order to disguise it as a legitimate conversation; consequently, even if the call comes from the scammer, the victim perceives it as a call coming from a contact already in their phonebook.

[0094] - Terminate and delete package

[0095] To disable the detection of voice phishing apps on infected users' mobile phones, it requests the installation of an app disguised as a security program; this app is one of the nested APKs. Upon execution, the malicious app requests user approval and displays behavior disguised as a malware scan, but in reality, it deletes legitimate security programs installed on the user's phone. It requires the “REQUEST_DELETE_PACKAGES” permission, and the deletion is carried out via android.intent.action.DELETE.

[0097] - C2 server

[0098] The malicious app connects to the user's mobile phone for remote communication and control. It retrieves information (e.g., IP address) from a predefined C2 server via the aforementioned database file to establish socket communication, or uses an IP address hardcoded within the source code to establish a connection. Additionally, it may attempt to connect to or induce a link to a website impersonating an organization; it can be identified that the connected website is insecure and uses the HTTP protocol.

[0100] - Modify the call connection by playing an MP3 file

[0101] The MP3 files contained within the APK file are recordings of voice prompts made after a call with a voice phishing scammer to deceive the victim. These files are defined by hardcoding the phone numbers of the impersonated organizations or companies, as well as the MP3 files located in the `assets` path. The MP3 files in the `assets` path may exist inside password-locked compressed files or in an uncompressed state. A more sophisticated attack involves a password-locked MP3 file in the `assets` path that is actually a compressed file with a .mp3 extension. Two types of files exist inside:

[0102] 1) .json file - Contains mapping information for impersonated phone numbers and voice guidance (mp3 files) in the form of a dictionary.

[0103]

[0104] 2) .mp3 file - a recorded voice guidance file that runs according to the mapping.

[0105]

[0107] In the case of the disguise method described above, the attack is relatively invisible because the mapping information is retrieved from a JSON file rather than being specified in a hardcoded form in the source code. The compression method used for the MP3 and JSON files in this method utilizes AES encryption, and since the password is hardcoded in the decompression section of the source code, the file can be decompressed after acquisition. It is possible to distinguish whether an MP3 file is a genuine MP3 file or a compressed file by checking the file's magic value; the following are examples of magic values ​​that can be checked for this purpose.

[0108] [Example of Magic Value for Normal .mp3, .wav Files]

[0109] 49 44 33 => mp3 file (ID3)

[0110] 52 49 46 46 => WAV file (RIFF)

[0112] [Example of Magic Value for Compressed File] 50 4B 03 04 => ZIP Compressed File

[0113] 1F 8B 08 => GZIP compressed file

[0114] 42 5A 68 => BZIP2 compressed file

[0115] 37 7A BC AF 27 1C => 7Z compressed file

[0116] 52 61 72 21 1A 07 00 => RAR compressed file

[0118] The source code related to the aforementioned malicious activity logs the class defining the malicious activity through static analysis, and all functions used within the class are extracted during the feature extraction process (S30). During extraction, classes and functions related to the malicious activity are searched based on strings using regular expressions. During the search, the source code portion related to the malicious activity is extracted in the form of an Abstract Syntax Tree (AST).

[0120] When files related to malicious activity are extracted through step S20, features related to malicious activity are extracted from the files extracted in the second step. In the present invention, a feature serves as a criterion for distinguishing between a malicious app and a normal app, and forms the basis of training data used to enable an artificial intelligence model to infer a malicious app.

[0121] An example of the features extracted in this third step is as follows.

[0122] - Package name (from Manifest information)

[0123] - Application name (from Manifest information)

[0124] - File size

[0125] - Manifest information (Activity, Service, Broadcast Receiver permissions)

[0126] - URL information (identifying fake websites) (from source code)

[0127] - Encryption information (algorithm, key value, etc.) (from source code)

[0128] - Signature information (distinction to make it look like a legitimate app) (from source code)

[0129] - Source code section related to malicious activity

[0130] - Library file (decryption key value)(.dll, .so)

[0131] - Nested APK SDK version (from source code)

[0132] - C2 information (IP address, HTTP protocol, etc.) (from source code)

[0133] The features obtained in step S30 are converted into a format usable by an artificial intelligence model and stored as training data (S40). The generated training data is stored in a data repository in JSON format and can be constructed using MongoDB, which can store object data types.

[0135] In order to investigate the effects of the present invention as described above, an experiment was conducted, and the results are as follows.

[0136] After collecting 14,210 normal samples (APK files) and 4,568 voice phishing samples from Google Play, features were extracted according to the present invention described above to create training data and train an artificial intelligence model. As a result, the malicious app detection performance of the trained artificial intelligence model was evaluated, and a final F1-score of 99% was achieved by adjusting the 10-fold cross-validation and train / test ratio for the Random Forest classifier model.

[0138] Figure 3 is a reconstruction of the method for obtaining features for inferring a malicious app of the present invention described above from a hardware perspective.

[0139] A computing device (800) according to the present invention includes a memory (810) that stores a program coded in a computer-readable language for the method described above, and a processor (820) that calls the program to perform mathematical operations. The processor (820) determines whether an app is malicious based on an installation file (APK) of an app installed on a mobile phone having Android as an operating system. If, in the determination, the app is determined to be malicious, it extracts files related to malicious activity from the installation file of the app and extracts features related to malicious activity from the extracted files.

[0140] The processor (820) determines whether the app is malicious based on the filename of a dex file with the extension dex included in the installation file, wherein the filename of the dex file includes the filename of a dex file included in the installation file of a normal app, but additionally includes additional characters or symbols.

[0141] The processor (820) extracts the files associated with the malicious activity from the dex file with the dex extension and the res directory.

[0142] The Dex file of the malicious app is encrypted, and the processor (820) finds a service to decrypt the Dex file through the Android Manifest file, and if the key value is specified as a string value, decrypts it using the string value, or obtains source code by decompiling the unencrypted Dex file included in the installation file of the malicious app, and obtains the decryption key value of the encrypted Dex file by tracing the variables of the decryption source in the obtained source code.

[0143] When the processor (820) finds a nested APK file from the res directory uncompressed from the APK file of the malicious app, it decrypts the encrypted dex file contained in the nested APK file in accordance with the description in paragraph 16.

[0145] Meanwhile, the present invention described above can be implemented as computer-readable code on a computer-readable recording medium. A computer-readable recording medium includes all types of recording devices in which data that can be read by a computer system is stored.

[0146] Examples of computer-readable recording media include ROM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. Additionally, computer-readable recording media may be distributed across networked computer systems, allowing computer-readable code to be stored and executed in a distributed manner. Furthermore, functional programs, codes, and code segments for implementing the present invention can be easily inferred by programmers in the art to which the present invention belongs.

[0147] In addition, the present invention described above can be coded as a program and installed on a mobile phone, and the programmed malicious app monitoring method of the present invention described above can also be implemented on a mobile phone.

[0148] The present invention has been described above with reference to various embodiments. Those skilled in the art will understand that the present invention may be implemented in modified forms without departing from the essential characteristics of the invention. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the invention is defined by the claims, not by the foregoing description, and all variations within the scope of the claims should be interpreted as being included in the invention.

Claims

Claim 1 A method for obtaining features for inferring a malicious app, comprising: a first step of determining whether an app is malicious based on an installation file (APK) of an app installed on a mobile phone having Android as the operating system; a second step of extracting files related to malicious activity from the installation file of the app if it is determined to be malicious in the first step; and a third step of extracting features related to malicious activity from the files extracted in the second step, wherein the source code related to malicious activity is identified by string-based search using regular expressions, and the identified source code is extracted in the form of an Abstract Syntax Tree (AST) and used as a feature. Claim 2 A method for obtaining a feature for inferring a malicious app, wherein in the first step, the determination of whether the app is malicious is based on the filename of a dex file with the extension dex included in the installation file. Claim 3 A method for obtaining a feature for inferring a malicious app in the first step, wherein the determination of whether the app is malicious is based on the fact that the filename of the Dex file is named in a form different from the filename of the Dex file included in the installation file of a normal app. Claim 4 A method for obtaining a feature for inferring a malicious app in the first step, wherein the determination of whether the app is malicious is based on the fact that the filename of the Dex file includes the filename of the Dex file included in the installation file of a normal app, but additionally includes additional characters or symbols. Claim 5 A method for obtaining features for inferring a malicious app, wherein, in the second step, the files associated with the malicious activity are a dex file with the extension dex and a res directory. Claim 6 A method for obtaining a feature for inferring a malicious app, wherein the DeX file of the malicious app is encrypted, a service that decrypts the DeX file through an Android Manifest file is found, and if the key value is specified as a string value, the service that decrypts using the string value. Claim 7 A method for obtaining a feature for inferring a malicious app according to claim 1, wherein the DeX file of the malicious app is encrypted, the unencrypted DeX file included in the installation file of the malicious app is decompiled to obtain source code, and the decryption key value of the encrypted DeX file is obtained by tracing the variables of the decryption source in the obtained source code. Claim 8 A method for obtaining a feature for inferring a malicious app, wherein, in claim 6 or 7, if a nested APK file is found in a res directory uncompressed from the APK file of the malicious app, the method described in claim 7 decrypts an encrypted dex file included in the nested APK file. Claim 9 In claim 1, the malicious activity is a method for obtaining features for inference of a malicious app, which is related to permissions not requested by a normal app. Claim 10 A method for obtaining a feature for inferring a malicious app according to claim 1, wherein the feature is a combination of at least two of package name, application name, file size, manifest information, URL information, encryption information, signature information, source code related to malicious activity, library file, SDK version of nested APK, and C2 information. Claim 11 A computer-readable non-transient recording medium having a program recorded thereon that enables a computer to execute a method for obtaining features for inferring a malicious app described in paragraph 1. Claim 12 A computing device comprising a memory for storing a program coded in a computer-readable language for the method described in claim 1, and a processor for calling said program to perform mathematical operations, wherein the processor determines whether an app is malicious based on an installation file (APK) of an app installed on a mobile phone having Android as an operating system, and if, in said determination, the app is determined to be malicious, extracts files related to malicious activity from the installation file of said app, and extracts features related to malicious activity from said extracted files. Claim 13 In claim 12, the processor determines whether an app is malicious based on the filename of a dex file with the extension dex included in the installation file, wherein the filename of the dex file includes the filename of a dex file included in the installation file of a normal app, but is named in a form that additionally includes characters or symbols. Claim 14 In paragraph 13, the processor is a computing device in which files related to the malicious activity are extracted from within the res directory and an dex file with the extension dex. Claim 15 In paragraph 13, the DeX file of the malicious app is encrypted, and the processor finds a service that decrypts the DeX file through an Android Manifest file, and if the key value is specified as a string value, decrypts using the string value, a computing device. Claim 16 In paragraph 13, the Dex file of the malicious app is encrypted, and the processor obtains source code by decompiling an unencrypted Dex file included in the installation file of the malicious app, and obtains a decryption key value of the encrypted Dex file by tracing a variable of a decryption source in the obtained source code. Claim 17 A computing device according to claim 15 or 16, wherein the processor decrypts an encrypted dex file contained in the nested APK file in accordance with the description in claim 16 when a nested APK file is found in a res directory uncompressed from the APK file of the malicious app. Claim 18 In Clause 13, the above malicious activity is a computing device that is related to permissions not requested by a normal app. Claim 19 In paragraph 13, the above-mentioned feature is a combination of at least two of the following: package name, application name, file size, manifest information, URL information, encryption information, signature information, source code related to malicious activity, library file, SDK version of nested APK, and C2 information.

Images