Bigmac attack: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 29: Line 29:




=== Investigation of f00d reset registers ===
== Investigation of f00d reset registers ==
==== xSleep signal response ====
=== xSleep signal response ===
The theory here is that the f00d reset would only work after responding to xSleep signal from the f00d processor. This idea was inspired from second_loader and secure_kernel always ending with a sleep loop.
The theory here is that the f00d reset would only work after responding to xSleep signal from the f00d processor. This idea was inspired from second_loader and secure_kernel always ending with a sleep loop.


Line 36: Line 36:
reset is still unavailable from ARM after f00d is sleeping.
reset is still unavailable from ARM after f00d is sleeping.


====
=== f00d reset from ARM window ===
ARM can reset f00d to start secure_kernel. Once secure_kernel is started this functionality to reset f00d from ARM is disabled through some unknown mechanism.

Revision as of 18:21, 25 June 2018

Testing parameters for resetting the f00d processor. On normal boot ARM resets the f00d processor to load secure_kernel writing:

*REG32(0xE0010000) = 1;
*REG32(0xE0010000) = 0;

Testing this from lk after secure_kernel results in no change in state. The testing material is a f00d payload that is constantly updating a counter in DRAM. f00d state is verified by checking if this counter is updated.

Testing reset from f00d

The following is executed from f00d context:

*REG32(0xE0010000) = 1;
*REG32(0xE0010000) = 0;

Result

f00d processor stops updating CTR and bigmac no longer usable.

Testing half a reset post-secure_kernel operation from ARM

The following was executed from post-secure_kernel lk ARM context:

*REG32(0xE0010000) = 1

Result

No change in state.


Testing half a reset pre-secure_kernel operation from ARM

The following was executed from post-secure_kernel lk ARM context:

*REG32(0xE0010000) = 1

Result

secure-kernel failed to load, stuck at "wait 2".


Investigation of f00d reset registers

xSleep signal response

The theory here is that the f00d reset would only work after responding to xSleep signal from the f00d processor. This idea was inspired from second_loader and secure_kernel always ending with a sleep loop.

Result

reset is still unavailable from ARM after f00d is sleeping.

f00d reset from ARM window

ARM can reset f00d to start secure_kernel. Once secure_kernel is started this functionality to reset f00d from ARM is disabled through some unknown mechanism.