Hola.!
Alguien me puede orientar, tengo un scanner automotriz con la App DiagzonePro, funciona por bluetooth el conector OBD II, perdí mi conector bluetooth, saben si cualquier conector es compatible.?

I've published the F-CAN findings from the 2003 and 2007 four-cylinder automatic Accords used while developing CarStats:

https://github.com/Small-ed1/accord-can-research

There are separate DBC, JSON and CSV maps for each observed vehicle, evidence and corrections, and a Python standard-library offline decoder/auditor. Confirmed, inferred and unknown fields stay distinguished.

One useful detail: engine RPM is the big-endian integer at 0x12C B4:B5, without the OBD-style division by four. The documentation also separates the year-specific checksum and distance conventions, raw versus normalized fuel counts, and throttle feedback from request-like channels.

I'm looking for independent confirmations or counterexamples on another vehicle. For the 2007, the most useful new evidence would be a diagnostic reference for 0x224 B1, metered validation of fuel-counter volume, or a synchronized reference for the accessory/clutch-control candidate. An anonymous summary with the exact field, vehicle configuration and independent reference would help.

These aren't Honda OEM DBCs or a complete specification for every Accord. The published tools are offline-only, and the repository excludes raw trips and identifying vehicle readings. Please use the issue templates for reviewed summaries. The material is publicly readable; no reuse license has been applied.

Need help cant find a download.

Hi all,

I'm looking for guidance, not a ready file. I want to understand the logic behind locating and editing these maps myself.

Vehicle / ECU:
- Dodge Durango 5.7 Hemi
- ECU: Continental GPEC2A
- Tool: KT200, full read done, backup saved
- WinOLS 4.7

What I want to do:
1. Disable MDS (cylinder deactivation)
2. Raise / remove Vmax limiter
3. Adjust torque limiter(s)

Where I'm stuck:
I have no A2L/damos for this ECU. I can open the file in WinOLS, but I don't know how to approach map identification on GPEC2A.

Questions:
- What is a good starting point for finding maps on GPEC2A without A2L? Typical axis values, map sizes, or patterns to look for?
- Is MDS usually a single enable flag/switch, or does it also require changes in MDS-related tables (RPM/load/temp enable conditions)? Any known traps (DTCs, lifter oil control solenoid faults)?
- Vmax: is it a single value or several limiters (per gear, per drive mode, TCM side)? Which unit/scaling is used?
- Torque limiter: are there separate limits for driver demand, TCM torque intervention, and gear-dependent limits? Which ones matter on the 5.7 with the 8-speed?
- Checksum: does KT200 correct the checksum on write for GPEC2A, or does it have to be done in WinOLS/externally?
- Any recommended tutorials, threads, or damos for a similar SW that I could use to learn the structure and compare?

I can share the SW/HW numbers and my read if it helps someone point me in the right direction, and I'll post my findings back once I get it working, so it's useful for others.

This is a hobby / learning project. If it goes well I'd like to work on other Stellantis vehicles (Pentastar / Hemi) later, so understanding the method matters more to me than a quick solution.

Thanks in advance!

anyone can contaact this man and ask his whatsapp number?
https://mhhauto.com/Thread-MHD-Flasher-Unlimited
and this man
https://mhhauto.com/User-userfane

After digging into the firmware for my cars ECU, one of the things I found out is they have pretty simple validation for frames.

It has between 60ms and 3000ms for freshness (time a valid frame isn’t received) and up to 20 rejected frames in a row before causing a BUS ERROR/fault.

The only other validation is the checksum and counter. Checksum is simple enough to find (it’s online anyway), and the counter is even simpler. Frames are transmitted with a 4 bit incrementing counter, but only the first 2 bits are ever checked by any of the ECUs (supposedly, you’ll see what I mean later). Not only that, but it only checks for REPEATS, not counter increments. That means you can send 1,2,1,2 or 1,2,3,4 and those are all valid. 1,1,1,2 would only accept the first and last frame.

This allows us to do a little hijacking. When looking at a CAN log you can see the deviation the ECU has for the frame timing, it’s usually smaller than its sending rate unless you have really bad grounding. So a frame sent at 3hz (3 times a second) probably has a sub 10ms jitter. But that’s fine since there’s ~300ms between frames. The trick is to grab a frame and store its counter value, and that’s your initial counter from the REAL ECU. Now you can send your fake frame with the next counter the ECU is supposed to send. So if you got a counter value of 2, you want to send 3. You now have control over that frame! For 3hz, you’ll wanna send your frame around 50-100ms after the last real frame to stay in the middle.

Whatever values you put will be accepted by any ECU that uses it, and the next frame coming from the real ECU will be rejected, since you already sent a frame with the next valid counter. Realistically this should work on higher Hz frames, it just gets more difficult to time it.

For this example I’m using frame 0x465, which is the ECO ambient assist light frame on any Honda that has one. It’s sent by the PCM, and has an upper/lower threshold for RPM and throttle angle, which selects 3 modes. Mode 3 is green, 2 is light green, 1 is white. (Sport mode, speeds over 87mph, or MIL set mode 1). The PCM transmits this frame and the Gauge Control Module receives it. I tried to make a “shift light” that blinks after 3500rpm, but the gauge control has its fading LED built in so it can’t really “flash”. It’s just a demo anyway.

I was only able to guess that the gauge control module has the same frame validation, but since this worked with no problems, I can only assume it uses the same 20 count reject/1.5s freshness validation.

Let me know if you have questions, I’ve done a lot with this stuff so far!

Hello folks!

I’ve already made several posts in this subreddit about my attempts to reverse-engineer a CarPlay/MMI box installed in my father’s car. My ultimate goal is to obtain a copy of its OS/firmware so I can modify it to suit my needs, experiment with it, and hopefully improve its functionality.

The biggest obstacle so far has been getting access to the firmware itself.

I’ve already attempted to gain UART access to the box but haven’t succeeded, although I’ve made some decent progress with the hardware reverse engineering. I also tried using Allwinner FEL mode, since the board is Allwinner-based, but that didn’t work either. If you’re interested in the hardware side of things, check out my previous posts: [this post] and [this post].

However, what I’m really interested in is the software, and I’m struggling to make progress there.

My original plan was to obtain an official firmware update file and reverse engineer it to understand how the system works. Unfortunately, the manufacturer doesn’t seem willing to provide the update file unless I can give them a specific reason for needing it. I’ve included screenshots of our conversation below.

This time, I contacted them directly, using my main email address and without making up an excuse for requesting the firmware. I’m currently waiting for their response, so hopefully that approach works.

In one of my previous posts, someone mentioned that they had managed to obtain an update file for a different MMI box and successfully modify its OS. That seems like it could be the easiest way forward, but so far as I just said, the manufacturer haven't been willing to help me.

Does anyone have any suggestions for how I could approach this?

One idea I had was to create a specially prepared USB flash drive that takes advantage of the MMI box’s built-in USB firmware update mechanism. Ideally, I’d like to find a way to get the system to execute some code that would allow me to dump its existing firmware onto the flash drive. Is something like that technically feasible, assuming the update mechanism has a vulnerability or accepts insufficiently verified update packages? If so, what would be a good starting point for investigating it?

I’m also open to other approaches, whether that’s finding a way to access the bootloader, extracting the firmware directly from the storage chip, finding compatible firmware from another device, or discovering a way to retrieve the official update package. Although I want to try the non invasive ways first, such as obtaining the update file and maybe making a usb stick exploit.

For reference, my device is an ANYFAR RM BM2506F, an aftermarket BMW MMI/CarPlay interface running a Linux-based operating system. It uses an Allwinner-based board, and I have already done some hardware investigation.

Here is the software information displayed in the box’s settings:

• Software: Box-C212 V2.6.3.0821
• Hardware: B2411-02-000d-0a-00-00-00
• System: Linux 5.4.61 (2025-07-24)
• Bluetooth: ZA_STD_BT01 V2.8.6 (2025-07-23)
• MCU: V5.1.8_202598 (0x02, 0x00)

I’d really appreciate any ideas, technical suggestions, or pointers toward resources that could help me make progress. I’m doing this primarily as a personal reverse-engineering project, because I’d love to understand how this device works and eventually customize its software.

Thanks in advance!

During our first week live, our founder discovered his dad had been recording every repair by hand. This is him using Revodo for the first time to turn those notes into a digital vehicle history. A real reminder of why Revodo exists. #Revodo #VehicleHistory

Following up on our previous post about CAN Opener SE. We've been making progress over the past few weeks and wanted to share a couple of updates.

What's new:

• New Carbon Black enclosure: We've introduced a Carbon Black option alongside our original Grey enclosure.
• Expanded international shipping: We've been working on improving our supply chain and are now supporting orders from the EU and Australia.
• Improved enclosure: We've refined the enclosure design, making it more durable and improving the buttons so they're easier to press.

For those unfamiliar with the project, CAN Opener SE is a compact OBD-II adapter built around the ESP32-C5, featuring:

• Dual independent CAN FD buses
• Dual-band Wi-Fi 6 and BLE connectivity
• OBD-powered operation (12–24V)
• Developer-friendly hardware: You're free to flash your own firmware and use the device for your own projects. You're not locked into our software.

We're also continuing development of Nexus, our companion app, which supports real-time CAN streaming, vehicle monitoring and controls through mapped vehicle profiles, trip tracking, and diagnostics.

Thanks to everyone who provided feedback on our previous post. We're continuing to improve the project and would love to hear your thoughts!

Store Link:

https://shop.canopener.io

Hardware Docs:

https://github.com/the-can-opener/CAN-Opener-Hardware

Discord:

https://discord.gg/5SzuSSYqmg

I want to get the rev counter an the coolant temperature gauge of a 2009 Renault Master (2.5 dCi) working without the engine control unit. I am therefore looking for the required CAN messages.

Hey everyone! I have two W126 clusters, one that I've identified as pre 1985, as it has Blue/black 12V wires, and another that is post 1985, as it has black/pink 12V wires. At least I'm pretty sure, please correct me if I'm wrong.

Onto the issue, I've tried pulsing 12V square, and 1.6~V AC sine, through an ESP33 to the white wire on the 8pin connector, all to no avail. Currently I have this setup, with the newer cluster, all black/pinks to 12V, as well as the red/yellow clock one, and brown being GND.

My PSU is rated for 4A, and I've tested all gauges on here, including tachometer, all work. It's just the Speedo that doesn't.

So I ask you guys, to please help me make this work. Thank you very much!

Hi everyone, I am looking to do some basic coding/adaptations on my Volkswagen Golf MK7.5 1.0TSI using the Car Scanner ELM OBD2 app.

I had one of those cheap, generic blue Chinese ELM327 adapters, but it doesn't work at all for coding (the app throws connection/protocol errors when trying to read coding modules).Since Car Scanner actually supports VAG coding, I want to upgrade to a proper adapter that is fully compatible with the app's advanced functions on the MQB platform...

Which Bluetooth OBD2 dongle do you recommend that is proven to work well for coding with Car Scanner on a Golf 7.5? I’ve looked into brands like Veepeak (BLE vs BLE+) and vLinker, but I want to make sure I buy the right one this time.

I know OBDeleven exists, but I specifically prefer to use the Car Scanner app if possible to avoid their subscription/credit model.

Thank you :)

Welp, after i made my last post here, and everyone was telling me not to give up, I decided not to. Im back at it again. This time more carefully.

Rip the OEM Pioneer radio 🥲

I recently purchased a VXDIAG Nano OBD dongle to initialize a new ABS module on a 2013 Ford Explorer. Does anyone have experience with installing or running Ford IDS through VX Manager?
I've followed the instructions on the VX Manager website, but I'm stuck. When I click Run under the IDS section in VX Manager, it only opens a folder in Windows Explorer. I'm not sure how to install or launch IDS from there. And I don’t know if a subscription from Ford/Motocraft is required?
Any advice would be greatly appreciated.

I have been working for about 8 months on a VWAG diagnostic tool... I've been very tentative about releasing it, but here it is.

Is it AI slop? Yes, because I am a mechanic, not a system programmer. This post is not AI slop, it is my own explanation of my tool.

I'm also not a tuner, I don't really use it for anything but learning so I would like to see what you guys are able to get from it or if it actually works in a real world scenario. That is the disclaimer, I have not done much with it besides read values and adapt a couple of things.

What is it?
VDCORE (VWAG Diagnostic Community Of Reverse Engineering) is intended to be a community driven diagnostic interface for VWAG vehicles. It can do just about anything any other diagnostic tool can do on these cars. Faults, coding, adaptation, whatever. (It does not handle sfd or sfd2.) It is contained entirely in the browser, aside from a small Windows application that runs in the system tray. This "Connector" app sends and receives data to the VAS 6154 or 6154A VCI.

The website interface translates the vehicle data into a diagnostic workstation.

How does it work?
The website uses native diagnostic protocols to actually navigate the vehicle's control modules. Just like ODIS does.

That is different from any other tool. Most tools like VCDS or OBD11 have a selected "library" of functions they can perform. This tool actually speaks the language and is able to have a conversation with the vehicle, not just read pre-determined sentences to it.

So instead of picking out a one-click-app to perform, you can manually perform each step and do the same thing. Each operation is generic or modular, meaning everything it does is through a small library of templates. These templates are run in Lua scripting language and designed according to the relevant ISO docs I could find. UDS, KWP/TP2, DOIP, OBD, etc.

The reason for that is I plan on implementing a macro/script recorder. So you can string together operations to create your own one-click-apps, including a logic engine for if, then, lists, confirmation, etc.

What can it do?
Honestly, that's kinda up to the community. It's entirely community driven, relying on user feedback to make improvements. Hook up your 6154 to your car, try something, if it doesn't work... Request it to be fixed. If it's not available, request it as a feature if it is within scope.

So far I have only tested it on my own vehicles, the concept is tested across hundreds of vehicles, but now it is up to you guys to test it on whatever else is out there in the world... So far it manages identification, faults, coding, adaptations, basic settings, and measured values.

Prolly works best for pre-SFD vehicles for many features, unless you have another tool that will unlock the SFD for it.

How much is it?
It's free. Bring your 6154A and try it out. If something is broken, submit feedback.

No accounts, no signup, no catch. Just sharing the tool I've been working on...

I'm not responsible for anything you do on there.

https://www.boredsystems.com/vdcore

I’m trying to get Apple CarPlay/Waze to project directly onto the Digital Dashboard (Active Info Display) of my 2018 VW Tiguan.

My head unit is a MIB2 Delphi with firmware train ⁠MST2_EU_VW_P0883D⁠. As you can see in the attached screenshot, multiple coding shops in Brazil are currently offering this exact software patch for Delphi units. Unfortunately, they refuse to sell the raw files or do remote sessions for customers in Europe.
Is there anyone in Europe or the Netherlands who offers this service? Alternatively, does anyone know where to find this patch? I work in IT, so flashing it myself via Telnet (D-Link) or an SD-card script is no problem if I just have the right files.

Any pointers to the right repositories or forums would be hugely appreciated!

I just wanted to say, ive had enough of this hobby lwok. it’s expensive and exhausting. I had a fully working dash and now its all fried. sorry not sorry.

Hi, seit einigen Tag läuft mein Hex V2 mit dem stm32f429 chip nicht. Wenn ich ihn an de PC anschließen leuchtet er nur blau und rot. Vcds erkennt das Gerät gar nicht und lässt sich nicht öffnen. Hattet ihr schonmal so ein ähnliches Problem. Wie habt ihr es gelöst?