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/04/unlocking-motorola-bootloader.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. :good: 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).
Last edited:
