I have converted the data into the CSV file using the I2* analyser… but i dont see the chars in the form of HTB{…} Can anyone provide a nudge?
Could you find the flag?
wow, the tricky part is realy that you think you could read the flag/password all in one go.
First i thought: “wow, so many password inputs”, until i recognized that it probably writes the full screen again.
Well I guess its intensional, since you do not want that somebody wants to see your password if he is behind your back 
Btw. I did it with notepad++ in combination with an hex-editor and replacing unneeded stuff by regular expressions 
. (atleast the code for the LCD + the screenshoot helps a bit to know what you expect)
First I tried it with an arduino simulator and with python, but I failed that way 
.
Hi - fascinating exercise for someone new to hardware hacking!
I’ve spent a few days on this reading various datasheets, understanding the structure of the packets and instruction set, and playing around with the logic software referenced above. I’ve written a Python script which parses the exported data. However, I’m getting gibberish back when I translate the data into text, and I’m not getting any characters that match the image or the flag.
I’ve even tried notating the CSV by hand but am getting exactly the same results as my Python script, so clearly my approach to finding Start conditions and/or filtering bits isn’t working…! It’s infuriating
Don’t want to ruin it by putting any more here that might spoil it for others - is anyone happy to help me off-chain to find out what I’m doing wrong?
Thanks!
Never mind - solved. I’d somehow miscounted one of the fields and moved every bit to the left! Grr.
I don’t want to spoil or cheat but I am very stuck…
I have the csv file with the data column where it should appear the text on the LCD screen. But I don’t see how to convert the data into a char. I have found several datasheet corresponding to the LCD screen with the same byte to char table but none match with what I have…
Finally found it ! The datasheet is not usefull, you must check the code of some library in order to understand how data are sent…
Woa, that was intense. Realized just in the end that the display has a mild shoulder surfing protection in place.
Btw, got most of the token out but somehow 2 chars are missing / flawed, can’t really understand why. Anybody willing to give me a nudge?
Hey guys I am still stuck with the part of the csv for too long. One thing i am confused is like, the exported data from the csv is the data frame of “the” protocol right?
After a week of studying the protocol, I finally solved it. It turned out that while I grasped the basics of how I2C works, the signal appeared different from what I had understood. Essentially, what I did was purchase an Arduino, an LCD with an I2C module, and a logic analyzer. I then sent characters like “A”, “B”, “a”, “1”, etc., and analyzed how they appeared on the logic analyzer, attempting to map the signals to the corresponding characters. With the mapping correctly established, a simple Python script was all it took to solve this challenge.
Lessons I learned from this debugging experience:
- The sample rate should be set to at least 2M in the logic analyzer. Initially, using a lower sample rate led to confusion.
- Rely on hexadecimal values rather than ASCII after retrieving data from Saleae.
- Read other people’s comments in this forum.
I’m grateful to everyone here who shared their valuable insights.