Cracking the Gmini

Basically the md5 checksum of CCOD (or CODE) chunk is computed, signed with rsa and put in the SIGN chunk.

Other chunks are not signed.

The public RSA key is in the firmware; and loaded to conventional memory at boot time.

Additional difficulties

• the code to actually flash the firmware is below 6100 and thus we don’t know it.
• updates are checked only at boot. However, updates are not checked if there is no “System” directory on the hard disk. (Instead the directory is created)
• code and data reside in different address space. TODO: find ways to write code memory.

Straightforward, but difficult with a 768 bits number. If you have CPU time to spare, feel free to factorize

1517533821386663035716480241063608157107695052020046863381673532011121972036247470917178101611769092616278152767446063345624176640291258869154806898409072452613611393327354191729558668815913950530144477980131766918220243204783123831

(base 10)

This attack consists in overwriting the public key data in some way, so that cracking it is trival. (eg. if we change the public exponent to 1, rsa(m) = m) We can then use the normal firmware update procedure to load our code.

We could set up an invalid FLSH chunk in an exsting AOS file, so that code (or data) is loaded at a wrong address.

TODO: check how FLSH chunk is used.

We might be able to load code after boot time (ie. upon load of an mp3 file); and boot our OS this way.

This can be combined with idea 1: overwrite the key data, then find a way to go back to the firmware update procedure.

Tested, it works! We don’t really even need to “pack” it

http://www.donat.org/archos/temp/20041207-18491100.jpg