HW:SEP

For now, just some random notes gathered from initial tracing of the SEP and prior knowledge from other community members, should be updated as i start digging deeper

fair warning: these are very messy at the moment, but it’s to help me get some preliminary notes down on SEP stuff - a proper page will come later

Coprocessor information:

As with other coprocessors like DCP, this is an ASC coprocessor and thus communicates with the main AP through a similar mailbox interface and occasional shared buffers (in AppleSEPManager, they call these “OOL” buffers, supposedly out of line buffers). Unlike the other processors which run RTKit or a derivative of, SEP seems to run a custom OS Apple internally calls SEPOS. Additionally SEPOS itself seems to be broken up into many different applications that all run on the SEP itself.

SEP seems to authenticate its own firmware (evidenced by kernel strings saying that SEP has “accepted” the IMG4), and seemingly will panic upon failure to authenticate the firmware. SEP firmware is encrypted by a separate GID from the normal AP GID, so a bootchain vuln in iBoot won’t give you any ability to decrypt SEP firmware or load arbitrary SEP firmware unless you also manage to compromise SEP itself.

Compared to the other ASC coprocessors, SEP is the only one that seems to have dedicated storage (at minimum for any sensitive information like wrapped keys and such) that no other processor on the device can talk to.

T8112 ASC SEP mailbox base: 0x25E400000 (actual mailbox at +0x8000, like other ASC IOPs)

Endpoint information:

Gigalocker/xART format (thanks sven for this info!):

SEP Message format:

bits 0-7 - Endpoint number

bits 8-15 - a “tag” value (for the control endpoint, an inbound and outbound message may sometimes share tags)

bits 16-24 - message “type” (for the debug endpoint, 0x1 is )

bits 25-31 - message parameters (debug endpoint, this is always the endpoint the debug endpoint is responding/receiving info about)

bits 32-63 - some kind of data (can be either a pointer, or a configuration value)

SEP boot flow:

• iBoot preloads SEP firmware
• XNU sends a boottz0 message, bringing SEP into second stage boot
• XNU sends img4, SEP verifies integrity, if accepted, boots into SEP/OS
• Endpoint setup (haven’t finished gathering data on this part yet, but longest/most complex part by far)

xART init flow (incomplete atm, may be wrong):

(message type 0 is some sort of fetch request, message type 0x5 is a fetch response it seems for individual lockers) (tags seem to be increasing in the order of the lockers within the gigalocker)

//Gigalocker initialization (TODO: verify if later OS versions use the same format)


[cpu1] [SEPTracer@/arm-io/sep] [xarm] >0x0(None) 0000010000000213 (EP=0x13, TAG=0x2, TYPE=0x0, PARAM=0x0, DATA=0x100)


[cpu14] [SEPTracer@/arm-io/sep] [xarm] <0x13(None) 0000000000130113 (EP=0x13, TAG=0x1, TYPE=0x13, PARAM=0x0, DATA=0x0)


//SEP xART fetch from gigalocker (this xART itself seems to have many sublockers?)


[cpu0] [SEPTracer@/arm-io/sep] [xarm] >0x0(None) 0000000000000113 (EP=0x13, TAG=0x1, TYPE=0x0, PARAM=0x0, DATA=0x0)


[cpu10] [SEPTracer@/arm-io/sep] [xarm] <0x0(None) 0000010000000313 (EP=0x13, TAG=0x3, TYPE=0x0, PARAM=0x0, DATA=0x100)

SEP Trusted Accessory notes:

//ping
[cpu0] [SEPTracer@/arm-io/sep] [stac] >0xf(None) 00000000000ffc18 (EP=0x18, TAG=0xfc, TYPE=0xf, PARAM=0x0, DATA=0x0)

//pong
[cpu0] [SEPTracer@/arm-io/sep] [stac] <0xf(None) 00000000000ffc18 (EP=0x18, TAG=0xfc, TYPE=0xf, PARAM=0x0, DATA=0x0)

AppleTrustedAccessory talks to this endpoint, likely for the Touch ID sensor on external keyboards.

SEP backwards compatibility notes:

SKS IPC is negotiated on both the kernel side and SEP side, lowest compatible version between both will be the IPC used for communication between main processor and SEP.

This should ensure that SEP and OS can continue to be compatible with each other even if SEP gets upgraded (since it’ll just use the older IPC version). (potential question: in the Linux driver how should this be accounted for?)

Miscellaneous notes:

The control endpoint seems to reply to incoming requests with a message type of 0x1 and input parameters if something was successful (likely an ack/okay from SEP side if all is good) (at least for messages that set input/output length or pointers)

SKS is very spammy in normal mode as mailbox messages to/from sep with it as the endpoint are constantly being sent (this is likely because of how Data Protection works according to the Apple security guide, a lot of these likely are retrieving/updating keys from/to gigalocker)

Single-user mode is helpful when tracing, as SKS will not be nearly as spammy and we can capture the initialization sequence.

Questions:

• when the debug endpoint is notifying the AP that an endpoint has come to life, the “DATA” field has a value of 0x2020202, 0x1010101, 0x0, or 0x2020404

• why is there both an xars endpoint and an xarm endpoint?

• one part of the SEP shared mem buffer at the very beginning during endpoint setup changes the lower byte of the first 32-bit word from 02 to 1f. why would that be? is that a configuration bit? is that done by macOS or the SEP OS?

TODOs:

• build a table of message types and tags for all endpoints (in XNU logs, a lot of the messages seem to have parts of the true SEP message masked out)

• capture how a gigalocker is created (this is a long term thing)

• update the SEP tracer for Ventura

xART fetch notes:

during the locker fetch sequence, a large number of the messages have 0x100 as the “data” part. responses from the SEP with respect to a locker fetch/unwrap request will always have parameter 0x10. A response with type 0x5 is success, 0x7 is an error (at minimum it’s the error signaling that a user xART locker couldn’t be found)