He Jailbroke His Renault's Infotainment Just to Fix the Clock

Opening Dialogue

Shiwen: On November 2nd, the Estonian ethical hacker Rasmus Moorats posted an article on his blog with a straightforward title: To fix the clock in his car, he jailbroken the car’s navigation system. The car was a 2014 Renault Latitude with TomTom Carminat LIVE navigation software, running a custom system based on the 2011 Linux 2.6 kernel. The article quickly rose to the top of Hacker News, receiving over 500 points and over two hundred comments. Interestingly, the technical approach was extreme but the goal was simple: to adjust the clock in the car that was one hour off. Yongliang, what kind of story is this?

Yongliang: It started normally. Estonia had daylight saving time, and at the end of October, the time changed from UTC+3 to UTC+2, causing the clock to be one hour slow. He searched through the settings menu but couldn’t find an option to change the time. The previous owner had warned him when selling the car: changing the clock required a navigation map SD card. He didn’t believe it at the time and thought the owner probably wouldn’t access the menu, so he didn’t get the card. Later, he confirmed that the previous owner was right: the settings menu’s definition was already on that card. Without the card, the navigation system didn’t know how to access the settings.

Q1: How could a single SD card lock up the clock?

Shiwen: Then find a way to get a card, couldn’t you just copy one?

Yongliang: No, that was the first obstacle. The system had DRM: it verified the CID of the SD card (a unique ID burned onto the card) and the file signature was tied to that CID. Copying the file to a blank card would be rejected. Moorats speculated that this DRM was to prevent map piracy. He checked third-party channels selling real cards, with shipping costs of about 60 euros to Estonia. He summarized his own words: I didn’t want maps, I used mobile navigation, I just wanted to change the damn time. So he made a decision that first made everyone laugh and then silent: he didn’t buy the card, he rooted the navigation system himself.

Shiwen: From a cost-benefit perspective, isn’t this completely uneconomical?

Yongliang: Of course it isn’t economical if calculated carefully. 60 euros for one transfer would solve the problem, but jailbreaking required weeks of unpaid labor. But for him, it wasn’t about cost; it was about principle: the car was property he paid for, but one of its most basic functions was held back by a proprietary card. This was the core issue in disputes over repair rights: you think you’ve bought the product, but you actually only got permission to use it, with the key to that permission in the supplier’s hands.

Q2: How did the chain of events work?

Shiwen: Let me explain his technical approach. What was the first step?

Yongliang: The first step was to rely on previous efforts. He found a reverse repository (written in French, the repository author described heavy use of LLMs) and obtained the firmware download URL from there. One file in the firmware called ttsystem was an ext3 file system, which served as the root file system of the device. Then he took what I consider the most professional step: using QEMU to build a emulator, customizing the same version of the 2.6 kernel, patching it, and setting up a simple CAN emulator. The system tried to restart every 3 seconds, so he patched it to ignore the reboot system call and force it to stay running. With the emulator, he could repeatedly test attack strategies without touching the real car.

Shiwen: What did he see in the emulator?

Yongliang: Looking at this 2011 device, the tight security measures are surprising: the rootfs is read-only, the SD card uses vfat and is noexec, with an additional unionfs layer on top. Almost all partitions are either read-only or exec-protected. His observation is that such strong security settings for a 2011 device are unexpected. He also reverse-engineered the parsing engine for the car system’s custom UI scripting language, ttn, and found that every time the system boots, a script file called master.script is loaded, revealing that the attack surface lies within this scripting language.

Shiwen: What weapons did the scripting language provide him with?

Yongliang: Two half-finished tools. The first is the SHEX command, which allows execve to execute arbitrary binaries but only accepts space-separated tokens. It can control which program runs without allowing parameter passing. Although the SD card is noexec, it can be bypassed by loading scripts from /bin/sh, but parameters cannot be passed, making it impossible to use. The second is the LOG command, which can write a line of printable ASCII to a specified path. LOGFILE defines support for ../ path traversal, and since ttn runs as root, theoretically it could write anywhere in the system. However, the rootfs is read-only, and other partitions are exec-protected, so writing there cannot be executed. He also conducted模糊 testing on the image decoder with Unicorn, finding many out-of-bounds reads, but no usable writes. The two pieces of puzzle he had couldn’t fit into the lockhole.

Shiwen: So how did he piece them together in the end?

Yongliang: This is the most beautiful part of the whole story. He remembered a classic technique in kernel vulnerability exploitation called core_pattern: by writing a pipe character and command to /proc/sys/kernel/core_pattern, the kernel would execute this command as root when the program crashed to handle the coredump. This feature was introduced in 2.6.24, and the car system’s kernel was exactly 2.6.28. So he used LOG’s path traversal to point LOGFILE to core_pattern, wrote a pipe command to execute the payload script from /bin/sh using /bin/sh, and then ran SHEX with /bin/dbus-monitor: this program would SIGABRT itself when it couldn’t connect to the system bus, generating a coredump without causing a whole machine restart. Once the kernel saw a coredump, it obediently executed the script on his SD card as root. The final master.script contained only three lines. After gaining execution rights, his first step was to fully back up eMMC with dd, then he found that time was stored in /mnt/flash/settings.dat. The car system had no concept of time zones; time was taken from the GPS and local offset was stored in minutes: his value was 180, which he changed to 120, and he finished.

Q3: What’s being discussed in the comments section?

Shiwen: More than two hundred comments on HN, what are they mainly talking about?

Yongliang: The direction of high-star reviews is surprisingly consistent: the absurdity of timekeeping issues is a industry problem. An experienced user said that the difficulty in setting up the VCR clock was an old issue from the 90s, but at least back then it could be done; without a dedicated SD card, fixing the clock was completely impossible, which can be considered the extreme example of user-unfriendly design. Another person gave an example from their own experience: a professional programmer in Arizona said that his new Honda CRV’s clock was off by one hour every six months, and he still hasn’t figured out how to fix it. Another person wanted to root their 2014 Honda car system because they couldn’t stand the automatic playback commands sent by Bluetooth every time it connected. Canadian netizens are even more worried: several provinces will no longer adjust the timekeeping settings next spring, and many car systems’ DST rules won’t be updated, leading to similar problems.

Shiwen: Did he mention that it’s a long way around?

Yongliang: Yes. Some people said the author should have directly bought the card from the previous owner; sometimes ordinary users are right. Others offered a commercial solution: simply install a new car system and ensure it supports functions like steering wheel control. A Volkswagen owner said that there’s already a DST switch in their car menu, while also criticizing Renault’s poor ergonomic design and firmware over the years. Several voices point to the same fact: some manufacturers make timezone switching into a switch, while others lock it away in DRM. The difference isn’t in technical difficulty, but in what they consider users to be.

Q4: What does this SD card look like in enterprise software?

Shiwen: With a technical team of seventeen years, are you familiar with this scenario?

Yongliang: Absolutely familiar. This is my experience, not statistics: almost every large company has this same pattern in their procurement history. One system says this feature needs to be added as a module, another module says its operation depends on its license server, the export format is proprietary, and if you want to migrate data, there’s another set of interfaces waiting for you. Renault uses a card, while enterprise software uses a contract—the structure is exactly the same: what suppliers lock in isn’t what they sell you, but the part of your system you can’t do without. DRM ostensibly prevents piracy, but in reality, it locks away basic functions like adjusting the clock as a hostage. When anti-piracy measures start hindering the owner from using their own property, it crosses a line.

Shiwen: The author said that security in 2011 was unexpectedly strong. How has it been by 2026?

Yongliang: It’s been dismantled by an determined individual with a set of open-source toolchains. QEMU, Unicorn, and reverse engineering tools are all free, but the strategy of using ambiguity for security has a shelf life, which is determined by the cost curve of reverse engineering. This curve is being pushed down by AI, and the article provides evidence: the author’s previous repository was heavily used with LLM assistance. Reverse engineering used to be an expert skill in small circles, but now the entry cost is clearly decreasing. For manufacturers, this means that locking users with private formats is becoming less effective: users who can’t break it will buy a card, while those who can spend no money at all. The pricing power of locking strategies is slipping away from suppliers.

Q5: Apart from disputes, what can engineers steal?

Shiwen: What can people in the tech industry learn from this article?

Yongliang: Three things. First, build a feedback loop yourself. At first, he was reluctant to spend time building a simulator, but later admitted that simulators were extremely useful: without real device feedback, one could create their own, instantly reducing the cost of trial and error by a factor of ten. When I led my team, this was also the rule—for any environment that couldn’t be verified, the first thing to do was build test equipment. Second, treat limitations as constraints for solving problems. If something can’t be executed, let the kernel execute it for you; if parameters can’t be passed, find a program that crashes easily. The difference between experts lies not in their permissions but in whether they can still solve a problem within the rules. Third, back up before taking action. The first thing he did when getting executive power was to fully back up eMMC with dd. This habit is worth adopting by every engineer.

Shiwen: A comment drew a lot of sympathy: Write down your discoveries for future versions of yourself.

Yongliang: Yes, someone reminded the author: It’s good that I wrote it down, because if daylight saving time changes again in six months, he would have to start over. Several people said this was very true, and personal projects should also write down their discoveries for future versions of themselves. The other side of jailbreaking isn’t rebellion; it’s living day-to-day. Finally, my overall judgment: This story will be repeatedly cited in debates about rights to repair because it sets a current price for device sovereignty. If the time is changed by one hour, an ethical hacker would need to build a simulator, reverse script parsers, and use kernel mechanisms to go around; for ordinary people, the only option is to spend 60 euros to buy a card. When self-rescue becomes exclusive to experts, it’s not an option anymore. What manufacturers really should fear isn’t someone breaking the jail, but more and more people being able to afford it.

---

Signed: Yongliang