You’re right I suspect Henry. It shows the device at 0x42, and then the list following that are devices typically found at that 0x42 address. Now I feel dumb. Lol
No need to feel dumb … This is a case where the UI is not clear enough to be fully self-explanatory. Sure, once it’s been used a few times, it makes sense … but unless you happen to know that certain device types tend to be at certain addresses, your confusion was the natural result.
Moreover, your reporting this was valuable! Developers and existing users have blind spots about areas where the UI is rough, because they have already mentally dealt with the problem … making it harder to “notice” that it’s not clear. New users see it, scratch their head, and waste time. This is an opportunity to make the product better.
Consider submitting a PR (if you have a good idea for better output). Alternatively, consider filing a bug on GitHub, which allows discussion, tracking, and someone else to make a PR with a fix. Generally, it’d be good to clarify these are not actually identified devices, but rather potential / common device types for that address.
If we all compared ourselves to henrygab, we would all feel like single-cell organisms!
I will do that Henry
Missed this Ian… I’m using 100khz
I2c is very useful and this teensy idea is cool. I am actually building a small lab for uboot attacks using depthcharge. One of the labs is using i2c companion to attack the bus. Most of what I am doing is in python right now. Though I am using the BusPirate to replay and do i2c sniffing.
Are you using the scripting feature within buspirate for the replay. I’m guessing your using bp <5?
Hey Jim, I can’t find my Teensy 4 at the moment. but this code at least compiles so that’s something ;-). Give this a try and let me know.
buspirate_teensy4.zip (5.0 KB)
It works fine, thank you!
great to here!, I didn’t mention this but there is a serial console on the teensy that reflects the state of your progress through the game. its output only at the moment.
For the record, I installed it on a Teensy 3.0 board and a 3.6 board. I connected to the Teensy serial port, and it looks like it’s running… I haven’t done the challenges yet. I need to solder some pins to it.
But nice project and great documentation.,
Minor Bug report: (I raised an issue on github). You have a 404 link error on the main page on the student guide. “md” vs “MD”.
It would be nice if this ran on a modern Teensy. I tried to compile and there was an error
error: #error “Sorry, i2c_t3 only works on Teensy LC and 3.x. Use Wire for Teensy 4.0, 4.1, MicroMod.”
31 | #error “Sorry, i2c_t3 only works on Teensy LC and 3.x. Use Wire for Teensy 4.0, 4.1, MicroMod.”
Try this version: Teensy 3.1 as BusPirate 5 hardware hacking CTF style teaching tool - #27 by jrsphoto
Thanks and I apologize. I didn’t see your correction. I was too excited to try it out and I missed your comment.
I’m going through the exercise using a Teensy 3.0. I’m loading different values into the 0x84 register, and reading 16 bytes, and “walking up the tree” by looking at successive values. It seems the BP6 is hanging up at times when I read 16 bytes
I2C> [0x84 0x0e ]
I2C START
TX: 0x84 ACK 0x0E ACK
I2C STOP
Logic analyzer: 1016 samples captured
I2C> [0x85 r:16 ]
And it never returns, The LEDs flash in a pattern, but I have to unplug and replug the BP to recover. It first happened when I wrote another value into the register. I rebooted, did the same thing, and it worked. So I keep trying different register values.
Note that the register 0x0a isn’t one of the documented registered in the CTF. I was exploring. So this might be caused by the Teensy doing something weird.
But I didn’t expect the BP to hang. Shouldn’t there be a timeout or some way to abort without unplugging?
Bus Pirate 6
Firmware main branch @ unknown (Nov 18 2025 10:42:22)
Thanks grymoire, I fixed the link, and glad you like it. There is so much more that could be done with this. I’ve thought about adding a GPS element to it but been busy with other things at the moment.