Method and system for protecting mobile application source code against reverse engineering

Abstract

The present technical solution relates to the field of computing, and more particularly to a method and system for protecting mobile application source code against reverse engineering. The technical result is that of more effectively protecting code against reverse engineering. The claimed technical result is achieved using a processor-implemented method for protecting mobile application source code against reverse engineering, comprising the steps of: obtaining the source code of an application; performing automated analysis of the code and, in the process, identifying at least one code area responsible for: authentication, authorization and management of application sessions; data input into the application; interaction with a file system and an operating system; interaction with internal resources; storage of secrets and accessing of a keystore; determining the criticality level of the identified code areas; determining a method for obfuscating the code areas according to their criticality level, wherein obfuscation methods are selected from the group of: data obfuscation, structure obfuscation, control flow obfuscation, or a combination thereof; obfuscating the identified code areas; and generating obfuscated application source code.

Description

A METHOD AND SYSTEM FOR PROTECTING THE SOFTWARE CODE OF MOBILE APPLICATIONS FROM REVERSE ENGINEERING AREA OF TECHNOLOGY

[0001] This technical solution relates to the field of computer technology, namely to a method and system for protecting the program code of mobile applications from reverse engineering. LEVEL OF TECHNOLOGY

[0002] Mobile applications (hereinafter referred to as MA) on the Android platform are subject to reverse engineering (hereinafter referred to as RE) by both attackers and MA developers from competing companies. RE refers to a broad range of application manipulations, including analyzing and studying the mobile application to gain unauthorized access to information about its internal structure and functionality, as well as exposing sections of code for further study, reconstruction, or modification. The ultimate goal of this research may be to gain a competitive advantage, optimize and improve third-party MA, bypass the security mechanisms of the analyzed application, gain access to stored and processed data within the MA, or create malware.

[0003] Traditional and widely used methods for protecting mobile apps include code obfuscation, data encryption, data channel protection, integrity control during app launch, and other organizational and technical measures. However, most of these approaches are well-studied, and various studies have resulted in the development and public availability of a large number of automated RI tools to speed up the overall analysis process. Therefore, widely used protection methods cannot provide the necessary and sufficient level of mobile app security in the current environment.

[0004] In addition to the aforementioned security issues with mobile apps themselves, there are vulnerabilities within the Android OS platform. Every month, Google publishes a security bulletin (available at: https: / / source.android.com / docs / security / bulletin?hl=en), which typically lists the numerous relevant CVEs discovered over the previous month, broken down by period. In other words, the security of the mobile app, including the data it processes, will depend significantly on the security of the underlying operating system; otherwise, if a high-level vulnerability is detected, Root access can be obtained at the OS level, and the entire application can be compromised for further, more detailed analysis. Operating system security will be the attacker's first line of defense.

[0005] Mobile applications for the Android OS are Java applications translated into Java bytecode, which is executed by the Java Virtual Machine (JVM). Java bytecode itself is transparent enough to be examined and easily recovered, even down to the source code. Developers strive to hide the code as cleverly as possible, using various techniques, such as obfuscation, compilation to native code, and encryption. However, even after obfuscation and obfuscation, Java applications have low protection against malicious code, as most implemented protection methods can be overcome by an experienced reverse engineer, and the JVM remains under the complete control of a user with superuser (root) privileges. This is what attackers do when installing analysis applications on already compromised phone devices with root access. Currently, the most effective protection for Java applications comes down to the following paradigms, which can be combined with each other: - Embedding backend logic (e.g. validation of licenses or specific tokens on a remote server); - Implementation of complex cryptographic algorithms, which will significantly increase the cost and time spent on RI; - Transition from protecting algorithms to protecting critical data, such as logins / passwords / keys / tokens for API calls, data stored and processed in the application, and other user / technical data with high significance.

[0006] Android-based mobile devices in general, and banking apps in particular, that lack similar security features, are highly unlikely to adequately counteract malicious attacks and dynamic security analysis. As mentioned above regarding the regular vulnerabilities of the Android OS platform, the effectiveness of built-in security features (antivirus software, emulator and root device detection, etc.) can easily be offset by a new high- or critical-level vulnerability.

[0007] A solution is known for encrypting software when it is transferred to the execution environment (US 7841009 B1b 11 / 23 / 2010), which involves comparing data for the secure delivery and installation of applications in the destination software environment.

[0008] This approach does not exclude the possibility of software leakage and its subsequent reverse engineering to create malware, which reduces the effectiveness of protection of original software applications. ESSENCE OF THE INVENTION

[0009] The present invention allows to solve the technical problem of effectively protecting application code from reverse engineering.

[0010] The technical result is to increase the efficiency of code protection against reverse engineering.

[0011] The claimed technical result is achieved by a method for protecting the program code of mobile applications from reverse engineering, performed using a processor and comprising the following stages: obtaining the source code of the application; performing an automated code analysis, during which at least one area of ​​the code is identified that is responsible for: authentication, authorization and session management of the application; entering data into the application; interaction with the file system and OS; interaction with internal resources; storing secrets, accessing the key storage; determining the criticality level of the identified code areas; determining an obfuscation method for the code areas depending on the criticality level, wherein the obfuscation methods are selected from the group: data obfuscation, structure obfuscation, control flow obfuscation or a combination thereof; obfuscation of the identified code areas is performed; and the obfuscated source code of the application is generated.

[0012] In one particular embodiment of the method, the data entry area of ​​the application is responsible for interaction with the backend, registering a new account, or recovering a password.

[0013] In another particular embodiment of the method, data obfuscation includes a set of transformations that ensure the concealment of the values ​​and structure of the application data.

[0014] In another particular embodiment of the method, the set of transformations includes at least one of: Data aggregation, which changes structures; data storage and encoding, which changes the values ​​of variables; data reordering, which changes the order in which data is stored and uses dynamic calculations to determine the desired array element.

[0015] In another particular embodiment of the method, structure obfuscation includes a set of techniques for changing the structure of the application by modifying variable names, changing the code formatting, and removing comments and debugging information.

[0016] In another particular embodiment of the method, control flow obfuscation comprises a set of transformations that ensure the concealment of branching and the sequence of operations in the source code.

[0017] In another particular embodiment of the method, when obfuscating a flow, a transformation is performed in the part of the control flow calculation, in which the sequence of code execution is hidden and dummy code is added.

[0018] In another particular embodiment of the method, the dummy code contains blocks with non-executable code and implicit predicates.

[0019] In another particular embodiment of the method, the predicate contains a complex condition that is resolved to true-false upon the requirement of passing the block.

[0020] In another particular embodiment of the method, when obfuscating the control flow, a change in the order of the control flow is performed, which changes the order of execution of operations.

[0021] In another particular embodiment of the method, when obfuscating the control flow, a transformation is performed that changes the execution structure of methods by combining them into a common method using a selector, or by cloning methods.

[0022] In another particular embodiment of the method, when obfuscating the control flow, the control flow is ordered, which involves changing the order of independent expressions and the directions of traversal in loops.

[0023] In another particular embodiment of the method, when obfuscating the control flow, flattening of the control flow is performed using a dispatcher and block numbering.

[0024] In another particular embodiment of the method, when flattening the control flow, linear sections of code are assigned a unique number for their subsequent selection for execution by the dispatcher.

[0025] The claimed invention is also implemented using a system for protecting software code of mobile applications from reverse engineering, containing at least one processor and at least one memory containing machine-readable instructions that, when executed by at least one processor, implement the above method. BRIEF DESCRIPTION OF DRAWINGS

[0026] Fig. 1 illustrates a block diagram of the claimed method.

[0027] Fig. 2 illustrates the general appearance of the computing device. IMPLEMENTATION OF THE INVENTION

[0028] Fig. 1 shows a flowchart of the claimed method (100) for protecting applications from reverse engineering. In the first step (101), the application's source code is obtained, which is then analyzed for the presence of code areas in step (102) for processing.

[0029] Classification and slicing of code at step (102) can be performed using static application security testing (SAST) tools. SAST (Static Application Security Testing) tools analyze application / program code or parts of it without actually running it in an executable environment. This technology is also known as white-box testing, and unlike dynamic testing, SAST verifies the entire executable code. Modern SAST tools support various programming languages, allowing for scanning that takes into account their specific features, ensuring maximum accuracy and efficiency.

[0030] SAST is easily integrated into a development pipeline or IDE (integrated development environment), making it fully automated and independent of operator expertise and experience. Source code analysis also includes feedback from the scanner on the exact location of the target block, class, method, or function within the code. Depending on the application tasks and the emphasis of SAST solutions, target events (fragments) can include vulnerabilities, confidential, or critical information. One of the key factors determining the effectiveness of target event detection is a regularly updated rule base with flexible customization and expansion capabilities.

[0031] Next, the SAST solution is used to classify the identified source code areas. An example of area classification is shown in Table 1. Table 1. Classification of Code Areas by Criticality

[0031] The following are examples of source code text for each of the areas.

[0032] Authentication, authorization, and session management / / Authorization by Bearer token OkHttpClient client = new OkHttpClient.Builder().addInterceptor(chain -> { Request newRequest = chain.request().newBuilder() .addHeader("Authorization", "Bearer " + token) ,build(); return chain.proceed(newRequest); }).build(); Retrofit retrofit = new Retrofit.Builder() .client(client) .baseUrl(url) . addConverterF actory(GsonConverterF actory . createQ) ,build(); / / Sessions configurator protected void configure(HttpSecurity http) throws Exception { http .cors().and() .csrf().and() ,httpBasic().and() . authorizeRequests() .anyRequest() .authenticated() .and() .logoutO .logoutRequestMatcher(new AntPathRequestMatcher(7api / logout")) .logoutSuccessHandler(new HttpStatusRetumingLogoutSuccessHandler(HttpStatus.OK)) .invalidateHttpSession(true) . clear Authentication(true) . addLogoutHandler(new HeaderW riterLogoutHandler(new ClearSiteDataHeaderWriter(Directive.ALL))) .permitAll() .and() .sessionManagementQ ,maximumSessions(3) .maxSessionsPreventsLogin(true) ,sessionRegistry(sessionRegistry).and() .sessionAuthenticationStrategy(concurrentSessionStrategy) .sessionAuthenticationFailureHandler(securityErrorHandler);

[0033] Entering data into the application (interacting with the backend, registering a new account, or recovering a password) / / Client auth data exchange to token fun performTokenRequest( authService: Authorizationservice, tokenRequest: TokenRequest, onComplete: () -> Unit, onError: () -> Unit ) { authService.performTokenRequest(tokenRequest, getClientAuthentication()) { response, ex -> when { response != null -> { TokenStorage. accessToken = response. accessToken.orEmpty() TokenStorage.refreshToken = response.refreshToken onComplete() else -> onErrorQ

[0034] Взаимодействие с файловой системой и ОС / / Read from system folder BufferedReader buffered_reader=null; try { buffered_reader = new BufferedReader(new FileReader( sys / kemel / abb- chargalg / eoc_status " )) ; String line; while ((line = buffered_reader.readLine()) != null) { System.out.println(line); } catch (lOException e) { e .printStackT race() ; finally { try if (buffered_reader != null) buffered_reader.close(); catch (lOException ex) ex .printStackTrace() ;

[0035] Взаимодействие с внутренними ресурсами / / Read / write from android shared prefs SharedPreferences settings = PreferenceManager.getDefaultSharedPreferences(this); SharedPreferences.Editor editor = settings. edit(); editor .putString( " language " , language) ; editor. commit();

[0036] Хранение секретов, обращения в KeyStore / / Android keystore try { KeyStore keyStore = KeyStore. get!nstance("AndroidKeyStore"); keyStore. load(null) ; String alias = "key3"; int nBefore = keyStore.sizeQ; if (!keyStore.containsAlias(alias)) { Calendar notBefore = Calendar.getlnstance(); Calendar notAfter = Calendar.getlnstance(); notAfter.add(Calendar.YEAR, 1); KeyPairGeneratorSpec spec = new KeyPairGeneratorSpec.Builder(this) .setAlias(alias) .setKeyTypef'RSA") ,setKeySize(2048) ,setSubject(new X500Principal("CN=test")) .setS erialNumber(BigInteger . ONE) . setStartDate(notBefore . getT ime()) . setEndDate(not After . getT ime()) .build(); KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA", "AndroidKeyStore"); generator, initialize(spec) ; KeyPair keyPair = generator.generateKeyPairQ; int nAfter = keyStore. size(); Log.v(TAG, "Before = " + nBefore + " After = " + nAfter); KeyStore.PrivateKeyEntry privateKeyEntry = (KeyStore.PrivateKeyEntry)keyStore.getEntry(alias, null); RSAPrivateKey privateKey = (RSAPrivateKey) privateKeyEntry. getPrivateKey(); RS APublicKey publicKey = (RSAPublicKey) privateKeyEntry.getCertificate().getPublicKey(); String plainText = "This text is supposed to be a secret!"; String dataDirectory = getApplication!nfo().dataDir; String filesDirectory = getFilesDir().getAbsolutePath(); String encryptedDataFilePath = filesDirectory + File, separator + "keep_yer_secrets_here"; Cipher inCipher = Cipher.getInstance("RSA / ECB / PKCSlPadding", "AndroidOpenSSL"); inCipher.init(Cipher.ENCRYPT_MODE, publicKey); Cipher outCipher = Cipher.getInstance("RSA / ECB / PKCSl Padding", "AndroidOpenSSL"); outCipher.init(Cipher.DECRYPT_MODE, privateKey); CipherOutputStream cipherOutputStream = new CipherOutputStream( new FileOutputStream(encryptedDataFilePath), inCipher); cipherOutputStream.write(plainText.getBytes("UTF-8")); cipherOutputStream.close(); CipherlnputStream cipherlnputStream = new CipherInputStream(new FilelnputStream(encryptedDataFilePath), outCipher); byte [] roundTrippedBytes = new byte

[1000] ;

[0037] Next, at step (103), the criticality of each code area is analyzed, assigning each area its own criticality value. An example of the area classification is shown in Table 2. Table 2. Criticality of code areas

[0038] Next, at step (104), obfuscation methods are determined for the identified code areas, taking into account their criticality. Differentiated obfuscation using the techniques described above is applied to different areas of the source code. This approach maximizes the protection of the most valuable (critical) areas of the source code while preventing and avoiding excessive obfuscation.

[0039] Table 3 below shows the obfuscation techniques used depending on the criticality of the source code:

[0040] Based on the results of this stage, obfuscation parameters (techniques) are determined, the implementation of which is also carried out further in an automated mode.

[0041] Let's consider the methods of code obfuscation used.

[0042] Data obfuscation is a set of transformations that ensures hiding the values ​​and structure of data used by an application in its work. The implementation involves several categories: - Data aggregation – changes related to the merging / unmerging of structures (constants, classes, arrays). Constants can be combined into aggregated arrays or other complex types, while obfuscated arrays are in turn split into several parts or merged with other arrays. Data storage and encoding is a set of transformations that include changes to variable values. Constant values ​​are replaced with dynamically calculated ones. String constants are encrypted, and encryption and decryption functions are added. Integer constants are broken down into terms. - Data reordering - changing the order in which data is stored and using dynamic calculations to determine the desired array element

[0043] Structure obfuscation is a set of techniques for changing the structure of a program by modifying variable names, changing code formatting, and removing comments and debugging information.

[0044] Control flow obfuscation is a technique used to hide branches and sequences of operations in source code. This set of methods includes the following: Control flow computation is a category of transformations that hides the code execution sequence and adds "junk" code (which does not affect program execution). The original code is interspersed with blocks of unreachable code using implicit predicates that, depending on conditions, can execute or skip the next block. The predicate contains a complex condition that evaluates to true or false upon traversal of the block; - Changing the order of control flow - obfuscations that change the order of operations, for example, bypassing cycles from the last element; - Control flow aggregation - transformations that change the execution structure of methods by combining them into a common method using a selector, or cloning methods to complicate analysis; - Control flow ordering - changing the order of independent expressions and directions of traversal in cycles; - Control flow flattening is a control flow management technique using a dispatcher and block numbering. Instead of sequentially executing basic blocks (linear sections of code), each block is assigned a specific number. The dispatcher determines block selection based on its number. The number for the next block is calculated as the current block executes.

[0045] Preventive obfuscation is a set of techniques that counter automated analysis tools such as debuggers, decompilers, and so on. Its primary focus is exploiting the limitations of such tools. This method includes the following approaches: - Anti-debugging - execution of special code to detect the presence of a connected debugger. If detected, the program terminates. - Anti-decompilation - the introduction of complex structures that can be recursive and consume the computing resources of the decompiler, or use implicit sequences or functions that lead to decompilation errors - Reflection is a dynamic code loading technique that allows hidden functions to be run.

[0046] The invention is not limited to this set of obfuscation techniques and serves as an example and description of the logic of a particular case of countering reverse engineering of a banking mobile application.

[0047] The obfuscation methods listed in Table 3 are applied either individually or in combination at step (105), depending on the criticality of a particular code region. Obfuscation techniques are automatically applied by the aforementioned SAST solution, which is configured to apply obfuscation techniques when relevant source code regions are identified.

[0048] The result of method (100) is obfuscated source code protected from reverse engineering. This approach significantly increases the complexity and labor intensity of reverse engineering, as it precludes the use of existing automated reverse engineering tools and requires specialized knowledge and skills from a dedicated reverse engineering specialist. However, the applied application protection does not significantly impact the mobile app's performance or user experience.

[0049] The above approach can be used both in the banking sector and beyond, as protecting mobile applications from reverse engineering is a pressing concern for owners and developers of all applications seeking to protect sensitive mobile application information from attackers and third-party application developers.

[0050] Fig. 2 shows a general view of a computing system implemented on the basis of a computing device (200) and ensuring the implementation of the claimed method (100). In the general case, the computing device (200) comprises one or more processors (201) connected by a common information exchange bus, memory means such as RAM (202) and ROM (203), input / output interfaces (204), input / output devices (205) and a device for network interaction (206).

[0051] The processor (201) (or several processors, multi-core processor) can be selected from a range of devices that are widely used today, such as those from Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™, etc. The processor also includes a graphics processor, such as an NVIDIA or ATI GPU, which is also suitable for full or partial implementation of the method (100). In this case, the memory means may be the available memory capacity of a graphics card or graphics processor.

[0052] RAM (202) is random access memory (RAM) and is designed to store machine-readable instructions executed by the processor (201) to perform the necessary logical data processing operations. RAM (202) typically contains executable instructions from the operating system and corresponding software components (applications, software modules, etc.).

[0053] ROM (203) is one or more permanent data storage devices, such as a hard disk drive (HDD), a solid-state drive (SSD), flash memory (EEPROM, NAND, etc.), optical storage media (CD-R / RW, DVD-R / RW, BlueRay Disc, MD), etc.

[0054] To organize the operation of the device components (200) and to organize the operation of external connected devices, various types of I / O interfaces (204) are used. The choice of the appropriate interfaces depends on the specific design of the computing device, which may include, but are not limited to: PCI, AGP, PS / 2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS / Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc.

[0055] To ensure user interaction with the computing device (200), various I / O information means (205) are used, for example, a keyboard, display (monitor), touch display, touchpad, joystick, mouse, light pen, stylus, touch panel, trackball, speakers, microphone, augmented reality means, optical sensors, tablet, light indicators, projector, camera, biometric identification means (retina scanner, fingerprint scanner, voice recognition module), etc.

[0056] The network interaction means (206) ensures the transmission of data by the device (200) via an internal or external computer network, for example, the Intranet, the Internet, a LAN, etc. One or more means (206) may be, but are not limited to: an Ethernet card, a GSM modem, a GPRS modem, an LTE modem, a 5G modem, a satellite communication module, an NFC module, a Bluetooth and / or BLE module, a Wi-Fi module, etc.

[0057] Additionally, satellite navigation tools included in the device (200) can also be used, for example, GPS, GLONASS, BeiDou, Galileo.

[0058] The submitted application materials disclose preferred examples of the implementation of the technical solution and should not be interpreted as limiting other, particular examples of its implementation that do not go beyond the scope of the requested legal protections that are obvious to specialists in the relevant technical field.

Claims

FORMULA 1. A method for protecting the software code of mobile applications from reverse engineering, performed using a processor and comprising the following stages: obtaining the source code of the application; performing an automated analysis of the code, during which at least one area of ​​the code is identified that is responsible for: authentication, authorization and session management of the application; entering data into the application; interaction with the file system and OS; interaction with internal resources; storing secrets, accessing the key storage; determining the criticality of the identified areas of the code; determining an obfuscation method for the code areas depending on the criticality thereof, wherein the obfuscation methods are selected from the group: data obfuscation, structure obfuscation, control flow obfuscation or a combination thereof; obfuscating the identified areas of the code; and generating the obfuscated source code of the application.

2. The method according to paragraph 1, in which the data entry area in the application is responsible for interaction with the backend, registration of a new account or password recovery.

3. The method according to claim 1, wherein the data obfuscation includes a set of transformations that ensure the concealment of the values ​​and structure of the application data.

4. The method according to paragraph 3, in which the set of transformations includes at least one of: data aggregation, performing a change in structures; data storage and encoding, performing changes in the values ​​of variables; data reordering, performing changes in the order of data storage and the use of dynamic calculations to determine the desired element of the array.

5. The method according to claim 1, wherein the obfuscation of the structure includes a set of techniques for changing the structure of the application by modifying the names of variables, changing the formatting of the code, and also removing comments and debugging information.

6. The method according to claim 1, wherein the control flow obfuscation comprises a set of transformations that ensure the hiding of branching and the sequence of operations in the source code.

7. The method according to claim 6, wherein, when obfuscating a flow, a transformation is performed in the control flow calculation part, in which the sequence of code execution is hidden and dummy code is added.

8. The method according to claim 7, wherein the dummy code contains blocks with non-executable code and implicit predicates.

9. The method according to claim 8, wherein the predicate contains a complex condition that is resolved to true-false upon the requirement of passing the block.

10. The method according to claim 6, wherein, when obfuscating the control flow, a change in the order of the control flow is performed, which changes the order of execution of operations.

11. The method according to claim 6, wherein during obfuscation of the control flow, a transformation is performed that changes the execution structure of methods by combining them into a common method using a selector, or by cloning methods.

12. The method according to claim 6, wherein, during obfuscation of the control flow, the control flow is ordered, which involves changing the order of independent expressions and directions of traversal in cycles.

13. The method according to claim 6, wherein, when obfuscating the control flow, the control flow is flattened using a dispatcher and block numbering.

14. The method according to claim 13, in which, when flattening the control flow, the linear sections of the code are assigned a unique number for their subsequent selection for execution by the dispatcher.

15. A system for protecting software code of mobile applications from reverse engineering, comprising at least one processor and at least one memory containing machine-readable instructions that, when executed by at least one processor, implement the method according to any one of paragraphs 1-14.

Images