Here is my little thread about Power NVRAM — another persistent key-value storage, located right on PMU chip. Only talking about iBoot context 
Modifying certain key there allows to enable debug UART on any boot loader (including DFU ones) very early and without touching normal NVRAM
https://twitter.com/nyan_satan/status/1156534325514575872?s=20
Both keys and values are unsigned 8-bit integers
Now let’s talk about known keys and values for them:
Now let’s talk about known keys and values for them:
0x0 — iBootState
Speaks for itself
Values:
Speaks for itself
Values:
0x1 — iBootDebug
The most interesting key for us. That’s the one that can enable debug UARTs and several other things
Values:
The most interesting key for us. That’s the one that can enable debug UARTs and several other things
Values:
kPowerNVRAMiBootDebugIAPSerial (1 << 0)
Enables primary debug UART (defined by DEBUG_SERIAL_PORT which is in its order defined by every iBoot target’s config header)
That’s what we need to set to get UART everywhere
Enables primary debug UART (defined by DEBUG_SERIAL_PORT which is in its order defined by every iBoot target’s config header)
That’s what we need to set to get UART everywhere
kPowerNVRAMiBootDebugAltSerial (1 << 1)
Enables secondary debug UART (defined by DEBUG_SERIAL_PORT2)
No target in the leaked iBoot source code defines DEBUG_SERIAL_PORT2
Enables secondary debug UART (defined by DEBUG_SERIAL_PORT2)
No target in the leaked iBoot source code defines DEBUG_SERIAL_PORT2
kPowerNVRAMiBootDebugJtag (1 << 2)
No, it doesn’t enable SWD-debugging unfortunately, but enables SHMCON (High-level shared memory console interface)
Not sure what that is exactly, must be another debug interface
No, it doesn’t enable SWD-debugging unfortunately, but enables SHMCON (High-level shared memory console interface)
Not sure what that is exactly, must be another debug interface
The rest of the iBootDebug values don’t seem to do anything interesting
0x2 — iBootStage
Speaks for itself
Values:
Speaks for itself
Values:
0x3 — iBootErrorCount
Remember that iBoot prints count of boot failures/panics in the end of its log? That’s where these counts are stored — lower 4 bits for boot failures and upper 4 bits for panics. That’s why they can’t be higher than 15
Remember that iBoot prints count of boot failures/panics in the end of its log? That’s where these counts are stored — lower 4 bits for boot failures and upper 4 bits for panics. That’s why they can’t be higher than 15
0x4 — iBootErrorStage
Speaks for itself. Failed iBootStage
Speaks for itself. Failed iBootStage
0x5 — iBootMemCalCAOffset0
0x6 — iBootMemCalCAOffset1
0x7 — iBootMemCalCAOffset2
0x8 — iBootMemCalCAOffset3
Something related to AMC — Apple Memory Controller
0x6 — iBootMemCalCAOffset1
0x7 — iBootMemCalCAOffset2
0x8 — iBootMemCalCAOffset3
Something related to AMC — Apple Memory Controller
0x9 — iBootBootFlags0
0xA — iBootBootFlags1
Related to PMU
0xA — iBootBootFlags1
Related to PMU
0xB— iBootEnterDFU
Another interesting key. If set to 0xA0, then on next boot LLB will enter DFU. Works since iOS 8
Another interesting key. If set to 0xA0, then on next boot LLB will enter DFU. Works since iOS 8
The easiest way to access Power NVRAM is DEBUG iBoot (or old enough RELEASE one with patched permission checks):
In case your device is too new to run iPhoneOS 3.0- iBoot and you haven’t got a DEBUG-one, soon I’ll post an instruction how to access it without these
• • •
Missing some Tweet in this thread? You can try to
force a refresh
