ITB-100HD Time Lapse

A friend and I spent some time playing around with FFMPEG today, and put together a sweet little time lapse video using about 14 hours of footage. After trimming out frames it compressed down to about 25 minutes.

If anyone is interested in doing this yourself I’ll post details about the process, and can provide a tool to make it much easier.


ITB-100SP MPH Hack

Itronics ITB-100HD SP Smart Plus

A forum user requested that the MPH modification be made to the itb-100SP firmware for the newer device. I spent some time on it last night and have a working version for anyone interested. (itb100spfw.bin v1.0)

itb-100sp Running MPH Hack

itb-100sp Running MPH Hack

I’ll add details about how I did it when I get some time.

ITB-100HD MPH Hack *Update*

It turns out that the branch that I removed in the original ITB-100HD MPH hack was not what I thought it was. It was actually a check to see if the GPS had received a signal yet.  This causes some problems because the string that prints the speed would get all messed up and overwrite itself.

I went back to the drawing board armed with a little more skill and came up with a pretty standard solution to the problem. I decided to try my hand at jumping to another area in the code, doing my conversion and then jumping back. I found a couple test functions that had no callers and figured that they would probably be a good place to start.

I already had the code I wanted to run, so that was easy to just stomp over the newly claimed test function. The harder part was figuring out how to branch correctly to end up with the results I wanted. I know branch with link was the way to go, but had no idea how to determine the offset of the branch. After looking around online it turns out it’s not as hard as I thought.

First you take the target location and subtract from it the starting location + 8 (account for prefetch), then right shift that by 2 and that’s your value.

After a few iterations and running it through IDA to make sure I got what I wanted, I was able to build a 100% working MPH firmware that no longer had strange behavior prior to GPS ready.

I also think I’ve learned quite a bit doing all this and look forward to tackling a couple other improvements. Some folks have requested an increase in the bitrate, but I’m not sure I want to run such a firmware on my camera.  (itb100hdfw.bin v2.1)

ITB-100HD MPH Hack

Itronics ITB-100HD

Itronics ITB-100HD

Last week I decided to get myself a dashboard camera to record crazy things I see on the road while driving. After lots of reading and comparing different cameras, I decided to buy the Itronics ITB-100HD.

There are a couple things about the camera that I’d like to change.

  1. The onscreen speed output it written in km/h. Since I’m in the USA that doesn’t mean anything to me and I’d rather have it in MPH.
  2. All video files are saved to the root of the attached SD card. This isn’t really so much a problem as it is an unfortunate implementation detail. I’d like to use an Eye-Fi card with the device so that I can automatically transfer files to my home network when I pull into the garage. More on this later.

I had seen online that there was a guy that spent some time working to make the device display in mi/h instead of km/h. He did some great work, but ended up selling the patched image on ebay rather than sharing the binary with other folks who wanted to do the same thing. Also mi/h, while technically correct is not what I expect when I see a speed. I much prefer MPH since that is how speedometers are typically labeled.

I decided to see if I could reproduce the same type of mod to the firmware that the other guy did, but do it without paying for it, and then share it with anyone else who wanted to do the same.

The device has the ability to update its firmware from the attached SD card slot. It’s as simple as putting the binary on the SD card and booting up the device. I figured that would be a good place to start, so I downloaded the latest v2.1 firmware and got to work. What I found was pretty interesting. I spent some time looking at the binary to see if it was a well known format. It turns out it was a gzip file, which contained a tar file, which contained to gzip files, which contained more tar files. I’ve drawn the structure below to make it a bit easier.

File Layout

File Layout

Once you get through the layers of the onion you find out there are a bunch of files in the ipnc folder within the itb100_fw file. Using IDA I was able to disassemble the binaries in this folder and find that there was actually a lot of symbol information in the files, which made it a lot easier. It took me a while to find what I was looking for, but eventually I found a function called AVSERVER_getCurrentSpeed. This seemed like a good place to start and after a bit of time I followed the logic and figured out what I had to do.

Original code that used getCurrentSpeed

Original code that used getCurrentSpeed

If you look at the above code you can see that the getCurrentSpeed function is called from within swosdDisplay. At that point it does some flag check and then prints the current speed. The flag appears to be the flag that sets if the speed is printed on the video or not. I figured I didn’t need that and could steal that code space from 00025F1C -> 00025F28. My goal was to apply a simple medication to the km value that was returned from getCurrentSpeed prior to when it’s used in sprintf. After some quick google searching I found the conversion 1 kilometer = 0.621371192 miles. I just needed to write some new code that multiplied the km value by 0.62137. Here’s what I came up with.


What this basically does is load 636 into R1, then multiply the km value by R1, then divide it by 1024. This essentially multiplies the value by 0.62109375 which is pretty close to the conversion value. It also fits nicely into the space that the old four instructions were using.

I didn’t have an ARM encoder, but had some friends encode the instructions for me so I could drop it into the original binary. There are several tools to do this, I just hadn’t used them before and I’m glad I knew some people who had. Once I had the raw bytes I was able to modify the binary file directly and replace the old code bytes with the new ones.

Modified code bytes

Original code bytes

Original unmodified code bytes

Modified code bytes

I wanted to make sure the bytes were right so I loaded the newly modified binary into IDA again to see if the change resulted in the correct disassembly. I’m happy to say after loading the bytes in the wrong order the first time. A quick fix solved the problem and I had the exact code change that I wanted.

Modified IDA output

Modified IDA output

The only thing left to do was to find the constant string that was used in the sprintf, and convert the ascii from “km/h” to “ MPH” I decided to add a space for aesthetic reasons.

km/h ascii text

km/h ascii bytes

MPH ascii bytes

MPH ascii bytes

The final step was to package the whole thing back up in the reverse order of how I unpacked it. tar->zip->tar->zip. The end result is — MPH instead of — km/h. Hopefully this helps other people who want to make this modification.

Have Fun!


Download: (itb100hdfw.bin v2.1)

Special thanks to the folks that helped out… You know who you are.

Compiling and Running code using Propeller Tool

A few people have asked me to explain how to go about building the POV code and getting it running on their badge. I decided to make a quick walk through explaining the steps.

What you need:

You’ll first need to go and download the Propeller Tool from the link above. Install it and run it, you will see a screen similar to this.

You will see that it automatically opens up a new file and names it ‘Untitled’ this is an empty .spin file where you actually write your code. There are several simple tutorials online that show you how to do the ‘hello world’ style first program, and other things to get you going. Many can be found here.

For now we will just load the POV app and load it onto the badge. Go grab the source code from The best way is to just copy and paste the raw code from the bottom of the page directly into the Propeller Tool. It should look like this.

Once you have the code in the tool feel free to save the file (File->Save). This will allow you to name it something.spin so you can load it up easily next time.

You now have to decide if you want the code to be temporarily on the badge, or permanent. Those are the only two options.

  1. RAM only: This will compile the code and load it into the device ram, once the device is reset, the ram will be cleared, and the code will be gone. If you decide to do it this way you will probably want to remove the ‘600’ from the ‘repeat 600’ line in the ‘PUB main’ function. Other wise it will only seem to work for a couple minutes and then stop.
  2. EEPROM only: This will compile the code and load it into the device EEPROM. This will allow you to reset, remove the batteries, and do just about anything without erasing the code. If you do this, you will erase the original Defcon 20 game that was on the badge. There are ways of recovering it, so don’t worry that you broke your badge.

Once you decide which one you want to do, go to Run->Compile Current->Load RAM (F10) or Run->Compile Current->Load EEPROM (F11). This will compile and load the software on your badge.

Your badge should now be running the new code. In the ‘PUB main’ section I included a couple different patterns for drawing. You can comment out the DEFCONXX line by putting a ‘ in front of it, and uncomment one of the other lines.

I’m currently working on making it more stable when drawing using an accelerometer, but I’m still waiting for it to arrive in the mail. If you modify the code, I’d love to see what else people get it to do.

Hope this helps.

Defcon 20 Mystery Challenge and Badge Pinout

Defcon 20 Mystery Challenge

Yesterday Lost posted a very detailed wiki page outlining the solution to the Defcon 20 Badge challenge. I read through it and the only thing I can say is bravo to the team that solved it. There are a lot of parts, and each one requires thinking outside the box more than the last.

I think next year I’m going to try to find a team to work with and focus some time on the badge challenge. I love thinking outside the box and trying to find solution to strange problems. The challenge is very interesting to me

Defcon 20 Badge Pinout

Ken Gracey over at the Parallax forums posted a schematic of the badge which labels all the pins along the top. This is much better than my hacked together version of just the left side pins from a couple days ago. I’m just happy the pins that I labeled match the actual values on the schematic. I guess I’m not totally stupid. 🙂!&p=1115400&viewfull=1#post1115400


Yesterday my ADXL335 arrived from and I got it all wired up how I thought it should work. It turns out I have no idea what I’m doing, and didn’t get a single useful signal from the device. I was hoping it would be easy to interface with, but it looks like the MMA7455 will be much better. I did get some pretty cool pictures of the device though.

Defcon 20 Badge POV

Yesterday I planned on going to several Defcon talks, and got to the convention center a little bit early to make sure I got a seat. To kill time I decided to go hang out in the Hardware Hacking Village and tinker around with the propeller tool for the badge. I didn’t really know what I wanted to do with it, but thought there must be something cool I can do with this thing.

The night before I had my badge infected by a goon and it began flashing a pattern on the LEDs. I began waving my badge in the air thinking that it must be some sort of POV (Persistence of Vision) or something. Turns out it appears to be completely random, so nothing was ever spelled out.

I decided to try to make the badge spell something out when I waved it in the air. I have never used the spin language before so it took me quite a while to get something that would even compile and run on the badge. It also took me a while to figure out what the IDs of the LEDs  that I was trying to manipulate were… 16-23 duh! Anyway after defining a bitmap for a couple letters, I was able to flash the individual lines of the letters in sequence and produce a pretty clear ‘D’ in the air. I spent a little bit more time defining the  rest of the letters in DEFCON and by noon had the badge writing ‘DEFCON’ in block letters as I waved it around.

People began to flock toward me and ask me about what I had done. I showed them the dirty code I threw together to get it to work, and was pretty embarrassed by the way I was individually writing each letter one line at a time. I ended up taking someones suggestion and changing it to say ‘DEFCON XX’ and then people just started asking me to flash it on their badges! I won’t lie, I felt like a celebrity for a couple minutes there. One guy even suggested I find the documentary crew and get them to film what I had created. I tried, but the film just didn’t capture it well.

Needless to say I didn’t leave the HHV until around 5PM and missed all the talks I had planned to attend. It was totally worth it, met some awesome people, and got to feel slightly famous for a couple hours.

X spacing was off, but it took me 54 shots to actually capture it. I fixed the bug, but I’m not going to try to capture it again.

The video doesn’t really do it justice since the framerate screws it up, but here is the video anyway.

If you want to load this on your badge, just use the propeller tool and the code below.