Reverse Engineering Bitmain ASIC

[elldeeone]

Hi all,

I'm working on reverse engineering the communication protocol between the control board and ASIC chips on a Bitmain Antminer KS3 (a Kaspa cryptocurrency miner) but aiming for all Kaspa related variants from Bitmain (KS3, KS5 and KS7). The end goal is to create open-source firmware and eventually implement the chips on a custom board, similar to what the Bitaxe project (https://github.com/bitaxeorg) has done for Bitcoin SHA-256 miners.

I understand that some may not feel too strongly about this topic or alternatively, very strongly about this topic, depending on where you fall in the crypto world, but I hope you can look at this as just another person who wants to free these chips from their very locked-down walled gardens. Bitmain is notoriously bad at providing the means or access to repair equipment post-sale, and their control boards are completely closed off - people who buy this equipment are entirely at Bitmain's mercy. On the Bitcoin side, the Bitaxe project has done incredible work liberating SHA-256 ASICs and enabling people to run them with open-source hardware and software. Nothing like that exists yet for Kaspa - which is what motivated me for this project.

What I've done so far:
  - Discovered an exploit that enables persistent root access on the stock control board (Linux-based, CV183x SoC, runs a 32-bit ARM binary called godminer). The exploit may be applicable to other Bitmain boards using similar SoCs, though i've not tested yet.
  - Decompiled godminer using Ghidra and identified the key functions that build work packets and parse responses
  - Reverse engineered what appears to be a custom binary UART protocol: 115200 baud for initialisation ramping up to 1.5 Mbaud during mining operation

What I need help with:
I'd like to probe the actual signals between the control board and the hashboard ASICs with a logic analyser to:
  1. Confirm the protocol is indeed UART and verify the baud rate
  2. Capture the full power-on initialisation sequence (before godminer starts)
  3. Check for any additional signalling (GPIO lines, chip select, etc.) that I may have missed in the decompilation
  4. Understand chip-to-chip communication on the hashboard itself

I'm looking for recommendations on a suitable logic analyser. A Saleae Logic Pro seems like the gold standard but is quite pricey. Given that it seems I'm dealing with UART starting at 115200 baud -> to 1.5 Mbaud, what would be a good budget-friendly option that could handle this? I've never used a logic analyser before, but am keen to learn so if anyone has any recommendations for good resources or documentation to get started would be really appreciated.

Also happy to hear any general advice from anyone who's done similar ASIC protocol reverse engineering. I can share more technical details if anyone's interested.

Thanks in advance! 

[coromonadalix]

you have now  some pico v2  based  logic analyser who go well with sigrok, and they say it can go up to 400Mhz ?? and not expensive at all,   you can even cascade them

[amyk]

Anything FX2-based (original Saleae clone) should be more than enough for that.

[EEVblog]

Most decent low end logic analyser solutions should easily handle UARTs to a few MHz, pretty bread and butter stuff.

Cheap Saleae Logic 8/4 clones exit to try it out to see if it does what you want before committing to the full priced genuine. Their software is pretty easy to use.

[bvdl.io]

Hi,

I love the initiative to work towards a BitAxe like open platform for Kaspa asic mining chips. I've been thinking of going at reverse engeneering them myself as well.

My usualy work is more related to the software side of things, but i do have access ot IceRiver KS7 and KS0 Ultra hashboards aswel as a logic analyser. I am very interested in learning more about the hardware side (like yourself).

Would you be open on collaborating in the same github repo in order to build op a BitAxe like ecosystem for Kaspa asics? I would love to take a look at the (Decompiled) godminer software in order to hack away at the UART protocol/comms.

Thanks for posting, hope we can help each other out