Hi rch, we have added a lot of people lately with intro posts on other subs like the one below. We also usually get about 10 subs a day from people just stumbling in here. So I wanted to create a welcome post, to kinda show them what we are about and how to get started. If anyone has anything to add please do so. If anyone has any questions about us or where to start do so here.
Our goal is to create a highly technical car subreddit, a place for automotive engineers, senior technicians, full blown car nerds, or people who are working towards one of these. We are interested in the inner workings of cars and today that often involves electronics. While we see electronics as the priority we are pretty liberal in allowing other topics as long as they somehow fit our goal of trying to understand cars. So things like DIY aero, suspension setup and other things the community is hacking on come up. In general our other tangential interests include: Modern cars, New tech, Open source hardware/software, DIY, hot rodding, eco modding, customization, security research, right to repair and more.
We started this subreddit about a year ago. Right now we have 3000 people and discussion is just starting to get good. Most of our members found us through maker or engineering subreddits. So I wanted to reach out to more of the car communities and try to grow our knowledge base.
Our name is r/carhacking and I know the term hacking can be offputting to some as it has a bad connotation. When someone says they are “hacking” their car it generally means they are trying to reverse engineer it for any number of reasons like to find security flaws, make upgrades, make repairs, or just understand how it works.
Here are a couple examples of posts that have been popular so far. A lot of our posts focus on beginner through intermediate projects using arduino and readily available hardware for the purpose of learning and or not paying a premium for things you can make yourself:
If your new our documentation is a good place to start
If you aren't new and you’re interested in helping out please consider:
Improving documentation - think about what resources have helped you
Spread the word - this is a niche community that is pretty spread out, but there is a lot of potential if we can get together on a third party site like this
Work on the theme, sidebar and flair - this is next level community stuff that isn’t necessary, but it’s fun to work on when you have the time.
Modding - right now we are fine, but we might need help in the future as we grow
Let me know if I missed something or got something wrong.
I get asked how to get started with automotive networking, car hacking, and CAN almost weekly. I often direct people to this subreddit, so I figured I would help out and post some resources I have found and think are a good place to start.
learning resources:
Car Hacking 101: Practical Guide to Exploiting CAN-Bus using Instrument Cluster Simulator
I also direct people to the Car Hacking Village to get some hands-on experience. They put on great conference talks, demos, and contests. Looks like they are even working on some “getting started” content.
I will add more as I think of them. Please add your finds in the comments.
Tools:
Good wiring diagrams and car manuals are essential. This is pretty much where my research starts for each project. You see how things are networked and what to expect to find on CAN. You'll quickly learn to recognize things like gateways. You can also use the troubleshooting section to understand things. For example, what things do I need to control to start the car?
I like:
prodemand (I pay $170/mo for a shop subscription, I think you can purchase it for individual cars, but be careful you often have to jump around to find a year that has complete diagrams)
Identifix (probably what I would buy if I was starting over)
Basic hardware: Here you will be working with things like Arduino, Linux, SavvyCAN, and Can-utils. You have to learn to do a lot yourself, but these tools are more open for you to make them do what you need.
The above articles offer a pretty good step-by-step guide to getting started with the Macchina M2.
Any cheap “Amazon special” OBD2 dongle will come in handy from time to time. They are all based on something called ELM327. "ELM327 abstracts the low-level protocol and presents a simple interface that can be called via a UART". This abstraction has fundamental limitations that prevent it from being useful in most serious applications. But, it is sufficient for reading and clearing some codes and that sort of thing when you’re getting started.
I’ve seen a few retrofitters and accounts advertising standalone Android Auto running natively on NBT Evo (iDrive 5/6) without requiring external MMI boxes or display swaps.
Does anyone know the details of how they achieved this? Did they gain root/shell access to the head unit to run custom binaries, or is it an adaptation of an open-source client?
I’d love to explore developing custom tools or tweaking the OS on my own ID6 unit, so if anyone has documentation, development workflows, or details on how people gain root access to tinker with NBT Evo, please share!
We just released a new CANsub firmware (02.05.01) that adds a 'dashboard view' to webCAN, our free browser-based GUI that runs on the CANsub.
This lets you build powerful custom dashboards for real-time visualization - with zero installation or backend required (everything runs in the browser).
You can read more about this in the CANsub Intro - if you get a few min to check it out I'd be very interested in any thoughts/ideas/feedback, e.g. what you think would be useful for your use cases.
As with the CANsub in general, we make it easy to create new dashboards via AI agents (if you want). I e.g. used this in my AI CAN sniffer article to create a quick Hyundai i10 dashboard to show the OBD2 vs. proprietary CAN signals, you can find a clip of the dashboard in the showcase 1 example.
Hello everyone so im just going to start to learn about ecu repair and I looking to meet people that already know and are willing to share with me some knowledge.
Getting into CAN with my 2013 Civic 1.8L. I can log traffic, but figuring out what I'm looking at is the hard part. Thought I'd try turning the cooling fan on with a scan tool while logging with a separate CAN interface, so I'd have something specific to look for.
Budget is around $400. Looking at the topdon AD800BT2, but still checking if it can run that test on my car. Seems easier to start with a knwon command than poke around blindly.
Anyone tried this? Anything to watch out for when picking a scanner for it?
I have a 2020 Opel Grandland X with the IntelliLink Navi 5.0 infotainment system, running firmware version 21.08.90.52_NAC-r0.
I'm interested in reverse-engineering the system to understand how it works internally and explore the possibility of modifying its software or redesigning its UI to make it look and feel more like a modern Android-based infotainment system, with a more futuristic design, animations, and customizable features.
Has anyone here actually managed to reverse-engineer this system or a similar PSA/Stellantis NAC infotainment unit? Have you successfully modified the firmware, gained access to the underlying OS, or developed custom software that runs on the original hardware?
I'd appreciate any information, GitHub repositories, technical documentation, or experiences from people who have attempted this.
I'm particularly interested in real, working solutions rather than just theoretical discussions.
I’m the developer of G86 Racing, from CrowFoundry. This is the hardware/data path behind G86 Car Computer: a service that collects supported GPS, ECU/CAN and sensor inputs near the car and connects them to the phone recorder and optional live pit wall.
The connection path
GPS / ECU / CAN / supported sensors
↓
Car Computer: native bridges + local MQTT broker + engineering logs
↓ local network
G86 phone: session timing, onboard video and optional live sharing
↓ internet, when sharing is enabled
Browser pit wall: received channels, timestamps and channel age
Hardware and interfaces
An example Linux setup is a Raspberry Pi with a 64-bit OS, a supported USB/serial NMEA GPS receiver and either a supported serial ECU connection or CAN interface. The computer runs the hardware bridges and an authenticated Mosquitto broker. The phone joins the reachable local network and pairs using a short-lived QR code.
Linux supports SocketCAN and supported local I²C sensors. The supported macOS and Windows builds use their available serial/network and compatible gateway paths; they do not gain Linux-only interfaces just by running the same app. Supported wireless routes include an ESP CAN module over BLE or local MQTT. A supported CAN/ELM Bluetooth adapter can also connect directly to the phone without Car Computer.
The wizard scans for devices, then you review the configuration and select one primary engine source. Finding a port, saving an adapter or pairing Bluetooth is not the same as receiving measurements. The live checks separately show broker connectivity, fresh channels and GPS fix.
Channels and actual rates
Depending on the ECU/profile and sensors, channels can include RPM, throttle, coolant temperature, oil pressure, vehicle speed and motion measurements. A generic OBD adapter provides the PIDs the car actually exposes, at the rate the adapter and vehicle permit. Changing from wired to Bluetooth or MQTT does not unlock channels hidden by a vehicle gateway.
For recognised supported u-blox, MediaTek and compatible Quectel receivers, automatic GPS setup requests 10 Hz in RAM. The dashboard distinguishes the requested rate from the measured output rate; unknown receivers and network feeds keep their settings. There is no single guaranteed sampling rate for every ECU/CAN channel.
Missing and stale values
The displays expose source information, timestamps and channel age. Unavailable measurements stay unavailable rather than being filled with invented engine values. Check the stream on the computer, then the phone, then the pit wall. A pit-wall recording only contains the packets that display actually received.
Logging and offline operation
The computer keeps independent local engineering recordings, with gzip NDJSON or ZIP exports and metadata describing sources and known gaps. The phone remains responsible for app runs, lap timing and onboard video. The open pit helper can also record the stream it observes and export CSV/NDJSON.
Managed acquisition requires an active Pro or Team subscription. First activation needs internet; after activation, a verified offline grant can allow local telemetry for up to 72 hours, capped by subscription expiry. Remote pit-wall delivery still needs internet. Basic phone GPS timing and local history are free.
US App Store subscription prices: Pro $14.99/month or $149.99/year; Team $49.99/month or $499.99/year, auto-renewing. Current prices vary by platform/region and are shown before purchase. Team ownership is optional; Pro supports a personal pit wall and team participation, while additional teammates need their own Pro subscriptions.
Based on recent publications, a lot of peoples are going at it with various ESP32 1.75 inch screen, i started mine around 2 years ago with TFT screen and some ESP32 WROOM. I went to the 1.75 inch screen route and since i've been trying to develop this.
What i tried to do differently based on the other projets it the ability to wire physical sensors as well for older cars where the CANBUS / OBD data doesn't contains as much informations as recent vehicules.
On my case, it's my AP1 S2000 which doesn't provide oil pressure / temperature from the ECU.
So, i started working on a breadboard, doing at the beginning hand made code (now almost fully assisted with GPT) to create something that could be incorporated on any vehicule, and also provide the ability to wire sensors directly to the board
I went also a different to try and create my own custom PCB (still tweaking the board at the moment) to be able to have something the most "out of the box" possible :
8 screens fully customizable
4 values per screen
Unit, Threshold and Threshold color per value customizable
2 Physical Sensor input
OBD2 Bluetooth BLE Dongle support (i'm going to add CANBUS capabilities also) (both will be supported / compatible)
OBD Values discover and assigned to specific values that can be renamed and customized as well
Smartphone application to manager each parameters per ESP Unit
Gauges data exportable with history data (only physical sensor for now but easily addable for each values)
I'm adding also some picture and videos of what i've done so far
The code is sitting on gitlab for now, i also wanna go opensource but i want to know if people would be interested
Side not, i'm clearly not confortable with PCB conception, i've went the AI route with my own breadbord conception as a baseline, i think there's clearly more to refined / polish on this side
For physical sensors, i also want to add more conversion table for different brand and type of sensors, right now i'm only using it for oil pressure, but the idea is to support more sensors
What's your thoughs ? I'm aware there's lot of similar projets going around and i found out about them really recently
I could not find published CAN information for the Alfa Romeo Giulietta 940, so I worked from captures on my own 2011 car, starting from fmntf's fiatcan work on the Fiat Doblò and karolkrupa's alfa-blue-me for the 159. A Raspberry Pi Zero W now takes the place of the dead Blue&Me module, node 4021.
What the captures settled:
B-CAN at 50 kbit/s, 29-bit identifiers, ID = topic<<16 | node. Body Computer 4000, cluster 4003, radio 4005.
**PROXI:** about a second after the bus wakes, the Body Computer sends `1E114000#`. On my car, nodes `400A`, `4003` and `401A` answered within milliseconds with the same six-byte value. A silent node gets three retries; a mismatch makes the odometer blink. The Pi uses the value read from that car. The public code reads it from a setting that is covered by tests but has not yet been run in the car.
The Body Computer's PROXI record `2023` had to list the telematic unit as present. I read and saved the original record before changing it with the documented script and keeping an undo file, then ran the alignment with the Pi answering diagnostics as the telematic ECU. This changes the car's configuration and is not a generic value to copy.
**Source handshake:** MEDIA makes the radio send 06314005#0C…; the node has about 100 ms to answer …84 on 06314021. Unprompted answers are ignored.
**Wheel buttons:** frame 06354000 from the Body Computer, one bit per button, same layout fiatcan documents for the Doblò.
**Track text:** the Doblò's format and 6-bit character set work on the Giulietta's radio.
The body-B-CAN pair on OBD pins 1 and 9 carried body traffic but no `18DA…` diagnostic frames during a PROXI alignment on my car. It is usable for body traffic; I used the module connector for the complete Blue&Me captures.
One rule in the software: it transmits only frames first recorded on this car, each tied to a capture file and timestamp. A fresh install is listen-only.
Write-up with the frame tables, timing and wiring:
When you want to record what a car is doing over time, there are two common starting points. One is to listen passively to the CAN bus and record every frame. The other is to actively poll the ECU with diagnostic requests, usually the standardized OBD-II PIDs or a manufacturer's UDS reads. Both get you data, but they fail in different ways.
Passive sniffing is read-only in principle, so it does not ask any module for anything. You see the real traffic at the real rate, with accurate timestamps, and you can catch short events that a polling loop would miss. The downside is that raw frames mean nothing until you decode them. Without a database file or a lot of reverse engineering, you are staring at hex and guessing which bytes are RPM, throttle position, or a fault flag. Decoding also depends on the bus speed, the gateway's filtering, and whether the manufacturer even sends the signal you want on the bus you can reach.
Polling is the opposite trade. The standard PIDs are documented, so the answers are easy to interpret, and most cars respond to them without any special setup. The costs are speed and coverage. Each request and response takes time, so your sample rate is limited and you get a snapshot rather than a continuous signal. The standard only defines a small set of parameters, so anything manufacturer specific needs UDS reads, which require knowing the addresses and data identifiers, and those vary a lot between makers and even between model years. Active requests also add load to the diagnostic channel and can interfere with other tools or sessions if you are not careful about who else is talking.
A common middle ground is to use passive capture to understand timing and relationships, then use polling or UDS to label the values with known names. Whether that combination is practical depends heavily on the vehicle, so I would not assume results from one platform carry over to another.
For people who have done both: which problems did you hit first, decoding the passive data or getting reliable answers from polling? I am curious whether the gateway filtering was the bigger blocker or the lack of documentation.
I recently completed an Embedded Systems course and am currently looking for a job. In parallel, I’m starting a hobby project called FELIX RACING — a motorsport-style digital instrument cluster built around automotive CAN communication.
Hardware:
STM32 NUCLEO-H723ZG with native FDCAN
MCP2515 + TJA1050 CAN module
Arduino and ESP32 for a second ECU/simulator node
Planning to use a 3.5-inch TFT display
Project scope:
I want to build a working dashboard that receives simulated vehicle data over CAN, displays parameters such as RPM, speed and engine temperature, and includes an engineering screen for monitoring communication health.
The main technical feature will be CAN communication integrity testing:
Message timeout and stale-data detection
Message counters and basic data validation
Injecting missing or invalid messages to test fault handling
Logging faults and verifying recovery when communication resumes
This will initially be a bench setup with simulated data, not connected to a live vehicle.
I’d appreciate specific advice on three things:
Hardware architecture: Is STM32 native FDCAN for the dashboard and an Arduino + MCP2515 for the simulated ECU a sensible setup? Are there any electrical compatibility issues I should address first?
CAN fault handling: For a small portfolio project, which failure scenarios should I implement to demonstrate meaningful automotive-style diagnostics beyond a basic message timeout?
Engineering quality: What would you expect to see in a project like this to distinguish it from a typical DIY dashboard — for example, testing methods, logging, protocol design, or documentation?
I’m looking for practical feedback from people with hands-on CAN and automotive embedded experience, especially on design mistakes worth avoiding before I start wiring everything up.
Hi. Does anyone have account on mhhauto forum and could help me to contact few users from there? I would send you links to users and a message (containing my phone number) that I would love you to send them. Its about scam company that I wanted to sue and I saw there are more victims and those people lost money on this company too. Anyone willing to help? Thank you.
I'm investigating whether it's possible to permanently disable all wireless communications on a 2026 Toyota Corolla Hybrid (Australian model) without affecting essential vehicle functionality.
I haven't purchased a new vehicle in approximately 18 years, and I'm genuinely surprised by how much the automotive industry has changed regarding connectivity, telemetry, and data collection.
I work in IT and cybersecurity, and I'm concerned about the privacy and security implications of modern connected vehicles, particularly persistent 4G connectivity, location tracking, and remote access capabilities.
With rapid advances in AI, large-scale data collection and increasingly sophisticated analysis techniques, these concerns are becoming even more significant to me.
My goal is to physically prevent the vehicle from transmitting data or communicating with external networks. Software opt-outs and privacy settings are not sufficient.
I'm willing to sacrifice connected services, SOS functionality, and OTA updates, provided essential vehicle functions remain unaffected.
Questions for Toyota technicians, automotive electronics engineers, or anyone with relevant experience:
Can the DCM/4G modem be physically disconnected or removed without affecting essential vehicle systems?
Are there other independent wireless modules capable of transmitting telemetry or location data?
Would removing the DCM fuse be sufficient, or is complete hardware disconnection necessary?
Could these modifications affect internal systems, infotainment, diagnostics, driver-assistance features, or normal vehicle operation?
Warranty: Could these modifications affect the warranty on a brand-new Toyota, particularly under Australian Consumer Law?
Is there a reversible, non-destructive hardware solution that minimises potential warranty issues?
How can I independently verify that no wireless telemetry is being transmitted?
Has anyone successfully done this on a recent Toyota, particularly a 2025–2026 Australian Corolla Hybrid?
I'm specifically interested in hardware-level solutions, technical documentation, and firsthand experiences, rather than software privacy controls.
I'm not looking to debate whether these concerns are justified. I'd simply like to understand what's technically possible and what the consequences might be.
Any technical insights would be greatly appreciated.
Home page with custom wallpapers + vibration meter
Live G-Force meter
Lap Timer - Sport Chrono inspired (tap to start, double tap to reset)
Gear Position - With calibration. This is actually really hard to get right and I'm still in prototype stage.
I'm hoping to get some help with some good 3D designs that fits the dev board better and can plug directly into the M3's link!
I'm planning on sharing the codes soon and creating a webpage for non-tech users to customize with their own homepage photos and upload this firmware on their dev board. Stay tuned!!
[Edit] Some people are confused about the usb-c so I wanted to explain: I can power it via the power pin that goes into the accessory source with a 12v->5v step down converter.
USB-C is used for now because I'm still in the prototyping stage and I still need to flash firmware to it.
On the actual usefulness of this thing: I've never misread my gear since the day I learned how to drive a manual, and I learned it on YouTube while signing the paperwork for my first Civic SI 😂. This is just a fun/learning project as a software engineer. Even if it never becomes a useful thing, I get to apply some electrical, physics, and programming together... With some helps by Gemini Argon 😅
P.S.1. I messed up the display a bit right before filming this so that's why you see the lines 😅
PullScan is more than just a CSV datalog analysis tool. Here’s what it offers today:
Datalog Analysis: Analyze complex automotive datalogs and understand what’s happening with your vehicle in plain English.
Screenshot Analysis: Upload screenshots of datalog graphs and convert them into interactive graphs for further analysis.
Fix Me: Uses machine learning trained on real-world automotive troubleshooting cases to provide guidance on how to address issues identified during analysis. Currently available for JB4 platforms only.
Live OBD2 Monitoring: Connect an OBD2 device to monitor your vehicle’s live telemetry while driving.
Performance Measurement: Measure 0–60 mph, quarter-mile times, and use Street Dyno to estimate vehicle performance. These features are still in beta and currently free to use. I’ll be sharing a video soon demonstrating how they work!
I’m continuously improving PullScan and working on new features. There’s more to come!
I pulled the TBM out of my 2025 RAM 1500 Big Horn (long story short, updates were screwing up my radio), but now the odometer is blinking. Figures. Trying to figure out how to get in to the system to tell it to stop looking for the TBM, but apparently there's a buttton of layers of security and hidden coding. Anyone done this before?
