[Verizon LG G3] IllegalArgument:
Hi all. First, apologies if this is the wrong place for this sort of post. It's mainly just a collection of my notes on the Verizon LG G3 running stock software update VS98510B, so there are a lot of different topics touched upon. I'm usually pretty shy around forums, but I figured something I've found might be useful to someone else, so I finally decided to post here. Anyway, here's what I've found.

Autorun Installer

This really annoyed me for a while when I first got the phone. Every time I'd try connecting it to my computer, it'd enter some sort of installer mode for LG/Verizon drivers. It would stay in this mode for about 30 seconds unless I manually put it back into ADB mode. After a good bit of digging around, I found out how to disable it without root or any special permissions. Open the stock dialer app, then enter the code "##3328873" and press send. It'll prompt for a service code, which is (of course) "000000". While the Verizon G3 appears to be missing a large chunk of the hidden menus, this section still seems to work. One of the options is a checkbox for "Tool Launcher enable" - uncheck it to disable the Verizon autorun installer.

Sideloading in Recovery Mode

I was curious how IORoot worked, so I started taking it apart. Basically, on the G3, it just uses a .zip sideloaded in recovery mode to copy over the su and related binaries. There's a decent bit of documentation out there on how to create your own .zip for sideloading, but I found one catch - the .zip needs to be signed with the proper key, or recovery will reject it. It turns out that this key is located at "./bootable/recovery/testdata/testkey" in the AOSP project. I forget the exact command for signing the .zip, but using this key, you can create your own sideload applications. Edify provides a nice way to script your application; I used it to create a sideload application to replace the HotspotProvision apk with a slightly modified version that skips the billing checks. Doing so does not require root access, as the sideloaded application appears to run as root by default. Replacing "HotspotProvision.apk" also does not trigger the root detector. However, I also made my own sideload .zip to copy over the su binary I compiled from AOSP - as soon as I booted the phone, the software status indicator changed to modified. I have some more information on that below. If anyone wants either of these sideload applications, I can upload them somewhere with their source, just let me know.

Ramdisk Compression

The boot, recovery, laf, and factory partitions are all mostly in standard format and can be split into the kernel and ramdisk parts with existing tools. However, most tools seem to expect the ramdisk to be compressed using gzip. Since it's not, they'll fail to extract the cpio archive from it. The G3 ramdisk is compressed using LZ4 instead. Once decompressed using the standard LZ4 utility, it has the same structure as a normal boot ramdisk - the cpio archive can be extracted to view the boot filesystem. I haven't really looked into it, but I believe the boot images all have a device tree binary appended after the ramdisk as well.

AT Commands

When looking into the boot process, I stumbled upon the AT command framework for the G3, which proved to be rather interesting. When connected to my computer in ADB mode, the phone exposes two serial ports. One of these ports looks like it's supposed to accept plain-text AT commands, but it also has been rather buggy in registering the end of a command for me. The other port accepts commands in some sort of binary format that I have not taken apart yet. If you want to send AT commands to the phone from ADB shell, write them to "/dev/smd0" and read the response from there. Sometimes, the response is not put on the device for some reason, but instead just printed to the logs under the tag "Atd"; just use "logcat Atd:V" to view them. The requests seem to be handled by "/system/bin/atd", which largely uses "/system/lib/libatd_common.so" to work. Looking through the disassembly showed some interesting things, included what looked like a test command that involved the bootloader unlock status, though I haven't figured out exactly how it works yet. A lot of the commands began with "AT%", which I think is the vendor specific prefix for AT commands typically. For some reason, I couldn't get any of these commands to work, even though some of the standard commands worked fine. One particularly interesting function (to me) was one that claimed to be able to write the software bootloader, SBL1. The function was called "store_sbl1_image"; there are some other functions that affect sbl1 as well. There are also functions for qfuses/QFPROM and other things that may be of interest to us. A lot of these functions access the misc partition through "/system/lib/liblgftmitem.so", so that may be a partition worth looking into.

Volume Key Booting

Entering the dialer command "##228378" and pressing send brings up a menu that has an option called "Device Test". Choosing this option prompts you that the phone will reboot; if allowed, it will reboot into MiniOS mode, which is stored in the "factory" partition ("/dev/block/mmcblk0p40"). This mode allows you to run a number of device tests, though many options are disabled somehow. One interesting thing I've observed is that, if the phone is shut down from MiniOS mode, then turned on by holding the volume down and power buttons simultaneously (possibly while plugged into a computer, I forget if this is necessary), the phone enters a pseudo-recovery mode that vaguely resembles real recovery mode, but is actually implemented after boot. Another volume key command is to hold volume up while powering on and connected to a computer by USB (the USB connection is required). This boots into factory download mode from the "laf" partition("/dev/block/mmcblk0p33"). The only way I've found to exit this mode is to remove the battery from the case. One final note is that while booting into normal mode, but having done so by holding volume down and the power button, the bootloader logs a message that it is going to enter fastboot mode. However, it does not and just boots normally instead. It seems that fastboot can only be activated if aboot fails to boot normally. I've read of people accomplishing this by messing up the "laf" partition and then booting into download mode, but I've not tried it myself.

Root Checker ("/system/bin/rctd")

After already setting my system to the "modified" status, I looked into the root checker executable at "/system/bin/rctd". A quick disassembly showed almost no strings in the binary. This is because they are all obfuscated. To load the strings, as series of instructions store individual characters into the stack at the proper offsets, eventually forming all of the strings needed by the program. Because I don't have the "Pro" version of IDA, I can't just run the executable through the debugger to get the strings out, so I had to resort to writing a really hacky emulator for a few ARM instructions to produce the strings. I only did this for one function, but the results were rather interesting. This function constructed the following string(s): "mt6575 mt6577 /sbin/su ro.hardware /system/bin/su /system/xbin/su /system/sbin/su /data/local/tmp/su /system/bin/busybox /system/xbin/busybox /data/local/tmp/busybox /system/app/Superuser.apk /system/app/SuperUser.apk /system/app/superuser.apk /system/app/SuperuserPro.apk /data/local/tmp/Superuser.apk /data/local/tmp/SuperUser.apk /data/local/tmp/superuser.apk /data/data/com.noshufou.android.su". I'm assuming this is a list of all of the files that the program looks for to determine if the phone has been rooted. In theory, using some way of randomly naming these files could prevent the root checker from detecting a rooted presence. If anyone who has IDA Pro wants to run "rctd" through the debugger, they might find more interesting things.

fastboot oem-unlock

While I've not tried booting into fastboot mode myself, I have "manually" executed the "fastboot oem-unlock" command. By disassembling the "aboot" partition ("/dev/block/mmcblk0p5"), I found that oem-unlock writes the value 0x01 to offset 0x1FFE10 of the "aboot" partition. I replicated this action with the command from a root shell "echo -en '\x01' | dd of=/dev/block/mmcblk0p5 bs=1 seek=2096656 count=1 conv=notrunc". After doing so and rebooting, which seemed to take longer than usual, I checked the kernel logs in "/data/logger/kernel.log*", and, in the bootloader logs section, there was a line displaying "[ 0.355056 / 01-01 00:00:00.340] [580] use_signed_kernel=0, is_unlocked=1, is_tampered=0.", seemingly indicating that the device was unlocked. However, it is not, as I'll mention later.

LGFTMITEM Spam in logcat

On the two VS985 phones I've looked at, both seem to produce a large amount of spam to logcat under the tag "LGFTMITEM". This takes the form of several lines being logged every 500 ms, consistently. I believe that setting the property "sys.lgsetupwizard.status" to "1" should stop it, though I haven't been able to do so successfully yet.

Bootloader Unlocking

One of the main goals of my tinkering has been to find a method for unlocking the VS985 bootloader. I believe I have identified the path to do so while disassembling "aboot", but I do not know how to enable it. I'll try to describe it here. In "sub_F81FF5C" of the "aboot" partition (I created a basic ELF format binary from the partition by trimming the first 40 bytes of the partition dump and then creating a single section ELF file loading that trimmed portion to address 0x0F800000), there is code that verifies the kernel and ramdisk images of the loaded boot partition. The code refers to "FEATURE_LGE_QCT_HW_CRYPTO", if that has meaning to anyone. Before the verification takes place, however, the function calls function "sub_F81FF58" with a memory location passed in R2. If this function call stores the value 0x67661147 in the memory pointed to by R2, the function bypasses all of the verification checks and simply prints "Device UnLock". This is why I believe "fastboot oem-unlock" would not be effective - my bootloader logs still indicate that the bootloader is taking the cryptographic verification path even though I have "unlocked" the device. I've tried to follow the function calls from here, but they get rather complicated and refer to memory locations not within the executable itself, which confuses me. In one of the functions invoked from here, which seems to print out the results of some sort of command, there are the strings "READ_UNLOCK_DEVICE_CERTIFICATE", "UNLOCK_DEVICE_AUTHENTICATION", "ANTI_ROLLBACK", and most interesting to me, "BACKDOOR". I've been having trouble figuring out how this part of the code works, so if anyone has any ideas, I'd be interested in hearing them.

Well, I think that about covers most of what I've found out about this phone. I'd be happy to explain anything in more detail if it's not clear.