2 ms·

> Broadcom provided no code for its gear > so Finger helped reverse-engineer the necessary specs by manually dumping and reading hardware registers I really w

> Broadcom provided no code for its gear > so Finger helped reverse-engineer the necessary specs by manually dumping and reading hardware registers I really wanted to leave this quote here for all to see. The badassery of this act should not be underestimated. I've done a little bit of work along those lines. Reverse engineering my laptop's features, writing my own free software to drive them from inside Linux, emailing the manufacturer asking for documentation and receiving user help pages. It was mostly USB stuff, the most well documented interface imaginable, and it was still hard. I simply cannot fathom how he reverse engineered this Wi-Fi stuff. That's just a huge inspiration for me, I hope I can get near his level some day. Thank you so much for your work and RIP.

racked 2y ago
You might enjoy this series of articles about writing a Wi-Fi driver using reverse engineering techniques: https://zeus.ugent.be/blog/23-24/open-source-esp32-wifi-mac/ https://zeus.ugent.be/blog/23-24/open-source-esp32-wifi-mac/
- matheusmoreira 2y ago
  Yes I really enjoyed reading that article, thank you so much. I'm really looking forward to seeing a brave soul show up to try and reverse engineer those 50 thousand hardware initialization memory accesses. That sort of thing is just incredibly difficult. I'd really enjoy reading about that too. In my case I intercepted USB communications with wireshark and tried to make sense of the packets. I'd use the proprietary manufacturer app, capture what got sent over USB and correlate the packets to hardware behavior. Mapped out all the functions that way. There were hundreds of them but mercifully most of those were the same command but with different parameters. The result was this totally magical software which sends buffers containing seemingly random numbers to the hardware and somehow that makes things happen. /* Clevo Control Center * Effects * Wireshark Leftover Capture Data * * 0 Wave cc00040000007f * 1 Breathe cc0a000000007f * 2 Scan cc000a0000007f * 3 Blink cc0b000000007f * 4 Random cc000900000000 * 5 Ripple cc070000000000 * 6 Snake cc000b00000053 * * There seems to be no pattern to it. Does the value of the last byte matter? * My keyboard apparently doesn't support the ripple effect, * even though it is present in the Clevo Control Center interface. */ Mapping out 50 thousand memory accesses though? Whoever achieves that has my respect and my attention.
  - racked 2y ago
    The new website containing all articles: https://esp32-open-mac.be/ https://esp32-open-mac.be/
  - racked 2y ago
    I've only just started learning about this field myself, but your approach looks good. That article has some follow-ups which should be linked below it or can be googled. IIRC the author uses some clever shortcuts to speed up the work.

racked 2y ago

You might enjoy this series of articles about writing a Wi-Fi driver using reverse engineering techniques: https://zeus.ugent.be/blog/23-24/open-source-esp32-wifi-mac/ https://zeus.ugent.be/blog/23-24/open-source-esp32-wifi-mac/

matheusmoreira 2y ago
Yes I really enjoyed reading that article, thank you so much. I'm really looking forward to seeing a brave soul show up to try and reverse engineer those 50 thousand hardware initialization memory accesses. That sort of thing is just incredibly difficult. I'd really enjoy reading about that too. In my case I intercepted USB communications with wireshark and tried to make sense of the packets. I'd use the proprietary manufacturer app, capture what got sent over USB and correlate the packets to hardware behavior. Mapped out all the functions that way. There were hundreds of them but mercifully most of those were the same command but with different parameters. The result was this totally magical software which sends buffers containing seemingly random numbers to the hardware and somehow that makes things happen. /* Clevo Control Center * Effects * Wireshark Leftover Capture Data * * 0 Wave cc00040000007f * 1 Breathe cc0a000000007f * 2 Scan cc000a0000007f * 3 Blink cc0b000000007f * 4 Random cc000900000000 * 5 Ripple cc070000000000 * 6 Snake cc000b00000053 * * There seems to be no pattern to it. Does the value of the last byte matter? * My keyboard apparently doesn't support the ripple effect, * even though it is present in the Clevo Control Center interface. */ Mapping out 50 thousand memory accesses though? Whoever achieves that has my respect and my attention.
- racked 2y ago
  The new website containing all articles: https://esp32-open-mac.be/ https://esp32-open-mac.be/
- racked 2y ago
  I've only just started learning about this field myself, but your approach looks good. That article has some follow-ups which should be linked below it or can be googled. IIRC the author uses some clever shortcuts to speed up the work.