search

ptresearch / IntelTXE-PoC

Intel Management Engine JTAG Proof of Concept
505 stars 106 forks source link

Cannot boot main CPU #15

Closed kakaroto closed 4 years ago

kakaroto commented 5 years ago

As mentioned in https://github.com/ptresearch/IntelTXE-PoC/issues/12#issuecomment-509339105, I am unable to boot the main CPU. I've confirmed the issue with 3 other people who get the same result on their own machines so I don't think it's a problem with my system. Enabling HAP bit does prevent it from simply shutting down but it does not make the main CPU boot. As explained in my earlier comment, I'm using the F5 image, and I can see that it loops forever in the small block at 0x35644, with ebx=0xC and byte_97258=0x2 and byte_97259=0x3.

Any ideas on what's happening or how to unblock it, let it boot so the main cpu is brought up ? Thank you.

wh04m1-4n0n1mu5 commented 5 years ago

I have the same problem.

Used the same board, did the new exploit step by step, including the HAP part.

h0t commented 5 years ago

I double-checked and confirm that there is a problem.

unix0825 commented 5 years ago

I double-checked and confirm that there is a problem.

Do you have plan to fix this problem? Or could you explain why this problem happens?

Thank you.

h0t commented 5 years ago

Do you have plan to fix this problem? Or could you explain why this problem happens?

Thank you.

It turns out that HAP doesn't work correctly on this platform, also I had probably found the problem with partition signature (Our working image was self-signed). As soon as I make the workaround I will update the branch.

kakaroto commented 5 years ago

I don't really understand why HAP would even be needed as the rops restore the stack as it would have been if no ct file was there. The only difference i see is that the ct header is affecting the tracer mmio. I've added rops that revert that and i think it goes further (loop with 7/8 instead of 2/3). I guess on Monday I'll try with those new rops and disable HAP. I don't think i tried HAP without the exploit, but if hap is broken on its own, that might be the issue here.

On Fri., Jul. 26, 2019, 2:16 a.m. Maxim Goryachy, notifications@github.com wrote:

Do you have plan to fix this problem? Or could you explain why this problem happens?

Thank you.

It turns out that HAP doesn't work correctly on this platform, also I had probably found the problem with partition signature (Our working image was self-signed). As soon as I make the workaround I will update the branch.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ptresearch/IntelTXE-PoC/issues/15?email_source=notifications&email_token=AAAG2VVL46OGJKQJT3GSOIDQBKJEHA5CNFSM4H7H6VNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD23TTAA#issuecomment-515324288, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAG2VX7S23RY3N32QMFQEDQBKJEHANCNFSM4H7H6VNA .

h0t commented 4 years ago

@kakaroto you right, this is issue related with BIOS, not ME problem. image BIOS reboots my platform.

kakaroto commented 4 years ago

I'm glad that was helpful. It looks like that "Wait for SIPI" has to do with multi processor initialization. My cores are stopped somewhere else though, but I didn't investigate this further, it seems to read some address (MMIO maybe, waiting for something to be initialized by the ME?) and expecting the result to have a specific value before it continues.

h0t commented 4 years ago

I've found workaround for this issue: 3f7e24e763c566471760a330087ff48b68f0d9d3.