I hacked a train toilet

The other day I rode on a Class 800 train in the UK. This is the “Intercity Express” train designed to replace the venerable HST (Intercity 125 with Mark 3 coaches, a train of which I have many memories and which I will dearly miss).

Modern trains in the UK have disabled toilets with power-operated doors. The older models of these toilets had “open”, ”close” and “lock” buttons on the inside, where you had to press “close”, wait for the door to close, and then press ”lock”. There is no separate “unlock” button; pressing the “open” button on the inside automatically unlocks and opens the door.

Of course, there is a reason for the separation of the closing and locking functions, but not the opening and unlocking functions: it avoids a Denial of Service attack where someone can just press “close” and then jump out before the door closes. If the interior “close” button automatically locked the door, this would result in the toilet becoming permanently inaccessible.

The problem with this design is that most people don't understand state machines, and this design confused a lot of people who were unable to lock the door correctly, or believed they'd locked the door when they hadn't.

As a result the newer disabled toilets on trains tend to have a lever you have to move to lock the door:

This design is an improvement since it is more intuitively comprehensible to most people. Except of course, this lever isn't a “real” lever directly connected to a locking mechanism but just some input to a microcontroller. This raises the question of what happens when the state of the lever doesn't match up with the state of the door and how the microcontroller deals with that.

Some models of train in the UK solve this robustly by having the lever spring back to the “unlocked” position if you try to move it to the “locked” position when the door is open. Presumably this lever-return mechanism is electromagnetically activated whenever the door is in the wrong state for the lever to be active.

Hitachi, however, have chosen a different strategy: a tiny metal pin is projected whenever you should not be able to move the door handle from “unlocked” to “locked”. This pin itself locks the lock handle in the unlocked position.

The problem with this is that there is some play in the lever around when exactly the microcontroller detects the lever as being in the “locked” position. As such, you can close the door, then hold the lever just beyond the point at which the locking pin could engage with it, but not to the point where it reads as “locked”. Then you can open the door, but the locking pin projects into thin air; thus the lever is free and can be moved to the locked position. The door close button remains active and you can then close the door. I confirmed that the door will then immediately lock as soon as the door is closed. Since I could do this and then jump out before the door closes, this is effectively a toilet DoS vulnerability on a train.

I've posted a video here where I demonstrate this issue.

You can also see the locking pin in the image above. Ordinarily, it should not be visible projected, but because I have the handle at the precise point where the logic thinks it's in the unlocked position but far enough away from it that the locking pin can't make contact, the locking pin has projected into air.

This is the second opportunity I've had to test this issue on the Class 800. On this particular occasion when I was testing this vulnerability, I seem to have actually confused the toilet door controller enough that it decided “screw this” and went into out-of-order mode, which didn't happen the first and previous time. The toilet was working again when I alighted from the train; I have no idea if it reset automatically after some period or if someone on the train reset it.

Amusingly this is not the first DoS vulnerability I've found on a train — but that will have to wait for another article.

Since some appear to have misinterpreted this article, I will clarify: I only demonstrated this because I could do it without inconveniencing anyone. There was nobody around waiting to use the toilet, and the train had multiple toilets. I didn't anticipate the toilet becoming “out of order” and am still not entirely sure why this occurred — but in any case the toilet was back in order after it had rebooted a short time later. In any case, the video is not of me trying to actually DoS the toilet, just to demonstrate that it would be possible.

For those that missed it, a recording of my 37C3 talk “Adventures in Reverse Engineering Broadcom NIC Firmware” can be found here.