FORUMS
Remove All Ads from XDA

Knox/Kernel/Bootloader Development SM-900A

3,317 posts
Thanks Meter: 1,560
 
By Da_G, Inactive Senior Recognized Developer / Moderator Emeritus on 27th January 2014, 10:56 AM
Post Reply Email Thread
15th January 2015, 04:37 PM |#21  
Surge1223's Avatar
Recognized Contributor
Flag Iowa
Thanks Meter: 7,362
 
Donate to Me
More
Quote:
Originally Posted by Cobaltikus

Consider the following assembly in aboot.mbn

If you were to run the aboot.mbn file, executing each instruction, following each branch, you would end up here

Code:
0x0F810A5C    00 50 93 E5    LDR R5, [R3]    (Loading value 0x0 from memory at 0xFC4CF808)
0x0F810A60    00 00 55 E3    CMP R5, #0x0    (0x0)
0x0F810A64    FC FF FF 0A    BEQ loc_F810A5C
This is an infinite loop, continually loading 4 bytes from the address 0xFC4CF808, and looping for as long as these bytes are all zeros.

What is it waiting for?

Once the value is not zero, it checks to see if it is 1. If it is not 1, it references the string "SPMI write command failure: cmd_id = %u, error = %u"

So what is SPMI? Apparently it is something that writes a 1 to the address FC4CF808 upon success.

Digging deeper. Feel free to help if you can if you want.

Ah ha! https://android.googlesource.com/ker..._shared/spmi.c

Post the aboot.mbn here, I'll see if I can help.
The Following 3 Users Say Thank You to Surge1223 For This Useful Post: [ View ] Gift Surge1223 Ad-Free
15th January 2015, 07:48 PM |#22  
Cobaltikus's Avatar
Senior Member
Flag Fredericksburg, VA
Thanks Meter: 106
 
More
Here's the link to the zip file where I got the aboot.mbn.

http://www.mediafire.com/?53pz69lc3l152og

I found it on this page:
http://forum.xda-developers.com/show....php?t=2703006

Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app
The Following 4 Users Say Thank You to Cobaltikus For This Useful Post: [ View ] Gift Cobaltikus Ad-Free
16th January 2015, 01:03 AM |#23  
Cobaltikus's Avatar
Senior Member
Flag Fredericksburg, VA
Thanks Meter: 106
 
More
Prompt
I'm in the process of writing a program in C# that reads the aboot.mbn file. So far what it does is output the header information and "soft-executes" each instruction one at a time, all the while keeping track of the state of each register, and memory, and following all branches according to the applicable conditions. The code section of aboot.mbn starts with 8 branch instructions.

1. I start at the first branch at 0xF800000 and follow that until I reach 0xF810A64 where the infinite loop is waiting for the SPMI command.
2. Then I follow the second branch (at 0xF800004) to 0xF8155B4 where another infinite loop occurs, this time it is a true infinite loop with no conditional exits, weird in my opinion, but I don't know, maybe this is normal.
3. So then I take the 3rd branch (at 0xF800008) until I see that this also leads to the same exact infinite loop at 0xF8155B4.
4. The 4th branch (at 0xF80000C) also leads to the infinite loop at 0xF8155B4.
5. The 5th branch (at 0xF800010) also leads to the infinite loop at 0xF8155B4.
6. The 6th branch (at 0xF800014) leads to a different infinite loop at 0xF8159A4 immediately.
7. The 7th branch (at 0xF800018) leads to 0xF80B8E8 where a BLX instruction attempts to branch to a variable address stored in memory at 0xF9251C0. When running this in my isolated environment where nothing else is running, the address 0xF9251C0 contains only zeros, because it's not the aboot.mbn instructions that write anything here. Something else is supposed to write an address here, and this BLX instruction will branch to it and start executing whatever is there.
8. The 8th branch ends up at the same infinite loop described in branch 1.

The output from my program can be seen here: https://raw.githubusercontent.com/Co...oot_output.txt
The Following 7 Users Say Thank You to Cobaltikus For This Useful Post: [ View ] Gift Cobaltikus Ad-Free
21st February 2015, 02:18 AM |#24  
goob1284's Avatar
Senior Member
Thanks Meter: 23
 
More
Would you guys be able to help me catch up? I have an S5 and I think a bootloader unlock would be somewhat similar to the Note considering they are both Samsung and on AT&T. If not, can you provide info on how you guys figured out thus far? Programs, processes? Thank you.
21st February 2015, 04:09 AM |#25  
Cobaltikus's Avatar
Senior Member
Flag Fredericksburg, VA
Thanks Meter: 106
 
More
I'm using IDA Pro, and also Visual Studio to make my own program to analyze aboot and sbl. I haven't had time recently and hope to get back to this soon. aboot was easier because it's all arm 32 bit instructions. sbl switches back and forth between thumb and arm and there are still more instructions I haven't implemented yet. I'm comparing the logic to the little kernel source code and I'd like to take advantage of the possible flaw in the signature verification implementation that could allow a forged signature. I left off at setting up unit test to reproduce the signature verification process. We know the signature should pass for the untouched bootloader, and so i want to see it happen and step through it. Once i have that in place i can start my forgery testing. It may be a couple more weeks before i have time to devote to this again. A good source for knowledge on reverse engineering for me has been http://opensecuritytraining.info/

Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app
The Following 7 Users Say Thank You to Cobaltikus For This Useful Post: [ View ] Gift Cobaltikus Ad-Free
22nd February 2015, 04:47 AM |#26  
goob1284's Avatar
Senior Member
Thanks Meter: 23
 
More
What is the unit test that you have?

Meanwhile, I'll try to catch up on looking into ARM and all that good stuff.
22nd February 2015, 04:47 PM |#27  
Cobaltikus's Avatar
Senior Member
Flag Fredericksburg, VA
Thanks Meter: 106
 
More
I compiled the openssl project for WIN64 to get libeay32.dll and slleay32.dll.
I use DllImport to expose the functions necessary to replicate image_decrypt_signature from image_verify.c from LK.
I use that to decrypt the signature extracted from aboot.

My unit test verifies that the decrypted signature matches the hash of the image, but it's not right yet. I'm missing something somewhere.

Image Base: 0xF800000
Image Size: 0x1263FC
Code Size: 0x1232FC
Signature Base: 0xF9232FC
Signature Size: 0x100
Cert Chain Base: 0xF9233FC
Cert Chain Size: 0x3000

If I'm understanding this correctly, image_decrypt_signature needs the signature bytes and the cert chain bytes.
I get the signature bytes using (Signature Size} bytes starting at {Signature Base}.
I get the cert chain bytes using (Cert Chain Size} bytes starting at {Cert Chain Base}.
It seems to decrypt just fine, meaning no errors, no null pointers, data is getting set. I get a populated byte array with a size of {SIgnature Size} that is supposedly the decrypted signature, which is supposed to match the hash of the image.
I'm getting the hash (both SHA256 and SHA1 just in case) of the image using both {Code Size} bytes and {Image Size} bytes starting at {Image Base} but none of the scenarios produce matching results.

Only the first 32 or 20 bytes need to match but they don't, so I know I'm either doing something wrong, or I'm missing a step somewhere.

Out of time for today.
The Following 9 Users Say Thank You to Cobaltikus For This Useful Post: [ View ] Gift Cobaltikus Ad-Free
23rd February 2015, 01:41 AM |#28  
Cobaltikus's Avatar
Senior Member
Flag Fredericksburg, VA
Thanks Meter: 106
 
More
The signatures in aboot and sbl1 definitely decrypt to SHA256 hashes, but hashes of what exactly? The SHA256 hashes I've tested don't match up...

Code:
    aboot sig decrypted: C9 00 3E FE 04 87 6B DC 3C BE CC CE EE 75 EF D5 A9 57 28 F8 2B 77 F4 CA E6 6F 9C D9 A7 41 7C C8
aboot image SHA256 hash: 06 95 69 4C 14 CC 2F E6 22 97 B1 66 1F A0 62 4E D0 7D CD 87 4F 06 D1 45 48 1B 7F 5D B9 B6 87 2E
 aboot code SHA256 hash: 56 33 90 F0 0D 24 01 A8 AE DB D9 79 59 93 21 74 07 F7 A4 53 8A 7E 74 AE CF F3 5E 75 48 3F 50 61

     sbl1 sig decrypted: 44 B2 BE 4A 54 4B 46 E4 89 E7 5E 35 AC C4 0B 2E C9 1D DA 73 94 20 43 11 EB 53 92 61 AF F4 25 B0
 sbl1 image SHA256 hash: 35 A6 55 D1 C3 41 50 0B 42 BD 54 EE 51 52 C3 0B 29 00 F1 DD 1C FD E9 D1 67 28 8A 87 D2 53 1D FF
  sbl1 code SHA256 hash: F2 D4 5B 83 2C B2 1B 64 7E 34 CE 1B CB B6 36 CA 78 0E D7 27 30 ED BA D6 54 F9 03 51 A0 87 0F A0
The Following 4 Users Say Thank You to Cobaltikus For This Useful Post: [ View ] Gift Cobaltikus Ad-Free
23rd February 2015, 05:39 PM |#29  
Cobaltikus's Avatar
Senior Member
Flag Fredericksburg, VA
Thanks Meter: 106
 
More
Question C vs C#
hash_find(image_ptr, image_size, (unsigned char *)&digest, hash_type);
from https://android.googlesource.com/ker...image_verify.c

Is the above c code likely to yield a different result than the following C#?

SHA256 mySHA256 = SHA256Managed.Create();
byte[] digest = mySHA256.ComputeHash(image_data); // where image_data is a byte array of {image_size} bytes starting at {image_ptr}
The Following User Says Thank You to Cobaltikus For This Useful Post: [ View ] Gift Cobaltikus Ad-Free
23rd February 2015, 06:02 PM |#30  
eragon5779's Avatar
Senior Member
Thanks Meter: 147
 
Donate to Me
More
Quote:
Originally Posted by Cobaltikus

hash_find(image_ptr, image_size, (unsigned char *)&digest, hash_type);
from https://android.googlesource.com/ker...image_verify.c

Is the above c code likely to yield a different result than the following C#?

SHA256 mySHA256 = SHA256Managed.Create();
byte[] digest = mySHA256.ComputeHash(image_data); // where image_data is a byte array of {image_size} bytes starting at {image_ptr}

It looks like the C code uses whatever hash it finds (unless I am mistaken), whereas the C# finds an SHA256 hash to use. So if the C code finds a different hash, it will output it.
The Following User Says Thank You to eragon5779 For This Useful Post: [ View ] Gift eragon5779 Ad-Free
23rd February 2015, 07:51 PM |#31  
Cobaltikus's Avatar
Senior Member
Flag Fredericksburg, VA
Thanks Meter: 106
 
More
Quote:
Originally Posted by eragon5779

It looks like the C code uses whatever hash it finds (unless I am mistaken), whereas the C# finds an SHA256 hash to use. So if the C code finds a different hash, it will output it.

I believe the purpose in both pieces of code is calculate the hash using the SHA256 algorithm. I know that is the purpose in the C# code because I wrote that. But the decrypted signature does not match the hash from the C# implementation. So either the C# implementation is different than the C implementation, or the signature is actually a hash of something other than just the image file, and Samsung has changed the image_verify function, or something else...
The Following 2 Users Say Thank You to Cobaltikus For This Useful Post: [ View ] Gift Cobaltikus Ad-Free
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes