Knox/Kernel/Bootloader Development SM-900A

[Da_G]

Hi 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

 

[TheDriller]

Hi 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

 

[Da_G]

Has anyone attempted patching of the SBL? Simple one-byte patches of code there or to the Kernel? Does the signature verification catch these, obviously full image verification is only done at flash-time on the various open partitions as they are modifiable freely without tripping Knox/etc. Hard to find any public-facing info on if anyone has done work on it yet, trying to get a feel before I start so I don't duplicate work.

Also, in poking around, Carrier IQ seems active on the AT&T Build. Surprised more people aren't up in arms over this given it's previous reception

 

[Walter.White]

I think you should talk to @ryanbg and @Surge1223 They have done lots of research regarding this Knox/BL and have made some pretty good progress.

I personally think that doing that will make sig check fail and the Knox flag would trip 0x0 and it won't boot.

P.S. No matter what you do don't flash over RPM because that will definitely hard brick your device. (No SD Odin mode either).
http://forum.xda-developers.com/showthread.php?t=2476353

Also please keep this thread clean because most of this kinda threads get closed down before because of flame wars.

 

[gordec]

DA_G is pretty reliable with good reputation. He can play dirty and get away with it just a little more.

Sent from my SM-N9005 using Tapatalk

 

[ryanbg]

Has anyone attempted patching of the SBL? Simple one-byte patches of code there or to the Kernel? Does the signature verification catch these, obviously full image verification is only done at flash-time on the various open partitions as they are modifiable freely without tripping Knox/etc. Hard to find any public-facing info on if anyone has done work on it yet, trying to get a feel before I start so I don't duplicate work.

Also, in poking around, Carrier IQ seems active on the AT&T Build. Surprised more people aren't up in arms over this given it's previous reception

Message me

 

[Da_G]

Message me, I'm taking a look at the SBL right now. I also found the source for it...

Hi Ryan, I surely am interested in looking at the SBL source also. Is it a generic platform source or specific to the AT&T variant?

PM sent.

 

[tazman171]

Hey Da_G! Just got the AT&T Note III myself, dropped my G-Note and broke it, but don't have any of the hardware needed to do what you are doing. Will be following this thread though and great hearing from you again.

 

[Da_G]

I don't have any of the hardare needed anymore either. Flying blind

And I just missed a byte flashing to aboot, bam, hard brick. Lets see if i can recover

 

[Da_G]

SD Card restore worked wonderfully. http://forum.xda-developers.com/showthread.php?t=2476353

Had made a 500mb image beforehand, wrote it to SD, booted from it, then flashed previously-dumped aboot back, fixed right up.

 

[radicalisto]

SD Card restore worked wonderfully. http://forum.xda-developers.com/showthread.php?t=2476353

Had made a 500mb image beforehand, wrote it to SD, booted from it, then flashed previously-dumped aboot back, fixed right up.

Nice, I managed to hard brick testing N900w8 bootloader on my N9005, Reason I was playing around is the N900w8 has the capability of downgrading from 4.4.2 NA2 to 4.3 and rooting via CF-Autoroot without tripping KNOX and upgrading/downgrading again with zero issues. - I flatlined straight out

 

[xclub_101]

SD Card restore worked wonderfully. http://forum.xda-developers.com/showthread.php?t=2476353

Had made a 500mb image beforehand, wrote it to SD, booted from it, then flashed previously-dumped aboot back, fixed right up.

For the research involved here it might be interesting to test IF the boot restrictions applied when booting from internal flash are still applied when booting from the external microSD - so for instance if you are on MJ7 bootloader now and you brick it you might want to first test is you can unbrick with a recovery image made from the older MI7 bootloader! (those are versions on N9005 but you should get the idea since most Note3 versions have gone through at least 2 bootloaders so far).

A few other things that I would like to contribute:

- the check on the very, very first bootloader is apparently weaker than any other security check after that - as far as I remember that one might be "fooled" by updating a 32-bit hash, which could be brute-force attacked in a decent time; everything after that initial step is on the same level as a brute-force attack on RSA (128 or 256, I do not remember);

- it might be interesting to also take a look at the trusted zone code (everything secure is pretty much done from there) and eventually find a way to dump the content of the qfuses (that might be needed in order to brute-force things later)

- it might be interesting to also look at the bootloader differences in the N9005W8 version - we already know that some of the keys involved in that case are controlled by somebody else than Samsung (Telcel)

- regarding debricking by booting from external SD - I now see that some/most Qualcomm models seem to NOT need any extra hardware signal, but Exynos models almost certainly do - search after 13-58_SM-N900_Boot_Recovery_Guide_rev1.0.pdf and you will see the official internal Samsung document on that (there is a similar one on the i9300)

- another interesting interesting document that might be worth reading in the context of knox and all SWREVs is called (13-74) Galaxy Note3 Unlocking for Reactivation Lock Guide Rev 5 0.pdf - but IMHO this is of less interest right now.

 

[KennyG123]

Thread cleaned
Reminder this is a Developers Only Discussion section
Take questions to your device Q&A section

 

[Cobaltikus]

KNOX WARRANTY VOID: 0x0

Referencing ODIN files here: http://forum.xda-developers.com/note-3-att/general/n900aucucnc2-odin-files-t2838117
In BL_N900AUCUCNC2
aboot.mbn (mmcblk0p6)
Address 0005F6E4 = "KNOX WARRANTY VOID: 0x%x"
So my question is: What if I just change that string to "KNOX WARRANTY VOID: 0x0"?
I know it's probably not going to work, but why not?
I would just go ahead and try it but I'm not ready to brick my device just yet.

....

Ok so I tried that and see that the auth failed in Odin 3.09 because the altered aboot.mdn within the BL tar causes a different md5 / different SHA1 hash, which is encrypted with RSA using the a public key which I believe is in the boot image, and I guess whatever is validating this has the private key so it can decrypt the encrypted md5 and compare it to the real md5. So if I want to edit aboot, I need to then encrypt the new md5 using the same public key... but then what would I do with that. I'm missing something. I'll get it. More reading...

On a good note, this did not flip the knox flag, nor did it brick my phone, so all is ok for now.

 

[benwaffle]

I think the files are signed with Samsung's private key (which we obviously don't have) and verified with their public key (likely in boot.img). So, no, you can't sign the modified boot image since you don't have the private key.

 

[Cobaltikus]

From what I know about rsa, the public key can only encrypt, and the private key can encrypt and decrypt. I don't know if that is the case here, but I'm guessing it is for now. Either way, "can't" is too strong a word for me. All encryption is crackable. I'm reversing the boot image and will figure it out eventually. The only two things that could possibly stop me are death, and someone else beating me to it.

Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app

 

[ryanbg]

From what I know about rsa, the public key can only encrypt, and the private key can encrypt and decrypt. I don't know if that is the case here, but I'm guessing it is for now. Either way, "can't" is too strong a word for me. All encryption is crackable. I'm reversing the boot image and will figure it out eventually. The only two things that could possibly stop me are death, and someone else beating me to it.

Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app

It's not encryption (well, sort of), but a signature. It's a 256 byte chunk of an 'encrypted' PKCS#1.5 padding and the SHA256 of the image (like aboot, or boot.img.) The private key does this 'encryption' and signing of the image hash, and the public key can simply verify/decrypt this signature to compare it with what it derives. If it matches, it returns 0 and continues to flash/boot/etc... If return =1 it will fail and boot/flash will be denied (like your Auth: fail in Odin.)

 

[Cobaltikus]

It's not encryption (well, sort of), but a signature. It's a 256 byte chunk of an 'encrypted' PKCS#1.5 padding and the SHA256 of the image (like aboot, or boot.img.) The private key does this 'encryption' and signing of the image hash, and the public key can simply verify/decrypt this signature to compare it with what it derives. If it matches, it returns 0 and continues to flash/boot/etc... If return =1 it will fail and boot/flash will be denied (like your Auth: fail in Odin.)

Thank you ryanbg! This information is truly helpful!

Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app

 

[Cobaltikus]

Does anyone know the address of the function which validates the signature? I've been looking at the NC2 binaries, but a more recent version would be just as helpful.

 

[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

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/kernel/lk/+/qcom-dima-8x74-fixes/platform/msm_shared/spmi.c