Decoding Dexcom STS data

[bernfarr]

It looks like the OneTouch UltraSmart data format has almost been decoded thanks to a lot of work from several people.

Maybe it's time for a new challenge. :eek:

I've been using a Dexcom STS continuous glucose monitor for about a month now. As soon as I received the software, I was disappointed with the lack of summary information that it gave me.

So I've posted information on my blog about what I've figured out so far about the data format. If anyone help can help me some in figuring out how to decode the data that would be great.

Have a look at my reader's challenge post (http://www.bernardfarrell.com/blog/2007/04/readers-challenge-help-me-decode-dexcom.htm) for more details.

[JasonJayhawk]

I saw your blog, did a Google search, and found that you'd posted here.

Anyhow, I agree with the other person's assessment -- it's not an SHA-1 (secure hash), since a hash can only go in one direction.

That said, a few things that make even more questions:

<DatabaseRecords Size="65536" CompressedSize="7028"...>

That size does not seem by chance, since it is 2^16 (16 bits) in length. When taking the ASCII text data of that XML node, I get a file that is 9,373 bytes long. I would have hoped it equaled 7028 bytes...

It's even less promising with the mention of the "RSAKeyValue" and exponent. I am taking a guess that they are performing RSA encryption on the data before doing anything else, since the record size should be 7,028 (I think the extra bytes that make it go up to 9,373 bytes are due to the added encryption padding; base64 decoding results in a string that may be readable by decoding with RSA -- or perhaps, I'm completely wrong, and they've got an efficient way of using those bits to record the numeric data in regular time intervals).

The only way to reverse that is to know their private key. And I'm sure that private key is somewhere not very obvious (or maybe it is...argh!). While the program is bad, they seemed to really be good at hiding stuff. Or maybe we're just looking too hard!

I find it also interesting that they have a "Signature value" -- I wonder why they would sign that data.

It would be interesting if you modified a single byte of that Signature to see if the program crashes. Or modify the modulus of the RSA key to see if it hurls. If it does, we know that decryption must be performed first. If it doesn't, we'll know that we can ignore that info.

So if you can be so kind as run those experiments, maybe we could get a bit further.

The next problem is that if it does turn up to be a string that has been encrypted with RSA, then if we were to find the private key and break it (which might take the effort of a cluster of key-breaking computers), we won't even know what we're looking for.

The decryption key could even be different for each device, depending on the serial number stored in the flash.

They're really covering their assets, if this is the case. Why, though? It's a frustrating mystery.

My thoughts are perhaps they think they need to encrypt it for patient privacy. Or maybe they want a piece of the money if someone takes their invention and does something with it?

One other trick might be to play with modifying some of the other data in the XML file to see how the program reacts. If you change a bit of that 9K data string, does the program fail upon discovering the error?

Someone probably got their hands on a toolkit that let them do this kind of encoding, and they got excited and really made it worse to figure out for those who need that info.

[JasonJayhawk]

Did a Google search and found someone else working on the same problem:

HELP with decompressing data., in Lang Xml (http://www.topxml.com/Lang-Xml/rn-274619_HELP-with-decompressing-data.aspx)

[bernfarr]

Thanks Jason

I'm chatting with a John Brown by e-mail and he has managed to accomplish some decoding.

I've sent him another data file plus the actual values for the start of that file (laboriously entered by hand from their software).

The data includes 4 types of records apparently:
Start mm/dd/yy hh:mm:ss
Gap hh:mm:ss
Sensor readings, value, mm/dd/yy hh:mm
Meter readings, value, mm/dd/yy hh:mm

So the first records in my system are:
Gap 00:10:00
Gap 00:10:00
Start 3/23/2007 11:20:24 AM
Meter 142, 3/23/2007 11:20 AM
Gap 00:10:00
Meter 143, 3/23/2007 11:44 AM
Meter 140, 3/23/2007 11:44 AM
Sensor 147, 3/23/2007 11:53 AM
Sensor 141, 3/23/2007 11:58 AM
Sensor 142, 3/23/2007 12:03 AM

If anyone reading wants them, I can post these two files at my site.

[JasonJayhawk]

Thanks for working on it. Was there any sort of decryption required?

(I'm just an observer. With newborn twins in hand, there won't be any time to inject anything other than peanut-gallery comments). ;)

[bernfarr]

But I've been distracted with other things.

I put a note on my blog (http://www.bernardfarrell.com/blog/2007/05/decoding-dexcom-data-format-update.htm) with pointers to sample data files.

And I'm hoping (probably foolishly) that the new Dexcom meter (http://www.bernardfarrell.com/blog/2007/06/dexcom-conference-call-on-monday.htm) plus software will be better.

If anyone else could help, that would be great. Anyone out there with .NET development experience?

[bernfarr]

This is just a quick update.

The new Dexcom software (DM 2) will work with both the Dexcom 3 STS and Dexcom 7 STS systems.

It provides a good export facility that lets you create an XML file or a Tab delimited file that Excel can understand.

So I'm dropping my quest to decode the data. Life's too short.

My advice - get hold of the new DM2 software if you can.

[jjames]

Bummer, and I love these kinds of riddles. :D