FORUMS
Remove All Ads from XDA

Archos gen8 bootloader crack (disable signature check)

20 posts
Thanks Meter: 18
 
By vitalif, Junior Member on 1st April 2011, 10:08 PM
Post Reply Email Thread
" PWNED " :D

As you know, Archos bootloaders check digital signatures of init and recovery kernels, so you need to install SDE to use custom kernels, and it somehow "watermarks" the device.

Good news everyone! I've disassembled both bootloaders, found the code which checks signature, and replaced it (first instructions of verify_hash function) with "return 0" which is "mov r0, #0; bx lr" in ARM assembly. It's much the same hack as on Archos 5, thanks EiNSTeiN from archos.g3nius.org for reverse engineering previous generation.

Archos gen8 boots using OMAP boot ROM from internal eMMC card. Primary bootloader ("boot0") is in 0x20000 bytes after the first sector of internal flash (i.e. at 0x200) and secondary bootloader is written into rawfs, /mnt/rawfs/avboot. boot0 contains image size and loading address in first 8 bytes.

So, here is the patch:
1) boot0: replace 8 bytes at 0x7520 from the beginning of mmcblk0 from 7F402DE9003091E5 to 0000A0E31EFF2FE1.
2) avboot: replace 8 bytes at 0x14424 in avboot from 7F402DE9003091E5 to 0000A0E31EFF2FE1 (same patch). 0x14424 from avboot beginning is usually 0x14824 from the beginning of mmcblk0p1 (avboot comes first in rawfs, just after 2 blocks of header).

Of course you need root to do it. I've done it on my Archos 101, then changed 1 byte in recovery image - it boots into recovery without problem (before the hack it didn't boot into this 1-byte changed recovery).

And of course do it with caution and at your own risk DO NOT replace the bytes if you find other original data at these offsets! Bad boot0 or avboot means bricked Archos. There must be some sort of test point (something connected to OMAP SYS_BOOT5 pin) to boot from USB, or a boot UART interface, so debricking the device must be possible, but it would require some effort to find it, find a proper bootloader and use it.

If someone wants to see IDA database, I'll send my.

P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
The Following 4 Users Say Thank You to vitalif For This Useful Post: [ View ] Gift vitalif Ad-Free
 
 
1st April 2011, 10:42 PM |#2  
chrulri's Avatar
Senior Member
Thanks Meter: 278
 
Donate to Me
More
Great work! With this base, can yout get something like CW to run?
1st April 2011, 10:48 PM |#3  
blazingwolf's Avatar
Senior Member
Thanks Meter: 409
 
Donate to Me
More
I'm so waiting for him to come back and say April fools.
1st April 2011, 11:14 PM |#4  
chrulri's Avatar
Senior Member
Thanks Meter: 278
 
Donate to Me
More
I'm gonna screw him up if this was an april fool
2nd April 2011, 03:43 AM |#5  
Techngro's Avatar
Senior Member
Flag NYC
Thanks Meter: 175
 
More
First, if this is an April fools, I will find you and hurt you.

Second, what does all that mean anyway? Does that mean Cyanogen on Gen8 is near? Does it have anything to do with roms?
2nd April 2011, 06:53 AM |#6  
wdl1908's Avatar
Senior Member
Thanks Meter: 157
 
More
Quote:
Originally Posted by vitalif

P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.

Maybe you should increase that number of post by explaining how you did this.
2nd April 2011, 02:21 PM |#7  
OP Junior Member
Thanks Meter: 18
 
More
)))) No it isn't an April fool, my device now really has a modified recovery. Ridiculously modified (1 byte changed), but that's the proof!
Check the patch by yourself )) all you need to write to mmcblk0 is a standard linux dd tool... which is included into standard Archos busybox...

Quote:
Originally Posted by wdl1908

Maybe you should increase that number of post by explaining how you did this.

In fact, it was not hard, and if I knew ARM assembly language before, it would be even easier... All I had to do is to find bootloader on the flash (boot0 is obviously in its beginning, and avboot is on /mnt/rawfs), copy it to computer, download IDA, feed bootloader to it and find functions similar to ones described on archos.g3nius.org (BigInteger_ModulusEnter, RSADecipher, etc). It also could be simpler, as BigInteger_ModulusEnter is mentioned inside an ASCII string inside data section... But I've found them by text search also there is a magic "ZMfX" in first 4 bytes of avboot and some other magic inside init and recovery... One also could use them to find interesting points in bootloader.

At first I've started disassembling with the wrong base address, but bootloader has code which copies itself to the correct one in the very beginning, so I've changed it and started over. In fact, it has size and address in first 8 bytes, so this also could be simpler...

So the hack is done, what needs to be done by now - utilize it and create some custom ROM or simply flash urukdroid without SDE...

Quote:
Originally Posted by chulri

Great work! With this base, can you get something like CW to run?

CW == ClockWorkMod recovery? I don't have any experience with CWM porting yet, but in theory yes, the hack gives us the ability to run custom recovery images.
2nd April 2011, 05:58 PM |#8  
Senior Member
Thanks Meter: 131
 
More
Don't know alot about the bootloader, but what advantage does this have?
2nd April 2011, 07:26 PM |#9  
OP Junior Member
Thanks Meter: 18
 
More
Quote:
Originally Posted by SWFlyerUK

Don't know alot about the bootloader, but what advantage does this have?

Hm. I'll explain... Bootloader is the program which starts up the device, similar to bootloader on your PC signature check in bootloader prevents us installing modified Linux kernel, initial ramdisk and recovery images. So, for example, we can't have netfilter in kernel without installing SDE, we can't have ClockWorkMod recovery on Archos at all, and we can't, for example, change MMC card splitting into 512M mmcblk0 for system + remaining for "internal SD" with data.
With signature check removed, all this is possible.

The underlying idea of all this signature checking is probably protecting f**king DRM... I HATE IT !!!!!! And hate companies promoting it =) When you install SDE on previous generation archos (5it), it removes drm keys from device memory (this is the "watermarking" mentioned on Archos site). It makes device unable to play the content buyed for it anymore... Not a big deal, but unpleasant. I don't know if this is the same on gen8.

In detail: Archos 101 has OMAP3630 processor. The "0-stage" (very-very first stage) bootloader, i.e. program which gains control after processor power-up, is hard-coded into one-time programmable area on the processor itself and is named "OMAP boot ROM" (similar to PC BIOS). The boot ROM can continue device booting process from different devices including SD/MMC card, NAND flash, UART (serial port) or USB interfaces. The boot sequence is determined from physical pin connection configuration. Our Archos boots from internal eMMC card.

So, OMAP boot ROM loads primary Archos bootloader, without checking any signatures or checksums, and simply transmits control to it. Primary bootloader sets up some processor configuration and then reads secondary bootloader (avboot) from flash. Then, it checks its MD5-RSA digital signature using Archos public key. If signature is incorrect, it hangs the device (goes to infinite loop). So if we modify avboot without removing signature check from boot0, device would be bricked. If signature is correct, control is transmitted to avboot. Avboot determines what system we want to start by pressing different keys, loads it, checks signature if system is init (normal system) or recovery, sets up configuration for Linux kernel and transmit control to Linux.

Interesting facts:
* According to the code, boot0 can use rawfs or FAT filesystems for boot partition.
* During boot process, various messages are printed to serial console. avboot even has some code for receiving commands over serial connections.
* OMAP processor boot sequence can be configured via special memory area which remains unchanged after soft reset, and this configuration will override one determined by physical pin configuration. This does not give us much profit, but is also interesting...
The Following 6 Users Say Thank You to vitalif For This Useful Post: [ View ] Gift vitalif Ad-Free
2nd April 2011, 11:13 PM |#10  
Senior Member
Thanks Meter: 131
 
More
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
3rd April 2011, 05:20 AM |#11  
blazingwolf's Avatar
Senior Member
Thanks Meter: 409
 
Donate to Me
More
Quote:
Originally Posted by SWFlyerUK

Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?

Whats being done will have no affect on performance of the device. It will however, allow a lot of work that can contribute to better performance on the device. That is assuming that we can put on a modified clockworkmod recovery on these devices without bricking them.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes