By: admin | Tags: Graphic, illustration, Logo
As medical implants become more common, sophisticated and versatile, understanding the code that runs them is vital. A pacemaker or insulin-releasing implant can be lifesaving, but they are also vulnerable not just to malicious attacks, but also to faulty code.
For commercial reasons, companies have been reluctant to open up their code to researchers. But with lives at stake, we need to be allowed to take a peek under the hood.
Over the past few years, several researchers have revealed lethal vulnerabilities in the code that runs some medical implants. The late Barnaby Jack, for example, showed that pacemakers could be “hacked” to deliver lethal electric shocks. Jay Radcliffe demonstrated a way of wirelessly making an implanted insulin pump deliver a lethal dose of insulin.
But “bugs” in the code are also an issue. Researcher Marie Moe recently discovered this first-hand, when her Implantable Cardioverter Defibrillator (ICD) unexpectedly went into “safe mode”. This caused her heart rate to drop by half, with drastic consequences.
It took months for Moe to figure out what went wrong with her implant, and this was made harder because the code running in the ICD was proprietary, or closed-source. The reason? Reverse-engineering closed-source code is a crime under various laws, including the US Digital Millennium Copyright Act 1998. It is a violation of copyright, theft of intellectual property, and may be an infringement of patent law.
Beyond legal restrictions, there’s another reason why researchers can’t just look at the source code in the same way you might take apart your lawnmower. It takes a very talented programmer using expensive software to reverse-engineer code into something readable. Even then, it’s also not a very exact process.
To understand why, it helps to know a bit about how companies create and ship software.
Software starts as a set of requirements – software must do this; it must look like that; it must have these buttons. Next, the software is designed – this component is responsible for these operations, it passes data to that component, and so on. Finally, a coder writes the instructions to tell the computer how to create the components and in detail how they work. These instructions are all the source code – human-readable instructions using English-like verbs (read, write, exit) mixed with a variety of symbols which the programmer and the computer both understand.
Up to this point, the source code is easily understood by a human. But this isn’t the end of the process. Before software is shipped it goes through one final transformation – it is converted to machine code. It now looks like just a lot of numbers. The source code is gone, replaced by the machine code. It’s now a bit like the inside of your car stereo; it “contains no serviceable parts”. Users are not supposed to mess with the machine code.
READ MORE
