A few things on knox / rooting and bootloaders that need more testing / development

[st3chn0]

Those are 3 links since I also wanted to keep some of the "history" on how that was discovered/announced, but the 3rd link is from the guy that actually sells the box and from what I see is saying:

"What this mean ? After replacing or WIPING eMMC and burning old bootloader on device with (KNOX Warranty: 0x01 ) You will get device with unknoxed boot and KNOX Warranty bit 0x0"

And then there is a long list of Exynos devices that are supported, including

Samsung SM-N900 Galaxy Note 3
Samsung SM-N9000Q Galaxy Note 3

and then a separate (and partial) list of the Snapdragon models that are NOT supported.

I have not tested the box personally and that is why I wrote from the very beginning in my original post "claims to be able to reset the knox flag on Exynos devices".

And to finish with that box and the claims they still make on Snapdragon - if they get (in a very controlled and non-destructive) way to remove the downgrading restrictions from the bootloader I think it might still be an interesting achievement - since that way you could revert any device with knox 0x0 to MI7, root and then go to whatever 4.3 or 4.4 you want. But of course that even in that scenario you need that box

if you follow through with the thread posts four links back to another one of links. I know he states that he has reset knox, had started making claims for knox reset bounty in the general forum.I had asked for evidence as everyone XDA should show, he had then posted a video which shows resetting the warranty bit on a 4.2.2 bootloader which has no links to knox. if you do a search in that thread im sure you would be able to find this.

 

[xclub_101]

if you follow through with the thread posts four links back to another one of links. I know he states that he has reset knox, had started making claims for knox reset bounty in the general forum.I had asked for evidence as everyone XDA should show, he had then posted a video which shows resetting the warranty bit on a 4.2.2 bootloader which has no links to knox. if you do a search in that thread im sure you would be able to find this.

I think you are confusing what Babak initially said (who discovered the method and then also claimed it might work on Snapdragon and then admitted he was wrong) with the very final post (which as I write this is the topmost sticky) from NoName, the guy that sells the box. While for Babak it was a matter of "dev karma", for NoName is a matter of money. We'll probably soon know more.

 

[Surge1223]

Heres some info that might help you guys. I've also attached viewmem in case you guys don't already have it compiled. You can use it to further investigate. View attachment viewmem.zip

Full-size image
​

 

[ryanbg]

I don't believe that is true. I have compared my flags with other stock btu with the same bootloader and firmware all my flags other than that my P flag is still 0

Also OP needs to recheck the sources regarding knox reset these are for warranty bit on the s4 (android 4.2.2 and below) the supposed claim of knox reset only resets the flash counter. Similar to what triangle away has done in the past

Sent from my SM-N9005 using xda app-developers app

I have another theory. The SBL1 I downgraded to was from an engineering build. It could be possible this is some sort of production/debugging flag? I know I can reproduce indefinitely the P1 flag to P0 with a simple SBL1 downgrade, but I'm not sure what the implications of this is, or why. I'm not sure what P is, but we can modify whatever it is since the rollback protection number is 0.

 

[st3chn0]

I have another theory. The SBL1 I downgraded to was from an engineering build. It could be possible this is some sort of production/debugging flag? I know I can reproduce indefinitely the P1 flag to P0 with a simple SBL1 downgrade, but I'm not sure what the implications of this is, or why. I'm not sure what P is, but we can modify whatever it is since the rollback protection number is 0.

Could be linked to SBL1 but I don't understand why my flag hasn't increased and I've done all updates ota. If I've had to reinstall I've used odin but I have never ticked the update bootloader option

Sent from my SM-N9005 using xda app-developers app

 

[ryanbg]

Could be linked to SBL1 but I don't understand why my flag hasn't increased and I've done all updates ota. If I've had to reinstall I've used odin but I have never ticked the update bootloader option

Sent from my SM-N9005 using xda app-developers app

I know for a fact it's linked to SBL1. Flags are device independent, based on carrier updates. They use the flag counter for milestone updates to prevent rollback. Each carrier's device will be different. I know some S4's have P6, some European devices have P3. I've been analyzing SBL1 in IDA and I can't find the counter that rolls back P to 0. I know where the counters are kept in the image blobs, SBL1 might have two, with one being hidden. It could have something to do with PBL too.

 

[Walter.White]

I know for a fact it's linked to SBL1. Flags are device independent, based on carrier updates. They use the flag counter for milestone updates to prevent rollback. Each carrier's

Definitely true. For instance MI1 (4.3) & MI9 (4.3) had ALL flags ending in 1 but once they released MJ5 ALL flags changed to ending of 2. Then they released NB4 (4.3) about 2 days ago and ALL the flags still end in 2. Interestingly enough though the leaked MLG (4.4.2) didn't change any flags either... All of them still end in 2 so that's the reason why we can still downgrade back to MJ5 and not to MI9. I guess they don't change flags till the final release!?

Also I wonder if the flags are related to # of fuses blown or simply a counter stored somewhere on eMMC. If it's former than we might have a big problem.

 

[ryanbg]

Definitely true. For instance MI1 (4.3) & MI9 (4.3) had ALL flags ending in 1 but once they released MJ5 ALL flags changed to ending of 2. Then they released NB4 (4.3) about 2 days ago and ALL the flags still end in 2. Interestingly enough though the leaked MLG (4.4.2) didn't change any flags either... All of them still end in 2 so that's the reason why we can still downgrade back to MJ5 and not to MI9. I guess they don't change flags till the final release!?

Also I wonder if the flags are related to # of fuses blown or simply a counter stored somewhere on eMMC. If it's former than we might have a big problem.

We know where the flag values are kept inside of .mbn images like aboot and sbl1. I can even modify the flags, but the problem is that when I do, I break the hash so it won't flash. Device side, I know there are calls made to QFPROM, but as I demonstrated earlier, I can change the P flag, which makes me believe we can change any flag.

 

[Walter.White]

I can even modify the flags, but the problem is that when I do, I break the hash so it won't flash. Device side, I know there are calls made to QFPROM, but as I demonstrated earlier, I can change the P flag, which makes me believe we can change any flag.

I guess we need to figure out a way to bypass hash checking by patching the verification call for it or something. Or we need to find a disgruntled Samsung employee who will release the signing key.

I guess once S5 is released.. many more developers will start digging thru this and hopefully someone will crack it open.

 

[st3chn0]

Definitely true. For instance MI1 (4.3) & MI9 (4.3) had ALL flags ending in 1 but once they released MJ5 ALL flags changed to ending of 2. Then they released NB4 (4.3) about 2 days ago and ALL the flags still end in 2. Interestingly enough though the leaked MLG (4.4.2) didn't change any flags either... All of them still end in 2 so that's the reason why we can still downgrade back to MJ5 and not to MI9. I guess they don't change flags till the final release!?

Also I wonder if the flags are related to # of fuses blown or simply a counter stored somewhere on eMMC. If it's former than we might have a big problem.

After many updates my P flag still remains at 0 and I'm on mk2 that's why I believe it isn't

Sent from my SM-N9005 using xda app-developers app

 

[ryanbg]

After many updates my P flag still remains at 0 and I'm on mk2 that's why I believe it isn't

Sent from my SM-N9005 using xda app-developers app

Again, every deice and carrier will have different flags. You say you're on MK2, which means you're probably on an S4. You could do a billion updates and still get P0 as long as your carrier chooses to leave it like that for each software update.

 

[st3chn0]

Again, every deice and carrier will have different flags. You say you're on MK2, which means you're probably on an S4. You could do a billion updates and still get P0 as long as your carrier chooses to leave it like that for each software update.

just realised it has now changed to P2 since the last time i checked which was around 10 days since then, I havent changed anything

 

[xclub_101]

just realised it has now changed to P2 since the last time i checked which was around 10 days since then, I havent changed anything

P is a more "special" flag - unlike S T R A (which change immediately after you update firmware), the P seems to also change without firmware update - since my post here:

http://forum.xda-developers.com/showthread.php?t=2567165

I have not touched Odin or Mobile Odin Pro and yet P has changed from 1 to 2, the only system-related things that I did were:

- reactivation lock ON

- hide the custom status in Wanam Xposed.

 

[ryanbg]

P is a more "special" flag - unlike S T R A (which change immediately after you update firmware), the P seems to also change without firmware update - since my post here:

http://forum.xda-developers.com/showthread.php?t=2567165

I have not touched Odin or Mobile Odin Pro and yet P has changed from 1 to 2, the only system-related things that I did were:

- reactivation lock ON

- hide the custom status in Wanam Xposed.

I've seen that thread, I was also able to get SECURE BOOT: NONE on my device, but only lasted for a single reboot. I believe this is related to some sort of MMC error handling or corruption. I noticed my P flag went from 0 to 1 since you mentioned, but I can reset it indefinitely. I'm sitting here scratching my head...

 

[xclub_101]

I've seen that thread, I was also able to get SECURE BOOT: NONE on my device, but only lasted for a single reboot. I believe this is related to some sort of MMC error handling or corruption. I noticed my P flag went from 0 to 1 since you mentioned, but I can reset it indefinitely. I'm sitting here scratching my head...

So far I believe it is more productive to think of the S T R A P flags as "debug info" rather than the same kind of stuff as the knox flag.

There was also a very interesting thread here - it sounds like a "pre-production" Note 3 that had no knox:

http://forum.xda-developers.com/showthread.php?t=2657631

 

[ryanbg]

So far I believe it is more productive to think of the S T R A P flags as "debug info" rather than the same kind of stuff as the knox flag.

There was also a very interesting thread here - it sounds like a "pre-production" Note 3 that had no knox:

http://forum.xda-developers.com/showthread.php?t=2657631

I know STRA at least are Rollback Protection counters. I was able to verify QFPROM calls in aboot. You have gtalk?

 

[siraltus]

So far I believe it is more productive to think of the S T R A P flags as "debug info" rather than the same kind of stuff as the knox flag.

There was also a very interesting thread here - it sounds like a "pre-production" Note 3 that had no knox:

http://forum.xda-developers.com/showthread.php?t=2657631

I don't think it didn't have Knox, I ran that app on my two-weeks-old SM-900T with Knox 0x1 and it also said "Knox warranty bit not found." I think the app is just buggy and doesn't know how to look for the Knox warranty bit on all devices.

 

[xclub_101]

I don't think it didn't have Knox, I ran that app on my two-weeks-old SM-900T with Knox 0x1 and it also said "Knox warranty bit not found." I think the app is just buggy and doesn't know how to look for the Knox warranty bit on all devices.

The 900T might be out of the list of devices known, but EU N9005 should be well inside the list. Moreover the firmware version that the guy has is earlier than any EU N9005 firmware that I could find. Of course that does not prove anything, but would be interesting to double-check.

 

[siraltus]

The 900T might be out of the list of devices known, but EU N9005 should be well inside the list. Moreover the firmware version that the guy has is earlier than any EU N9005 firmware that I could find. Of course that does not prove anything, but would be interesting to double-check.

Agree, I'm just saying that the app is kinda wonky.

 

[ryanbg]

I've done a bit of reverse engineering, and I've discovered two very important pieces of information.

1. TrustZone appears to not be device specific, you could most likely flash any N3 TZ and possibly even S4/N2, as long as it is signed properly.

2. It appears rollback information is stored in the rpmb. I found a string in TZ.mbn directly indicating so.

Here's my idea; Since the only way to communicate with TrustZone is via TEE (Trusted Execution Environment) or in our case QSEE (Qualcomm Trusted Execution Environment) which is a proprietary stack. The device driver for QSEE is /dev/qseecom. I'm doing some experimenting on whether it'll accept commands or data, but this looks to be the most promising route. If it were possible to rollback the counters to 0, which I know now to be rpmb based so we can most likely reset them, we could flash an old aboot that exists from MHV or MG3 (I might be able to insert the certificates MG3 since it is not signed, but it's 4.2.2 based.) I'm able to see much lower level debug and logging information thanks to @Surge1223. The files in /firmware/image and /system/etc/firmware are elf images of TZ HLOS applications. Another place to start investigating more thoroughly. I would not be surprised to find Knox related things too.

After an attempt of provisioning rpmb:

D/ (24162): TAL: TIMA_backend_open--int8_t TIMA_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: QCOM_backend_open--int8_t QCOM_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: tima-pkm--Attempting to load TZAPPS
D/QSEECOMAPI: (24162): QSEECom_get_handle sb_length = 0x104e80
E/QSEECOMAPI: (24162): Error::Failed to open /dev/qseecom device
E/ (24162): TIMA: tima-pkm--Unable to start TZ app; errno = 9
D/ (24162): TAL: TIMA_backend_open--int8_t TIMA_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: QCOM_backend_open--int8_t QCOM_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: tima-pkm--Attempting to load TZAPPS
D/QSEECOMAPI: (24162): QSEECom_get_handle sb_length = 0x104e80
E/QSEECOMAPI: (24162): Error::Failed to open /dev/qseecom device
E/ (24162): TIMA: tima-pkm--Unable to start TZ app; errno = 9
D/ (24162): TAL: TIMA_backend_open--int8_t TIMA_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: QCOM_backend_open--int8_t QCOM_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: tima-pkm--Attempting to load TZAPPS
D/QSEECOMAPI: (24162): QSEECom_get_handle sb_length = 0x104e80
E/QSEECOMAPI: (24162): Error::Failed to open /dev/qseecom device
E/ (24162): TIMA: tima-pkm--Unable to start TZ app; errno = 9
D/ (24162): TAL: TIMA_backend_open--int8_t TIMA_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: QCOM_backend_open--int8_t QCOM_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: tima-pkm--Attempting to load TZAPPS
D/QSEECOMAPI: (24162): QSEECom_get_handle sb_length = 0x104e80
E/QSEECOMAPI: (24162): Error::Failed to open /dev/qseecom device
E/ (24162): TIMA: tima-pkm--Unable to start TZ app; errno = 9
D/ (24162): TAL: TIMA_backend_open--int8_t TIMA_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: QCOM_backend_open--int8_t QCOM_backend_open(void**, appID, uint32_t, uint32_t)
D/ (24162): TIMA: tima-pkm--Attempting to load TZAPPS
D/QSEECOMAPI: (24162): QSEECom_get_handle sb_length = 0x104e80
E/QSEECOMAPI: (24162): Error::Failed to open /dev/qseecom device
E/ (24162): TIMA: tima-pkm--Unable to start TZ app; errno = 9

Hmm...


More information: RPMB Secure Boot PDF