Reverse Engineering is just the first step

Last year I said that reverse engineering obsolete systems is useful giving as an example adding Coreboot support for very old motherboards that are simpler and whose components are more likely to have been described somewhere already. One thing that I realized I didn’t make very clear in that post is that there is an important step on reverse engineering: documenting. As you can imagine from this blog, I think that documenting the reverse engineering processes and results are important, but I found out that this is definitely not the case for everybody.

On the particularly good side, going to 33c3 had a positive impression on me. Talks such as The Ultimate GameBoy Talk were excellent: Michael Steil did an awesome job at describing a lot of the unknown details of Nintendo’s most popular handheld. He also did a great job at showing practical matters, such as which tricks did various games use to implement things that at first sight would look impossible. And this is only one of his talks, he has a series that is going on year after year, I’ve watched his talk about the Commodore 64, and the only reason why it’s less enjoyable to watch is that the recording quality suffers from the ages.

In other posts I already referenced Micah’s videos. These have also been extremely nice to start watching, as she does a great job at explaining complex concepts, and even the “stream of consciousness” streams are very interesting and a good time to learn new tricks. What attracted me to her content, though, is the following video:

I have been using Wacom tablets for years, and I had no idea how they really worked behind the scene. Not only she does a great explanation of the technology in general, but the teardown of the mouse was also awesome with full schematics and explanation of the small components. No wonder I have signed up for her Patreon right away: she deserve to be better known and have a bigger following. And if funding her means spreading more knowledge around, well, then I’m happy to do my bit.

For the free software, open source and hacking community, reverse engineering is only half the process. The endgame is not for one person to know exactly how something works, but rather for the collectivity to gain more insight on things, so that more people have access to the information and can even improve on it. The community needs not only to help with that but also to prioritise projects that share information. And that does not just mean writing blogs about things. I said this before: blogs don’t replace documentation. You can see blogs as Micah’s shop-streaming videos, while documentation is more like her video about the tablets: they synthesize documentation in actually usable form, rather than just throwing information around.

I have a similar problem of course: my blog posts are not usually a bit of a stream of consciousness and they do not serve an useful purpose to capture the factual state of information. Take for example my post about reverse engineering the OneTouch Verio and its rambling on, then compare it with the proper protocol documentation. The latter is the actual important product, compared to my ramblings, and that is the one I can be proud of. I would also argue that documenting these things in a easily consumable form is more important than writing tools implementing them as those only cover part of the protocol and in particular can only leverage my skills, that do not involve statistical, pharmaceutical or data visualisation skills.

Unfortunately there are obstacles to these idea of course. Sometimes, reverse engineering documentation is attacked by manufacturer even more than code implementing the same information. So for instance while I have some information I still haven’t posted about a certain gaming mouse, I already know that the libratbag people do not want documentation of the protocols in their repository or wiki, because it causes them more headaches than the code. And then of course there is the problem of hosting this documentation somewhere.

I have been pushing my documentation on GitHub, hoping nobody causes a stink, but the good thing about using git rather than Wiki or similar tools is exactly that you can just move it around without losing information. This is not always the case: a lot of documentation is still nowadays only available either as part of code itself, or on various people’s homepages. And there are at least two things that can happen with that, the first is the most obvious and morbid one: the author of the documentation dies, and the documentation disappears once their domain registration expires, or whatever else, or if the homepage is at a given university or other academic endeavour, it may very well be that the homepage gets to disappear before the person anyway.

I know a few other alternatives to store this kind of data have been suggested, including common wiki akin to Wikipedia, but allowing for original research, but I am still uncertain that is going to be very helpful. The most obvious thing I can think of, is making sure these information can actually be published in books. And I think that at least No Starch Press has been doing a lot for this, publishing extremely interesting books including Designing BSD Rootkits and more recently Rootkits and Bootkits which is still in Early Access. A big kudos to Bill for this.

From my side, I promise I’ll try to organize my findings of anything I’ll work on in the best of my ability, and possibly organize it in a different form than just a blog, because the community deserves better.

33c3 impressions: ethical development and Dieselgate

The Dieselgate is in my opinion an interesting case study for the ethics of software development and hacking in general. Particularly because it’s most definitely not a straightforward bad guys vs good guys case, and because there is no clear cut solution to the problem. There was a talk about this (again) at the Chaos Computer Congress this year. It’s a nice talk to watch:

I was actually physically in the room only for the closing notes, and they had me thinking, thus why it was the second talk I watched once back in Dublin, after the Congres was over.

[Regarding the responsibility for Bosch as the supplier to Volkswagen]

If you build software that you know is used to be illegally, it should it must be your responsibility to not do that and I’m not sure if this is something that is legally enforceable but it should be something that’s enforceable ethically or for all us programmers that we don’t build software that is designed to break the law.

The rambling style of the quote is clearly understandable as it was a question asked on the spot to the speaker.

Let me be clear: these cheating “devices” (the device itself is not the cheating part, but rather the algorithms and curves programmed onto it, of course) are a horrible thing not only from the legal point of view but because we only have one planet. Although in the great scheme of things they appear to have forced the hands of various manufacturers towards moving to electric cars quicker. But let’s put that aside for a moment.

Felix suggests that developers (programmers) should refuse to build software to break the law. Which law are we talking about here? Any law? All the laws? Just the laws we like?

Let’s take content piracy. File sharing software is clearly widely used to break the law, by allowing software, movies, tv series, books, music to be shared without permission. DRM defeating software is also meant to break (some, many) laws. Are the people working on the BitTorrent ecosystem considering that the software they are writing is used to break the law? Should it be enforceable ethically that they should not do that?

Maybe content piracy is not that high in the ethical list of hackers. After all we have all heard «Information wants to be free», particularly used as an excuse for all kind of piracy. I would argue that I’m significantly more open to accept de-DRM software as ethical if not legal, because DRM is (vastly) unethical. In particular as I already linked above, defeating DRM is needed to fix the content you buy and to maintain access to the content you already bought.

Let’s try to find a more suitable example… oh I know! “Anonymous” transaction systems like Bitcoin, Litecoin and the newest product of that particular subculture, Keybase’s zCash which just happens to have been presented at 33C3 as well. These are clearly used to break the law in more way than one. They allow transactions outside of the normal, regulated banking system, they allow to work around laws that apply to cash-only transactions, and they keep engineering to make transactions untraceable. After all, Silk Road would probably have had a significant reduction in business if people actually had to use traceable money transfers.

Again, should we argue that anybody working on this ecosystem should be ethically enforced out? Should they be forced to acknowledge that the software they work on is used for illegal activities? Well, maybe not, after all these systems are just making things easier, but they are not enabling anything that was not possible already before. So after all, they are not critical to the illegal activity, so surely it’s not the developers fault up to this point.

Let’s take yet another example, even though I feel like I’m beating a dead horse. The most loved revolutionary tool: Tor. When you ask the privacy advocates, this is the most important tool for refugees, activists, dissidents, all the good people in the world. And arguably, in this day and age, there are indeed many activists and dissidents that a lot of us want to protect, as even the US starts feeling like a regime to some. When asked about it, these advocates would argue that supermarket loyalty cards are abused more than Tor.

But if you do take down your starry-eyed glasses, you’ll see how Tor has been used not only by Silk Road and its ilks, but also for significantly nastier endeavours than buying and selling drugs. Another talk from 33c3 criticised law enforcement using “hacking techniques”, particularly when dealing with child pornography websites, and for once it was not doing so simply to attack law enforcement’s intentions of breaking Tor, but rather the fact that they have caused lots of evidence to be thrown out as fruit of poisonous tree.

I’m not arguing that Felix is wrong with saying that Bosch very likely knew what the software they developed, under spec from their customer, would have caused. And I’m not sure I can actually asses the ethical differences between providing platforms for people to hire killers and poisoning our cities and planets. I’m not a philosopher and I don’t particularly care about thinking through trolley problems, whether for real or for trolling. (Yes we have all seen the memes.)

But at the same time, I find it ironic that about the same group of people who cheered on his take down of Bosch would also cheer Tor and the other projects… you could say that what Felix referred to was more about immorality than illegality, but not all morals are absolute, and laws are not universal. And saying that you want to enforce whatever laws you think should be, but not others, well, it’s not something I agree with.

Leaving this last consideration aside – and it’s funny that just his last few phrases are what brought me to post all this! – I really liked Felix’s talk and happy that he’s talking a grown-up approach, rather than the anarchist hacker’s. Among other things admitting that it might not be feasible to suggest or force the car companies to open-source their whole ECU code, but it might be feasible to approach it like Microsoft’s Shared Source license.

Finally I would point out that this is a possibly proper example of where giving the ability of users to upload their own code is not something I’d be looking forward to. The software that is the centre of the storm is not designed to just defeat regulation, for the sole sake that corporations are evil and want to poison our planet, even though I’m sure that it would be an easy narrative, particularly with the Congress crowd. Instead, these curves and decisions are meant to tip the scales towards the interests of the user rather than those of the collectivity.

You just need to watch the talk and you’ll hear how these curves actually increase the time-to-service for cars, both by reducing the amount of dirt getting caught by the EGR and by reducing the amount of AdBlue used. It is also stands to reason that the aim of not only the curves, but the whole design of these cars is to ignore regulations wherever possible (since the ECU helps cheating during the needed tests) to improve performance. Do we really expect that, if people were allowed to push their own code into the ECU they would consider the collective good, rather than their own personal gain? Or would you rather expect them to rather disable the AdBlue tank altogether, so they have to spend even less time worrying about servicing their cars?

Let me be clear, there is no easy solution to this set of problems. And I think Felix’s work and these talks are actually a very good starting point to the solution. So maybe there is hope, after all.