Thread by @nyan_satan

Here is another little thread of mine about Tatsu Auth Debug - this time we’ll sniff whatever happens between Astris and the Apple’s server

As always read on your own risk!

To understand what’s going on here, it’s highly recommended to read the first part

By default Astris wants to connect to https:// gs.apple.com :443 (public TSS, spaces are used so Twitter won’t short it), but we can override it by modifying “TatsuServer” field in astris_prefs.plist which is located at ~/Library/Application Support/Astris

We pointed Astris to a VPS of mine with NGINX that proxies whatever coming to the TSS and logs out request/response

Had to use this approach because local SSL proxies (such as Charles) didn’t work for some reason (at least my tester couldn’t set it up)

But apparently TSS happily works under HTTP, so this was an overkill

Overkill or not, but we got what we wanted - debug auth request (for a DVT iPhone 12 Pro Max, so latest SoC rev) and response (unsuccessful, of course)

pastebin.com/KJmRxneF

Most of the fields speak for themselves - Board ID, Chip ID, Security Domain, ECID, CPFM and nonce (doesn’t match with the APTicket nonce and is shorter)

What “EnAppleDebugExternal” and “TicketIdentifier” mean is currently unknown to me

Since now we know what request looks like, it would be also nice to know what proper response looks like. We tried to send the (pre-) EVT device’s data (the device is actually Proto2 btw), but wasn’t accepted. Apparently it never required the auth in the first place

But hey, Tatsu wouldn’t be Tatsu if it didn’t allow more things with zeroed ECID! Let’s try this. And wow! It works

pastebin.com/5v9sHgPu

Let’s decode the ticket from Base64. The result looks very much like an Image4 manifest (ASN.1)

Let’s decode it with OpenSSL. Apparently the ticket is split into 2 parts - IM4M (picture 1, without any Image4 hashes, obviously) and IM4C (picture 2, no idea what that is)

It’s currently unknown to me what happens with the ticket afterwards - whether it’s sent to a device in full, or something extracted from it first. Astris can probably answer this question, at least partially, but obviously requires more RE

I also tried to change Chip ID in the request to other ones from 2020 lineup:

T8103 (M1)
T8301 (S6)

Both returned success (with ECID 0, I mean), so it’s safe to assume these SoCs use the debug auth mechanism as well

I also tried some new yet unreleased SoC - T6001 (cc. @never_released) and it returns success, too. Older Chip IDs (such as T8030) return error (94)

Conclusions:
1) Debug auth is used since A14 (M1, S6), except for some early revisions (at least we could SWD/KIS into the A14 rev 00)
2) Future SoCs are gonna use it too
3) The end of prototype fun?

Credits/thanks to:
@1nsane_dev

Stay tuned for more information!