9

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.

alt text
(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.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
mwilliams
  • 9,946
  • 13
  • 50
  • 71

3 Answers3

3

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!

Jacob B
  • 2,005
  • 13
  • 12
1

I'd start looking for hex-representation of known values. Does the device (as pictured) have a screen, or can you look in windows?

If you can, say, find a series of numbers in hex that you have found inside the Windows version, you might be able to figure out the 'record' format. Looking at it, it seems to contain some kind of header/version information, and a series of records with hex-encoded numeric values.

That should give you a good starting point.

Alex Taylor
  • 7,128
  • 2
  • 26
  • 22
1

I would just run a VM for the windows version and use ollydbg to reverse assemble it. That is your best bet instead of staring at a binary file and guessing which variables correlate with what offset.

Messing with your own insulin pump is probably not the smartest idea though. Assuming that the file manipulates the pump.

Unknown
  • 45,913
  • 27
  • 138
  • 182
  • The data file is off of my PDM and is for statistics use only. I will not be transferring the file back or interfering with the functionality with the PDM at all. As for a VM, yes, I could, however, I'm not going to purchase a Windows license for this. – mwilliams Jun 10 '09 at 21:49