[Help-Project] Reverse Nokia Firmware HASH

[Adonix31]

Hi all!

i'm new to this forum and i saw that there are lots of interesting stuff regarding unlocking and reversing. However, what i'm interested about is reversing for phone Hacking and Firmware customizing

See, i'm a member of PNHT group (pnht(dot)org) and we have done so far a greate job in reversing Nokia Firmware file formats and coded tools that enable firmware cooking. However, some parts of the firmware like ROM is protected against any modification. The phone will perform an integrity check of the ROM at power on, and if mismatch, it won't turn on!

Apparently, Nokia included Hashes inside the FW that the phone uses to check the FW for modification. I have included a bloc that have the hashes.

A395978002000000162302980522954C05F90200617B9C0068 010000000400002B190000
70D68F4541D7CE0987565DC5764F62342728468C223A7916000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000001000 000400000000000000E4030000524F4653302A000094000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 0000000000000000000000000000000000
803E54BBD9F0A462B1FE8CEB9880A1F8F7F69775C0917B7C73
A747C48FA5B955C646A6C3663A7A1DAFC3A9AD9FCA1BE0256
3FA23BD60A794B374FCDFA3284806CE874854E7D739B7DBCB1
19281E354F69437217749380E033DFB681D31F06FD76D9F92E C
73BCEFDF3A90861FCC2DCB514E77B6A0659B872E631AE13AE2
9D7BA4
E8EADE312C1900002C190000FFFFFFFFFFFFFFFF3031312E30 3
1322E30302E3031000000000000000000000000000000

In this block, the yellow and orange colored data are hashes. I identified them by comparing files for the same phone, but different version and having little difference. I have uploaded these files for inspection. I think that the yellow one is for the data block i pasted and the orange one is the hash for the Firmware.

What i want to know if there is a way to know the computation method of these hashes or if it's possible to bypass them using a dummy hash or by patching the boot loader or any other method.

I believe that if we succeed in doing this, there are lots of new opportunities that will open like porting other OS'es to our phones etc...

[UniSoft]

However, some parts of the firmware like ROM is protected against any modification. The phone will perform an integrity check of the ROM at power on, and if mismatch, it won't turn on!

Yup... signed with RSA1024

Apparently, Nokia included Hashes inside the FW that the phone uses to check the FW for modification. I have included a bloc that have the hashes.

Here you are wrong...
What you included is actually so called Certificate (or SEAL)... here you can find name of code section, size of code section, entry point, base address, and some other information, and of cause hash (SHA1) of all code section...
What did you mark as yellow - yes is SHA1,
but orange is signature (seal) of this certificate RSA1024 (0x80 bytes).

I believe that if we succeed in doing this, there are lots of new opportunities that will open like porting other OS'es to our phones etc...

forget about it... only if you can Factoring RSA1024...
or if you can find collisions in sha1

[Adonix31]

First, Thanks for the reply

Originally Posted by UniSoft

Yup... signed with RSA1024
Here you are wrong...
What you included is actually so called Certificate (or SEAL)... here you can find name of code section, size of code section, entry point, base address, and some other information, and of cause hash (SHA1) of all code section...
What did you mark as yellow - yes is SHA1,
but orange is signature (seal) of this certificate RSA1024 (0x80 bytes).

You are right about the RSA1024 certificate. I misscalled it hash
However, regarding the yellow block sha1, i don't think that it's the one for the code bloc since the block size is 0x400 and the hash is included inside. unless Nokia puts some dummy hash in place of the catual one, the compute sha1 and replace it, i don't see how they compute sha1 hash.
I tried several stuff, but i haven't got the correct value. any idea how this is computed?

Originally Posted by UniSoft

forget about it... only if you can Factoring RSA1024...
or if you can find collisions in sha1

I know that this is the near impossible way. However, what i needed to know is at wish stage the check is performed (bootstarp, bootloader etc...). In other words, if the check is done inside the CPU ROM bootstrap, or in one of the bootloaders of the MCU file.
I think that there must be a way to probably patch this part, since for nokia 5800, early firmwares had all ROFS protected and later versions have only ROFS1 protected. If this is true, then the change is in MCU file.

[UniSoft]

However, regarding the yellow block sha1, i don't think that it's the one for the code bloc since the block size is 0x400 and the hash is included inside.

sure it is... code follow next, after certificate...
(in some implementatons inverted one most significant bit)

...010000 00040000 2B190000...

in your case: (offsets are from begin of certificate)
0x400 - is offset to first byte of block (first byte)
0x192B - is offset to last byte of block (included in hash)

what you see inside firmware file that is length only 0x400, it is not all block, only certificate, cause for every root key hash it is diffrent... code block is common for all root key hashes.

i don't see how they compute sha1 hash.

it is inside SecureROM

what i needed to know is at wish stage the check is performed (bootstarp, bootloader etc...).

All of them... when starting any signed code...

[Adonix31]

Thanks m8, I got that part

Originally Posted by UniSoft

what you see inside firmware file that is length only 0x400, it is not all block, only certificate, cause for every root key hash it is diffrent... code block is common for all root key hashes.

i have a question regarding this:
Why does phones like nokia 5800 have 6 blocks (or key hash) and N8-00 have only one? Any info?

regarding the following code
A395978002000000162302980522954C05F90200617B9C0068 010000000400002B190000

The colored parts are different if i compare two ROFS3 files with different version for the same phone.
However, for each key hash : 162302 and 05F902 are the same inside the file and 052295 increments by one.
What's the meaning of these blocs?

Thanks alot

[UniSoft]

Why does phones like nokia 5800 have 6 blocks (or key hash) and N8-00 have only one? Any info?

this you need to ask not me...
Root Key - is the main key... on this key based all nokia protection...
and its hash programmed inside MPU (CPU)... and cannot be changed...

regarding the following code
A395978002000000162302980522954C05F90200617B9C0068 010000000400002B190000

16230298 = 0x98022316 - i don't know what is this, not important (not using)
0522954C = 0x4C952205 - time (i guess creation time) = 20:33:09 18.09.2010 (not important, and not using)
05F90200 = 0x02F905 - i don't know what is this (not important, and not using) - looks like counter
most of the data inside certificate is just info... not important and not using...

The colored parts are different if i compare two ROFS3 files with different version for the same phone.

of cause... it one of the feature of creating certificate...

[Adonix31]

So far, with some rofs are unprotected, i wasn't interested with these blocks since i was able to modify, repack and flash the phone without any problem. however, this isn't the case for all phones That's why i'm trying to understand their meaning

If i change the sha1 hash, the certificate will no longer be valid, right? i mean the certificate protects the block containing unimportant info, plus sha1, code start/end (correct me if i'm wrong)

[UniSoft]

If i change the sha1 hash, the certificate will no longer be valid, right?

Yes

A395978002000000162302980522954C05F90200617B9C0068010000000400002B190000
in your case first 0x168 bytes (signed)

[kaisak]

Originally Posted by Adonix31

First, Thanks for the reply


You are right about the RSA1024 certificate. I misscalled it hash
However, regarding the yellow block sha1, i don't think that it's the one for the code bloc since the block size is 0x400 and the hash is included inside. unless Nokia puts some dummy hash in place of the catual one, the compute sha1 and replace it, i don't see how they compute sha1 hash.
I tried several stuff, but i haven't got the correct value. any idea how this is computed?


I know that this is the near impossible way. However, what i needed to know is at wish stage the check is performed (bootstarp, bootloader etc...). In other words, if the check is done inside the CPU ROM bootstrap, or in one of the bootloaders of the MCU file.
I think that there must be a way to probably patch this part, since for nokia 5800, early firmwares had all ROFS protected and later versions have only ROFS1 protected. If this is true, then the change is in MCU file.

We have checked SecRom Hash verification routines carefully. Seems no hole inside, PKCS#1 is checked correctly, so no way to tamper it anyhow...

[hakkothebest]

Hey guys why don't you decap the rap/rapido chip and get over with this maybe it was what dm3 have done isn't?

[Haltec]

Flylogic's Analytical Blog

http://siliconpr0n.wikispaces.com/Tu...+decapsulation


If possible, would that gain ALL relevant data for FULL access ???

And how: 0522954C = 0x4C952205 - time (i guess creation time) = 20:33:09 18.09.2010

???


BR


Haltec

[Adonix31]

It's nice to finally see some people interested with the subject

I want to know if there is a way to path the loaders of the MCU file. As i've seen, the ROFS check seem to be done in the second bootloader (i've seen text reference). Or, is it possible to set the phone to R&D mode? In R&D mode, ROFS check is disabled. Dzirt told me that the R&D certificate is filled with FF. I don't know where this certificated is located, but could we replace it with another one (one from other parts certificate)?

Like i said before, it seems that Nokia can change access to ROFS inside the MCU file. Previous Firmware versions of 5800 were restricted and later they removed this restriction on ROFS2/3.

[UniSoft]

As i've seen, the ROFS check seem to be done in the second bootloader

you can write to phone whatever you want...
signature checking only at starting signed code...

Or, is it possible to set the phone to R&D mode?

Only if you have R&D Certificate

Dzirt told me that the R&D certificate is filled with FF.

Yes it is true...
By the way, does anybody see this R&D certificate???

I don't know where this certificated is located

inside firmware

but could we replace it with another one (one from other parts certificate)?

cannot

[Il.Socio]

Originally Posted by UniSoft

What did you mark as yellow - yes is SHA1,
but orange is signature (seal) of this certificate RSA1024 (0x80 bytes).

Thank you for sharing...
If you don't mind, I would really like to go deeper in these investigations in order to fill a lot of holes in my current knowledge of the firmware file format.

Let's suppose I would like to check if this digital signature is valid.
Where can I find the RSA public key to use in order to decrypt the 0x80 bytes?
And after decrypted I'll get a SHA1 hash as result... and here comes a second question... On which data is computed this SHA1?
In other words, where can I find the data protected by this certificate?

Any information is appreciated

[Il.Socio]

Originally Posted by UniSoft

in your case: (offsets are from begin of certificate)
0x400 - is offset to first byte of block (first byte)
0x192B - is offset to last byte of block (included in hash)

Well... I believe this is the response that I was looking for in my second question.
Only need to know where is located the RSA Public Key