r/CarHacking

I did a long press on "SETUP" button ..and i got this..

Any cool things to do ?

Installed MU version : 8740

installed software version : MEN2_EU_VWGPx_P7381L

Hey everyone,

​Quick update on my project to reverse-engineer and customize the aftermarket MMI box from my dad’s car (original post [here]).

​Full disclaimer: I’m definitely not an electrical engineer or a seasoned hardware hacker. I’m doing this as a passion project to learn the ropes, so bear with me if I miss something obvious!

​What I've tried so far:

I opened up the box hoping to find a UART serial console to get root/shell access. I tapped into several likely test pads (TXD, RXD, TX1, RX1) using a logic analyzer, an ESP32, and an oscilloscope, cycling through pretty much every standard baud rate.

​Instead of dropping into a bootloader or Linux/Android shell, I was just getting raw logs that turned out to be CAN bus debug traffic.

​The rookie mistake (and the damage):

While desoldering my probe wires, I managed to lift a pad and sever a trace. That accidentally confirmed 100% that it was a CAN line: the iDrive wheel and touch inputs completely stopped working on the MMI side after desoldering (They work fine if i remove the MMI BOX setup and leave just the factory NBT Evo HU tho).

​The bench setup & next steps:

​I already bought an identical replacement unit for my dad's car so he isn't left without CarPlay/Android Auto, which turns this damaged unit into a dedicated workbench testbed.

​Since my micro-soldering skills are still a work in progress and my micro soldering station havent arrived, I’m gonna send the board to a tech to fix the severed trace. I'm also having him solder flying breakout wires to all key test pads so I can probe freely without risking the PCB traces again.

​Where I need some community insight:

​Spot any sneaky or unpopulated UART/debug pads on this layout that I might have overlooked?

​Has anyone managed to get root on one of these boxes before?

​Should I ditch hunting for UART and go straight for an eMMC/SPI flash dump, ADB over USB-OTG, or something else?

​I took high-res macro photos of the entire board (front and back) so you can zoom in and inspect the SoC, traces, and pinouts: [Full RES Images/Google Drive]

​Any theories, tips, or sanity checks would be hugely appreciated!

__

P.S. Quick clarification since a few comments here and on my other post misunderstood the setup: I am not modifying the factory BMW / Harman OEM head unit. I’m tinkering with an aftermarket MMI Box, an AFTERMARKET retrofit interface used to add Apple CarPlay or Android Auto, and auxiliary cameras while keeping the factory iDrive system fully functional.

A while back, I picked up an aftermarket MMI box for my dad’s car to enable Android Auto on the OEM head unit, that only supports factory CarPlay. Naturally, curiosity got the better of me, I wanted to see what hardware actually powers these boxes and what kind of headroom they have for tinkering.

My initial attempt to drop into a Linux shell over Wi-Fi hit a dead end because all network ports were locked down. That prompted a full teardown, and the board layout was an unexpected surprise. The build quality is clean, utilizing recognizable, reliable components from manufacturers like NEC and Toshiba rather than generic unbranded silicon.

Quick Hardware Overview:

SoC: Allwinner T113

RAM: 128 MB DDR3 @ 800 MHz

Storage: 4 GB eMMC

Apparently this PCB is a white-label platform rebranded across dozens of different manufacturers and vehicle applications, but i cant confirm, but need to say i could find all of the 3 boards for sale individually on the web.

Currently, I am tapping into the onboard UART interface using an ESP32 as a serial bridge to secure root terminal access. The next step is extracting the stock firmware image from the eMMC to modify it.

The project is still actively in progress, updates soon.

I picked up a project during COVID: I put an Ignitron standalone ECU in my Golf MK4. Great ECU, but one thing bugged me from day one: no phone connectivity. If I wanted live data, I had to drag a laptop into the car. Every. Single. Time.

In 2024 I finally got tired of it and decided to build the missing link myself.

The hardware. V1 was deliberately dumb: an ESP32-S3 with a CAN transceiver sitting on the bus, forwarding the ECU's frames over BLE. That alone solved the original problem, live ECU data on the phone. The bridge has stayed dumb on purpose: all the ECU-specific decoding lives in the app, so adding a new ECU doesn't need a firmware update. That's how the app later picked up support for a few other standalones (MaxxECU, ECUMaster EMU, Haltech, each with its own CAN broadcast layout and quirks) plus a generic OBD-II mode for stock ECUs.

The GPS problem. Then the app grew a lap timer and I hit a wall that has nothing to do with CAN: phone GPS delivers about 1 Hz no matter what update rate you request. You can't do honest lap deltas or 0-100 timing from that. So the current hardware revision also carries a 25 Hz u-blox GPS and an IMU. Timing and g-force come from real sensors now, and the phone is purely a display.

The app. This turned into the real rabbit hole. "Just show me RPM" became a full digital dash for a landscape-mounted phone/tablet: Skia-rendered gauges with shift light and warnings, a lap timer with sector times and delta-to-best on the 25 Hz feed, a performance meter (0-100, quarter mile) that re-derives the official time from the raw GPS+IMU log after the run instead of trusting live-filtered values, and a drive recorder that burns the telemetry HUD (speed, RPM, g-force, lap delta, track map) into the exported video in a single native re-encode pass, without any screen recording.

It started as a lockdown itch and turned into the longest-running side project of my life. No regrets.

Does anyone know what the developer password is for 12.1 Inch Android 12 Car Radio for Nissan 350Z?

Hi guys,

I was wondering if has OP-COM firmware to share?

Currently purchased a V1.70 OPCOM with genuine chipset to be flashed with original firmware for more ECU programming capabilities and for adjusting gearbox parameters.

On the internet all the OPCOM software (original and cracked) can be found but unfortunately not the firmware…..

EDIT: I‘m looking for the .hex files to use in OCFlash, V1.39 or V1.59, preferably not through a forum where I need to pay 40 USD for a registration first.

If you're tired of clunky legacy tools or paying thousands for CANoe licenses, check out what I’ve been building: AiCAN.

​Runs natively on Windows (macOS & Linux coming soon), supports Peak/Vector/Kvaser/SocketCAN, and handles heavy CAN/CAN-FD traffic smoothly without freezing.

​P.S. There's also an in-app AI tool if you hate manually digging through massive logs.

So I wanted to know more about the internals of my Ioniq, and spent way too much time on it ever since I got my WiCAN Pro last summer, so I could see all my car’s secrets live in Home Assistant. It was slow going and difficult at first, but I finally have something to show for it (though it didn’t help with the WAF, I regret to inform you).

The tool I built that finally helped me make progress faster now allows anyone with a WiCAN to scan their car (Ioniq or otherwise) and do reverse engineering in “easy mode”, because it’s a CLI and therefore coding agents like Claude Code/OpenCode etc. can directly use it to talk to your car, scan it, capture a set of responses and do some crunching and clever analytics to derive meaning from them.

Here’s a tiny set of the things I found that weren’t yet known for these cars:
- OBC AC Input voltage and current (helpful for diagnosing AC charging issues)
- Individual wheel speed sensors (owners will know why this is helpful to know)
- A whole suite of HVAC sensors
- Vehicle speed, motor RPM, remote control of lights/blinkers/horn/trunk/VESS and other fun stuff.

Now I’ve done a lot of this on my Ioniq 2017, so the profile for it is pretty complete at over 200 verified parameters (I started with less than 10 a year ago). But I reckon owners of the facelift (38 kWh) might still get value out of this tool (I expect a lot of the 2017-2019 model PIDs carry over 1-to-1). I can’t wait to see what you folks are able to do with this, and I hope it helps keep our magnificent Ioniqs on the road for many more miles (and kms).

Go see the Ioniq profile on GitHub for the full list of ECUs and all the gory details I found on the car’s modules and adjacent systems, and read the docs if you’re curious about the tool itself and would like to contribute (I would personally be very thrilled if you do!). Thanks for reading all the way! 🙏

I have an older BMW with a BURY/THB UNI System 8 hands-free installation. The system originally used a Nokia phone cradle, and I would like to adapt it so that I can use a modern phone, such as an iPhone, over Bluetooth.

I am trying to decide between two possible approaches:

1. Designing an adapter that connects a bluetooth module directly to the BURY System 8 / Universal adapter interface.
2. Reusing the existing Nokia cradle and its Nokia Pop-Port connector, and building a Pop-Port-to-Bluetooth adapter.

I don't yet know which approach is electrically simpler or better. As a matter of fact i am actually on a pretty beginner level in electronics and i actually wanted to take this project on to improve my skills. I would like to understand the pinouts and signals available at both interfaces before choosing one.

The car currently has a BURY System 8 installation. The setup consists of the BMW wiring, a BURY System 8 control unit/base, the System 8 BasePlate, and a removable Nokia cradle.

The Nokia cradle is labelled as compatible with:

• Nokia 3100
• Nokia 3200
• Nokia 6100
• Nokia 6200
• Nokia 6220
• Nokia 6610
• Nokia 6820
• Nokia 7210
• Nokia 7250
• Nokia 7250i

The cradle uses the standard Nokia 14-pin Pop-Port connector for the phone.

BURY made the System 8 as a modular system, so different phone cradles/accessories could be attached to the same BasePlate. BURY also produced Bluetooth versions of the System 8 accessories.

I also found this Official BURY System 8 documentation, don't know if it's useful: https://www.bury.com/en/products/s8/

My goal is to keep as much of the original BMW/ BURY installation as possible and make it usable with a modern phone.

Ideally, I would like:

• Bluetooth connection between the phone and the adapter
• Bluetooth for phone calls
• use of the BMW/ BURY microphone
• call audio through the BMW speakers
• potentially retention of the original call buttons/controls, depending on how the system works
• possibly power the adapter from the existing BURY system
• Music capabilities

My current instinct is that reverse-engineering the Nokia side may be easier than reverse-engineering the proprietary BURY System 8 connector, but I may be completely wrong about this.

Hi everyone,
I’m currently developing ZL ECU Studio, a new Windows-based ECU binary analysis and calibration editing tool, and I’m looking for a few experienced ECU tuners/calibrators who would be willing to test the current private RC build and give me honest feedback.
Current version: 0.19.0-rc.2
Main features include:
HEX editor
Calibration maps
TABLE / 2D / 3D / Heatmap views
Structure Scanner
ECU Research
Custom .zldef definitions
Binary and map comparison
Snapshots and ChangeSets
Validation Center
Checksum provider architecture
Project/workshop workflow
The software is currently offline only. It does not perform ECU communication or flashing.
The test package includes a fully synthetic BIN file and matching .zldef, so you don’t need to provide your own ECU file just to test the software.
If you have your own legally obtained ECU files, you can also test them locally. You do not need to send those files to me.
What I’m mainly looking for is feedback about:
usability
map editing workflow
file analysis
definition workflow
scanner/research usefulness
comparison tools
performance
missing features
bugs or crashes
The build is currently unsigned, so Windows may show a SmartScreen / Unknown Publisher warning.
If you’re interested, send me a Reddit DM or email:
zlecustudio@gmail.com
I’m especially interested in feedback from people who normally use tools such as WinOLS, ECM Titanium, TunerPro or similar ECU software.
Thanks!