| XZ Backdoor symbol deobfuscation. Updated as i make progress |
This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.
This is a repost and update to an imgur album with screenshots of ToaruOS throughout its development, as imgur is no longer a viable platform for maintaining this collection.
My first commit in the ToaruOS repository, ecd4fe2bc170b01ad700ff76c16da96993805355, was made on January 15th, 2011. This date has become ToaruOS's "birthday". It would be another six years and two weeks before ToaruOS's first real release, 1.0.
Discord is now slowly rolling out the ability to send colored messages within code blocks. It uses the ANSI color codes, so if you've tried to print colored text in your terminal or console with Python or other languages then it will be easy for you.
To be able to send a colored text, you need to use the ansi language for your code block and provide a prefix of this format before writing your text:
\u001b[{format};{color}m
The mainline release of QEMU includes working simulation of Tricore. Both TC1.3 and TC1.6 CPU instruction sets are supported. No peripherals are implemented.
However, the mainline QEMU's "triboard" based machine specification is insufficient for most ECU use cases as it does not define the correct memory regions or aliasing.
I have an example of setup for Simos18 here: https://github.com/bri3d/qemu/tree/tricore-simos18 . The kernel load code (and constants) as well as the hardcoded entry point are actually unnecessary with the use of the QEMU "loader" device, documented below.
So, to get started, first we simply build QEMU for Tricore: ./configure --target-list=tricore-softmmu && make . You should now have a qemu-system-tricore binary, provided your dependencies were set up correctly (the QEMU documentation is good for this).
An upcoming project has me looking at car hacking at the moment. I watched a great video ( https://www.youtube.com/watch?v=nvxN5G21aBQ ) which caught me up to speed on the fundamentals. There are a few other videos out there on introductory car hacking, but they all seem to revolve around the virtual can interface provided by vcan. I decided I didn't want to test virtually because then I wouldn't know how to work with the actual connection hardware. At the same time, being a beginner, I DID NOT want to plug into my personal vehicle's ODB2 port.
I was looking for something between vcan and a real car. A little googling led me to the ScanTools ECUSim 2000:
https://www.amazon.com/OBDLink-ScanTool-ECUsim-Simulator-Development/dp/B008NAH6WE
This board simulates a car. It has a ODB2 port for interfacing just like one would do with a
