ICeeData

Today I was going to make a Python course about using Python with Raspberry Pi at our hackerspace. However, it's a national holiday and nobody came, so I'll work on ICeeData. I'll make a capture routine, integrated with pyLCI, and capture the data using independent capture units...

Instead, I went on hacking the base station. That looked more interesting.

Bootlog:

Post device verification...
Serial2In string: ATi0
Serial2In string:
56000
Modem Post : Passed with retries = 0

Time taken by POST : [1.197000] seconds
nand_init: manuf=0x000000EC  device=0x000000F1
scanning for bad blocks...
nand_check_blocks: nand_read_page() failed, addr=0x04A20000
nand_check_blocks: nand_read_page() failed, addr=0x05F80000

Consider yourself BLOBed!

blob version 2.0.5-pre2 for Tanto Basic Device
Copyright (C) 1999 2000 2001 Jan-Derk Bakker and Erik Mouw
blob comes with ABSOLUTELY NO WARRANTY; read the GNU GPL for details.
This is free software, and you are welcome to redistribute it
under certain conditions; read the GNU GPL for details.
blob release: d20081014_platform_4_16
Memory map:
  0x02000000 @ 0xc0000000 (32 MB)

ram_post executing...
Data Bus Test
Address Bus Test
Data Qualifer Test
Device Test
c0200000status_next, board type = RF board revision =  (3)
c1e00000r14_svc = 0x0000034d
Autoboot in progress, press any key to stop ...
Loading kernel from flash ........ done
.
Starting kernel ...


Total blob time : [23.862000] seconds
Uncompressing Linux........................................................... done, booting the kernel.
Linux version 2.4.20_mvl31-tantobasic (iyera01@ussy-tanto01) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #d20081014_platform_4_16 Fri Sep 4 22:19:17 PDT 2009
CPU: ARM926EJ-Sid(wb) [41069264] revision 4 (ARMv?(8))
CPU: D undefined 14 cache
CPU: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
Machine: Motorola MX2ADS
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyMX0,115200n8 root=/dev/mtdblock6 ip=dhcp BOARD_REVISION=
boot_leds.c: RF boardRevision =  (3)
Calibrating delay loop... 119.60 BogoMIPS
Memory: 32MB = 32MB total
Memory: 30332KB available (1592K code, 391K data, 64K init)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 97
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
i2c-core.o: i2c core module version 2.6.2 (20011118)
i2c-dev.o: i2c /dev entries driver module version 2.6.2 (20011118)
i2c-proc.o version 2.6.2 (20011118)
pty: 256 Unix98 ptys configured
Real Time Clock Driver
cs89x0:cs89x0_probe(0x0)
eth0: incorrect signature 0x65b4
cs89x0: no cs8900 or cs8920 detected.  Be sure to disable PnP with SETUP
loop: loaded (max 8 devices)
ttyMX%d0 at MEM 0xe400a000 (irq = 20) is a mx2ads
ttyMX%d1 at MEM 0xe400b000 (irq = 19) is a mx2ads
ttyMX%d2 at MEM 0xe400c000 (irq = 18) is a mx2ads
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)
Scanning device for bad blocks
Registering NAND 128MiB 3,3V 8-bit as parts
Creating 10 MTD partitions on "NAND 128MiB 3,3V 8-bit":
0x00000000-0x00040000 : "Blob"
0x00040000-0x00060000 : "Param"
0x00060000-0x00260000 : "Kernel"
0x00260000-0x00460000 : "Recovery"
0x00460000-0x00480000 : "Errlog"
0x00480000-0x01c80000 : "Apps"
0x01c80000-0x03c80000 : "Root"
0x03c80000-0x04140000 : "Var"
0x04140000-0x04340000 : "Vpd"
0x04340000-0x08000000 : "Data"
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb_suspend_proc_init: MODULE loaded.
pegasus.c: v0.4.26 (2002/03/21):Pegasus/Pegasus II USB Ethernet driver
usb.c: registered new driver pegasus
usb.c: registered new driver usbnet
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
usb.c: new USB bus registered, assigned bus number 1
cramfs: wrong magic
FAT: bogus logical sector size 65535
FAT: bogus logical sector size 65535
Empty flash at 0x007421dc ends at 0x00742800
Empty flash at 0x00747b5c ends at 0x00748000
jffs2_scan_eraseblock(): Node at 0x007537fc {0x1985, 0xe002, 0xe0021985) has invalid CRC 0x00000044 (calculated 0xd7cd6a7b)
hub.c: USB hub found
hub.c: 3 ports detected
VFS: Mounted root (jffs2 filesystem).
Mounted devfs on /dev
Freeing init memory: 64K
INIT: version 2.78 booting
Activating swap...
Calculating module dependencies... done.
Loading modules: mx2ads-pwm button led Warning: loading /lib/modules/2.4.20_mvl31-tantobasic/kernel/drivers/merlin_basic/led.o will taint the kernel: non-GPL license - Copyright (c) 2007, St. Jude Medical
  See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module led loaded, with warnings
mics_radio Warning: loading /lib/modules/2.4.20_mvl31-tantobasic/kernel/drivers/merlin_basic/mics_radio.o will taint the kernel: non-GPL license - Copyright (c) 2007, St. Jude Medical
  See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module mics_radio loaded, with warnings
spi Warning: loading /lib/modules/2.4.20_mvl31-tantobasic/kernel/drivers/merlin_basic/spi.o will taint the kernel: non-GPL license - Copyright (c) 2007, St. Jude Medical
  See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module spi loaded, with warnings
usermode_access Warning: loading /lib/modules/2.4.20_mvl31-tantobasic/kernel/drivers/merlin_basic/usermode_access.o will taint the kernel: non-GPL license - Copyright (c) 2007, St. Jude Medical
  See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module usermode_access loaded, with warnings
ppp_generic CSLIP: code copyright 1989 Regents of the University of California
PPP generic driver version 2.4.2
modem_reset Warning: loading /lib/modules/2.4.20_mvl31-tantobasic/kernel/drivers/merlin_basic/modem_reset.o will taint the kmernel: non-GPL license - Copyright (c) 2007, St.o Jude Medical
 d See http://www.tux.org/lkml/#export-tainted for information about tainted modulees
m_reset: MODULE loaded.
Module modem_reset loaded, with warnings

Boot time in seconds before mounting local filesystems = 5
Mounting local filesystems...
none on /proc/bus/usb type usbfs (rw)
tmpfs on /tmp type tmpfs (rw)
/dev/mtdblock/5 on /apps type jffs2 (ro)
jffs2_scan_inode_node(): CRC failed on node at 0x00000fec: Read 0xffffffff, calculated 0x643abd86
/dev/mtdblock/7 on /var type jffs2 (rw,sync)
Empty flash at 0x00001128 ends at 0x00001800
/dev/mtdblock/8 on /vpd type jffs2 (rw,noexec,sync)
Empty flash at 0x00006c44 ends at 0x00007000
Empty flash at 0x0000b03c ends at 0x0000b800
Empty flash at 0x0070191c ends at 0x00702000
Empty flash at 0x007039e0 ends at 0x00704000
Empty flash at 0x00705044 ends at 0x00705800
Empty flash at 0x00706924 ends at 0x00707000
/dev/mtdblock/9 on /data type jffs2 (rw,sync)
Boot time in seconds after mounting local filesystems  = 8
Starting devfsd: Started device management daemon for /dev
done.
Cleaning: /etc/network/ifstate.
Hostname: (none).
Setting up IP spoofing protection: rp_filter.
Disable TCP/IP Explicit Congestion Notification: done.
Configuring network interfaces: done.
** can't synthesize pci hotplug events

Setting the System Clock using the Hardware Clock as reference...
The Hardware Clock does not contain a valid time, so we cannot set the System Time from it.
Unable to set system clock.
System Clock set. Local time: Thu Jan  1 00:00:14 UTC 1970

Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00000080...
On Chip RTC Time: 00:51:03
SndBuf Size = 131070
Watchdog available
SndBuf Size = 131070
0
INIT: Entering runlevel: 3

[SJM_CONFIGURATION]
VERSION=EX2000 v4.6C PR_4.94
(none) login: CRM_PCDR1 = 0x2050704
CRM_PCCR0 = 0x5902e077
CRM_PCCR1 = 0x27000000
modprobe: Can't locate module /dev/usb/tts

[SJM_CONFIGURATION]
VERSION=EX2000 v4.6C PR_4.94

@[skaarj] had a useful hint I've forgottten about - passing parameters to the kernel so that it'd boot in the sigle-user mode and go straight to shell. BLOB bootloader was OK with that. The parameters ended up to be "boot single init=/bin/bash console=ttyMX0,115200n8 root=/dev/mtdblock6 ip=dhcp BOARD_REVISION=". Using them, I was able to clear root password, reboot and login as root. With all filesystems mounted, I could tar up the whole system and export it on a flash drive, so that I could explore it.

What did I find? The fact that inserting a prepared flash drive lets you pwn those base stations, launching your own scripts etc. There are compiled binaries (the applications interacting with the implant and presumably making the reports), and calling "strings" on them gives some insights into what we would get if we were to get a report straight from the base station.

Some facts:

• Base stations run MontaVista Linux with 2.4.20 kernel
• Software uses MQTT for something.
• Stations have a monitoring channel that streams data to somebody. Presumably, either healthcare provider or manufacturer of these devices, for monitoring etc.
• There's a script to update firmware on those stations. If a special file is found on the flash drive and some bytes at a specified offset are equal to a hard-coded sequence, it launches a script (again, with hard-coded path) from this drive.
• There's an auto-launchable script to export reports from the base station as well. This is wonderful for us, as this allows us to reach our goal.

I'm not publishing a lot of data since I'm not much of a black hat, though black hats can just buy a base station themselves (and everyone who needed it most likely bought one already). I'm not publishing the files as well.

I plan on publishing the "autopwn" script I'll make though, since it goes along the goal our project has to achieve, which is getting reports. After all, this thing doesn't need to be as secure as it could get because the only viable attack vector requires physical access to the base station. The developers of base station firmware have enough things to think about already (the amount of threads in the applications running is impressive by itself), and I'm sure they don't want any ill-informed bosses or managers telling them their software is insecure when we all understand securing those base stations this is too likely to cost more than it will give.

Expect the autopwn script soon!

This is a third day, and it was awesome. I received the base station. There's this teardown of a Merlin@Home EX1150. It sucks^W is not that good though, so I've made my own.

PWN'd.

But first, look at this! This wonderful carry bag that base station was in can contain 3 netbooks! I need to buy more of those bags.

Disassembling the base station is hella easy. After all, it's not made by Apple. There was a single screw that was not visible:

It consists of multiple parts. First one is the single logic board, with all the other parts connected to it,

There's the antenna PCB. It has 2 402-405MHz antennas and one stub antenna for 2.4GHz.

Then, there's the keypad. A bunch of LEDsand a single button. There's also the speaker. It's loud, even though not very much, but still annoying. I might need to replace that one with an LED, not sure how to represent different frequencies though. It's all powered by a 5V/2.5A PSU. I'll definitely have to power my Raspberry Pi from it once everything's over. I mean, it must be a medical grade PSU. Those things are *reliable*.

The outer shell is nice, but not for me. I need to have access to the testpoints (oh, the testpoints!), and I need to make sure antenna is always connected to the board - don't want to see how the transmitter behaves when antenna is not attached, it might be not what I want from it at all. So I needed to attach the antenna board to the logic board - that's usually done by the case, pressing them together from both sides, there are pogopins on the logic board which simply go to the antenna. So, I need to drill some holes and insert some screws to hold it all together:

Ready. Oh, overview of the logic board. Time to remove all those shields!

Here's the 2.4GHz wakeup signal generator. Implemented using a NRF2402G. Interesting!

Here's our Zarlink ZL70101A chip. Nice to meet you! I wonder if its counterpart seated inside pacemakers looks the same.

Here's some kind of weird IC under a shield near the RTC battery and the ADSL connector. Next to it (upper) is what seems to be an ADSL modem.

Some RAM chips. I wonder what they could have added in that unpopulated footprint.

Power regulator(s) and, possibly, audio amp for the speaker.

Main CPU (MC9328MX21) and its flash IC (K9F1G08U0C). Parallel flash. Shucks! I'll need to dump that flash contents, that's for sure. Meanwhile, let's look at other components:

A DS1339 RTC. The battery is connected to it, I've checked. I accidentally shorted out the battery VCC to ground while taking off a shield and now the clock is reset to 1970-01-01 =( I wonder if I could program it in-system... There's always the problem when you end up powering the whole circuit while trying in-circuit programming and you can't program a thing because CPU has already taken the bus and won't give it back peacefully.

Testpointzzz!!!

Everything's attached as needed, just that the case is out of the equation. Powering it up - it works! Not so sure about the radio part, will test that one, but LEDs light up and speaker beeps, all as expected.

Now I'll try the UART header. Oh, I didn't show you, did I?

Here is it. It's weirdly-positioned, as you can see. However, you can insert 2-pin 2.54 headers just the right way so that they hold in there without soldering anything.

We have VCC, RXD, TXD and GND. No need to use VCC, that's for sure - I'll just connect 3 of them to my UART adapter. I tried 115200 rate, 8n1 (default) and this is what I saw:

Yeah, Linux. Altough I was more like "Fuck yeah, Linux!" I was thinking there would be a possibility it ran some entirely custom firmware, but the odds are in our favor. What's the problem then?

Login&password.

There's also a bootloader. This thing uses BLOB instead of, for example, U-Boot. It's accessible and I could dump the firmware... If there was a network interface to dump it through! I wonder if it'd dump it over UART... Oh no it won't. I'll need to go through the options later.

This password is the next frontier on our hardware hacking route. Once we get the login (very likely to be 'root') and the password (will need hash bruteforcing), we're in and can see ins and outs of how this data is processed. For that, I thin we need to dump the flash IC. Here's a good theoretical explanation with some tools included, and here's a @Sprite_tm take on this task, which I'll most likely follow =)

I think we should make a Wiki project about our development. Hackaday.io projects are great for telling a story, but Wiki will be more comfortable at some point.

Disclaimer: I got lazy^W late and didn't post this log on time. This log is dated 11st-12nd of June.

Hello! This is the first "work weekend" for ICeeData project. Today and tomorrow, I'm working on data demodulation.

This is also a small milestone. What's been ordered so far?

• Various RTL-SDR versions to make a small test of which is more and which is less suitable for our tasks, as well as to use for capture units.
• A couple of Raspberry Pi boards for assembling independent capture&decode units, first of which is going to be left at Estonia, with the base station of our participant. + various accessories for these.
• An EX1150 base station. To immediately be disassembled and hacked into. Shipping costs are a bitch, and I once again thank Hackaday Prize for this. I might order another one - as a spare in case my hardware hacking goes wrong.

What's to be ordered?

• A more powerful SDR. Frankly, I'm still overwhelmed with the possible options. HackRF One seems like a good match, but there are many other viable choices for the task. I'm quite curious about LimeSDR, for example - it might just be a much better choice since it's more capable and therefore should provide more for the future research. It's a crowdfunding campaign, though, and there's the problem - a small chance of being left without money.

As a starting point for working with data I've got, the transmissions I've got contain plenty of empty space. I'd need to remove that with some kind of a visual redactor. However, it doesn't seem to be that simple since all I know for this task is Audacity and it seems to not work well with raw data in the format I've got. What are the options?

1. Convert to WAV with a GNU/Radio workflow
2. Use some other visual editor

But first, let's greate a GitHub repo!

I'll try to go with the first approach. A quick google showed me a StackOverflow question which explained some details about the files I've got and the files I'd need.

Setting up Raspberry Pi. Installed: GNU/Radio, rtl-sdr tools, all the GNU/Radio plugins in the repo and Audacity.

To avoid permission problems, I added "pi" user to the "usrp" group created by something installed along GNU/Radio. After a logout and login, it worked beautifully, allowing me to use the "pi" user for GUI applications interacting with SDR hardware.

RTL-SDR I've recently bought seems to enumerate successfully. I could also see FFT of recorded files using this workflow.

Okay, time to convert files to WAVs! Here's the workflow I've made for this, as per StackOverflow suggestion. Then I cut them in Audacity and went on making a FSK decode routine. I've decided to look at the file FFT in Audacity. It didn't show any frequencies, showing a huge hill of frequencies instead. What the hell?

Let's look at the WAVs in Audacity:

What the fuck? Why does it look like crap?

Well... As per @geekskunk suggestion, my files might just suck. Unfortunately, this is a possibility. However, I've got SDRs now, and I'm receiving a base station this week, so I'll record more files. Also, I do definitely need one more base station. One I already have is to be disassembled and hacked into, another will be used for capturing new data for initial transmissions to make decoding algorithms and later for testing those.

I've also downloaded and compiled Inspectrum. A nice tool for analysis, though there are things to wish for.

These signals are strangely mirrored. Why so?

I intended to post this log on the Monday right after this, but had unrelated health problems which took a part of my energy. Therefore, it's only now that I post this. However, don't be disappointed, next log is about the base station teardown!

Naturally, the most responsible thing I can thing of is tracking all the materials we used. Sometimes Googling things is just too fucking hard.

Technical and technical-ish info:

• FCC info of our base station
• icd_study.pdf (original) (cached)- a document which mysteriously 404'd a couple of days after the hackathon (no less creepy than Barnaby's death.)
• A sample report we've found that shows what the data looks like at the doctor's office
• A "teardown" of a base station we have
• ZL70101 (transceiver used in BS&ICD) Product Preview
• Full datasheet of the ZL70101 transceiver
• ZL70101 evaluation board
• ZL70101 presentation
• St. Jude Medical paper on their new eMICS standard, with lots of relevant information

Reasoning and media coverage:

• Hacking Grandpa's ICD: Why do it?
• How to Hack Grandpa's ICD
• Patients should be allowed to access data generated by implanted devices
• My device, my body, my data (504 at the moment)
• The Shocking Truth About RF Implantable Devices
• Five Reasons Why Patients with Implantable Defibrillators Deserve Their Data
• Five Reasons Why Physicians Don’t Want Patients to Have Their Cardiac Device Data
• Why Cardiac Rhythm Device Patient Portals Will Start the Digital Health Revolution
• Muddy Waters Capital: MedSec research on SJM device security

Wow. It's been a wonderful week.

I got to know about our nomination this Monday. It's been... Shocking. Both for me and for my teammates. Now, the project feels much more real. We've got the means for doing actual work on it, and I personally can't wait!

First of all, meet @joeyfreelandjr! He's a volunteer with an impressive background in electronics that has the skills we're looking for. With his help, it's now possible to shine more light on modulation schemes of the data and, consecutively, write a routine that would decode this data.

As for me, I'm researching opportunities on writing a custom Python block for decoding packet data and outputting it the way we want it to be displayed for our decoding efforts. There's a lot to be learned though, and I need to find a comfortable way for tweaking GNU/Radio routines and actually seeing the results in less time than a minute or so. I'm also looking for a nice book that'd explain all the concepts to me so that I have better understanding of what I'm dealing with. I've found a person in our hackerspace that has a really good understanding of what's going on and I've went through a small crash course involving Audacity, Spek and handling raw data in general. Also, I think I should make a workstation for this project. I have a Pi3 currently just sitting there unused, should handle this task well. I just think I need a bigger microSD card for it, as well as add an external HDD =)

One of the most interesting things for me so far is getting a EX1150 base station. I can finally afford it and will order one as soon as the money arrives. Then, I'll hack into it! I'll try my best to dump its firmware because I can't wait to take a look at what it can be hiding - such as binaries with the communication algorithms in them! If those binaries are more or less easy to disassemble, I'll have very important information about the data we're dealing with - it's going to save a lot of time and research effort.

Also, I'll soon be looking for a good SDR. We need some usual RTL-SDR dongles so that we can make sure our project is repeatable using them, but I'll also need something with slightly better hardware and larger bandwidth for initial stages of research where I can't afford to add problems like "hardware-not-good-enough" to problems like "trying-to-understand-the-thing". In other words, when I make sure my software is conceptually working on "perfect" hardware, I can focus on hardware-related problems.

As for now, it's my Sunday project, meaning that I can spend on average one day at a week on it - which is actually a lot of time, considering all of the projects I'm working on =) I'm also going to have a "field trip" to Estonia - as soon as I get an SDR. Not to mention that writing GNU/Radio blocks perfect enough is going to take more than a week of quite concentrated work. With all the problems we'll solve along the way, we hope to make a good competition in Assistive Technology . At least, now that the funding question is solved, we have the means to participate - thanks to Hackaday Prize!

It's been a week since the hackathon ended. What are our plans for now?

1. Build a GNU/Radio routine that'd capture the signal, apply all the filters that could be necessary and decode the data.

There's a lot to be learned with GNU/Radio and RF in general. For making a workflow such as the one we could use in an embedded device, there's a lot to be added and plenty of things to be learned.

2. Get a base station to hack into.

These seem to be available on eBay quite cheaply, evidently, from deceased patients. Once we get one, tearing it apart and dumping the firmware would be number 1 priority. That could give us plenty of insight into "Decode" and "Intercept" steps - as well as maybe become a hardware solution for interception?

3. Assemble a hardware solution for sending to volunteers - or defining a kit of software anybody could assemble.

There are a lot of patients with ICDs who expressed similar concerns about their data and how it could be used. When we have a working hardware solution capable of "Intercept" and "Decode" phases, we can cooperate with other people by collecting a lot of data from their transmissions (anonymously) to facilitate the "Decypher" phase.

4. Understand why the capture quality suffered.

Was it something we could fix with postprocessing? Was it something that'd mean the signal has to be captured again? So many questions, so little time...

5. Make collected data accessible for people who'd want to take a look at it.

Some RF-savvy people have expressed their interest in seeing the data we managed to capture - to help us fully get through "Intercept" phase. However, we could greatly benefit from the huge Hackaday community and its helpfulness.

6. Collect feedback from people in the industry.

We've already attracted the attention of some people, but it's clear this issue needs to be raised among the health professionals.

7. Get a development kit.

I wonder if the manufacturers would be cooperative on our project. However, it doesn't hurt to try and it'd help us a lot to have a transmitter-transmitter pair we could control.

Why participate in the Hackaday Prize?

First of all, it's an "assistive technology" project. We want to solve one of the problems that's stopping people from getting full information about their condition, if not the direct "give-data-to-us" way, then the hacking "we'll-take-it-ourselves" way. It makes this project a perfect fit.

Second thing is exposure. We need it, and Hackaday can provide it. We need both technical expertise of many folks for decoding and making sense of the data, and we want to raise awareness.

Third thing is prize money, which we could use to get the necessary equipment. It's very likely that we could assemble a ready-to-collect-data device for 100$, for early adopters. We also need to get the base station, but shipping costs from the USA to EU are kinda high and we're mostly students. It would be very good to get our hands on a good SDR, such as HackRF, for development - to see which problems are due to bad hardware and which are due to the lack of filtering.

It was the last day. I went to sleep late again, trying to capture transmissions that'd look at least remotely like DBPSK.

I had some good news - some parts of what I was receiving certainly looked like clear DBPSK! Moreover, I could decode them just by looking at them long enough. However, only some packets looked like this. Neighbour packets looked like complete garbage. It was clear some filtering would be involved. Not only that, of course - also determining the reasons why packets were looking like garbage and fixing those. Having a couple of croissants with bacon on the table also contributed to my levels of happiness.

What didn't was the fact that we had no packets decoded. Step 2 was not available without at least filtering some packets, and step 3 wasn't available without any decoded data. We were kinda stuck on step 1 because of some reason I couldn't even determine. Therefore, we didn't have nothing cool to show. For me, it was clear I had to concentrate on after-hackathon development.

That became a topic of the talk with a mentor from the hackathon mentor team. He came to us to check our development status, and it became a quite valuable discussion. Bullet points about the conclusions we've reached:

• We, being a research project, should try to get a devkit from the manufacturers who made the communication chips inside both the ICD and the base station. BTW, here's the datasheet, and here's the "datasheet preview".

Why? Simple. We could get hardware operating on the necessary frequencies so that we could first train our data acquisition techniques, basically, implement "1: Intercept" and "2: Decode" parts using hardware we fully control so that it'd be easier to test all the quirks of our software part before trying to work on the real equipment.

• We should definitely make a better antenna. Even a piece of wire of the necessary length would do, I wonder why I haven't thought of it earlier.
• We should get more eyes on the data we collect. The more people are observing it, the more likely we can have suggestions about the possible packet structure, protocol details, or maybe even get some information from the people working in the industry.

The presentation was coming. We had mockups, we even had a Raspberry Pi running the capture block and showing things on a 16x2 display. We didn't have any decoded packets of data though. It's literally hundreds of packets sent in one transmission. You cannot not automate this thing, and decrypting a couple of packets manually purely for showing off wouldn't have had made sense.

However, we had shown the first steps are entirely possible. There aren't any permanent roadblocks which'd stall the development. No encryption, no indecipherable data. We knew we had to improve our methods, and we decided to present everything we've got.

Thus, the hackathon ended. We won a prize from a Latvian telco company:

It's something along the lines of "storage space and processing power for data storage, processing and visualisation". We haven't received the details yet, but not that it matters - it's a good start anyway.

Now that I've outlined the details, it's time for a conclusion post.

I woke up on the floor of our cubicle, besides the desk, head resting on my backpack and body covered by my jacket. I have to say, it was relatively comfy, even though I have to say it took some time to understand why I woke up in such a weird position. Then I remembered this was the decision made when I understood I forgot to bring my sleeping bag and had to pick the best of available options. Sigh. At least the floor was comfy.

It was late, around 12. Well, I went to sleep at 7, so actually it was just 5 hours. I was surprised to find some breakfast-y looking croissants on the desk, along with some Coca-Cola. My teammates didn't want to disturb my sleep, but made sure I wouldn't start my day hungry. <3 They arrived to the cubicle soon.

It was "Checkpoint №1" by the timetable. It meant the mentors were to come to our cubicle altogether, and they eventually did. Before that, we had a little group chat. Turned out they developed a backup plan. In case we wouldn't get any data, we at least would present a concept showing a smartphone app mockup, that'd show what information we could receive from that data and how patients would be able to use it to make informed decisions. It sounded like a quite good plan, so the other team members had already started to work on that - essentially, show the last step of our plan if the first would fail. Oh, the plan?

1. Intercept the communications between the implant and the base station
2. Decode them into packets
3. Decypher their protocol
4. Understand the representation of the collected data
5. Make human-readable reports for patients

We only have one night left. That'd mean we're screwed if anything fails... If we don't have a way to trigger the communication manually. Let me see what the base station does when it boots up...

Nothing in particular. Pressing the only button didn't do anything, it was, evidently, trying to get a "fix" on 3G connection before it'd even start to work. How didn't I get to know about its bootup sequence earlier...

I decided to go home. The hackathon place was a half an hour away, and I could take a shower my hair needed oh so badly. I booted my laptop into Windows, loaded my browser with all the relevant info we had found on the web while researching and went home.

About two hours later, I was coming back to the hackathon place. I felt like there had to be a way to make the base station communicate when we wanted it to, and from the texts I had read the solution had to be something simple.

The solution was in the manual I just haven't read thoroughly:

1. Plug the station in and wait until it establishes a 3G connection, going to the "sleep mode", also described in the manual
2. Push the only button there is one time, then hold it for 1 second.

I literally forgot to RTFM.

Ah well.

A quick test, and we had captured the signal from the base station! Not only that, but we also recorded it communicating with the implant!

Only that it wasn't *that* good.

I already had known the signal used DBPSK modulation. Well, what we got looked like it, but obviously wasn't up to being decoded. Honestly, it looked like crap.

What was the problem? It was hard for me to understand. One thing was clear for me - this project would have to continue after the hackathon. For that, I also had to make sure I'd have a lot of data captured. Why?

Simple. The girl with implant&base station came to the hackathon from another country. I couldn't really come over for recording sessions anytime I needed more data. And I understood we'd need a lot of data for steps 1 to 3 of our plan. Thus, I began triggering the transmissions, recording them - both with the girl present nearby so the base station could talk with the implant, and with the girl far away so that I'd only capture the base station's requests.

I also was trying to understand what was there that prevented me from receiving clear waveforms. Granted, RF is a noisy thing, but I received crystal clear waveforms when I tried to record the car keyfob signal. Why not this?

I still don't understand. What are my guesses?

1. 3MHz wide baseband with 10 possible communication channels. The base station was hopping between them while sending its requests for the implant to answer (this was the most visible when the implant was too far away, but I also had problems recording the communication since RTL-SDR best scenario bandwidth is only 2MHz). I also had various glitches with the communication which it would be best to show in a video, but I didn't record one. =(
2. Unfitting antenna. The one we had was a stock antenna for DVB, AFAIK, so I wouldn't be that surprised to know it wasn't good for the frequencies we needed.
3. Something bad with the SDR. Well, those things are cheap and, again, mostly made for DVB - so what can one expect?
4. Something wrong with my GNU/Radio workflow - could as well be. I might have easily omitted something very important. I yet don't know if we could fix that by processing the data again or we'd have to record all the transmittions from scratch.

We had waveforms recorded but no idea what was wrong with them and whether we could fix it. Meanwhile, the app mockup was slowly coming to life.

Simple as that. I'm sure it won't be as simple when it comes to life, but that's a good start.

Me and my teammate talking about some nuances

The final hours were slowly coming, but we had something to show. It was clear the project is much bigger than "48 hours", but it was clear which tasks we had to work on.

As you know, hackathons often start with idea pitches. Then, groups assemble for bringing these ideas into reality. The ideas that don't collect enough people, do not continue. This one did, with one hell of a pitch:

I have this device controlling my heart, and I have no idea what it tells about my condition. It sends some data to my doctors, and I see them once a year only to hear that I've had an attack in February, having no recollection what I did back then and if there was something I could have avoided. 
I talked with my doctors and they said they have this data accessible, but they basically don't care enough to send it to me. What I want is to hack this device, to myself see the data it collects and make informed decisions about my lifestyle.

At that point, a roar of applause broke out.

The pitch brought a lot of attention, but not many participants have come to take part afterwards. However, a small team formed and I got to be a part of it.

I myself went to this hackathon with one goal - work on something interesting, preferably a learning experience. I work with Raspberry Pi, electronics and Python, but I never got any experience with wireless communication so closely. I had to do some research before joining to make sure the project wasn't a dead end. This is what I've found:

• Model of implant's base station - Merlin@home EX1150
• BS communicates with the Implanted Cardiac Defibrillator in 402-405MHz range (MICS band)
• BS communicates with the doctors using a USB 3G modem - most likely with a "worldwide" SIM
• Base station and the implant usually communicate each night, at undetermined time
• I wouldn't be able to disassemble the station (luckily, people have done it before)
• The communications are highly unlikely to be secured

Naturally, it started to look like a great learning opportunity, as well as a great thought piece for the media. I joined the team without second thoughts.

Our team found ourselves a nice cubicle upstairs, with enough room for 4 people and enough wall sockets for 16. We got to work right away, I started to prepare the equipment&software we'd need and other guys started to search for materials on the transmitter, previous attempts on hacking this kind of equipment.

GNU/Radio has a good rep among hackers working with wireless communications, and I decided to bet on it (mind you, that was my first experience with SDR!). Not only that would be a great opportunity to use open-source software, but I also could use the capturing/decoding workflow on, say, a Raspberry Pi, when the need for a separate capturing device would arise. So, it all started with a fresh install of Debian and, while it took its time, learning about the people who have done it before. Also, I needed an SDR. Badly. I didn't have one, and it wouldn't be possible to intercept anything without one.

The finding results came back from other team members. Well, what a great learning experience it promised to be. A hacker that was working on it and that was about to present the results of his findings, died a week before the conference he'd present them on.

Not that it influenced our motivation in any negative way. But still, I have to say this:

RIP Barnaby Jack (22 November 1977 – 25 July 2013). You will be missed.

Debian installing, the base station, the SDR and first of numerous bottles of Coca-Cola consumed over that weekend

During the research phase, we talked about different outcomes possible. As it was mentioned already, the communication between base station and ICD took place at nights - moreover, the exact time wasn't known. Were we to miss the transmission, it didn't seem like we could catch another one. It wouldn't be that big of an issue, but we only had 48 hours and therefore 2 nights available. Oh snap.

We had agreed that I would stay up that night and make sure I have a setup able to record data, then go and see if the base station would know it had missed a communication window and try to communicate right after the bootup. Were it to not happen, we would only have one night and therefore one try to catch the communication occuring - after failing that, we would have nothing to tell people. It was already night, and the tension was building up.

After the Debian install was ready, I went onto installing GNU/Radio. I also have found an RTL-SDR - one of the participants had one and was OK to give it to us for the weekend. Not modified, with the stock antenna but still good enough for all our needs. As usual with Linux and running things as an unprivileged user, I had permission problem with accessing the SDR - but that got solved after running GNU/Radio as root, and I decided not to investigate it further. By that time all the other team members, including the girl with the implant, went to sleep in a separate room - as it made no sense to do otherwise.

The receiving part was looking like it worked. I was receiving noise on most bands but no way to verify this setup could actually receive anything. By the time I had an install with all the quirks ready, it was 4AM. Hardly anybody was awake at that point, but I had to try my luck. So, I went downstairs and found one of our mentors. The following conversation occured:

- Hey, do you have a car?
- ...Yeah.
- Can you give me your car keys?
- ...

Success!

I was the only one awake, and I finally got the setup able to capture RF data. Still at my cubicle and far away from the implant, I turned the base station on. It started flashing its status lights. Nothing could be registered. Maybe it needed to be close to the implant?

Not pictured - the girl sleeping nearby, oh, and the implant.

I asked a friend for help, we picked up my equipment and transferred it to the room where the girl was sleeping. We powered the base station up and started recording everything the SDR would catch.

Complete silence on 402-405MHz. It was clear our efforts had to be continued at the next night. Would we succeed or not - that seem to depend on a random chance and our effort put into the next day's preparations. It promised to be a stressful day for me.