search

denandz / lpc_sniffer_tpm

A low pin count sniffer for ICEStick - targeting TPM chips
GNU General Public License v3.0
156 stars 28 forks source link

Unable to find VMK in capture #2

Closed skullhornet closed 4 years ago

skullhornet commented 5 years ago

After reading your brilliant article I wanted to try this out for myself, however I am having trouble finding the VMK which I already know.

The device is a: SLB 9635 TT 1.2

I do not believe there is any noise in the collected data because if I process the captures like this:

cat log3 | sort -n log3 | uniq | md5sum 538f481cd99795ececece6f464329484 cat log3 | sort -n log4 | uniq | md5sum 538f481cd99795ececece6f464329484 cat log3 | sort -n log5 | uniq | md5sum 538f481cd99795ececece6f464329484

Windows 10, version: 10.0.17134.1

The VMK starts with: fc4ce32c8a75503cfa1350308fd7e...

Wires are soldered onto the device, and the connections have been verified. The wires go to a pin header, all 8 wires are connected. The overflow LED does not light up during the capture. Fast-Opto is enabled.

Do you have any suggestion to what could be causing this ?

I have attached one of the log files.

log3.zip

denandz commented 5 years ago

Hmm, this is the second time this has come up with TPM 1.2 chips. Sounds like there is a bug when this code is being used with a the SLB 9635 chip. I'm starting to think that basing this off the lpc_sniffer project was a mistake, and a more robust option would have been to dump the LPC information and writing script to do the protocol junk on your host, instead of the TPM.

skullhornet commented 5 years ago

It is strange that the capture should fail on the icestick unless the SLB 9635 changes the protocol slightly. Moving the logic to the host sounds like a better idea but won't this cause an overflow of the buffer ?

I will try the capture on an LA next week and see if I can make out the VMK from there.

Thank you for your quick reply :)

denandz commented 5 years ago

I'd be surprised if there were protocol differences, it should be sticking to the standard. I think either there is a bug in the sniffers state machine logic or its something really silly like read_serial.py and readline() causing issues with legitimate 0x0A bytes.

Not entirely sure how to go about just dumping everything with the ICEStick, would need 33MB/s transfer speed :-/ Should be able to do it with https://github.com/GlasgowEmbedded/Glasgow - so hopefully it's in production soon!

skullhornet commented 5 years ago

I tested with a C program reading the serial interface as raw but I get the same result so we can rule out read_serial.py at least.

denandz commented 4 years ago

This should now be addressed thanks to commit 2b601c18f892ff607b983ac184c22e63b6396e79. Closing the issue, can re-open if SLB9635 chips are still buggy