Ugh, it has VMProtect. I kind of don't want to deal with any anti-tamper, but at the same time it's not Denuvo. Dunno.

I'll be fine since I'll get a speaker ticket, but my travel companion is probably going to miss out.

I wish there was a service manual I can look at, because I'm comfortable poking at it with a multimeter. Worst case I still have a few other servers of the same configuration I can just swap everything over to, but I don't really want to trash all that compute due to a few faulty components.

I initially thought it might be CPU2, but with how many different components are being affected, I don't think it's localized to the CPU, unless it's just shorting out and dragging everything else with it.

Read through the repo, you tell me what you think is missing. It's the research folder one. There's some things that have not been fully discovered with regards to content, but there should be sufficient information for doing things with the prongs.

You don't need a microcontroller, just a UART adapter.

It's unknown how unique the device key is. Currently it's the same at least across a manufacturing batch. The P-Com is a microcontroller that wraps the protocol, but is frankly not worth considering due to its proprietary and needlessly complex implementation.

It's in the encrypted part of the firmware. I made a decrypter, which requires the device key, which you can extract with the microcontroller's UART console or SWD (which is disabled in the firmware but enabled when there is no valid firmware).