ECU flashing with M2

Developer Projects
#13

Anything is possible but since the majority of flashing software for different vehicles is proprietary you would need to know the device protocol or be able to reverse engineer it. You could use the M2 as a sort of man in the middle attack between a flashing tool and the vehicle your trying to flash but still have to figure out how to accomplish what you want. You can attempt to reverse engineer but you need a programmer to do that and be able to pull the firmware from that device or similar methods. But then again if you have access to the hardware necessary to do the flash are you going to waste your time trying to copy it?

For an older system like the J1850 VPW the information is out there but I haven’t seen anything personally about other things. And with forums out there dedicated to hacking ECM’s someone is probably trying.

#14

Ok so at least you’re working in the raw bins, I assume with WinOLS. Or maybe really old school and using IDA or a straight hex editor (if thats the case, mad props to you).

You’ll still need to write your own bootloader though. Most of the europeans did WEIRD stuff, or rather blame it on Bosch. Especially later cars, right up until they turned on TPROT and laid down the hammer altogether.

You’d need to write a specific bootloader for each ECU, and maybe even each different Operating System depending on how much structure has been changed. The only Bosch ECU’s I have experience with are the EDC16-C34 (2006-10 GM duramax diesel) and EDC17-CP18 (11-16 Duramax)…they are NOT easy controllers to work with, and depending on if any segments have digital signatures or more complex checksums that WinOLS cant calculate…you’ve got your work cut out for ya. :slightly_smiling_face:

Start reading about CAN, USDT/UUDT protocol, and sniff a reflash process using your commercial tools…that will give you a huge head start.

Ben

#15

Also…having the A2L’s obviously is all but essential, but what would really be key to developing a reflash tool is if you had the Funksionsrhamens (whatever its called) or other engineering level ECU strategy docs…usually those at least have an outline of the flash process on a higher level.

#16

Yes I’m working with WinOLS, I’m not quite that old school!

TPROT is annoying but it has been got around now, I understand there’ll be some investment on the software side in order to buy information from people to make this happen, but the M2 hardware could work out to be a good piece to use, especially if it is compatible with so many other software projects.

I appreciate your input

#17

The Macchina hardware is 100% definitely capable of it…put bins on the SD card, and have the Macchina pull the bins off there, reformat into what the ECU wants to see during a reflash process, and go from there.

Software is going to take a LOT of work and a LOT of time.

TPROT, there are many different versions…the latest versions have not been defeatable as far as I know, or at least via OBD port…gotta open up the ECU and flash it via JTAG.

I think some of the latest BMW’s, even the JTAG port is password protected…so unless you’ve got a connection at BMW, its game over.

The 2017+ GM Duramax diesel pickup trucks are like this; SHA256 digital signatures on all cal segments, and a password-locked JTAG port…so unless someone high up at GM wants to get fired (best case) or go to jail for a long time (worst case), its “untunable”…

All car mfg’s are going this way quickly unfortunately. It wont be long before the ECU processors are actually storing the flash as an encrypted binary, and then a dedicated ASIC chip decrypts the flash/OS on the fly as the engine runs…pretty wild stuff.

#18

Just my 0.02 - I can confirm most of what @dmaxben has said, from my experience developing nisprog (Nissan ECU reflashing):

You’re looking at hundreds of hours of work
Then you need to write a bootloader.
Then you need to modify and calibrate the ECU files themselves.
Then you need to generate checksums.
Then you need to get it all rolled into the proper hardware layer/protocol…

Yes. Around 1000-2000 hours in my case.

Not to mention you should expect to/plan on bricking at least a dozen ECUs

I did better on this one : not a single bricked ECU. One close call though.

I haven’t checked in on the RomRaider community in awhile. Last I knew there was only one supported piece of hardware that could pull and flash the rom.

RomRaider has so far been Subaru-centric, but now with nisprog and some open definitions files, many people have tuned and reflashed their Nissan ECUs.

I believe the best investiment in time would be to write a J2534 implementation for M2, and leave the flashing to the PC/host side, as it is meant to be. I don’t think there is any reflashing protocol that cannot be carried out by a J2534 device. One limitation of M2 however would be the lack of “special function” pins that some ECUs need to have at a certain voltage to enable reflashing.

1 Like
M2 Hardware Changes
#19

Most of what the op is trying to accomplish seems like bosch ecu.

  1. bootloader not so needed as these ecu’s typically just need tp2 protocol or UDS for newer.
  2. Cal sections, seems like he has this covered with winols.
  3. file checksums, covered if winols likely.

OP needs to basically integrate transport(TP2) on hardware ideally, let PC control the application(kwp2000), can bus. Kline needs to have similar hardware code written as well if doing older bosch. You also need to know how to handle seed key security for programming mode, flash file encryption/compression methods, and block checksum for block flash verification. TPROT passwords can be read by OBD, but you need bootstrap loader to actually utilize them and do bootmode flashes. You can bypass TPROT entirely via OBD with some IDA work. Its a large undertaking, and a lot of “secret” knowledge involved.

You can do it all as said like J2534 passthrough, via the PC. J2534’s major downfall in my opinion is that you have to always poll for messages, no possible event for message received, so you must be crafty with threading to accomplish reading thread, and handlers that way. It can be done(ive done it).

If you go either route, i agree in the amount of hours others have said, 1000-2000. You can maybe be lucky and get some of the information required if you search well on internet and understand programming well. IDA is tremendous help along with matching .a2l files.

Best of luck!

#20

I will be picking up a Tech 2 (clone) as soon as my taxes come back. I will be working with the M2RET software and some other stuff I have to try and make a bridge so I can run my Tech 2 through my M2’s and be able to decipher what it is doing.

I will be doing this with my older truck (J1850) then with my '09 CTS. I may also try to use my Lab and mimic some of the stuff so I can easier grab the results as less noise will be in the system.

I understand this is used as a pass through device to work with GM’s flash software so maybe I can figure out how to do it with an M2. No promises though but would be cool to figure out.

#21

LMK if you need any help, i may or may not be of any when its comes to J2534 :slight_smile:
Have a fair amount of experience with it.

#22

Thanks skijump40, it seems you understand exactly what I am looking to do. If you have experience with this, would you be interested in a quick chat about it? Thanks

#23

Yes sure i can help answer some questions.

#24

J2534 is a protocol that works with UDS and allows you to program modules?

Hopefully once I get to that point it will be easy to see what is going on.

#25

So far as I can tell (and I’m no expert), J2534 is essentially a standard that defines a Windows DLL interface. Everyone who wants to support it writes a windows driver for their hardware that turns J2534 calls into raw CAN traffic. It’s called a pass-through device because it kind of makes your CAN hardware just a dumb device that forwards traffic in both directions. That way the DLL and the program contain the actual logic and the underlying hardware is somewhat irrelevant. You can use a Kvaser or Peak or some other tool to do the flashing and it doesn’t matter which. All they’re doing is forwarding traffic back and forth. But, the problem I have with it is that it really boils down to what appears to be a Windows DLL. You can’t use Linux to flash your car, the manufacturer isn’t going to produce a linux program to do it. You can’t use OSX, that’ll never happen. Instead it locks everything into Windows and that makes me sad.

I’m more interested in what the end program is sending and receiving via the J2534 calls. In other words, I’m much more interested in the resultant raw CAN. That’s likely to be UDS messages going back and forth in a modern vehicle.

#26

Thanks @CollinK. When I get my Tech 2 I will try to see what it does. Been getting bogged down with homework but still working on tying two M2’s together so I can make a bridge. The bridge will be transparent to SavvyCAN but still trying to figure it all out. When I get a little closer I will post a new thread for it. Basically I am hoping that I can track canbus traffic on either side of the bridge to allow RE a module on its own without affecting the traffic its self. This will be very helpful in trying to engineer the Tech 2 as it will make syncing commands to results much simpler.

#27

The j2534 specifications basically tell you exactly everything you need to know and how the hardware should work, theres a few docs that you have to pay for(copyright, etc).

basically the J2534 doesnt really do any of the transport/application protocol logic, its just a bridge to the actual physical network(can) You must implement all the manufacturer specific “stuff”

UDS is pretty standard now, so thats where i would start, any test ecu on the bench should work thats modern(check first).

Sniffing the can is the way to go, rest will be up to you to decipher. Feel free to post up anything i may be of some help with deciphering some of it even if its not my exact expertise(bosch).

#28

May take me a little while to do this since I am still working on getting 2 M2’s talking to one another while dealing with Calculus in college and working full time… I will get to it and with the tech 2 I should have the tools available to look at it but I have some work to do before I can dig into this.

I do have the software already that is used with the tech 2 to program modules so I suspect the J2534 may already be in there somewhere since it will do up to 2013 GM’s. Unless this is built into the Tech 2.

Wireshark will also sniff USB ports now so I could try to track everything that is going on.

I know I searched on this before and nothing came up but now you do a search on it and a bunch of stuff comes up. I will have to look at it later. Downloaded the SAE document describing it…

Rodney

#29

I have a knock off Tech 2 with the tech2win software. I believe the J2534 info is in the tech2win software as the tech2 is used as a pass through. Here is a setup/walkthrough doc for the factory updates. http://www.drewtech.com/technician/Installing_Tech2Win.pdf
I believe GM started changing some sort of protocol around 2011 and they went to the MDI VCI (Multipul Diagnostic Interface, Vehicle Diagnostic Interface). It still uses J2534 but the tech 2 can no longer handle it. They also require you use their SPS (service programming system)which is a subscription asked service. Not sure how this will impact the use with the M2 but to echo back what a lot of others are saying it will be a heck of an undertaking that will only be useful for a small number of vehicles. That being said, it would be cool, good luck.

#30

Here is some very helpful info on GM programming.

1 Like
#32

Yes, those documents look pretty neat. It’s a shame that scribd charges money but I suppose it isn’t a fortune.

#33

Aaaaaaa… http://techposts.org/how-to-download-documents-from-scribd-for-free-100-working/ …choo!!
Oh sorry, probably its the weather. :laughing:

Ok, i am by no means an expert…Please dont ask how i know these. I cant say. Its top secret stuff. :grin:
No seriously, i am no expert.:roll_eyes: But please do ask any questions, if you want to.

J2534 is an SAE (Society of Automotive Engineers) protocol, created under the right to repair act, aiming to break the monopoly of dealerships.

After passing the court and law of right to repair, a unified protocol was created compiling a new dll covering the following:

ISO9141
ISO14230 (KWP2000)
J1850
CAN (ISO11898)
ISO15765
SAE J2610
J1939 (since 2005)

Note that each manufacturer has a J2534 API (Application Programming Interface) dll (Dynamic Link Library). If you want to search it up and mess around a bit with. Trust me, it can swallow your time without you noticing as you mess around.

The standard has two sub-standards to it (well actually its three, J2534 included), J2534-1 and J2534-2.
So basically simply put, what it does is unifying in a way all the current communication protocols that were made from manufacturers.

With this said though, J2534 interfaces is by no means equal to OEM’s interface.
J2534 interfaces are pretty much used under a paid license of the OEM software, which then can control automatically the interface.
Again, with this said, this means that the software can ask the interface to play dead while fetching a stick.
J2534 in simultaneous communications most of the times falls short.

For example (i am located in EU), BMW online system while going through any type of programmings, using the OEM interface, especially on Fxx and Gxx series vehicles, can set to bootloader, program, code, restore user specific data (radio stations, seat memories etc) in multiple ecus (average of 50 control units give or take a couple), all at the same time.
Just looking at the screen doing its thing, is absolutely terrifying.

If you ask this from a J2534 interface (again i am in EU which means full coverage on ecus not just emissions like in US), it will just simply fall short. Not only by the multitasking, but on the protocols as well.
There is no interface out there that will cover it all on all manufacturers. Nope. If one was manufactured, then everyone including the manufacturers would use that. Plus there are new protocols available now that J2534 interfaces don’t have due to hardware limitations.

IF you managed to read thus far…:clap::clap::clap: :rofl:

I would happily share any knowledge i have with you guys.
Just @ me on your post and i can reply to anything i can and know (and have the time to do so) . :upside_down_face: