NOTICE: This content was originally posted to Google+, then imported here. Some formatting may be lost, links may be dead, and images may be missing.
Reshared from https://plus.google.com/+ClaudXiao/posts/H7xC18RR6wm
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.
It was only a matter of time, I suppose. Unfortunately, the press will probably inflate this into another silly Android security scare.
I am not someone who has rooted my device. Will this affect my Note2? Thanks +Chainfire
Was only a matter of time. Surprised it's taken this long.
Details on the filename? or are they polymophic?
+Chainfire Greetings and compliments. I can do my root BLU Life View with some Kernel yours?
China eh? I wonder if Kingo Rooting tool has anything to do with this...
Let me guess, rooted and unlocked only? (now I have to read it to find out)
It has to be some kind of rooting or rom tool, or the boot partition couldn't have been written to in the first place.
Old Boy reference?
Just wait until Apple bribes the press to blow this out of proportion.
Any one run the "do you have it" app yet?
Oldbootkiller ups...i can not read China Letters! Please in english=)
It looks like it will log chinese texts - so that's how you can detect it using the debug monitor?
+Brian Klippel Why pay for what will happen anyway? The ridiculous part is that the only way to get this loaded is a) downloading an infected file to a rooted device with system write protection and SELinux disabled or b) flashing an already-infected boot.img, both of which require explicit interaction with the user. Again the Android mantra holds true: only root if you want to take responsibility for your device.
The problem is, how the attacker put the imei_chk into / sbin directory and successfully modified the init.rc script We believe there're at least two ways to achieve it?:
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;
During system's running, after gaining root permission, forcibly write malicious files into boot partition through the dd utility.
. In Oldboot's case, we're more likely to believe that the attacker chose the first way (But we still can't exclude possibility of the second one)
Hope this will be fixed !
+Justtyn Hutcheson I'm not even sure "a)" is a guaranteed infection. For the trojan to be written to the boot partition the device pretty much has to be in a recovery mode or cable connected to ADB.
One can write to the boot partition with a live device.
No ADB, no fastboot.
You'd need hands-on access or some remote root access.
Once you'd gain root access to the device you can write anything anywhere and execute any arm binary or shell script.
But these devices were "infected" by the reseller or someone inside the reselling chain.
Even where I live, pretty far from China, resellers, especially gsm carriers, are very into "customizing" the phones and tablets.
A logo and some "special" apps... What's so difficult?
Going with the "physical access" method, you'd need:
a) an infected boot.img for each specific device and specific firmware revision;
b) a recovery which doesn't verify signatures or a bootloader which will happily flash unsigned binaries while in download mode.
As far as the infection through the running system is concerned, it's even harder: the app would have to detect the device type and firmware revision, determine its partition layout and fetch the right payload for the exact pair of device/firmware revision (condition a) still stands: boot.img is a combination of kernel+initramfs, which are very device/firmware specific). Only then it can write boot.img to the eMMC.
Also, it has to run as root in an unconstrained SELinux context, which essentially means that the user authorized it.
Nevertheless, almost all media outlets are definitely going to blow this out of proportion and make Android sound like it has no security model whatsoever.
What about a platform independent method?
Hypothesizing that I'd get root permissions in a live phone, I'd dump the boot partition (/dev/block/mmcblk0p1), grep for the initrd, dd -skip $offset the initrd.cpio, dump de contents of the cpio in a tmpfs folder, add my binary, libs and lines for /init, repack the cpio, concaternate with the kernel, dd back to mmcblk0p1, and reboot.
The big question.... How this device was infected?
+Pașca Alexandru you can also do Adb over WiFi which is possible
Samsung users keep using Chinese origin root tools and saying "YaY!!! I'm rooted" despite all the efforts from xda and +Chainfire
Good luck guys :D
Is the device unlocked and rooted?
Level 5 Trolling
+Pașca Alexandru I know system can be remounted writable while active, but I did not know that boot could be. I always assumed that could only be done when the recovery partition was the active.. Or is it just a matter of staging what needs to go to boot then forcing a restart?
Wish I knew if I have this or not. I ran the test app. Cant understand...
Yeah, thats the problem, so how do we know if we have it on our devices and what the soulution might be.
+Brian Klippel partitions are not active or inactive. The boot partitions, 0 containing bootloader and some configs and 1 holding the kernel and initrd, are never mounted or readily accesible by the user.
0 is usualy a fat16 with fastboot and 1 contains raw zImage folowed by initrd. the recovery partition contains a minimal operating system usable in a full-reset of the main Android OS. It ain't recovering anything. Custom ones, like TWRP do.
So, as the #0 partition is not mounted by default it could be mounted by user. r/o of r/w. Whichever.
The partition containing kernel+initrd does not contain a filesystem. The kernel is written directly in the gpt partition. There is nothing protecting it from writing. For example, piping data towards the block character in /dev is writing it.
L.e. obviously it is writable only by the user with correct permissions.
Damm... Well something important to remember..... Use and GOOD ANTIVIRUS ON YOUR ANDROID.
+Fernando Sosa name one. An OPEN source one! One that does not just pretend to find vi... malware and prompt you to pull up the credit card.
+Pașca Alexandru Thanks for the detail, I appreciate it. I haven't explored android system operations past using custom recoveries and image tools such as Odin. I suppose it all makes sense to have it that way in typical environment where the end user is assumed never to have su/sudo. But I have to admit I'm curious why they don't just mount both r/o locked when booting to system, and only allow write from recovery? Would it make OTA impossible? If not it seems it would be a lot more virus resistant. I'm not advocating a locked bootloaded, but is there any room for a middle ground?
According to +Tim Strazzere, it's just this: https://blog.lookout.com/blog/2013/12/09/mouabad-p-pocket-dialing-for-profit/, which isn't new.
+Brian Klippel If you have a partition mounted readonly it's just a matter of remounting with rw flag.
And, as far as I know, nand flash can't be hardware r/o.
+Artem Russakovskii That one is specifically Mouabad.p -- this one we track as Mouabad.s -- but yes, same family :)
+Fernando Sosa more like don't be a dumbass and install bad files
Using any productor of 360, you lost your safety.
+Brandon Padilla 360 is not china, just fucking 360
+ajahdkalsamkakdslsaak ahskaikakalw too bad apple sells your data to the US Government
About samsung, kingo jabs,
If this was somehow flashed in a current samsung device it would trigger the binary count and Knox, something kingo root has avoided so far.
If it's in boot partition it means that either this was placed there by manufacturer or only affects rooted devices.
+Juha Uotila I know this I was merely poking fun. The NSA doesn't buy shit they just steal it from every company that involves private user data
It would have to be device specific or very adaptive as there is way more variance in android devices than there is in the PC world.
Also googles play service is an admin service so google can stop it. It is still very likely to be something people install rather than a windows style malware that you can just catch from bing online. (Think nimda and codered)
There will just be a few cases of this mainly because of the difficulties in getting this thing on devices. But I'm waiting for the media blowup, oh what fun it will be.. :(
And they have done it again... Those guys of the red empire...
Are you not better to scan a file on PC before flashing it to be safe?