[Xperia Z Original Android Development] Tungstwenty:
[MENTION=3665957]the_laser[/MENTION] and [MENTION=2784807]DooMLoRD[/MENTION]:

I have analyzed a fairly big portion of the aboot code and also some portions of the TZ. This was somewhat new to me, in particular the concept of the secure vs non-secure mode, and the consequence that even the kernel code cannot access everything. User vs Supervisor is not the same as Secure vs Non-Secure; the kernel runs as system/supervisor/irq/etc. but non-secure, and only the TZ and other trusted code runs as Secure

:good: for having learned something new, :( for the apparent conclusion that the secure world cannot be tampered with.

Even though all the secure code is available for reading and analysis, due to the chain of validations it shouldn't be possible to modify the behavior that invalidates the DK if the RCK is present. Unless an exploit is found on that code...

I was thinking if there was any way to try to get the BE2 working. Do you know if any of these would be valid?

1. Replace the kernel at runtime

Having root, would it be feasible to let the locked bootloader load (and verify) the signed kernel, have it run the initramfs binaries, and at the first opportunity that /system/* binaries are executed trigger the load of a kernel module *.ko that would load a new kernel image (from a specific file or unused partition) to replace the current one - kexec perhaps???

I'm not sure if this is possible because of the state that the original kernel leaves the hardware in (mmc controller, filesystem divers, etc.) - having a "hard" jump to a fresh kernel might not work at all...

2. Patch kernel or userland libraries to not jump to TZ but to other code for the BE2 calculations

This would require:

- the memory and other hw resources used for implementing the BE2 could be accessed from non-secure mode

- the TZ relevant code be reversed and recompiled to work as part of the regular kernel (non-secure)

- calls to the secure code be hijacked and directed to the alternate implementation

- the keys used for the process can be obtained so they are fed to the decoding engine

It is almost certain that this won't be doable, as it would mean that the implementation wasn't properly secured (hw resources and special memory addresses). And if that were true, it would be more likely to find an exploit to patch the TZ so it could receive the DK and work as if it was present all along.

For those into the tech stuff, this page gives a very good highlight of the TrustZone concept. I should have read it before spending so much time on ARM disassembly :o. Assuming it is properly implemented, approach 2 is probably impossible.

One thing I found on the aboot code is that a "root override" setting exists (not sure yet where it comes from) but it appears to only be related with being able to flash all partitions in flashboot even with the bootloader locked, and to unlock even if ROOTING_ALLOWED is 0. The kernel signature validation might not be affected by this.

Also, according to [MENTION=3665957]the_laser[/MENTION] the tokens are signed with a private key, although not all - for instance the DK, RCK, etc. are changed dynamically so they can't be signed. Perhaps only the SIN token and others like that, which are shipped with the device from the factory and not changed on the field - at most, deleted.