Translate to Thunderbolt DFU to support T2 security chips

[rickmark]

The T2 processor is almost identical in DFU protocol to USB DFU, but instead uses Thunderbolt as the transport. Because of this sending the same payloads over Thunderbolt DFU will likely allow it to be used with the T2 chip as well.

[h0m3us3r]

@aunali1 your photos are for different model (2018 vs 2019), and they did indeed help.

No, sorry, shoulve been more clear there, force_dfu still needs to be shorted to 1v8. I just ment that battery is not needed for dfu contrary to most (all) info I could find.

[rickmark]

Interesting, you’re saying the T2 is bus powered by the usb host (which means a hub where you can power on and off to reset)

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: h0m3us3r notifications@github.com Sent: Friday, February 28, 2020 1:14:07 PM To: axi0mX/ipwndfu ipwndfu@noreply.github.com Cc: Rick Mark rickmark@outlook.com; Author author@noreply.github.com Subject: Re: [axi0mX/ipwndfu] Translate to Thunderbolt DFU to support T2 security chips (#141)

@aunali1https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faunali1&data=02%7C01%7C%7C57230d34607940a0c7cf08d7bc9325e1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637185212483013920&sdata=h5Tej%2FmdXxPQptwVc4g4FSut7TNid3eBbTl0F9YqRT0%3D&reserved=0 your photos are for different model (2018 vs 2019), and they did indeed help.

No, sorry, shoulve been more clear there, force_dfu still needs to be shorted to 1v8. I just ment that battery is not needed for dfu contrary to most (all) info I could find.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faxi0mX%2Fipwndfu%2Fissues%2F141%3Femail_source%3Dnotifications%26email_token%3DAAA6TWZUITNXDNS27IXL7P3RFF5B7A5CNFSM4I57JPEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENKFZDI%23issuecomment-592731277&data=02%7C01%7C%7C57230d34607940a0c7cf08d7bc9325e1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637185212483013920&sdata=oNW5GCkxjEE%2F637Vidkgf1pa1umPougvhJ6oIv7zAqo%3D&reserved=0, or unsubscribehttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAA6TW3BVYN335VE7CS2VBTRFF5B7ANCNFSM4I57JPEA&data=02%7C01%7C%7C57230d34607940a0c7cf08d7bc9325e1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637185212483023925&sdata=9K%2BsWA5IozksQk9YSEzwokhyNxmEu2zMjvzvp0nvU94%3D&reserved=0.

[h0m3us3r]

Bad news. Brute finished. Pointers not found :'(

Possible reasons:

1. Wrong offset range.
2. LOAD_ADDRESS needs to be different (but I don't seem to understand why is it different for t8010/t8011 vs t8015 to begin with and whether it is even important).
3. All of the above.
4. All of the above plus something else. Aka using t8010/t8011 procedure was wrong to begin with, and it needs to be done t8015/some other unknown way.
5. I am an idiot and fked something up in the code during transition t8010 -> t8012.

[h0m3us3r]

@rickmark

Interesting, you’re saying the T2 is bus powered by the usb host (which means a hub where you can power on and off to reset)

Yes, but if the battery is still plugged in, just cycling usb power will not reset T2. I am doing it with a usb cable, a relay spliced into the 5v line, and an arduino that controls said relay via serial. Keep in mind that FORCE_DFU still needs to be shorted to 1v8. On the plus side, there is absolutely no need to control FORCE_DFU; leaving it shorted to 1v8 at all times is perfectly fine (I was not sure about that, and it's the reason why my arduino code is made to control another relay that shorts FORCE_DFU).

[rickmark]

This makes some sense: since the T2 ate the SMC which controls system power battery etc, and needs be programmed on a new board, it makes sense that it could operate on separate power...

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: h0m3us3r notifications@github.com Sent: Friday, February 28, 2020 3:57:43 PM To: axi0mX/ipwndfu ipwndfu@noreply.github.com Cc: Rick Mark rickmark@outlook.com; Mention mention@noreply.github.com Subject: Re: [axi0mX/ipwndfu] Translate to Thunderbolt DFU to support T2 security chips (#141)

@rickmarkhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frickmark&data=02%7C01%7C%7Cce27fce2daa54c8a8d5508d7bcaa014d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637185310654937348&sdata=WKOMmclyaPeJKQmfuhyWTiQ%2F19TUphFEo8ude7VQynw%3D&reserved=0

Interesting, you’re saying the T2 is bus powered by the usb host (which means a hub where you can power on and off to reset)

Yes, but if the battery is still plugged in, just cycling usb power will not reset T2. I am doing it with a usb cable, a relay spliced into the 5v line, and an arduino that controls said relay via serial. Keep in mind that FORCE_DFU still needs to be shorted to 1v8. On the plus side, there is absolutely no need to control FORCE_DFU; leaving it shorted to 1v8 at all times is perfectly fine (I was not sure about that, and it's the reason why my arduino code is made to control another relay that shorts FORCE_DFU).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faxi0mX%2Fipwndfu%2Fissues%2F141%3Femail_source%3Dnotifications%26email_token%3DAAA6TW2BLKZOUIPI7775P7TRFGQHPA5CNFSM4I57JPEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENKSRPY%23issuecomment-592783551&data=02%7C01%7C%7Cce27fce2daa54c8a8d5508d7bcaa014d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637185310654947348&sdata=3N4yN6GsEOCZYhmh04ncKa38JzUNfpBpypvTCmwcxs4%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAA6TW6A44WCKUUFPEOBX4TRFGQHPANCNFSM4I57JPEA&data=02%7C01%7C%7Cce27fce2daa54c8a8d5508d7bcaa014d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637185310654957339&sdata=zm4wss4CwMhx4IP94N%2FNlOvNgalJwGhsBdEhJWhCmjM%3D&reserved=0.

[h0m3us3r]

That is not a feature unique to T2 by the way. All Ax's are same too. Not sure about Sx's, but wouldn't be surprised if they do same too.

[aunali1]

@rickmark So for the 2019 MBA it requires some more modification to the MLB. Rather than a button, it is a bog-standard test point. Also, based on these images, you'll need to solder a 2.2k Ohm 1/20W 5% SMD resistor on R8010 (in yellow).

[h0m3us3r]

@aunali1 I have 2019 Pro, not Air. But anyway, I found it yesterday already, it is a button. I was looking near T2, but it is across whole board, near battery connector. I already run a brute, and got no pointers...

Out of frustration, and due to the lack of further ideas, I'm setting another brute with about 130,000 combinations. Will give me a ~4 days break to think about some other way, because something tells me it will be nothing again.

[MCMrARM]

How do you check whether the brute gave meaningful results?

[MCMrARM]

also, tbh unfortunate that the iBoot on the t8012 is actually newer than t8015; otherwise we'd be able to do more meaningful assumptions.

edit: doesn't this basically make these likely ranges not really likely? https://github.com/h0m3us3r/ipwndfu/commit/8c87ff9f4c2a4736e56819b9db13d1570e407f83#diff-24c8c2126a7bd4a92b45374fbf1a82e4R199

edit2: According to my memory layout exploitation tests, on the T2 the PCIe part of iBoot is disabled/removed. Therefore it might be possible that the function moved to an even lower address.

[h0m3us3r]

It is not newer than t8020, it is between t8015 and t8020 (closer to t8015). Both roms are available.

[h0m3us3r]

Comparing t8015 an t8020 was how I got my 1st brute range. But I went with the assumption that the procedure needed for t8015 is silicon related, and used t8010 procedure, which might not be true.

[h0m3us3r]

@MCMrARM

How do you check whether the brute gave meaningful results?

If offsets are correct, we get code execution, and the cpu gets stuck in B 0 (branch to offset 0, or to itself, the 0x00000014 opcode). It will disconnect from host in the process and we wont be able to dfu.acquire_device()

If offsets are incorrect, T2 will crash, but since we have FORCE_DFU asserted, it will boot straight into dfu, and we will be able to dfu.acquire_device(). We can try next combination immediately if this is the case.

There is another possible outcome, but it happens quite rarely: the exploit didn't work. In this case, T2 does not crash, nor gets stuck. We can dfu.acquire_device(), but it takes much less time than if T2 crashed (1 ms vs ~900 ms for T2). If we get this outcome, we have to reset the T2 before we try the next combination of offsets.

[h0m3us3r]

@MCMrARM

doesn't this basically make these likely ranges not really likely?

Why would that be?

[MCMrARM]

I wonder if the t8012t8020 has the PCI subsystem enabled in SecureROM.

Well, I messed up with the t8020/t8015 thing, so I guess you're right, it makes sense. If indeed t8015 had bootrom older than t8012 then the offset range would be most likely completely different.

edit: meant t8020, not t8012 so corrected that, I am pretty sure that t8012 has it disabled.

[h0m3us3r]

~~Not sure how I missed it the first time, but I am a dummy, took a look at my 1st range, and the result is just slightly out of it. Anyway, my second run found func_gadget: 0x10000ad14 write_ttbr0: 0x1000004a4 as a possible combination.~~

This still does not give us pwndfu, as we don't know a big lot of other pointers, but (if those two are correct, further testing needed), we do have code execution now, and can do memory search for the missing ones. My asm-fu is not strong enough for that though.

False alert, pointers are wrong.

[MCMrARM]

If we do achieve code exec, I should be able to do shellcode for finding the remaining ones.

[MCMrARM]

@h0m3us3r I mean I can't 100% guarantee it wasn't already disabled on the t8010 (I think I checked it and it wasn't disabled there but honestly this was like half a year ago) but the t8012 disabled the PCI subsystem and wouldn't this break the heap spray?

I remember trying to figure out the proper offset for heap spraying but never managed to match it up with ipwndfu's for some reason. (I can share my code; it's a C project that does allocations in the same order as iBoot and of the same size; based on the allocator from the leaked iBoot source code). It was always off by 0x40, and I have no idea what did I do wrong.

edit: might be unclear; never managed to match it up on t8010.

edit2: the reason why I mention the removal of the PCI subsystem is because it removes the pci bridge allocation (it is a 0x200 structure), so this can definitely affect things, just not sure if at this point or not.

edit3: not sure how useful this broken code is but according to it the missing allocation shouldn't change anything but i mean, that can be just as well wrong because it's off by 0x40.

[h0m3us3r]

@MCMrARM, @rickmark I suggest moving this conversation off of this issue thread and to slack/discord. PM me at h0m3us3r@warranty-void.com for an invite if you agree.

[h0m3us3r]

Quick question: what determines load_address?

@MCMrARM, I sent you the invite btw, did you get it?

[rickmark]

226 resolves this issue

[rickmark]

I feel like we can close this issue as resolved,

As I understand PRs are not being accepted

[sasimaci]

Found: CPID:8012 CPRV:10 CPFM:03 SCEP:01 BDID:18 ECID:000D253202230026 IBFL:3C SRTG:[iBoot-3401.0.0.1.16] ERROR: This device is not supported. mac@macs-MacBook-Pro ipwndfu % any help !!

[h0m3us3r]

Use my or @MCMrARM fork.

[jbwaring]

@aunali1 Dear Aunali1, could you share your sources for the board pictures with t2 force dfu pads? I am trying to get an A2141 to dfu without the internal keyboard.