How I reverse engineered everything for my car

Hey all,

I don’t have my M2, as I just ordered it yesterday… But I wanted to share how I was able to reverse engineer, and control different things on my car using another dongle(just like the M2). Once I get my M2, I will be able to share source code, etc with everyone.

This was on a 2003 Trailblazer. I was able to control the windows, radio, seat heaters, lights, seat motors, etc…

What’s the first step you ask? Get a device such as an M2, where you can log can traffic.

After you’ve got that, you need software to help you reverse engineer which message actually controls the window, seat, etc… For me, I am a software/application/electrical engineer… So I wrote my own software that logged all of the can messages.

The software I wrote, connected to the hardware through a serial interface. The software had a list that would be populated with the messages, once I hit the start button to start logging. So my process is, hit start logging, press the window down button on the car, hit stop logging. Now I have my message, somewhere in this list that rolls the window down. How do I narrow this down, to which one it is?

Without knowing my module IDs, I had to try the messages one by one. So I already had all the messages in a list in my software I wrote. So I had another button in my software, that would resend every single message that I just logged. So I replay every message, and when my window goes down… I know I definitely have the message somewhere in my list. My next step was to put a delay between the sending of the messages. This would allow me to watch as my software sent all of the messages. Then I could narrow it down to around 10 messages that it could be. Then from there, I could only send those 10 messages with an even longer delay. When the software sends the message, and the window rolls down… I know thats it! :smiley: So from there, I would log that this message rolls my window down. Then I would try to manually send the message myself.

I would repeat this for every action I wanted to perform on my vehicle. After a month or so of getting, and organizing everything. I was able to control pretty much anything on my car.

*Something to note:
Most cars after 2008 (or maybe it’s 2012?) have gateway modules. Gateway modules prevent users like us from seeing all of the traffic going across the CAN BUS. The only time we would see traffic, is if it’s requested by a scan tool. We would see the request, and response. So, if you don’t see any traffic across your CAN BUS because you have a gateway module on your car… You will have to go a different route to do this.

That route would be to find a scan tool that controls your windows, lights, etc… Then monitor the can bus when that tool is controlling them. This has good news and bad new though…

Good news: You have the message now to control your window, seats, etc…
Bad news: You can’t use it. OEMs use security on their modules. So unless you know how to get past that, you won’t be able to use the messages you get this way.

Don’t be disappointed though! Some OEMs don’t use security for output controls, and some modules on other OEMs might not use security for output controls. But the ECM, and BCM most likely will for a lot of the OEMs.

Once I get my M2, I can write software to help all of use reverse engineer our vehicles with the M2. I will be back, when I get it. Other than that, any questions, just ask.


I will certainly be very interested in what you have done. I would actually like to PM you to discuss what you have done because it will relate directly to my 2003 Avalanche that I want to do the same thing with. As a Software Engineer I can do some other cool stuff as well…

Just have to have time to do it but would certainly like to see what your able to do.

As far as the gateway stuff goes… From what I have seen so far in those cases the ODB II port appears to be connected to the BCM and the BCM acts as the traffic cop. If one grabs the factory manual for the vehicle they are looking at and really read everything you can figure out what modules are on what systems. On my '09 CTS the factory manuals specifically split out the different modules into the different buses that they are on. In most cases you just need access to that bus which can generally be tapped into directly from the BCM. Luckily most OEM’s have a location where you can jump on the bus and talk directly to the modules which makes it much easier for their diagnostics tool if the BCM doesn’t allow them to pass the information. But I certainly am interested in what you have found out regardless.

I haven’t heard of another spot to plug into, that bypassed the gateway module. Or do you mean just tapping in to the wires themselves? I had a vehicle where I needed to view all of the traffic going across the bus, but it had a gateway module :frowning: I had to set up Canalyzer, to act as a man in the middle, so all of the traffic went through that. Then I was able to get all of the traffic, once I tied directly into the CAN BUS wires. But, let me tell you, that was no easy task setting up Canalyzer to do that lol.

As far as I can tell, all of the OEMs are using gateway modules now. This is so all of the modules on the bus can talk at different speeds (as they’re still transitioning all to UDS 14229). But your scan tool only needs to talk one speed, and one protocol, to the gateway module. Then the gateway module will talk to the other modules, and act as a go between for you.

Couple things…

The following pertains to all GM vehicles.

The body of the trailblazer NEVER went to CAN. It remained the same Class 2 (J1850 VPW) architecture throughout its entire 2002-2009 production run.

starting around 2005-2006, they switched over to next gen ECM’s (E67, E40) and TCM’s (T42)…this was due to the transition to the Gen IV small blocks…Gen IV engines with active fuel management and 58x CKP reluctor wheel couldnt run on the tired old P59 (which only spoke J1850 VPW). These new ECM’s also speak CAN. Butttttt…they also speak Class 2 at the same time.

CAN was only used for ECM <-> TCM communications, and for ECM/TCM scan tool communications/diagnostics/reflashing, because GM had to prepare for the upcoming 2008 EPA standard of CAN for powertrain scan tool communications.

EPA doesnt care about body/chassis though, and GM wasnt about to revamp the entire body electrical architecture and interior modules when the trailblazer was being put out to pasture after 09 MY anyway.

So even though the ECM and TCM went CAN around 2006ish, the body was still Class 2. The ECM was the gateway. If there was anything interior/body/chassis related that needed data from the powertrain, the ECM would send it out over Class 2.

The BCM and interior modules on all GMT-800, GMT-355, GMT-360 never spoke any CAN whatsoever.

And finally…you are wrong about the security thing. There is no security on any current GM Class 2 or CAN databus whatsoever, even as of the current 2018 MY.

The only thing that requires security access (2 byte seed/key) is if you want to change the VIN on a module, or reflash a module. GM has had that since the mid 90’s, when modules first started being VIN coded.

All the regular powertrain/chassis/interior scan tool bi-directional controls dont require any security access. Sniff the bus while using a Tech 2 to mess around with bi-di controls if you dont believe me.

When GM switched over to using 100% CAN (500k dual-wire 11 bit for powertrain/chassis, and 33.3k single-wire 29-bit CAN for interior/body/comfort/convenience), the BCM then became the gateway for high speed CAN and low speed CAN. Again, no security or any of that crap for messages or scan tool controls (aside from VIN update in the BCM, TCM, ECM, and module reflashing).

Starting with most 2017 MY GM vehicles, they did split up and isolate some high speed and low speed CAN networks, and begin using gateway/isolation modules. THis was due to rising security concerns with OTA attacks on the vehicle via the Onstar module (which has wifi, bluetooth, and LTE connections). Still no “encrypted” CAN messages, just the onstar module, instrument cluster, and radio were physically isolated from the rest of the truck via a gateway module that would carefully check over all messages before passing them along to the rest of the truck. These isolated busses on 2017+ MY GM vehicles are not wired to the OBD port. You;d have to dig into the dash to access those directly.

2016 MY and earlier GM vehicles, everything was wide open and available via the OBD port. Yes, the BCM on the GM vehicles that are 100% CAN is a gateway between high speed and low speed, BUT thats only for intermodule communication (ie, the ECM on high speed needing to send rpm, speed, oil pressure, coolant temp etc to the instrument cluster which is only on low speed)…if you plug into the OBD port, you can access 100% of every module on the vehicle, no gateways or firewalls that you’d be talking to…because the Macchina can speak both high speed and low speed CAN simultaneously…

Hope that clears things up. :slight_smile:

I’d really like to start working on a J1850 VPW (Class 2) library for the Macchina…there isnt much out there. Theres just always the issue of not enough hours in the day! I have a full bench setup of Class 2 modules though if anyone needs me to test things.



See my explanation regarding the BCM “gateway” thing, the 08-13 CTS falls into that category.

High speed and low speed GMLAN go right to the OBD port, you can access both and do whatever you want with the Macchina. SWCAN on pin 1, high speed CAN on pins 6/14.

The BCM acting as a gateway is ONLY if the ECM (or TCM, or anything that is only on the high speed bus) wants to tell something to a module thats only on low speed (instrument cluster, for example), or vice versa.

The BCM and its job as a high speed/low speed gateway has absolutely nothing to do with a scan tool, or “hacking” the vehicle.

THIS IS NOT A VW!!! You arent dealing with any middle man gateway etc, you dont have to splice into additional wires in the dash blah blah blah.

Every module on all 2016 MY and earlier GM’s can be accessed DIRECTLY via the OBD port. There are no modules that are NOT physically wired directly to the OBD port. (well, except the yaw/lateral acceleration sensor for ESC, thats on a dedicated CAN only between the abs module and the yaw/lat sensor, but thats irrelevant because the ABS module re-broadcasts/mirrors all that stuff out on the common high speed bus that goes to the OBD port anyways).

And I guess the two front window motors are LIN, using the door modules as a gateway between LIN and low speed SWCAN. But, again, the door module simply just mirrors all those messages out onto SWCAN anyway, theres zero need to actually tap into those LIN circuits.

Hey Ben,

Thank you for clarifying everything. I was saying that security is needed for some OEM output controls. I’m not sure which ones, as I haven’t experimented with all of them. I didn’t realize all of GM doesn’t require seed key for output controls, that makes me very excited. I will have to play with my 97 Jimmy. My 2003 trailblazer I was working with was the GM Class 2 single wire on everything I was talking too, you’re right :stuck_out_tongue: . I didn’t have a scan tool, to view the traffic for the output controls, that’s why I didn’t realize GM doesn’t need security access for their IO controls. I know Toyota doesn’t require security for output controls (not sure all of which years though). I was working with a 2013 Lexus IS250. I was able to reverse engineer, and write software to program keys, and program the TPMS sensors to the vehicle. I also did this with a 2007 Prius as well.

I think Ford is big on using security for their IO controls. What other OEMs don’t require security for output controls? I think us making a list of this would be useful. We could reverse engineer the messages, and we could use them for our projects here.

Ben, Sorry I haven’t been more active with the J1850 stuff… I have been trying to get my end of summer projects done with it getting closer to winter. And then my lab stopped working… I will be testing out my lab later today or tomorrow. I have a panel I hooked my simulator to on one circuit hoping the Radio Shack power supply was my issue with it and I also have the BCM and Dash cluster for the Blazer. I should have something up and running hopefully this weekend for it and can start tinkering with stuff. I should also hopefully be connecting with my hacker buddies and they should be able to guide me to getting things to work with this too. They have J1850 on their radar but are very busy so if I get it going they should have no issues with me pursuing it.

I had a 12 volt step down power supply for a PC I am installing into my truck and had been powering the simulator off that. Was powering the whole setup with a radio shack power supply that supplies 13.8 volts which you would hope wouldn’t affect it but nothing was communicating. I now have an adjustable bench 12 volt supply running it so we shall see… Either way the actual car modules should work too.

mrdennis87, dmaxben, redheadedrod,

You’re all infinitely more savvy than I. I’ve written a lot of vba for Excel, and have dabbled a tiny bit with Arduino, but I’m no coder. I have a 2000 Jeep Cherokee with a bored and stroked 4.6 L six that I would love to connect my M2 to, but cannot find any sample code for beginning to talk to my vehicle.

I’m sure I’m not the only one searching for example code. Do any of you have any suggestions, or know where I can find examples?

First off do you know what protocol your vehicle uses? Pretty sure it won’t be CANBUS.

WJ grand cherokee will probably have some mixture of PCI (J1850 VPW), SCI (I forget what that is), and CCD (stands for chrysler collision detection, I forget what that is too).

I dont believe the grand cherokee used any CAN until 2005 when the WK grand cherokee came out.

Based on the tables I’ve found in a couple locations, I believe the 2000 XJ Cherokee uses ISO 9141.

At the moment be aware that the only protocol that has working software for sure is the CANBUS. The SWCAN MAY be working but I am confused if the current software is working or if it needs additional modification. I have midterms this week so I don’t know I can test myself anymore until the weekend.

The other protocols such as J1850 (Both GM and FORD protocols) and LIN (And variations of LIN, K-LINE etc) just haven’t been programmed yet. I am trying to get VPW working but haven’t had the time to spend on it. Was fighting with my LAB. I hopefully will have my lab fully up and running this weekend. I have a BCM and dash cluster for a 2002 trailblazer mounted to a board. It probably will work right now but I need to modify the board to be able to turn it on and off. I also have a simulator on the board but wasn’t working the last time I tried it.

I have some things to try once I have the lab up and running and depending on other distractions hope to atleast have a reader up and going soon. Should have had it up and running months ago but have been distracted most of this summer with other projects.


Interested in your quote

I’m trying to start some basic reverse engineering on my 2013 VF Holden Commodore (Chevy SS) doing the simple all window down controlled via a long press on the remote.

I’ve managed to start to find some other stuff on the CAN0 , clutch n brake pedal and now have a modified cable as per your “SWCAN hack” post that connects SWCAN to CAN1 so could use SavvyCAN and start working on my 1st project.

The issue I have, at least for the things I have been looking for is my SWCAN data seems to purely be status messages, like windows open or closed (ID 0x1064A040) so I’m wondering why the switch messages would only be on the LIN? Surely Holden grabbed a lot of the electronic stuff out of the GM parts bin

Because your VF commodore/chevy SS is on the new Global-A platform.

Global-A makes much more widespread use of LIN in comparison to the older first-gen GMLAN common architecture (what a VE commodore would use).

Common-architecture had the door modules communicating with the BCM, OBD port, and rest of the truck on SWCAN. Global-A has the door modules communicating with the BCM on LIN only.

Note I said communicate WITH THE BCM. Not just with the window motors. Yes, common-architecture vehicles with auto-up windows used LIN for window motor <–> door module communications. But door module <–> BCM and rest of vehicle was SWCAN only.

So for Global-A vehicles, you’re not going to get any window switch commands or “detailed” window information on SWCAN because it doesnt have to be, the door modules/window switches communicate directly with the BCM via LIN only…UNLIKE common-architecture.

To get the more detailed stuff about window switches and commands via the OBD port (and not have to splice into a LIN circuit), you’re going to have to act as a scan tool and specifically ask the BCM for window switch status (because the BCM is the CAN <–> LIN gateway).

So in a lot of ways, the newer Global-A vehicles are much more of a pain to reverse engineer and tinker with via the OBD port, because they made widespread use of multiple separate isolated LIN networks…it wasnt just “everything is only on SWCAN” like the older common-arch vehicles.

Clear as mud?


Thanks for the detailed explanation, time for some more research

Your best bet is to get a factory service manual for your vehicle and see what it has. Should be available on Disk but be aware it will be a little costly. But well worth it.

They generally show all of the wiring and likely there is a service port somewhere you can plug into to access everything. Chances are that one of the BCM plugs has all of your LIN buses on it that you want to look at. The service manual will tell you what sockets and pins you can use to make a splitter cable etc. So you can tie into those buses by making new wire harnesses and not destroy the factory units.

(Note that in some cases you may have to dig a little to get both sides of the cable that you need. )

I think global-A BCM’s have like 5 separate LIN controllers.

Not sure if they’re all available on one connector though, have to check schematics.

I know that for this Blazer I have the BCM from all of the Class 2 data were available at a specific splice. It was the backbone for the databus and I saw the same thing in another vehicle I looked at so I wouldn’t be surprised to see it here too. But have to look over the docs. I looked where it described the databus connections and it shows where everything is connected. Although if they all go to the BCM I would think they would be available at the BCM.


I have been able to control most functions of my 2012 Chevy Volt but everything in the Volt runs on CANBUS. I can say with confidence GM doesn’t use security only for SPS programming. I learned a lot just sniffing and replaying messages to see what it does. You do need to go the scantool route to control functions no other way around it. Happy sniffing everyone. I provided a few vids of what I have accomplished so far.

dmaxben. It’s always great to find you “dmaxben” on a topic that relates to one of mine I’m seeking answers! Your knowledge is vast and covers many verticals.

I’ve been reading about CAN bus hacking for several years in my pursuit of bringing more modern controls and displays on older vehicles. In my case the Hummer H2. I found you here while i was researching tools to sniff and control Class 2 and GMLAN. Most of the others, i read about can’t.

Besides my immediate quest, I have some interesting projects relating to in vehicle Entertainment/Display and Computing, Phone Mirroring with multiTouch control and Bus control of vehicle functions. others may find interesting and want to collaborate on.

That being said, thrilled to find Ben on a CAN projects! I recently saw a press release from EFILive where they were crediting you for spearheaded a project involving BCM programming. (which i think is my current issue I’m seeking knowledge)

My immediate problem: I combine two GM 4x4 vehicles. One of which is close to your heart. One uses Class 2 (H2) the other Class 2 & GMLAN (2500HD). I’m successful up to this point but ran into issues with an unconventional twist to the typical build. All good if PowerTrain and all it’s moduels stay together in 1 vehicle. But If I substitute part of the PT, (T-Case and it’s related modules, in my case) from one to the other, I can’t get the module to function correctly. A high end scan tool, knows the modules exist and read it’s current state. I can scan the TC switch and read signals and control LED’s. I can scan TCCM and read and control current flow into the actuator but not control physical movement of the position selector. NO errors being reported and the H2 seems happy. But no functionality of the TC. I read somewhere in pursuit of answers that the TCCM is VIN coded in order to identify correct functionality for the specific application. I changed the VIN of the GMLAN ECM to match the TCCM, to no avail.

That’s where I am today. You may know exactly what i’m missing. Whether you do or don’t I’m still looking the shopping list of proper tools, harnesses, etc to sniff and send both Class 2 and GMLAN signals, Which is what brought me here in the first place. Finding Ben here was an added bonus.

Sorry so long! If there is interest, i look forward to collaborating on my other bus project.