Question: How did you reverse engineer the protocol?
MrApplejuice opened this issue · 6 comments
I am very curious, I would like to check your implementation against my hardware. I am just looking for a very quick answer here:
- Did you use some kind of software or hardware to listen on the smbus?
- Did you decompile/disassemble the windows driver?
- Different?
I am not unfamiliar with hardware debugging but I would like to know what yields the quickest results! Thanks in advance!
If you look at the other thread #1 that steps through the process I used. (mostly from i2ctools)
The main tools were
i2cdetect
i2cget
i2cdump
i2cset
Awesome thanks you for the pointers! Sorry that I did not really parse a "Unable to Run" issue in much detail, but there seems to be a lot of information in there! So with this I am on my way. I will test if I can get my hardware to work! If I it leads to something useful I will try to make a PR.
Thanks again!
Nope @RattyDAVE I don't use i2cdetect, i2cget, i2cdump, i2cset to reverse engineer protocol at all.
But I just used a (cracked version of) debugger the IDA Debugger under windows to crack executable...
Well, I also willing to pay debuggers multi thousand USD price but somehow author doesn't allow me to do that due I just using GMail account.
Nothing to do for me.
Ah I forgot to say that, if it doesn't work, I already found nuvoton chip's I2C pins. I understand it uses I2C before debugging process (due enable/disable I2C port make some change at program).I planned to eavesdrop it with hardware (specially my sub $10 device with using my new released ESP32 logic analyzer code will do the job) If debugging session doesn't work. I just not pick that way in priority due location of chip is not easy to reach due heatsink of the CPU at my MB. Physical eavesdroping will be real shortcut for the job but I just want to play IDA first. That takes some time from my life...
Hello @EUA , did not have time in forever to follow up on this.Thanks for the more detailed feedback! Makes a lot more sense. The i2c-tools do not really give you much to work with. Only thing I know is that my LED controller is not responding to the same port as yours - cool.
The gmail-stuff is pretty ridiculous, I have to admit. Maybe there is something weird that has to do with US-law or something? Who knows...
Anyways, given that it is way easier for me to probe the drivers than my mainboard, I will try the first route first. I partially started already, but the initial annotation process is always very slow... I will post updates should I have any!
Thanks again!
I just not pick that way in priority due location of chip is not easy to reach due heatsink of the CPU at my MB
Just one last comment. Maybe an easier way to get to the same signal might be to use the PCI expansion slots. That was at least my thinking. Looking at the pins -> https://qph.fs.quoracdn.net/main-qimg-811b4485c1225a055cb378a0b6b0c4a9-c
The "SMBus" seems to be connected to the first few pins (5-9). Might be easier than to probe the mainboard directly, but then again, I am not sure if these are the same signals (I mean, I assume they are, but I do not really know it).
Hi @MrApplejuice,
Well, it could be a different I2C bus at PCIe power.
Also I don't believe if you really need eavesdrop the I2C bus.
Just take a chip register dump via dump() function at my script and save anywhere.
Than change a setting at bios menu and re-dump.
After comparing 2 dumps, I believe you will understand what and where is changed.
Probably it takes couple of dump to understand your chip register structure.
:)