LinkLiar VS UnsignedFlash

Ever since I used https://github.com/halo/LinkLiar , my Mac disconnects and reconnects from WiFi every few minutes. I have tried resetting network preferences and nothing has worked.

Are you on Mac, Windows, Linux, or something else? If you're on Mac, there's an open source app I use. If you're on Windows, there are some tutorials you can follow to do it without installing anything (I've tried it on Windows once a long time ago, so I'm not really sure if it still works). If you're on Linux, there are also tutorials, though I've never tried them before so I'm not sure if they work. Also, to avoid suspicion, you may want to change your netBIOS/localhost name (actually, I'm not sure if they're the same thing, but changing either seems to have the same result since its visible when logged into your router settings. You can do it via Settings or Terminal for Mac and there are probably some tutorials for Windows and Linux.)

JG Lim's Mercedes instrument cluster exploit: https://github.com/jglim/UnsignedFlash . A good example of a common issue in modern control units.

That's pretty cool! I wonder how properly they were really signed - there are _so many_ mistakes even in systems that at least don't use an example key off the Internet.

The most common ones I know of are:

* Out-of-bounds write issues allowing "signature was validated" flags to be overwritten in Flash memory, like https://github.com/jglim/UnsignedFlash

* State machine mistakes, like https://github.com/bri3d/VW_Flash/blob/master/docs/docs.md - allowing Flash to be written again after it was already written, without an erase first.

* Filesystem parsing mistakes, like those in a number of VW AG head units: https://github.com/jilleb/mib2-toolbox/issues/122

* The use of RSA with E=3 and inadequate padding validation, like https://words.filippo.io/bleichenbacher-06-signature-forgery... .

* Failure to understand the system boundaries, like in the second part of https://github.com/bri3d/simos18_sboot where "secret" data can be recovered by halting the system during a checksum process.

* Hardware fault injection issues, as used in https://fahrplan.events.ccc.de/congress/2015/Fahrplan/system... .

Fundamentally this is of course, a very hard problem, since in the "protect against firmware modification" case, the attacker has physical access. But, compared to the state of the art in mobile devices and game consoles, automotive stuff is still way behind.

My writeups and JG Lim's cover three of the common mistakes in modern modules (supplier backdoor bugs in Simos supplier bootloader, state machine issues in Simos VW bootloader, and block buffer validity confusion / bounds check issues in Mercedes instrument cluster).