Post the aboot.mbn here, I'll see if I can help.
Knox/Kernel/Bootloader Development SM-900A
- Thread starter Da_G
- Start date
Post the aboot.mbn here, I'll see if I can help.
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://xdaforums.com/showthread.php?t=2703006
Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app
http://www.mediafire.com/?53pz69lc3l152og
I found it on this page:
http://xdaforums.com/showthread.php?t=2703006
Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app
Last edited:
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/Cobaltikus/aboot_mbn/master/aboot_output.txt
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/Cobaltikus/aboot_mbn/master/aboot_output.txt
Last edited:
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.
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
Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app
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.
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 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 A0C vs C#
hash_find(image_ptr, image_size, (unsigned char *)&digest, hash_type);
from https://android.googlesource.com/ke...ec3b472a95/platform/msm_shared/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}
hash_find(image_ptr, image_size, (unsigned char *)&digest, hash_type);
from https://android.googlesource.com/ke...ec3b472a95/platform/msm_shared/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.
Last edited:
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...
After further studying the NC2 boot.img, where I expected to find the signature/encoded SHA256 hash of the boot image, instead I found the string SEANDROIDENFORCE followed by what's looks like the signature, except the 256 bytes do not decrypt using the certs from aboot as I had expected they would.
Further NC2 boot.img studies
Still no matching hashes...
What are these decrypted signatures a hash of?
Here's some info on the NC2 boot.img
Still no matching hashes
Still no matching hashes...
What are these decrypted signatures a hash of?
Here's some info on the NC2 boot.img
Code:
Boot Magic: [ANDROID!]
Kernel Size: 0x7E1198
Kernel Address: 0x8000
Ramdisk Size: 0xF245B
Ramdisk Address: 0x2000000
Second Size: 0x0
Second Address: 0xF00000
Tags Address: 0x1E00000
Page Size: 0x800
Page Mask: 0x7FF
Device Tree Size: 0x13D800
Unused: 0x0
Boot Name: [SERPHLUA001 ]
Command Line: [console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 ]
ID: [BD 70 BF 0D D7 F0 80 BC CC CE 2E 98 2A E4 C0 4E 0E 22 B8 C9 00 00 00 00 00 00 00 00 00 00 00 00]
Extra Command Line: [ ]
Kernel Padded Size: 0x7E1800
Ramdisk Padded Size: 0xF2800
Device Tree Padded Size: 0x13D800
Image Size Padded (No Header, No Signature): 0xA11800
Signature Magic Offset: 0xA12000
Signature Magic Size: 0x10
Signature Magic: [SEANDROIDENFORCE]
Signature Bytes: [55 0B F3 E2 92 63 73 38 58 F1 8B CC 93 E4 FE 67 78 57 E9 9D FE B7 23 05 B0 98 FE CF 08 D5 BF 9B 85 88 BB A5 02 E6 7E EF 17 A0 68 24 7B 9C 20 03 65 1D 01 9F E4 C3 D6 BD 08 29 F7 32 5D 6A 12 24 2B 35 57 DA 8E 84 F7 A8 EC F2 87 0E EE 1F F7 41 DE 01 6B EC AE AF EF A9 FB 54 08 58 CA 0F 22 44 11 45 60 99 45 FA 9C CF F7 9F EC 44 7C 34 F3 5A D0 E9 E7 81 9D 7A 56 E3 EE 8C 1E 76 B7 F6 2F 20 08 9B 09 2E 2D 59 BA 6C FE 33 E7 6D DB 5E C1 6C D2 98 36 83 9D 7D 67 95 2F 1C 03 C3 CB EC 17 B7 A4 CD D7 E3 05 3E 65 8E 2A 4D A2 ED DF 91 A4 9F 44 1A 63 00 E9 DA 2A 01 E0 18 5A 6F 6A 95 64 16 2D 14 0C 3B D3 DA BA 05 F8 F0 C5 31 B1 B3 2E 9E 32 D7 6F DA EF B4 A8 92 CF 57 5A EA F8 19 5D 1A DD 9E 05 C3 BA 5B EF C4 9D D0 75 27 3D BB DF C6 31 DA 13 D0 B0 C8 DA B1 75 51 E4 51 B7 AB 3A 5A]
Certs from aboot: [30 82 05 1F 30 82 04 07 ... FF FF FF FF FF] (too long for this post)
Signature Bytes could not be decrypted with the given Certs
Certs from sbl1: [30 82 05 1F 30 82 04 07 ... FF FF FF FF FF] (too long for this post)
Signature Bytes could not be decrypted with the given Certs
boot image no header no signature SHA256 hash: [73 97 C3 00 88 A1 DA 99 86 04 0F D5 31 18 05 DA B7 DC 4B D5 D9 2B 80 A2 86 DF 63 8D AE AD 70 4E]
boot image no header no signature SHA1 hash: [EE 92 2B F2 C6 52 35 C1 1F 93 51 14 FE 3A E8 CB 95 2F 5E ED]
boot image no header + signature magic SHA256 hash: [81 D1 43 B1 55 0F C4 5A 44 6B EC 01 DC B4 A0 40 5B 65 AA 73 A2 79 CD 60 A8 6D 9F E8 97 7B 57 AE]
boot image no header + signature magic SHA1 hash: [E1 22 9C ED 36 DC C8 FA 06 1A 78 56 74 A0 E3 AC BE 1E 9A 7F]
boot image no header + signature w/magic SHA256 hash: [1B C9 32 B7 CA 87 4F 32 B2 36 C1 C8 EB 2F 6E 3B 8A 8D 6F 1F DD 1A D3 7C 61 2A E9 1E E0 7D D7 12]
boot image no header + signature w/magic SHA1 hash: [16 97 0B 4A 5C 8A 1C 35 AF 07 83 7C 69 F6 C1 90 9B 32 CA AC]
full boot image with header and signature SHA256 hash: [62 09 6D E9 C5 F1 3E 31 A9 FF E9 AE C3 83 26 1F E9 4B C2 08 B2 75 89 EE 1D 0F 48 8C 9D 9C 62 E3]
full boot image with header and signature SHA1 hash: [07 C3 30 34 FC 22 97 DE 7C 0F F1 5A 5B 40 DA DA 65 29 50 CC]
Kernel Padded SHA256 hash: [77 3A A6 5C 6E 27 C1 4A 01 9F C5 5E 1A 85 11 15 93 1A AE E9 BF CD CF 26 56 3C 15 C6 CE DA A5 98]
Kernel Padded SHA1 hash: [01 D3 F1 A9 71 E4 F3 6B CC DA 5C 36 2E 18 64 10 FD C9 D5 0B]
Kernel SHA256 hash: [12 6D D9 78 2E FA 30 D9 C6 9F 77 59 3E 86 EF FA C5 6F 0C 05 A7 98 56 E9 EA A6 4C 92 5A D1 05 A6]
Kernel SHA1 hash: [9E 8D 87 E4 6D 26 D2 29 35 CF 4D 0B 9F 9A 62 85 EE F5 C0 34]Still no matching hashes
I've encountered the same issue with the MSM8226 (Moto G),
msm_shared\image_verify.c from LK computes the SHA256 of the image (the executable part, between the header and the signature) and compare it against the decryption of the signature (the public key for the decryption is taken from a hard-coded certificate called 'certBuffer').
Using the 3rd level certificate from the 3 certificates embedded in sbl1, I was able to successfully decode a 32-byte value,
but that value is NOT a SHA-256 hash of the executable image.
msm_shared\image_verify.c from LK computes the SHA256 of the image (the executable part, between the header and the signature) and compare it against the decryption of the signature (the public key for the decryption is taken from a hard-coded certificate called 'certBuffer').
Using the 3rd level certificate from the 3 certificates embedded in sbl1, I was able to successfully decode a 32-byte value,
but that value is NOT a SHA-256 hash of the executable image.
I was finally able to figure out how the image is validated, there's an HMAC that is being used, and the keys are the HW_ID blown into the device QFuses and SW_ID (which AFAIK is not blown into the device QFuses).
I have posted the details and source code to perform the verification here.
I have posted the details and source code to perform the verification here.
Last edited:
Here's a challenge, with a promise: If anyone can tell me a *whole* number, that is greater than 1, less than the number below, and can divide evenly (no remainders) into this given number, then I will post an unlocked version of this bootloader:
30310227443825557164637841134532835686376611503408502531860765963455300123001425357433901857606714854370993142496277291555727555950302916722764009678253038044915627710013760093404959110480885960238598272495266094529551013559294793224096294549257213714205690260942916163293005725783830137925442173459072995196702936914489243372379321809774050419066981056816086680937123592313643848620475605453779376975867030091157741605140826181015905443696516802481613520898487742214014181167217971394852733810725937594394745310894177235758866052028744469776942503974741288421721044906812625642895826317982940818042059262513605710231
30310227443825557164637841134532835686376611503408502531860765963455300123001425357433901857606714854370993142496277291555727555950302916722764009678253038044915627710013760093404959110480885960238598272495266094529551013559294793224096294549257213714205690260942916163293005725783830137925442173459072995196702936914489243372379321809774050419066981056816086680937123592313643848620475605453779376975867030091157741605140826181015905443696516802481613520898487742214014181167217971394852733810725937594394745310894177235758866052028744469776942503974741288421721044906812625642895826317982940818042059262513605710231
Last edited:
The number ends in "1" it's not divisble by 12 I assure you. We Have to find a pattern.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
29Hi guys!
I've been a bit busy in life for my first two months or so of owning the Galaxy Note 3 SM-900A. But finally I've run into a bit of a block of time, so I'm hoping to get some bootloader work done. I've already been studying it for a day or two, and am ready to begin some modifications in attempt to disable Knox/Signature verification/etc. But unfortunately I was broken into a few months back, and all my specialty hardware related to brick recovery is stolen (JTAG, etc.) - so I need some help from anyone who has a nice cozy return policy/warranty/replacement system available to them, who can risk rendering the device into a total brick (perhaps not bootable by any known method other than JTAG)
If you can help me out, please PM, I will get back to you soon regarding contact methods etc. - I am used to using an IRC channel on irc.freenode.net where #xda-devs lives, but perhaps we could use a more up-to-date collaboration method also.
Again, we will make every effort to do incremental testing that runs as much a minimal risk of brick as possible, but with such things there are no guarantees. Be ready and absolutely willing for a brick if you want to help. Thanks
Sent from my SAMSUNG-SM-N900A using Tapatalk11Hi guys!
I've been a bit busy in life for my first two months or so of owning the Galaxy Note 3 SM-900A. But finally I've run into a bit of a block of time, so I'm hoping to get some bootloader work done. I've already been studying it for a day or two, and am ready to begin some modifications in attempt to disable Knox/Signature verification/etc. But unfortunately I was broken into a few months back, and all my specialty hardware related to brick recovery is stolen (JTAG, etc.) - so I need some help from anyone who has a nice cozy return policy/warranty/replacement system available to them, who can risk rendering the device into a total brick (perhaps not bootable by any known method other than JTAG)
If you can help me out, please PM, I will get back to you soon regarding contact methods etc. - I am used to using an IRC channel on irc.freenode.net where #xda-devs lives, but perhaps we could use a more up-to-date collaboration method also.
Again, we will make every effort to do incremental testing that runs as much a minimal risk of brick as possible, but with such things there are no guarantees. Be ready and absolutely willing for a brick if you want to help. Thanks
Sent from my SAMSUNG-SM-N900A using Tapatalk
Done and done. I'm ready to crack this thing :thumbup: let's do this.
Sent from my SM-N900A
9I 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.8I was finally able to figure out how the image is validated, there's an HMAC that is being used, and the keys are the HW_ID blown into the device QFuses and SW_ID (which AFAIK is not blown into the device QFuses).
I have posted the details and source code to perform the verification here.7I'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
