5,604,859 Members 33,745 Now Online
XDA Developers Android and Mobile Development Forum

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

Tip us?
 
xclub_101
Old
(Last edited by xclub_101; 1st March 2014 at 11:45 AM.)
#41  
Senior Member - OP
Thanks Meter 255
Posts: 979
Join Date: Oct 2012
Quote:
Originally Posted by ryanbg View Post
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.
...

1. TZ was known not to be device-specific and the overall protocol to talk to code in TZ and enter TEE was described using the privileged SMC instruction, for instance here:

http://blog.azimuthsecurity.com/2013...ootloader.html

However it is product-family specific (I would expect Qualcomm to be different than Exynos) and I doubt there are any easy attacks left on the TZ direction itself (that must be crypto signed and so on, and the easy attacks have been already described and presumably patched already).



2. Nice to see that somebody else confirmed that the rollback information is in rpmb - first that was mentioned by the z3x team (the guys selling the Easy-Jtag hardware solution) but since they will be using it for their product I do not think they will want to share anything they have learned about it



3. Still IMHO attacks on knox could be done in theory easier by "rollback" rather than finding a new major exploit in the current TZ code.



4. Given that you provided the link to that Nokia PDF on TZ - what is IMHO the scenario that seems more credible to me regarding knox flag is that a value (we believe at least 2 bits, possibly more than that but unlikely to be more than 8-16 bits) from the qfuses is combined with the "device secret" mentioned and a one-way computation (hash?) of that is stored somewhere in rpmb. On boot the computation is done again and is compared to the value in rpmb - when there is a match you have knox 0, when there is no match you have knox 1. When something which is considered important is seen (like for instance during boot any kernel or recovery that is not signed by Samsung) the first free bit in the qfuse is blown; this automatically changes the computed value, and since it no longer matches the one in rpmb we see knox 1; when Samsung (or T-Mobile, see the 2 threads above) does a warranty repair they can "restore" knox - but not by "unblowing" the qfuse (which is not possible), but instead they look-up the (public) unique ID of the device, then probably do a look-up for the "device secret" (most likely somewhere at Samsung), calculate the new hash and write that new value in the rpmb, so on the next boot the computed value now matches again the (now different) value in rpmb. In this scenario if we want a solution to reset knox we "only" need a way to calculate the secret and then a way to write it in rpmb. There is also the possibility that instead of calculating the new value outside the device (in that complex Samsung-involved way) they make a call inside the TZ, but that would be something to break any stupidity records since would by-pass the entire "device secret" effort.



5. One major mystery that remains in the above scenario is why N900W8 does not trigger the knox flag under certain conditions (like having TWRP as custom recovery) - still having the downgrade option is not anything special (probably the rollback restrictions are not added to the rpmb) but the TWRP recovery is certainly not signed by Samsung so at any boot knox should be set; possible explanations could be:
- the W8 boot process does not check recovery/kernel signatures on boot (?)
- the W8 boot process does the check but does not burn any other qfuse either on choice (??) or because they can not as a result of a bug (???) or as a result of already having all the qfuses blown (???? only makes sense if a very low number of bits of qfuses are dedicated to knox, 1 or at most 2).
N9005 Universal Root De La Vega / Mobile Odin Pro, Knox 0x0, MJ7
The Following User Says Thank You to xclub_101 For This Useful Post: [ Click to Expand ]
 
ryanbg
Old
#42  
Senior Member
Thanks Meter 466
Posts: 293
Join Date: Jan 2008
Location: Minnesota
Quote:
Originally Posted by xclub_101 View Post
1. TZ was known not to be device-specific and the overall protocol to talk to code in TZ and enter TEE was described using the privileged SMC instruction, for instance here:

http://blog.azimuthsecurity.com/2013...ootloader.html

However it is product-family specific (I would expect Qualcomm to be different than Exynos) and I doubt there are any easy attacks left on the TZ direction itself (that must be crypto signed and so on, and the easy attacks have been already described and presumably patched already).



2. Nice to see that somebody else confirmed that the rollback information is in rpmb - first that was mentioned by the z3x team (the guys selling the Easy-Jtag hardware solution) but since they will be using it for their product I do not think they will want to share anything they have learned about it



3. Still IMHO attacks on knox could be done in theory easier by "rollback" rather than finding a new major exploit in the current TZ code.



4. Given that you provided the link to that Nokia PDF on TZ - what is IMHO the scenario that seems more credible to me regarding knox flag is that a value (we believe at least 2 bits, possibly more than that but unlikely to be more than 8-16 bits) from the qfuses is combined with the "device secret" mentioned and a one-way computation (hash?) of that is stored somewhere in rpmb. On boot the computation is done again and is compared to the value in rpmb - when there is a match you have knox 0, when there is no match you have knox 1. When something which is considered important is seen (like for instance during boot any kernel or recovery that is not signed by Samsung) the first free bit in the qfuse is blown; this automatically changes the computed value, and since it no longer matches the one in rpmb we see knox 1; when Samsung (or T-Mobile, see the 2 threads above) does a warranty repair they can "restore" knox - but not by "unblowing" the qfuse (which is not possible), but instead they look-up the (public) unique ID of the device, then probably do a look-up for the "device secret" (most likely somewhere at Samsung), calculate the new hash and write that new value in the rpmb, so on the next boot the computed value now matches again the (now different) value in rpmb. In this scenario if we want a solution to reset knox we "only" need a way to calculate the secret and then a way to write it in rpmb. There is also the possibility that instead of calculating the new value outside the device (in that complex Samsung-involved way) they make a call inside the TZ, but that would be something to break any stupidity records since would by-pass the entire "device secret" effort.



5. One major mystery that remains in the above scenario is why N900W8 does not trigger the knox flag under certain conditions (like having TWRP as custom recovery) - still having the downgrade option is not anything special (probably the rollback restrictions are not added to the rpmb) but the TWRP recovery is certainly not signed by Samsung so at any boot knox should be set; possible explanations could be:
- the W8 boot process does not check recovery/kernel signatures on boot (?)
- the W8 boot process does the check but does not burn any other qfuse either on choice (??) or because they can not as a result of a bug (???) or as a result of already having all the qfuses blown (???? only makes sense if a very low number of bits of qfuses are dedicated to knox, 1 or at most 2).
I found a very interesting log file on my device that was hidden pretty deep...

Quote:
init_ddi_data: usable ddi data.
<LP> ODIN MODE
<LP> PRODUCT NAME: SM-N900V
<LP> CURRENT BINARY: Samsung Official
<LP> SYSTEM STATUS: Official
KL: API Status 0x0
KNOX KERNEL LOCK: 0x0
<LP> KNOX KERNEL LOCK: 0x0
WV: API Status 0x0
KNOX WARRANTY VOID: 0x0
<LP> KNOX WARRANTY VOID: 0x0
QFPROM oem_config1: 0x00000f03
<LP> QUALCOMM SECUREBOOT: ENABLE (CSB)
anti_en 0xf
QFPROM_RAW_AP_ANTI_ROLLBACK_ROW0_LSB: 0x10001
QFPROM_RAW_AP_ANTI_ROLLBACK_ROW1_LSB: 0x3
QFPROM_RAW_SPARE_REG19_ROW0_LSB: 0x0
<LP> RP SWREV: S1, T1, R1, A2, P0
<LP> WRITE PROTECTION: Enable
odin3_init()
udc_start()
The Following 4 Users Say Thank You to ryanbg For This Useful Post: [ Click to Expand ]
 
ant456
Old
#43  
Member
Thanks Meter 85
Posts: 65
Join Date: Apr 2013
Where did you find that bootloader log file I've only had my phone for a week so I still have the 14 day warranty so I can just exchange it at the store if you have any tests you want me to do
 
ant456
Old
#44  
Member
Thanks Meter 85
Posts: 65
Join Date: Apr 2013
This forum went underground too? Sounded like you guys were making some progress.
 
Walter.White
Old
#45  
Walter.White's Avatar
Senior Member
Thanks Meter 439
Posts: 515
Join Date: Nov 2013
Not sure how but this user claims to have reset Knox back to 0x0 http://forum.xda-developers.com/show....php?t=2671643

P.S. I hope once S5 is released, it gathers more developer attention and we can finally crack open this damn thing.


 
Mjoelnir77
Old
#46  
Member
Thanks Meter 21
Posts: 98
Join Date: Aug 2011
Would be interesting to know whether https://www.fsf.org/blogs/community/...alaxy-backdoor could be used to access stuff on knox devices (and patch the system that way) that Samsung would us not want to do ...
 
ryanbg
Old
#47  
Senior Member
Thanks Meter 466
Posts: 293
Join Date: Jan 2008
Location: Minnesota
Quote:
Originally Posted by Mjoelnir77 View Post
Would be interesting to know whether https://www.fsf.org/blogs/community/...alaxy-backdoor could be used to access stuff on knox devices (and patch the system that way) that Samsung would us not want to do ...
I've been looking into it the past couple of days. It may be possible to use an older modem and a hacked-together ServiceMode.apk to issue AT/DM/FTM commands directly to the modem. Decompile HiddenMenu.apk, there's all sorts of goodies in there. It's a little more complicated than I'd like to think, but it seems plausible. They have their own custom firmware/RIL library though, we don't have the luxury of using that to take advantage of the exploit, so we'll have to find another way.
 
siraltus
Old
#48  
Senior Member
Thanks Meter 318
Posts: 749
Join Date: Jan 2010
Hey, not much to go on here, but it could be taken as confirmation that the Knox flag is resettable using a secret unique to each handset:

http://forum.xda-developers.com/show...5&postcount=27
 
Zibri
Old
#49  
Zibri's Avatar
Senior Member
Thanks Meter 21
Posts: 119
Join Date: Dec 2010

 
DONATE TO ME
Quote:
Originally Posted by siraltus View Post
Hey, not much to go on here, but it could be taken as confirmation that the Knox flag is resettable using a secret unique to each handset:

http://forum.xda-developers.com/show...5&postcount=27
That's VERY likely to be true.
 
E:V:A
Old
#50  
E:V:A's Avatar
Recognized Developer
Thanks Meter 1441
Posts: 1,115
Join Date: Dec 2011
Location: -∇ϕ
Quote:
Originally Posted by ryanbg View Post
I found a very interesting log file on my device that was hidden pretty deep...
And where is that? (Do you know what wrote it?)

Quote:
Originally Posted by ryanbg View Post
I've been looking into it the past couple of days. It may be possible to use an older modem and a hacked-together ServiceMode.apk to issue AT/DM/FTM commands directly to the modem. Decompile HiddenMenu.apk, there's all sorts of goodies in there. It's a little more complicated than I'd like to think, but it seems plausible. They have their own custom firmware/RIL library though, we don't have the luxury of using that to take advantage of the exploit, so we'll have to find another way.
Any progress? I did something similar for the SGS3, found tons of goodies. I'd like to see what you have if anything new.
MSM8960 Info, Architecture and Bootloader(s)
El Grande Partition Table Reference
How to talk to the Modem with AT commands


Want to know when your phone is getting tracked or tapped?

Help us develop the IMSI Catcher / Spy Detector!
(To be part of the EFF & The Guardian Project toolsets.)
_______________________________
If you like what I do, just click THANKS!
Everything I do is free, altruism is the way!
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
I do not answer support related PM's.


Tags
knox, root
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes