I am actually fascinated by car electronics. I had heavily modified the software on mine, but it was easier than modern stuff, no encryption of the code, and even the checksum code only triggered a DTC with no consequences.
The only module that was encrypted was the main module, but it if you knew the security PIN you could do what you wanted. It was determined by people that if you observed the jitter of the CAN line fast enough, you could leak the pin via a side channel attack.
But modern car electronics are encrypted, and some probably have security processors that might trigger some irreversible states if you tamper with them. Modern cars are basically as locked up as a PS5.
I am fascinated by what you are saying and would love to read more about it. How did you go about modifying the software of some part of your car.
Having worked in this field, I can confirm that most such parts these days come with chip supported read/write protections for part of flash that contain the code. But even with no protections, I think that being able to modify embedded firmware is a feat in itself.
> I had heavily modified the software on mine, but it was easier than modern stuff, no encryption of the code, and even the checksum code only triggered a DTC with no consequences.
What's the vintage of the vehicle? When I was in the 'car enthusiast' phase of my life ECU "reflash/remaps/tunes" were very popular and still happen on more 'modern' cars.
I’ve been following that thread very closely. Prepping myself to install cruise control but as I have a cem-b in my car, I have to solder to the board.
For the CEM, I have done no modifications, yet. I have however spent a fair amount of time, reverse engineering the AW55 firmware and have discovered virtually all the maps related to the shifting process, pressures, speeds etc. I have a completely understanding of how the firmware works.
To say I am the only one with such a complete understanding and tuning abilities for it, may not be an understatement.
What isn't mentioned in the article is why UD2 is chosen. It is a relic from the SecuROM days, in fact, one of the developers on SecuROM is the one who also works or worked at Denuvo.
I would imagine many things from the SecuROM era live on in Denuvo.
But if you read the article you will realize that certain games will not work in the future due to Denuvo.
"This destroyed any exception-based hooking since majority of the time an exception is triggered, Windows will write an EXCEPTION_RECORD high up in unused stack space. You can probably see where this is going. Now, whenever the CPUID is hooked via an exception, that important value will become overwritten with an EXCEPTION_RECORD, causing undefined behaviour later on. I believe this can be bypassed if you attach a debugger to the process and set certain flags when it comes to exception handling, but the method of patching every hardware check is still cumbersome due to randomness anyway."
As Windows matures, behaviour can change, breaking certain stuff.
The anti-tamper codes, if any tampering is detected will crash on undefined/unallocated regions. Meaning that if Windows ever were to overwrite that region for whatever reason, will trigger the crash.
Such was the case for SecuROM in early days. It featured the CRC checks mentioned, if any single byte was changed, including an INT (breakpoint) instruction, it would crash. Here it's unlikely that it wont crash. Rendering the game inoperable.
> The anti-tamper codes, if any tampering is detected will crash on undefined/unallocated regions.
That's basically the whole point of any anti-tamper product. I just think you picked a terrible example of a feature that could break due to OS changes specifically.
> Meaning that if Windows ever were to overwrite that region for whatever reason, will trigger the crash.
We're talking about random stack memory inside of a virtual machine that likely doesn't call any external code whatsoever. There should be no real way for Microsoft to accidentally corrupt this memory.
In that case the "unused" stack was overwritten by a function called on that thread. But I'd assume that Denuvo is careful to not call any third party code while it expects the "unused" stack data to remain unmodified, so this shouldn't happen here.
So this code can only break if the data is overwritten from code outside the control of that thread. On Unix, certain signals could cause that. Or the OS could decide to zero out the unused thread while the thread isn't running. Zeroing the thread could the helpful to wipe secrets spilled there (forward secrecy related), or if whole pages can be zeroed (via something like MADV_ZERO), it could reduce the memory consumption by allowing threads to shrink.
While I would like that thread zeroing feature, I think it's unlikely that MS will implement something like it. So the code should be unlikely to break in practice.
The GTA SA bug was reading of an uninitialized variable. The value it contained was correct simply by chance as it was placed there by the previous invocation of the function and never overwritten by something else intermittently. Any changes to functions that happened to be called in between these 2 could have changed the value of the stack memory.
The aforementioned check on the other hand is placing random value below the stack pointer. This means that by design it cannot call any external/os/game functions and is basically isolated/"pure" from any interactions with third party code.
IIRC Denuvo costs a fortune to keep in a game, since it’s a subscription model. Once sales sufficiently taper off there’s not much sense in paying for it anymore.
Some games have had it for an extremely long time. and some publishers never remove it (Eg. Sega). In some cases I guess they got a lifetime deal with an older version of Denuvo, but other cases are sus. I wonder is it for money laundering purposes.
I like the concept of the Comma device. If only to get just one feature from it, adaptive cruise control.
But it requires for me to not only reverse engineer, but potentially also modify the firmware of my ABS unit to allow it to brake, which I am not comfortable doing.
There's some hair splitting here: one may have to reverse engineer the mappings of the can bus for your car if you want to port the Comma to your platform, but I do believe the second clause is correct: it's a MITM system and does not monkey with the onboard ECM at all. Unplug device, give to dealer for service or updates, plug device back in
True in my experience. Back in 2019 i got a model year 2020 honda civic hatchback that was not yet supported. So as not to break the car, I purchased an oem steering motor for the car, dumped the firmware and then found the necessary data to support the car. I've been using comma since then. Other comments are correct about it being an assistant. You are the captain, now thinking more strategically about the road and vehicles ahead. The comma handles the tactical of keeping between the lines. The brain relief from all the mostly automatic constant correction is huge on long road trips. It's got a good driver attention model as well. Keep your eyes on the road. I will say a pair of glasses frames is sufficient to fool it though.
It would be an interesting reverse engineering challenge, 20 years down the road when it is more accessible.
I spent 1.5+ years on my 2005 car's ECU to reverse engineer most of the maps, since no public tuning files existed.
I then went and spent 1 year on the TCM for which again, no tuning files existed. With the patent files, I was able to discover the algorithms and maps, and am even in IDA as I write this, and in Ghidra emulating some code.
Hello. How does this suspension handle severely neglected roads with large potholes or even off-road type with say 40-50mph? And I mean regularly, for years?
I mean I am asking only because my government has failed to fix these roads and we've had protests that lead to nothing. They are the only connection between the rural parts of the country, as in the only ones.
You have no choice but to go at a speed useful enough to get anywhere. For me, these are real-world conditions.
We'll have colonized the galaxy in 10 million years. In 200 million years, I'd expect that some future historical society could undertake a project to clean out the heavy elements in the Sun to keep it going.
Yeah, but if humans exist by the time the sun fails us, they wouldn’t really be the same species as us, and they’d hopefully have progressed to the point that they could escape the Earth.
You're saying we wont maintain tradition and our "humanity"?. I like to be a little more optimistic and believe in us as a species transferring values until the end.
Look at all types of mammal that exist, from us to platypuses to bats to whales. Evolved in a few hundred million years. Modern humans have been here for a few hundred thousand.
In 500 million years absolutely anything could happen (if we survive this century).
I remember back in the day of the Sony Satio U1, the last Symbian v5 phone, the software was horrendous(screen tearing, random OS freezes) and later, the phone abandoned. I think it was afterwards that Sony and Ericsson split?
The only module that was encrypted was the main module, but it if you knew the security PIN you could do what you wanted. It was determined by people that if you observed the jitter of the CAN line fast enough, you could leak the pin via a side channel attack.
But modern car electronics are encrypted, and some probably have security processors that might trigger some irreversible states if you tamper with them. Modern cars are basically as locked up as a PS5.