Why hack the Latitude Communicator?
Since I’m in the middle of this project, I figured I’d start posting the results here. They may be of interest to people like me.
So, let me start with a little background. First, if you don’t know what this device is for, or why you would have one of these in your home, or near you anywhere, then this is likely not the page for you. Second, I’m not the first person to have this idea: https://hackaday.io/project/11323-iceedata. Third, although I am now a firm believer in “a patient’s data is his own”, if you don’t have a background in reverse engineering, electronics, coding or anything related to any of those fields, or if you are a patient with only passing interest, then YOU ARE KINDLY ASKED IN BOLD TO MOVE ON! This isn’t just for your safety. This isn’t being said in the same vein as someone asking you to don a bicycle helmet. This is being said by someone with years of experience breaking things, and learning the hard way that experimenting with things doesn’t always end in positive results. If you need the data that this device provides, and your doctor has prescribed this, and you are happy with your treatment (possibly even if you aren’t), then you SHOULD NOT muck with your device. I repeat, IF YOU NEED THIS DEVICE, HAVE NO BACKGROUND IN ANY OF THE AFOREMENTIONED FIELDS/DISCIPLINES, OR ARE JUST REALLY CLUMSY THEN DON’T READ THIS.
With all of that out of the way, let me start by saying, I love the idea of the project I linked to. Really, I do. I know why they might want to do this. There are some serious benefits:
- It can provide a sort of competition to device manufacturers.
- It is another means of collecting your own data.
- It sends the message that people are actually interested in not being just guinea pigs.
All of these are reasons that I hope they are successful. However, I think that, in the end, the approach might be a little wrong-headed. Why? Well, think about it this way: you already have a device that can send and receive the signals you are interested in. Why not just take advantage of that? And they possibly already hacked into their system and are able to do what I’m trying to do with the Communicator.
Why the Latitude Communicator?
The simple answer is: I had one. The more complex answer is that I started off with a defibrillator manufactured by Guidant. Guidant was unfortunately purchased by Boston Scientific. Why unfortunate? Well, I liked Guidant. The company seemed small and agile and somehow, genuinely interested in the people they were trying to help. Boston Scientific has the exact opposite feel. Don’t misunderstand me. Boston Scientific as a company hasn’t tried to treat me poorly or anything, but it is clear, they are in this for the money. Not from the patient mind you, but from your doctor. Other countries have a single-payor health system or something else constructed from taking in taxes. In the US, our version of a health care system involved trying to mandate having health insurance. Which, from the get-go, is a broken idea. I’m not saying single-payor health systems or other kinds of health systems are better or worse than this one. It’s just that we’ve created a “payment-triangle” where the end-user of the service doesn’t understand the cost of the service. This allows a company like Boston Scientific to provide a “service” to the doctor where they will remotely collect data, providing it to the doctor when they want it. This system assumes the doctor wants to pay for this additional service (mine does not, so I’m being monitored, but the data goes nowhere), and it assumes that Boston Scientific knows what the doctor wants to see (I’ll get to this in a minute).
Now, here’s where the problems arise. First, my current doctor suggested I go to see a specialist at a hospital. I thought this might be a good idea, so I decided to go. It was here I learned that the medication I was taking was pretty much useless for my condition, so she put me on some other medication. But it was here that I was able to start on the path to helping myself. First, I had gotten my first MRI. Most people think of this as more of a routine diagnostic, but when you have a defibrillator, you can’t get one. So when I was told this was possible, I finally felt I’d arrived into the world of “Star Trek” medicine. You know, the medicine where Dr. McCoy waves a magic device and you’re healed? That’s the medicine I want. But then, afterward, she’d wanted me to get Holter monitoring data and so forth. I was thinking, “WTF? I have a built in Holter monitor effectively, and you want me to use this bulky recording mechanism again?” I hadn’t started thinking about the ramifications of using my device to do the job of a Holter monitor yet (yes, there are many). Then, I went to my last check-up with her. She always asks the same questions: “Did you have your device checked today?” My answer? “No!? How can I, you only do the checks on Thursdays. We come here on Fridays because it’s too far to travel!” But, I had brought the information from my last device check-up with me. I proudly handed her the packet. Then she started looking through it and this is when the problems started. “Where’s the first page?”, she asked. “They didn’t give me that page, they kept it,” I replied. “This doesn’t look like VT. It looks more like SVT. Let’s pull up your last device check and compare the results.” And this is where the straw finally broke my back. When they pulled up the results I’d provided previously, I discovered, much to my dismay, that the Boston Scientific techs that take the data, really don’t take the data the doctor needs. There were several events the device had identified. And the techs provided the report showing those events. But what they failed to provide was the “strips” that go with them. These “strips” are readouts that basically show my heartbeat during the time of the event. What I eventually would discover is that the Boston Scientific techs would produce the final report, but the data related to the “strip” that they did provide, was only the data while I was sitting right in front of them. The “live” strip. While this data certainly had some interesting stuff, and the techs had happened to catch some possible SVT (doctor lingo for fast-beating upper heart chamber), what it didn’t show was anything from the events the device had recorded in the 3 months prior to the checkup. The main purpose of a defibrillator is to monitor you for dangerous heart rhythms and shock you if it thinks something is going wrong. But, it is also supposed to help your doctor decide if the treatment path they have chosen is actually working for you. They can’t do this if the device data isn’t made available to them and made available in a form they understand. After this visit, I was determined to find out how I could get my own data. It was then that I also became a convert to the “a patient should always collect their own data if possible” religion. Not only am I a convert. I’m a fire-and-brimstone preaching convert.
Hacking the Latitude Communicator for fun and … safety?
How did I start hacking this device? Well, the first thing I had to do was take it apart. Fortunately, I had just the tools. My wife had gotten me a Tekton driver and bits. Lots of bits. So I had just the right tool for the four rear screws on the device:
Without it, I wouldn’t have been able to open the back unless I’d used my Dremel tool. And I really didn’t want to do that. So, what does it look like under the hood? Well, if you’ve read this far, then I’ll give you some gratuitous tech-porn:
You can see the OMAP5910 and the Altera MAX II.
I tried to get a closeup, but I think this is where the limitations of WordPress failed me. Or maybe the photo software failed me. This kind of analysis always benefits from the use of a flatbed page scanner. Yeah, that’s what I usually use. But I was in a hurry. You’ll also note some unpopulated connector pads there. Cool! Let’s check them out!
After breaking out the multimeter and buzzing around, I found out that those pads lead to these pads here. I’ve worked in the industry long enough to realize that, back in the early 2000’s, people disconnected the JTAG on the board by using 0-ohm resistors. And, counting these pads, it looks like standard JTAG to me. Correction, when it’s a TI chip we are talking about, the JTAG is never standard. It’s almost always that weird 14 pin TI variant. If you don’t think so, take a look at the previous picture.
Now that I’m finally in the game, it’s time to buzz around on the processor. Oooooh, look, the guys at Guidant’s design team (since this was designed by Guidant, not Boston Scientific) did us a great favor:
That is pretty much the bottom of the BGA. Now I don’t have to guess which pin does what. I can know if I can only find a pinout. Where would I find a pinout? And with that, we then have this:
At this point, I’m leading you down this primrose path because I wanted to skip over another more obvious first choice for an approach. There is a connector that IS populated. It is show here:
Its that little tiny thing about 1/3 of the way down the photo. In the center. Yeah, that little one. Why did I skip this? I didn’t. At least when I first opened up the device, that was the first thing I went for. It turned out I had a header and female mate that I’d already had for another project (Yeah, another project like this!). So I did hook this up. What did I find? Right off, I found a serial port! Whoooo-hoooo! I know, you’re saying, what’s with the hunt for JTAG if you’d found a serial port!?
First, by default, the serial port doesn’t do much. At least not in the wrong hands. But, after a fashion, I figured out that the serial port wasn’t going to lead me to the promised land. Hence, the hunt for JTAG. We’ll come back to this serial port though.
Back to the JTAG. So, I put my 0-ohm resistors in (wires for those playing at home) after I’d buzzed out the proper pinout. Once I did that, I was able to verify, as I had surmised, the suspected JTAG pads were in fact in the TI 14 pin configuration for their typical ARM JTAG. Beautiful. So, I broke out my ARM-USB-OCD-H (or similar, I liked this because of the voltage range). The problem is that the only tool I really had to work with was openocd. Not a problem really, but it can be a real biatch to work with if you don’t have a configuration file, which I didn’t. I looked everywhere for info about the OMAP5910 JTAG. TI didn’t leave much in this department. I found out EVERYTHING ELSE about the chip from here. But, unfortunately, there was nothing about the JTAG.
This is what I had gotten from my “empty” configuration:
Open On-Chip Debugger 0.10.0-dev-00463-g0c2de8b (2016-12-19-21:48) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: RCLK - adaptive trst_only separate trst_push_pull Info : RCLK (adaptive clock speed) Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!! Info : JTAG tap: auto0.tap tap/device found: 0x03df5d81 (mfg: 0x6c0 (<unknown>), part: 0x3df5, ver: 0x0) Info : JTAG tap: auto1.tap tap/device found: 0x6b47002f (mfg: 0x017 (Texas Instruments), part: 0xb470, ver: 0x6) Info : TAP auto2.tap does not have IDCODE Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 7 -expected-id 0x03df5d81" Warn : AUTO auto1.tap - use "jtag newtap auto1 tap -irlen 2 -expected-id 0x6b47002f" Error: auto1.tap: IR capture error; saw 0x0003 not 0x0001 Warn : Bypassing JTAG setup events due to errors Warn : gdb services need one or more targets defined
Or at least pretty close. Eventually I dug up the fact that the JRC (JTAG route controller in OCD parlance) actually had an instruction register length of 10 bits. The instruction register, for those unfamiliar with JTAG, is the register that lets you select which chain/command you are “executing”. This posed a problem in that none of the TI documentation that was publicly available seemed to contain anything with a 10-bit instruction register. I finally decided that what they had probably done was include the low voltage version of this. I would have put a link to the actual low voltage device, but as luck would have it, I don’t. But essentially, they have a 10-bit JTAG tap controller. So the trick is to figure out what combinations of 10 bits actually connect to anything useful. That is where URJTAG was more useful. It is a little more flexible than openocd when it comes to guessing at unknown JTAG taps.
As luck would have it, I was able to perform a little sorcery (no, at this point I’m not going to show you how the sausage is made), and I was able to force the JTAG tap to show up. This let me put breakpoints on reset and elsewhere so I could see exactly what was going on. Remember I told you I’d come back to that serial port? Well, here’s where I come back to it.
The bootloader_core has finished initializing the processor [BOOT] Loading the BootLoader from flash... Jumping to BootLoader... The Communicator BootLoader 6-10-00 has been launched. Performing POST dev_sdram: verifying zeros in SDRAM survive refresh dev_sdram: verifying walking ones (data and address) in SDRAM survive refresh dev_sdram: POST tests complete, SDRAM is fully functional dev_cpld: verifying power level and validating rev 0x62 dev_timer: verifying that RTC clock is correct (1 percent tolerance) POST succeeded Booting in mode 'default' Preparing for boot Setting ethernet address CA:BB:EE:50:02:00 Loading Linux from flash, kernel 1... Jumping to Kernel...
And that’s all she wrote. Nothing after that. But you can see a few things right away:
- U-boot wasn’t used here. I don’t know the whole history of U-boot, but it likely wasn’t quite there yet. So we have a custom bootloader.
- It sets some kind of ethernet address. This wouldn’t normally raise any flags, but the thing only has a modem in it. So this tells me this is the address for the wireless bit?
- Linux is being booted here.
Well, after pressing keys, and trying a few things, it was clear I wasn’t getting anything going down the serial road. So this is where I come back to why I went the JTAG road in the first place: because I was stuck on the serial road to nowhere.
After a few fortunate circumstances, I was able to boot and get the thing breaking and debugging, just like I wanted (well, not exactly, but that isn’t for this post).
And that is where I will leave this for right now… it grows late, and time is short and I’ve got other missions to accomplish. In my next post I’ll talk about where I went with the JTAG…