Tag: Hacking

Vodafone R205: opening it up

I have posted about using an R205 without a Vodafone blessed network, and I wrote a quick software inspection of the device. This time I’m writing some notes about the hardware itself.

I have originally expected to just destroy the device to try to gain access to it, but it turns out it’s actually simpler than expected to open: the back of the device is fastened through four Torx T5 screws, and then just a bit of pressure to tear the back apart from the front. No screws behind the label under the battery. I have managed to open and re-close the device without it looking much different, just a bit weathered down.

Unfortunately the first thing that becomes obvious is that the device is not designed to turn on without the battery plugged in. If you try to turn it on with just the USB connected – I tried that before disassembly, of course – the device only displays “BATTERY ERROR” and refuses to boot. This appears to be one of the errors coming from the bootloader of the board, as I can find it next to “TEMP INVALID” in the firmware strings.

Keeping the battery connected while the device is open is not possible by design. Particularly when you consider that all the interesting-looking pads are underneath the battery itself. The answer is thus to just go and solder some cables on the board and connect them to the battery — I care about my life enough not to intend to solder on the battery, that one can be connected with physical placement and tape. This is the time I had to make a call and sacrifice the device. Luckily, the answer was easy: I already have a backup device, another Vodafone Pocket WiFi, this time a R208, that my sister dismissed. Plus if I really wanted, I could get myself a newer 4G version as that’s what my SIM card supports.

There are two sets of pads that appear promising, and so I took a look at them with a simple multimeter. The first group is a 5-pads group, in which one of them correspond to ground, two appear to idle around 3V, and one appears to idle around 4V. This is not exactly your usual configuration of a serial port, but I have not managed to get more details yet. The other group is a 10-pad group with two grounds, and a number of idling pads at 1.85V, which is significantly more consistent with JTAG, but again I have not managed to inspect it yet.

Annotated image of the E586 board.

So I decided to get myself some solid core wires, and try to solder them on the five-pad configuration I saw on the board. Unfortunately the end result has been destructive, and so I had to discard the idea of getting any useful data from that board. Bummer. But, then I thought to myself that this device has to be fairly common, since Vodafone sold it anywhere from Ireland, to Italy to Australia at least. And indeed a quick look at eBay showed me a seller having, not the R205, but the Huawei E586 available for cheap. Indeed, a lot of four devices was being sold for $10 (plus €20 for postage and customs, sigh!). These were fully Huawei-branded E586 devices, with a quite different chassis and a Wind logo on them. Despite coming from New York State, this particular Wind-branded company was Canadian (now goes by Freedom Mobile); I’m not sure on the compatibility of the GSM network, but the package looked promising: four devices, but only one “complete” (battery and back cover). I bought it and it arrived just the other day.

An aside, it’s fun to note that I found just recently that Wind was used as a brand in Canada. The original brand comes from Italy, and I have been a customer of theirs for a number of years there. Indeed, my current Italian phone number is subscribed with Wind. The whole structure of co-owned brands seems to be falling apart though, with the Canadian brand gone, and with the Italian original company having been merged with Tre (Three Italy). I’m not sure on who owns what of that, but they appear to still advertise the Veon app, which matches the new name of the Russian company who owned them until now so who knows.

Opening the Wind devices is also significantly easier as it does not require as much force and does not have as many moving parts. Indeed, the whole chassis is mostly one plastic block, while the front comes away entirely. So indeed after I got home with them I opened one and looked into it, comparing it with the one I had already broken:

//platform.twitter.com/widgets.js

If you compare the two boards, you can see that on the top-right (front-facing) there is a small RF connector, which could be a Hirose U.FL or an otherwise similar connector; on the R205, this connector is on the back, making it not reachable by the user. The pad for both RF connectors are visible on as not used in the opposite board.

Next to the connector there is also a switch that is not present in the R205, which on the chassis is marked as reset. On the R205 the reset switch is towards the bottom, and there is nothing on the top side. The lower switch is marked as WPS on the chassis on the Wind device, which makes me think these are programmable somehow. I guess if I look at this deeply enough I’ll find out that these are just GPIOs for the CPU and they are just mapped differently in the firmware.

I have not managed to turn them up yet, also because I do not trust them that much. They appear to have at least the same bootloader since the BATTERY ERROR message appears on them just the same. On the other hand this gives me at least a secondary objective I can look into: if I can figure out how to extract the firmware from the resources of the update binary provided by Vodafone, and how the firmware upgrade process works, I should be able to flash a copy of the Vodafone firmware onto the Wind device as well, since they have the same board. And that would be a good starting point for it.

Having already ruined one of the boards also allows me to open up the RF shielding that is omnipresent on those boards and is hiding every detail, and it would be an interesting thing to document, and would allow to figure out if there is any chance of using OpenWRT or LEDE on it. I guess I’ll follow up with more details of the pictures, and more details of the software.

Vodafone R205: prodding at the software

In my previous post on the matter I have talked about using a Vodafone-branded Huawei R205 (E586) mobile hotspot with another network operator without needing any firmware modification or special tool except for a browser and the developer tools in there. I also let it understood that I have decided to sacrifice the device, because I have another similar device that I can use, more powerful, and anyway I should get a newer generation, as this one does not have 4G support at all.

Before I venture into the gory details of yet another personal project that will most likely not get to its end, let me point you all at Juan Carlos Jimenez’s series of posts reverse engineering another Huawei device. In his case, that was a significantly friendlier Huawei ADSL modem. I still consider that almost a prerequisite reading.

In my case, the device is a Vodafone R205 “Pocket Wifi” adapter, and as I said before it is, or was, common in at least Ireland, Italy and Australia, although with different colours (the Australian version is black, while the Irish and Italian are white). As I’ll show later (but actually a bit of Googling would have showed already), this device is actually a rebranded E586 mobile hotspot, which other providers, such as Three UK, also distributed.

I was honestly afraid I would end up breaking the device once I opened it. It turned out not to be the case, but anyway before doing that I decided to snoop around what I could from the outside, or rather, while connected to it. As showed in the previous post, the device does come with a lot of non-minified JavaScript written by Huawei engineers, which makes it particularly interesting. Indeed some of the files come with a very short changelog at the top, too:

/*******************************************************************************
File Name   : vendorWifi.js
File Author : s00168237
Create time : 2011-09-27  05:49
Description : support Huawei API interface
Copyright   : Copyright (C) 2008-2010 Huawei Tech.Co.,Ltd
History     : 2011-09-27       1.0      create the file
version     : R205 firmware v1.0 and webUI v0.41
release date: 2011-11-18
version     : R205 firmware v2.0 and webUI v0.5
release date: 2011-12-19
version     : R205 firmware v2.3 and webUI v0.51
release date: 2012-12-21
version     : R205 firmware v2.6 and webUI v0.52
release date: 2012-01-06
version     : R205 firmware v2.7 and webUI v0.52
release date: 2012-01-13
version     : R205 firmware v3.0 and webUI v0.6
release date: 2012-01-16
date         version               author(No.)         description
2012.03.29   FWv4.0 UIv1.12.3389   tangyao t81004060   for vodafone fireware v4.0
2012.04.24   FWv4.1 UIv1.14.3559   tangyao t81004060   for vodafone fireware v4.1
2012.04.25   FWv4.2 UIv1.14.3559   tangyao t81004060   for vodafone fireware v4.2
*******************************************************************************/

Considering that the current Vodafone firmware (or should I say fireware) is 8.0, at least on the Australian website (the Irish one does not seem to have any), mine is significantly behind times. I have explicitly not updated it, afraid that they may have covered the hole that I have been using to configure the device.

There is also another interesting fact to note at this point: if you start Googling around you’ll find plenty of shady sites (Astalavista-shady I would say) that try to either sell to you or trick you into installing possible malware. What they promise is a way to de-brand the Vodafone R205 into a standard E586, which is indeed something nice to have, but as I said they are shady, so I have not bothered even considering them.

On the other hand it means that someone already managed to find a way to extract the firmware files from the Windows executable that Huawei provides, and reverse engineered the protocol that they use to flash the firmware onto the device. And they decided not to publish them, but rather make proprietary software bundled with Norton-knows-what. I find that extremely uncool, and on this, I’m definitely more aligned with the CCC crowd than what looks like your average mobile phone/broadband “hacker”.

Moving on, I decided to check for what may be open on the device. For instance if telnet or SSH were open it would make it easier to figure out ways around the device, but that didn’t help either. Indeed very few ports are open on the device: DNS, DHCP, HTTP and HTTPS (more in a second) and ports 1900 UDP and 50000 TCP for UPnP/IGD.

Nmap reports the following for the HTTPS configuration, which suggest a well expired certificate, since it is not valid after 2008, even though the firmware is clearly more recent (the changelog above reads 2012).

ssl-cert: Subject: commonName=ipwebs.interpeak.com/organizationName=Interpeak/stateOrProvinceName=Stockholm/countryName=SE
Issuer: commonName=Test CA/organizationName=Interpeak/stateOrProvinceName=Stockholm/countryName=SE
Public Key type: rsa
Public Key bits: 1024
Signature Algorithm: md5WithRSAEncryption
Not valid before: 2003-09-22T11:33:43
Not valid after:  2008-09-20T11:33:43
MD5:   2fcc e6cc bac8 8ea2 ca80 287f 2b8d 7d75
SHA-1: 7c6f 422e 37cb 83bf c3ef b004 f050 2c6f deba 6be2
ssl-date: 1970-01-01T00:20:18+00:00; -47y4d22h09m00s from scanner time.
sslv2:
  SSLv2 supported
  ciphers:
    SSL2_RC4_128_WITH_MD5
    SSL2_RC2_128_CBC_WITH_MD5
    SSL2_DES_192_EDE3_CBC_WITH_MD5
    SSL2_RC4_128_EXPORT40_WITH_MD5
    SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
    SSL2_DES_64_CBC_WITH_MD5

Both the HTTP and the HTTPS ports report themselves as IPWEBS/1.4.0 (nmap considers this “Huawei broadband router http admin”, so I suppose they use it for their non-mobile routers too), and that matches the commonName found in the certificate.

Port 50000 (which is used by UPnP but responds to obvious HTTP requests, thanks SOAP), seem to have a different server altogether, with all headers shouted (all-capitals) and reporting itself as:

SERVER: PACKAGE_VERSION  WIND version 2.8, UPnP/1.0, WindRiver SDK for UPnP devices/

Both servers actually point to the same owners: Interpeak appears to have been bought by Wind River Systems (as you can see if you go to interpeak.com), I assume some time between 2003 and 2009, as the certificate is still pointing at the Swedish company, and in 2009, Wind River itself was bought by Intel.

My first thought (which came before realizing Interpeak was bought by Wind River) was that maybe the Intel UPnP SDK was derived off Wind River’s, but said SDK was last released in 2007, so it appears the two are unrelated. What I did not realize until I checked the Wikipedia page I linked, is that Wind River is actually the company behind VxWorks, which points almost straight at this device using VxWorks internally.

Turns out that there is an easy way to confirm this. You can find the firmware update packages online, on various Vodafone websites (different versions for different countries); these are Windows executables that look like installers, but are rather flasher applications. You can also find the update packages for the E586 (which is the same device, just without the Vodafone branding.

Though I have not found a way to extract the firmware from those files yet, I knew it was not overly complicated. There are scammy-looking sites that provide tools to flash unbranded firmware onto branded device (which is very similar to what I’m trying to look for anyway), but I would not trust those to the point of running them on any of my systems. So I turned to what every bored person with a little bit of understanding of reverse engineering would: binwalk.

While it has not been able to clearly identify something like “start of VxWorks firmware at address 0xdeadbeef”, it did have a very long list of random things starting from copyright strings and finishing with a lot of HTML fragments. This looked promising so I decided to run strings on the same file. The results were very promising and interesting. Starting from figuring out that the E586 firmware updater is written using Qt, and you can even find an XPM cursor in it (XPM, in a binary file, really? Sigh!).

]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
     ]]]]]]]]]]]  ]]]]     ]]]]]]]]]]       ]]              ]]]]         (R)
]     ]]]]]]]]]  ]]]]]]     ]]]]]]]]       ]]               ]]]]            
]]     ]]]]]]]  ]]]]]]]]     ]]]]]] ]     ]]                ]]]]            
]]]     ]]]]] ]    ]]]  ]     ]]]] ]]]   ]]]]]]]]]  ]]]] ]] ]]]]  ]]   ]]]]]
]]]]     ]]]  ]]    ]  ]]]     ]] ]]]]] ]]]]]]   ]] ]]]]]]] ]]]] ]]   ]]]]  
]]]]]     ]  ]]]]     ]]]]]      ]]]]]]]] ]]]]   ]] ]]]]    ]]]]]]]    ]]]] 
]]]]]]      ]]]]]     ]]]]]]    ]  ]]]]]  ]]]]   ]] ]]]]    ]]]]]]]]    ]]]]
]]]]]]]    ]]]]]  ]    ]]]]]]  ]    ]]]   ]]]]   ]] ]]]]    ]]]] ]]]]    ]]]]
]]]]]]]]  ]]]]]  ]]]    ]]]]]]]      ]     ]]]]]]]  ]]]]    ]]]]  ]]]] ]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]       Development System
 %s%s %s
]]]]]]]]]]]]]]]]]]]]]]]]]]]       
]]]]]]]]]]]]]]]]]]]]]]]]]]       KERNEL: 
 %s%s
]]]]]]]]]]]]]]]]]]]]]]]]]       Copyright Wind River Systems, Inc., 1984-2005

Yes, I guess this firmware is based on VxWorks, if someone still had doubts. The strings are also quite telling, including the fact that the device comes with wpa_supplicant, and thus is likely able to operate as a Wireless client rather than just as an access point, which is going to be nice if I ever wanted to implement my proof of concept.

The firmware itself appears to have a lot of juicy information: in addition to the JavaScript (that does appear to be minified in the new firmware version) it provides a number of information on the webapp itself, and possible commands for the AT interface of the device. All of this is generally going to be more interesting if I can find out how to extract the actual firmware image from the device. I just need to find a working PE dumper tool and figure out which resource is exactly 32MiB in size.

Hopefully by the time I get to publish the next post in this series, I will have something more useful for everybody, either a way to flash the new firmware without the original tools, or access to the serial port on board of the device (spoilers!)

Using a Vodafone R205/R208 mobile hotspot on another network

Before I dig into background and story, let me provide technical information of what this post is about. The Vodafone R205 is a Huawei-manufactured mobile hotspot; the R208 is its bigger brother, using a similar if not identical firmware. Vodafone sells these devices as “mobile broadband” throughout the world: I got mine in Ireland, my sister got one in Italy, and a quick googling showed it to be extremely common in Australia, too.

The R205 appears to be just a branded E586 (as noted by the hardware model silkscreened on the PCB — I have opened up the device, I’ll write about that in the future) with a custom Vodafone-specific firmware. There are out there shady sites that tell you how to flash any random E586 firmware on it, but I’m not really interested in doing something like that.

I moved to Dublin almost four years ago, and a few months after I was here, my sister planned to come visit me with friends. Because of the timing of her flights, that left them with about a day during which I still had to work, and they would just go randomly shopping and touristing around. She knew Dublin already, but at the same time as I had gotten to experience it better, they wanted to have me “at hand” to contact — since the roaming fees from Italy were crazy at the time, I decided to just buy a mobile hotspot (Vodafone R205 by Huawei) for cheap and get a month (because I needed more than a weekend) data on it, it was significantly cheaper than the roaming fees, and I kept the hotspot afterwards. I asked before buying, the device was neither SIM- nor network-locked, which is why I went for Vodafone rather than the other slightly cheaper options.

After the month ran out, instead of keeping the original SIM on it, I put another Vodafone SIM, coming from work. The reason was to be found in a number of issues with the connectivity of hotspot mode on Android phones, and in my need for a backup Internet connection while oncall. This worked out fine because the APNs of the business account matched the public account ones, so I had nothing to reconfigure: just plug the SIM in and it works.

Then came the day I went to Zurich on a work trip, and I needed connectivity. Since Switzerland is not part of EU, the special roaming rules don’t apply and the Vodafone roaming charge was just crazy insane, so I ended up grabbing a local data-only SIM card (including an USB mobile broadband modem). Unfortunately I wanted it on the go to play Ingress, too, and that was slightly more complicated to do with a USB device (never mind security frowning upon me even considering plugging in the USB device to my work laptop and installing its drivers). So I put the SIM into the hotspot, and it failed to connect. Ouch.

My first guess was that they told me a lie regarding the device not being network locked: a different Vodafone SIM worked, a Swiss Orange didn’t. But when I started googling for unlocking the device, a few of the more honest unlock services would actually tell you upfront what error message you need an unlock for. And I didn’t have that particular error message. Instead the problem was a failure to connect to the IP network. Which turned out to be an APN problem.

Indeed the APN for Orange (now Salt) is different from Vodafone’s, so you have to go and change it, which is fairly easy: there is a “Mobile Broadband” section, and within that there is a form to configure the various APN and login settings. Except every time I filled it in, it would error out with a “missing field” error.

R205 error message, when trying to set umobile parameters

I forgot how I ended up trying this, but since it was telling me it marked the field as red, and no field was red, I opened the Developer Tools and tried again. And I got an error log in the console:

setAccountTypeCallback failed

Put a breakpoint on the log in the JavaScript (that thankfully Huawei didn’t actually minify!) and I can figure out what is being called when I try to save. The important part is in this function:

if (value === "Custom") {
    callbacksToChain = 0;
    $.each(['setCustomAccountTypeCallBack', 'setConnectionModeCallback', 'setAccountTypeCallback'], function() {
        callbacksToChain++;
        Util.addHookAfter(window, this, doConnectionIfAllIsWell);
    });
    setMobileBroadbandConnectionSettings();
}
else {
    callbacksToChain = 0;
    $.each(['setConnectionModeCallback', 'setAccountTypeCallback'], function() {
        callbacksToChain++;
        Util.addHookAfter(window, this, doConnectionIfAllIsWell);
    });
    saveConnectionDetails();
    setAccountType();
}

If the selected profile is ‘Custom’, then the form values are actually sent to the device. Otherwise only the profile name is sent over to be selected. This makes sense to a point, if the providers may have a long list of profiles with different configurations that may be updated via firmware update rather than asking the users to reconfigure it.

The problem is, of course, that there is no “Custom” profile in the interface of my R205 – but as I found out recently, there is on my sister’s R208 – and the only value for which the form gets enabled is selecting the empty row in the drop-down box. Which is then empty and causes the profile to be empty, and that explains the error message, and even the lack of red on the page: there is no CSS style for the drop-down box to be red.

Simply adding a “Custom” entry to the drop-down box is enough to make the device accept the parameters in the form, which is not horrible at all. Unfortunately doing so from a mobile phone is not easy, as you have to go and use the developer tools for it to work. At least it appears that as long as the last configuration was a Custom one, then the drop-down still lists Custom as an option, which allowed me to reconfigure the hotspot in Japan with just my mobile phone while sitting in a coffee shop in Fukuoka. The R208 I have from my sister is in Italian (since she got it in Italy) and has a “Custom” entry in the drop-down box, so it would be slightly handier to set up.

I have planned at some point to write a simple tool that can set the parameters without looking at the UI, but I have not done so yet. This should be fairly easy since it would just be a matter of sending a login request to get the admin cookie and then send the form with the right parameters. As a command-line thing on Linux it would make it easy to set up, but the useful part would be as a simple Android app that I can use to reconfigure the device without going crazy.

Expect another post in a few weeks about what I found inspecting the device a little bit in software and hardware, if nothing else because I was bored while waiting for some information and approvals to continue my other project.

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