A Case Study of Device Modification:

In June, I received a well-reviewed commercial device modification case that could only run on specified phones and ROMs, claiming that major apps could not detect it and that it was a modification framework that did not require root access.

I only had a Nexus 6P on hand, so I installed it on the phone and ran it, but it crashed instantly without any crash logs. However, this log gave it away:

This clearly indicates a call to System.exit(0) for an intentional exit.

Static Analysis

From the image, it can be seen that the dex has been obfuscated and the strings have been encrypted.

Decrypting Strings and Repackaging

String decryption is often in a fixed smali format:

const-string vX, "Encrypted String"
invoke-static {vX}, Lcom/test/decString(Ljava/lang/String;)Ljava/lang/String;
move-result-object vX

This case is no exception, so I wrote a script to match the above code and then call the decryption code (extracted from the source code) to decrypt the string.Then replace the encrypted string with the decrypted string, delete the two instructions below const-string vX, "Decrypted String", and repackage it (if anyone has a better solution, please let me know).Of course, I also added a hook for system signature verification:

private void hook(Context context) {
    try {
        DataInputStream is = new DataInputStream(new ByteArrayInputStream(Base64.decode(oriSign, 0)));
        byte[][] sign2 = new byte[(is.read() & 255)][];
        for (int i = 0; i < sign2.length; i++) {
            sign2[i] = new byte[is.readInt()];
            is.readFully(sign2[i]);
        }
        Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
        Object currentActivityThread = activityThreadClass.getDeclaredMethod("currentActivityThread", new Class[0]).invoke(null, new Object[0]);
        Field sPackageManagerField = activityThreadClass.getDeclaredField("sPackageManager");
        sPackageManagerField.setAccessible(true);
        Object sPackageManager = sPackageManagerField.get(currentActivityThread);
        Class<?> iPackageManagerInterface = Class.forName("android.content.pm.IPackageManager");
        this.base = sPackageManager;
        this.sign = sign2;
        this.appPkgName = context.getPackageName();
        Object proxy = Proxy.newProxyInstance(iPackageManagerInterface.getClassLoader(), new Class[]{iPackageManagerInterface}, this);
        sPackageManagerField.set(currentActivityThread, proxy);
        PackageManager pm = context.getPackageManager();
        Field mPmField = pm.getClass().getDeclaredField("mPM");
        mPmField.setAccessible(true);
        mPmField.set(pm, proxy);
        Log.i(TAG,"PmsHook success.");
    } catch (Exception e) {
        Log.e(TAG,"PmsHook failed.");
        e.printStackTrace();
    }
}

This is the effect after deobfuscating with jadx and decrypting the strings, making the code much more readable:

Bypassing Authorization, Signature Verification, System Authentication, and Login

This is a brutal process, and there are many checks in this case, so there are also string encryptions and verifications.Of course, this is not the focus of this article, so I won’t elaborate on the specific brutal process.Finally, the true face of the new device appeared:

Principles of New Device

Ultimate Technique One: Root-Free Hook

This case compiles the Xposed source code and modifies the feature codes, changing the names related to Xposed to system names such as camera, email, and phone.Then it hooks the stack information, filtering out the stack of the hook framework.Then the renamed Xposed is integrated into the LineageOS source code.Finally, by writing a Hook module with the modified XposedBridge.jar, a root-free integrated hook framework is achieved.This really allows for unrestricted access.

Ultimate Technique Two: Comprehensive Hook of Android Device Information Interfaces

This is self-explanatory; it hooks all functions related to obtaining device information at the Java layer, including I/O redirection for file reading. Attached is a list of the hooked interfaces I compiled.

Ultimate Technique Three: Faking Real User Activity

Major manufacturers are implementing risk control, including IP profiling, device profiling, user profiling, phone number profiling…, devices without user behavior are inevitably considered abnormal users and will not pass risk control.By hooking relevant interfaces, each new device fills in different SMS, call logs, contacts, photos, startup times, and randomizes the values of surrounding Bluetooth, Wi-Fi, and sensors.

Ultimate Technique Four: Consistent Base Station, GPS, and IP Location

Currently, location information can be obtained mainly through base stations, GPS, and IP locations, three dimensions.Device modification must generate different IPs through proxy connections (VPN), so it is necessary to ensure that the base station and GPS locations are not significantly different from the IP location, making each new device appear at a new geographical location.

Ultimate Technique Five: SysPropertyHook

Xposed is only a Java layer hook; most device fingerprint SDKs now obtain data either natively or through both native and Java layers for comparison.Here, we hook SystemProperties.set, Settings.System.put, Settings.Secure.put, Settings.Global.put.This ensures that after modification, the /system/build.prop, System.xml, Secure.xml, Global.xml files are genuinely changed, ensuring that the native layer retrieves the same information as the Java layer when using getProp.

New Device Process

Preparing New Device Information PhoneInfo

By reading the device information set from the /assets directory, a random device information is generated, and the baseband and GPS locations are obtained through the current IP, along with user information.All this information is written into phoneInfo.json on the SD card.

Completing the Hook

By reading the device information from phoneInfo.json on the SD card, the hook is completed, and the new device is ready.Due to copyright reasons, the case will not be provided.

– End –

Kanxue ID:seandong

https://bbs.pediy.com/user-766159.htm

This article is original by Kanxue Forum seandong Please indicate the source from Kanxue Community when reprinting.

Popular Reviews from Previous Issues

1. Windows Kernel Exploit Kernel Vulnerability Study (3) – Arbitrary Memory Overwrite Vulnerability

2. Windows Kernel Exploit Kernel Vulnerability Study (2) – Kernel Stack Overflow

3. Writing Windows Kernel Shellcode

4. Static Analysis Challenge Writeup for Beginners

﹀

﹀

﹀

Official Account ID: ikanxue

Official Weibo: Kanxue Security

Business Cooperation: [email protected]

↙Click “Read the original text” below for more valuable content.