Reverse engineering a statistics data file from my insulin pump controller

Question

This may or may not be a grey area subject, though my intentions are certainly not, so my intention is not to stir up an ethical debate on the topic of reverse engineering.

I'm a type 1 diabetic currently undergoing pump therapy. I'm an OmniPod user, it's a disposable pod that adheres to my body and dispenses insulin for 3 days. It's controlled by a personal diabetes manager [PDM] (seen below) which controls how much insulin to dispense during meals, bloor sugar readings, and it contains a food index for carb counting on the go.

_{(source: myomnipod.com)}

The new PDM has a USB port for the downloading of data. The software is free for Windows users (a package called CoPilot), but there is no Mac support.

Upon plugging the PDM into my Mac, it mounted like any other USB device would and presented me with a readable volume with a single file on it with an IBF extension. It weighs in at 16KB.

My first instinct was to pass it through a text editor and was presented with a very binary looking file. I then passed it through strings (see below) and opened it up with a hex editor. Though I couldn't gain much information aside from the strings below; no compression format details or anything.

$ strings omnipoddata.ibf 
Insulet
OmniPod
basal 1
Post-meal
e-meal
Pre-meal
e-bedtime
Pre-bedtime
.(@P
.(@P
.(@P

What should be my next step in this process? I'm a dynamic language guy, so any resources for Ruby would be great, or Python. Are there any test driven reverse engineering processes?

As far as the data I'm looking to obtain, it's information I would like to chart to gain more information on my progress (insulin intake, blood sugar readings, timestamps); all of which is possible in the Windows software package.

Answer 1

What I would do next is try and find some numbers. There's a bunch of ways the numbers could be encoded:

• Ints (1, 2, 4 bytes, various endianness)
• Floating-point (of various sizes)
• Fixed point or some other strange format

You have the advantage of knowing some numbers that are going to be in there, since you can see the data on the screen. So I'd look for those numbers in the file (in the various formats above). This should give you some data, at minimum.

Next, you mention timestamps. Timestamps are usually pretty easy, because they're invariably 32-bit unsigned ints, and you have a good ballpark range (time() +/- a few 100,000). So look for ints near there.

You can do all this by hand with a hex editor or write a little script. Once you start getting some data out, look for patterns. This should help a lot with finding more interesting fields. Good luck!