Project Logs

Collapse

• Hardware hacking succeeded

  Arya • 06/26/2016 at 14:12 • 4 comments

  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"...

  Read more »

• Tearing down the base station

  Arya • 06/23/2016 at 17:29 • 1 comment

  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:

  Read more »

• First work weekend (late log)

  Arya • 06/20/2016 at 17:39 • 0 comments

  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!

  Read more »

• Links to useful information

  Arya • 05/09/2016 at 04:24 • 0 comments

  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

• Woohoo, the Hackaday Prize! What now?

  Arya • 05/09/2016 at 04:06 • 0 comments

  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!

• Plans & Hackaday Prize

  Arya • 04/25/2016 at 11:00 • 0 comments

  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.

  Read more »

• The hackathon story - third day

  Arya • 04/25/2016 at 01:45 • 0 comments

  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.

  Read more »

• The hackathon story - second day

  Arya • 04/25/2016 at 00:00 • 0 comments

  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 had barely started the step 1. An app mockup would be step 5, essentially, the only thing we could show if the first step failed. Sounded like a good idea. Mentors came to our cubicle, I booted up my laptop to launch all the software I'd need to continue the work.

  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...

  Read more »

• The hackathon story - first day

  Arya • 04/24/2016 at 21:56 • 0 comments

  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.

  Read more »

View all 9 project logs