[Verizon Samsung Galaxy S 4] LilTechPrincess:
Break down of VRoot Application

Why would they do that?

I have been doing some long running tests on this, and here is what I have found: This applies the VRoot Method specifically. I have 6 S4's, two Note 2's and 1 Note 3. All of them were rooted with this method. Additionally, I installed the root application on a clean Windows 7 VM. I then setup dumps of netstat each second, and RAN this for the last 48 hours. Additionally, I filtered everything on the VM through the stateful packet inspection feature of my Cisco ASA, and did a complete TCP Dump of all tests.

When I first installed the application I made a dump of my registry hive, and then again after installation and first run. The application made no malicious or suspicious changes to my file system or registry. I observed that the application was not automatically running on install. Once I was done with that I launched the application for the first time. I found that the app spawned three process, specifically, Root.exe, RomasterConnection.exe, rommaster_daemon.exe. I observed that the Root.exe was the primary application process. This process made a few http calls to 91.199.212.171, 178.255.82.1, 58.61.152.154. All of these packets were captured on my tcpdump were non-encrpyted, standard HTTP. They all appear to be requests for updated banners, logos, and check for updates.

The second process that was spawned was rommaster_deamon. This application appeared to be the local listeners for the root exploit. Specifically, it bound three sockets to my loopback address. All data that was transmitted in regards to the daemon appeared to be local only. This process never established communication with a non loopback address.

The third process that was created was RonnasterConnection.exe. This process was only active during the root itself, and when you initially connect the phone. This process connected to the following IP's: 123.235.32.69, 202.104.151.51 and 218.59.209.165. These resolve back to dataservice.mgyun.com, and point to an API located at: /models/api/Adaptation. This was also done via HTTP. After reviewing the packets there are some strings being exchanged that are obfuscated. This is likely due to the fact that they are exchanging data via an API. I don't personally feel like there was a real threat to this.

Additionally, this application never transmitted data beyond the initial execution. I let it run for almost two days and the application never sent a single packet beyond initial startup, connection of a phone, and actual rooting. In fact, after a few minutes the root.exe application would allow it's sub processes to die if they werent used, completely unbinding the ports.

Lastly, I dug into the included DLL's and executables. I decompiled a lot of them, and checked the manifests on almost all of them. Here is an example of the manifest for the main application:

1 VERSIONINFO

FILEVERSION 1,7,2,0

PRODUCTVERSION 1,7,2,4200

FILEOS 0x4

FILETYPE 0x1

{

BLOCK "StringFileInfo"

{

BLOCK "080404b0"

{

VALUE "CompanyName", "????"

VALUE "FileDescription", "Root??"

VALUE "FileVersion", "1, 7, 2, 0"

VALUE "InternalName", "Root"

VALUE "LegalCopyright", "Copyright (C) 2013 Xinyi All Rights Reserved"

VALUE "OriginalFilename", "Root.exe"

VALUE "ProductName", "Root??"

VALUE "ProductVersion", "1, 7, 2, 4200"

}

}

BLOCK "VarFileInfo"

{

VALUE "Translation", 0x0804 0x04B0

}

}

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

<security>

<requestedPrivileges>

<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>

</requestedPrivileges>

</security>

</trustInfo>

<dependency>

<dependentAssembly>

<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30729.1" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

</dependentAssembly>

</dependency>

</assembly>

Specifically, I noticed that its execution level is set to "asInvoker" which basically means the application is content with running as whatever level it was executed as. If you were to execute the application as a non-admin it would be completely "OK" with that. Thats not very typical or ideal for a malicious application.

Ill follow up shortly with my findings on the phone application. Again, these captures, etc. have been performed over about 48 hours.