Discussion  - 
Hi all,
We found an Android trojan in the boot partition of an infected Android device. Since the boot partition will be loaded as a read-only RAM disk during Android's running, all existing antivirus solutions can't effectively clean it.
The trojan will drop malicious APK to system directory, connect to C&C servers, download and install other adwares, fetch and execute other commands.
We classify this trojan as bootkit and named "Oldboot". This is the first Android bootkit in the wild as best we know. By our statistics, there’re more than 500,000 Android devices infected by this bootkit in China in last six months.
Qihoo 360 Technology Co. Ltd. (NYSE: QIHU). Zihang Xiao, Qing Dong, Hao Zhang and Xuxian Jiang. Jan 17, 2014. ——. A few days ago, we found an Android Trojan using brand new method to modify devices' boot partition and booting script file to launch system service and extract malicious application ...
Artem Russakovskii's profile photoAlex Daloo's profile photoVictor Jimenez's profile photoJohn Kozyrakis's profile photo
Alex G
Shlt becomes real.
This has to be highly device model specific.
And this reopens the debate on whether locked/secure bootloaders should be used.
"The attacker has a chance to physically touch the devices, and flash a malcious boot.img image files to the boot partition of the disk;"

Taking this point further, you could also dupe the user into flashing a malicious rootfs for you. I wouldn't be surprised if something like that doesn't spring up on XDA in the future.
Half a million infections? How did you get that statistic?

Interesting find. I suppose with a root vulnerability and unlocked Bootloader it wouldn't be too difficult to modify a rootfs, but sounds like cable flash is more likely from how you found it.
Alex G
One of the greatest vulnerabilities i can think of is the user pressing OK in rooted phones.
+Chris Fries
Well, our product has detected the dropped APK file as malicious a few month ago, but fail to clean it.
Have you compiled a list of infected devices or operating systems/versions used? Maybe there is a pattern somewhere?
+Corsin Camichel
Almost random in manufacturer, models and versions. The underground economy around the mobile phone in China is a big story in fact.
Considering that Google activates 500,000 devices each day, that's a small number. I am, however, interested to know what the affected SoC is. Native code injection is limited by the processor itself.
The main reasonI tell my customers to NOT TRUST ROOT images.
Does the phone need to be rooted? Unlocked bootloader?
Can we quantify the risk factor here? I mean what is the risk of the average user getting infected by this if indeed the phone needs to be either rooted, have unlocked bootloader or both.

Nonetheless it is an interesting find and well done!
As asked on the mobile malware mailing list-- do you have a hash for the sample? Is it just one sample you have or are you seeing different hashes on different phones?
Great find. I wonder what the method of delivery is for infection and what its primary target/purpose is for. 
The devices would have to have an unlocked bootloader (or some kind of bootloader bypass like loki).  It's really not that hard to dump, modify, and repack a boot image on the fly, so this doesn't require physical access and, since most Android devices use the same boot/recovery image format, is hardly model specific or SoC specific as the same ARM native code can run on a variety of devices. It's a great move by malware makers to ensure persistence.

Probably the hardest part would be knowing what partition is the boot partition as that can vary across devices. However, some SoC venders like MediaTek always locate the boot partition at /dev/bootimg or you could scan for by-name entries to find it.
Ah, turned out this is just MuoaBad which we've been tracking for a bit. I'll get a sample shared in a little bit.
Does anyone know why this application declares  android:process="system" in the manifest? I mean, since it is installed in /system/app then all the permissions it requests get granted, correct? Is there a reason behind the process=system attribute?
That attribute will allow the app to request the same id as the system and that will allow it to:
1)Impersonate the system
2)Access and modify system preferences files, internal files(such as security configurations, etc.)
3) Do cross app calls to system apps since it has the same id as the system.
4) Access internal API not accessible to the public via the SDK.
+Victor Jimenez  so it is pretty much the same as declaring sharedUserId=system , isn't it? What's the difference (if there is one)
As fat as I have seen, yes they are almost the same.
I would have to double check the package manager code.
I have always seen that app build with or in the OS context use the android:proces and App build with the sdk use the sharedUserID.
I know this for sure, if you use the android:process you HAVE TO SIGN IT WITH THE CORRECT PLATFORM/SYSTEM KEY!
Which now that I think about it it means that who ever wrote this exploit had access to the original source code for the device(not uncommon) AND that he or they have the original platform and system key! Now that is bad!!!
+Victor Jimenez as far as I know oldboot isn't signed with platform keys, it is just installed in the system image. so that assumption about the key doesn't seem to be correct. are you sure about it, can you point me to Android source code that checks the certificate of the package before allowing it to use a process name? I tried to find such a piece of code in the Android source without success. the mystery remains! 
Add a comment...