[Miscellaneous Android Development] k0nane:
Technical Details
​

Just what do we know about RCT? RCT, the Root Checker Tool, has one primary purpose: to make persistent note of any presence of rooting-related tools, the running of su, or the remounting of the system partition as read-write. The main "meat" of the tool - if not all of it - is in /system/bin/rctd. Mr. Rosenberg was kind enough to decompile and analyze the tool, and state that it checks for the following files:

/system/[bin,sbin,xbin]/su

/sbin/su

/data/local/tmp/su

/system/app/[s,S]uper[u,U]ser.apk,

/data/data/com.noshufou.android.su

/data/local/tmp/[s,S]uper[u,U]ser.apk

/system/[bin,xbin]/busybox

/data/local/tmp/busybox

The tool writes a hexadecimal number to /persist/rct and /data/system/lgmdm_root_flags.txt (these files are identical in contents) that represents the "root status". Mr. Rosenberg confirms that "[the] number is an encoded representation of whether su, Superuser, busybox, etc. are installed". The tool writes a human-readable representation of what it's found to /persist/rct.cfg. An example from a rooted system (if used on a previously-virgin system, this package will prevent this from being written):

Rooted

Not allowed command had been executed.
> su
Mount option had been changed.
> /system
Rooting related file had been installed.
> su
> superuser
> busybox

[LG RCT v1.0.1220]

A "clean" system will display "not rooted" and nothing else except the bottom line.

RCT also writes copies of ls -l /, portions of /dev/log/main and /dev/log/system, ls -l /system/app, ls -l /persist/LostFound, df -h, and basic system information (see below) to files named after asteroids and stored in /persist/LostFound.

VS870 4G
Model name : L1v
Manufacture : LGE
OS Version : 4.1.2
Secure : 1
Operator : Verizon Wireless
Country : US
Product version : M8960A-AAAANAZM-3.0.0743
Build date : Wed Mar 6 21:51:54 KST 2013

RCT may have other functions. rctd only does what's described above - it's a logger and nothing more, according to Mr. Rosenberg. There may be other portions of the system, but I have not found them.

I do have "clean" copies of the entire /persist and lgmdm_root_flags.txt, but due to the sensitive nature of some of the logs, and to protect the privacy of my tester, I prefer not to publicly distribute them. If anyone needs them, please contact me here, on XDA, Twitter, or chat.freenode.net #oudhitsquad.

How RCT Starts/Is Triggered

rctd, the main daemon that makes up RCT, is started as a system service in init.l1v.rc. I seem to have misplaced my copy of this file/the kernel, but it's a very standard service start. As the bootloader is currently locked, there's not much that can be done about this.

Inside com.lge.systemservice.core, BootCompletedReceiver waits for the BOOT_COMPLETED signal to be thrown, then executes the following:

const-string v1, "ro.build.target_operator"

const-string v2, ""

invoke-static {v1, v2}, Landroid/os/SystemProperties;->get(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

move-result-object v1

const-string v2, "VZW"

invoke-virtual-quick {v1, v2}, vtable@0x18

move-result v1

if-eqz v1, :cond_1d

.line 12
new-instance v0, Landroid/content/Intent;

invoke-direct {v0}, Landroid/content/Intent;-><init>()V

.line 13
.local v0, mServiceIntent:Landroid/content/Intent;
const-string v1, "com.lge.action.ROOTINGCHECKER"

invoke-virtual-quick {v0, v1}, vtable@0x6c

.line 14
invoke-virtual-quick {p1, v0}, vtable@0x60

.line 16
.end local v0 #mServiceIntent:Landroid/content/Intent;
:cond_1d
return-void

For those of you who don't speak smali, the real juicy bit of that appears as the following, when run through dex2jar:

[SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2][SIZE=2]
[/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE]if (SystemProperties.get("ro.build.target_operator", "").equalsIgnoreCase("VZW"))
{
Intent localIntent = new Intent();
localIntent.setAction("com.lge.action.ROOTINGCHECKER");
paramContext.startService(localIntent);
}

Yes, it really is just checking an item in build.prop to see whether it should run or not. That's an alternate way to stop rctd, but not one that I like. It is safe to remove the entirety of BootCompletedReceiver.smali, and for anyone working on modifications in the future, I would do so.

As you can see, an intent is thrown, and caught by rctd, which does its thing. It (rctd's main function) seems to run once per boot, but I cannot guarantee that.

Other Framework/System Finds

com.lge.mdm contains one item of interest. The rest of the framework, and /system/app, is largely clean. LGMDMGeneralController is the file of interest, and for the sake of readability in this post, I've run it through dex2jar. Here it is: Pastie This class contains a lot more than just RCT-related items, many potentially worth investigating.

Other things of note:

Viewing strings of other binaries, including those pertaining to FOTA, indicate the presence of "rooting history tables". Where these are, I don't know, and it could be as simple as what's already outlined here. Do proceed with caution, particularly around updates, as the updater system is rife with checks and logging for modifications.

There's an "ATS Agent" of some type hanging out in the framework. Its purpose is to take logs, and it may be responsible for the asteroid-namesake files. It is not present on the international model, thus can be assumed to be specific to VZW. Proceed with caution. I am automatically suspicious of these "diagnostic" tools after CIQ.

There's a GUI for RCT's output. See below.

Finally, I found some dialer codes. :D There's fun to be had here - proceed with caution, but enjoy Verizon/LG's hidden menu, and see what's to be seen in the Rooting Check entry (RootingCheck class inside the hidden menu apps/JARs).

A Message for Verizon and LG

Teehee, you guys are funny. :rolleyes: This wasn't hard, no more than Samsung's silly attempt to block package installation back on the Galaxy Indulge 4G (on MetroPCS). Go ahead and keep trying to prevent your users from controlling their devices... it's a losing battle.

Oh, and suck me. (And Dan.)

Credits/Donations

Please see the previous post for these notes. This was a good number of hours' worth of research - if I have helped you, please consider giving a small token. This system isn't going away any time soon.
​