Rather then trying to quote multiple people I'm just going to make a blanket statement in regards to most of what's on this page.

Will this replace commercial software for professional tuners?
Nope and this was never meant to do that. These Pcm's are almost 20 years old(well some of them) but they are still "License" the same as brand new stuff by commercial tuning products and that just doesn't seem right. This is meant to provide an alternative for your average Joe that wants to make make a couple of changes, swap a cam, intake etc but doesn't want to spend more getting the car tuned then it cost for the part's they just installed.

Will this ever have the coverage of commercial tools?
Once again....Nope and it doesn't need too. If your swapping an Engine into a non-stock application the OS number you use won't matter and there are some OS's that are FAR better suited to swaps then others. If you want to be able to tune your 2002 Corvette you'll need to either shell out the cash or have the skills to write your own Xdf's. (You know who you are )

Does Open Source Flashing gain us anything commercial products don't already offer?
Absolutely, the limit of what can be done was a finical decision by commercial companies. How much money would a Custom OS with 3 Bar Map, 2 Step rev limiter, wide band support and integrated boost controller have profited them VS the number of hours it would have taken to develop. The whole idea behind Open Source is that ANYONE can modify and contribute to the project. If a job takes 1 person 100 hours..in theory it would only take 10 people 10 hours. By sharing the work load far more can be accomplished before someone gets burned out on it from working on the same every night for weeks on end, and in the event they decided to walk away from the work others are free to pick up with the last person left off and in some cases that could be saving many hundreds of hours worth of work. No one working on any of this does anything like this for a living so things don't need to make sense from a finical standpoint and that's where every one is going to benefit.


Are there time's when a professional tuner will use this software?
You can count on it. I'm not going to name names but there are more then a dozen mail order and tuner shops on this forum using my Android app because there is no commercial tool that does what my app can...the irony is the reason they need my app is because a commercial tools screw things up when it flashed the Pcm. Many of these tuners have been waiting for the PC software to add support equivalent to my Android App, telling a customer on the Dyno..... hold on let me plug in my Bluetooth dongle and get my phone out to fix your Pcm isn't exactly professional but when it's the only option you do what you need too.


As for the CAN based stuff.....
There has been some talks of moving on to CAN once the VPW is done but at that point you are going to start cutting into the commercial tools market and it's dealing with technology that's a lot new with a lot less know about it then what were are currently working on. I'm not going to say it'll never happen but it's not something any one's making plans to do at this point. There is a place for commercial tools...it's just not with 20 year old computers.


@ kmkommes post count has nothing to do with knowledge or ability. Usually the people with low post counts and old accounts are the one's that know the most

 

If it can turn off VATS, recalibrate speedo/trans parameters for tire sizing, and turn off DoD, its almost infinitely valuable for that alone.
I do a few of those every week, usually on a bench harness, to get a PCM ready for someone doing a swap.

 

Is there a particular OS ID that you need or prefer?

There's an XDF for the 12202088 OS that was used for 2001 models that Dimented24x7 reverse-engineered pretty thoroughly, and another guy continued working on. That might have what you need. I haven't looked into that stuff much yet, but after we get writing to work reliably that will be my next focus.

If you Google Dimented 12202088 XDF I bet you'll find a thread on another forum where sometime posted the XDF file. I'll put the link on the our GitHub wiki when I get a chance.

 

Correction - search for Dimented 12202088 Comprehensive
And don't let it get autocorrected to "demented."

 

THIS!!! Plus I remember when HPT was worth it. You could split the cost with a couple buddies and basically tune any GM vehicle if you knew how to work the original credits given. Now I have two of my own vehicles that need tuning that I just cant bring myself to spend the $200 on yet. I was going to buy a Dodge seat on a friends EFI live for $500 too, then the repository vanished. This reminds me of the good ole neptune/chrome days with my honda's

 

CAN programming is 10 years old now. It's time for something cheaper/free. I guess I'll take care of the CAN stuff then. It does't look a whole lot different than what you are doing.
It appears as though the ELM327 supports the protocols needed for this.

I know how to get the following info out of my E38/E67 really easily by simply sending a couple of CAN messages.
PIDs supported
Infotypes supported
VIN
Operating Systems
CAL version
ECU Name
Software module Identifier
Serial
Seed

What's next?
1) Seed/Key
I do not know how to calculate the key for the seed. Without this, you can't read or write to memory. So I think this should be step 1 in any open source project. Until the formulas are known, numerous methods can be used to get the key. If the key isn't known you can simply just listen on the bus for the key when using any other tool that is reading or writing to memory. This is what I am currently doing. Once the key is known it appears as though reading the memory is pretty easy.

2) Read from raw memory (or whetever you want to call it, hah). This looks to be easy.

3) Determine which items to are valuable to change.
Where should I start?
Some items like changing the VIN (and maybe serial) should be easy. You don't even need to know where in memory the VIN is saved. You simply just send a message say "change VIN please". Other items like changing the key or the disabling VATS will be a little more difficult. I think I could determine where in memory these items are located pretty easily. I just don't fully understand the write to memory process works yet and how checksums work (if they are needed).

4) Write new stuff

Should I start a new thread for the CAN based stuff? I guess I'll focus on GEN IV GM right now.

I think I know specifically where the VIN/Serial/Seed/Key and a few other parameters like OS are saved. I just don't know how to write to those memory locations safely. YET....

If anyone can help and wants to chat, send me a PM and I'll send you my email and phone #.

 

If you do that many you should easily have unlimited already. If you do alot of different make and models then it may be cheaper to buy unlimited in efi live for that pcm type. If your tuning for money buying unlimited is just part of IMO if you want to make more profit.

Wait until you buy a 2018+ and want to tune it, you can use 6+ credits.

 

Plus unlocking...still better than the 20 credits needed for a Viper though. Had a friend of a friend ask if I could tune his so I looked into it all excited, then found out it would cost $1k just to get in the pcm.

 

 

I didn't see it either, so I was wondering the same thing. Unless someone discovers something that maps OS IDs to rows in that seed-key table, I think we'll just have to figure it out by trial and error.

Once nice thing about that table is that it will now take at most 256 attempts to unlock any PCM that uses an algorithm in that table. So rather than trying all 65536 possible key values, you just have to run the seed through all 256 rows in that table. It should be easy for us to write an app that, or maybe just add a button to the existing app, so that if someone has a potentially-compatible PCM (uses VPW, uses the 68332 CPU, etc) they can find the right algorithm and we can start tracking which OSIDs use which rows in the table.

That said, I wouldn't be surprised if newer vehicles use more sophisticated seed/key algorithms than what's covered by that table.

Also, older PCMs that our current app does support, but that have been flashed by commercial tools, might use algorithms that aren't in the table. We won't know until we try.

 

I was also confused by the example. Isn't the 2's compliment of 1234 EDCC?

Do we know that the algo tied to the OS?

My plan right now is to write a program to calculate 256 keys. I can then determine exactly what algo is used on my particular ECU.

How many different OS are there?

 

If you're comfortable working in C#, or are willing to learn, you're welcome to fork our app, or better yet add CAN support to it. Yay for open source, right? I've made some effort to make it possible to add support for other protocols and PCMs, however since we have only been using VPW with 0411s so far I'm sure that some restructuring will be needed here and there.

Steps 2 and 4 might be harder than they sound. The "read random range of memory" code that's built into the 0411 PCM won't actually read the entire EEPROM - some address ranges are not supported, and it's very very slow to use the standard VPW requests and responses. And for the write operation, you can't rewrite the entire EEPROM while executing code that is in the EEPROM (especially since write process requires erasing chunks of EEPROM before writing new stuff). So to get around both of those issues the app writes a little bit of code into RAM (the kernel) and tells the ECU to execute it. When the app is reading RAM, it's really talking to that kernel, not to GM's code. Creating the kernel took some real work - Antus did that part, and I'm really glad he did because I might just be using HPTuners otherwise.

Once you get a full dump of the PCM, the next steps would be to search for ranges of data that look like tables, and disassemble the code (hopefully using IDA Pro (expensive, but worth it)), and basically puzzle over the code and data until stuff starts to make sense.

It's do-able though. Honestly I'm a little surprised that we're only just now doing it for early-2000s cars.

 

E37 OS #'s
2007 2008 2009 2010 2011
12610011 12617248 12628829 12635865 12634915
12628830 12618032 12628960 12639473 12640965
12618029 12630187 12653247
12635399 12647468
12635813 12653292
12635814 12653628
12639670 12653771
12639673


E38 OS#'s
2007 2008 2009 2010
12602922 12615434 12617175 12633056
12605732 12615493 12626014 12635859
12605898 12617631 12628982 12635863
12607218 12618277 12628983 12636005
12608677 12619078 12628990 12637084
12609099 12622139 12630501 12639270
12611833 12622142 12633016 12639835
12612281 12622161 12636008 12644905
12612291 12624402 12647991
12612381 12649046
12612739 12653252
12613889 12653249
12614088 12653674
12614676 12654075
12614682 12656198
12616478 12656930
12617569
12628981
12628988



E67 OS #'s
2006/07 2008 2009 2010
12603381 12617449 12628912 12635857
12604676 12618164 12630465 12635947
12604996 12618588 12631817 12639299
12605331 12620193 12632176 12639469
12605669 12625349 12635973 12635857
12606475 12628837 12636036 12639299
12607442 12630367 12639301 12635457
12607783 12630458 12653238
12608370 12631999 12652955
12609256 12653669
12609502 12656245
12610013 12656942
12611134
12611938
12611951
12615419
12617015
12617217
12617747
12618768
12625341
12626281
12628999
19211212

There is very little interchangeability outside of the year the OS is listed for, these are not like the 3rd gen's where you can swap OS's to what ever you feel like. I'll have to do some digging for the T42 and T43 OS number's. Off hand I'd guess there are 10-15 that would cover 2006-2010. The 2011 to 2013 stuff gets a little better but then every thing gets mixed up again in 2014 where the Pcm family splits again.

2004-2006 CAN stuff is mostly going to be the E40's and covers most Car's and the Trailbazer/Envoy(full size trucks used P59's and didn't switch till mid year 2007 to the E38). The E50 is in a family all by itself. It's 24x crank and 1x cam signals making it a 3rd gen engine but use's early 4th gen electronics and data coms. They are equivalent what was done for the 96,97,98 F-body/Corvette Ls1A style pcm, it was a new design but didn't stay in production very long.

 

If your dealing with pcm's using DOD your working with E series pcm's for 4th gen engines and is outside the scope of our work currently. We are working on the P1 and P59 pcm's used from 99-04 in car's and 99-07 in full size trucks and Suv's.

 

Vin, yes this can be done with 3B commands. Serial number......only 1 person to date has been rumored to have been able to change the serial number but it was never demonstrated and they never released the program.


Changing the key requires use of a flash kernel but can be done. To disable VAT's requires writing the entire block in the pcm, you can not change individual bytes in the area this information would be stored. You must write the entire block.


Easy is relative..... Yes the actual method to read it is very simple as shown below....but this requires a flash kernel to do so. A new creation of a flash kernel has been the largest issue we've run into over the course of the Pcm Hammer development

 

So who wrote this Seed/Key document? Can anyone point me in the correct direction to find this guy? I have a few questions.

1) There seems to be an error in the example or I am doing something wrong. When I use seed 1234 against Algo x24 I do NOT get 5E2C like in his example. I pointed out the 1's vs 2's compliment error in his example. Examples are awesome, when they are correct. Please let me know if I did something wrong and I will correct it.

Now, If I rewrite the code to not use
0x2A = Complement – if HH>LL use 2’s complement, else use 1’s complement
but instead use
0x2A = Complement – if HH<LL use 2’s complement, else use 1’s complement
it works as intended

Can someone please look over this and tell me if I did something wrong.

2) Using the corrected code, I found some seed/Key examples on the internet, and ran them in my program and found the ALGO used.
These seed key combos
seed 2590, key 0328
seed 4470, key 2309
seed 136A, key 293A
Use Algo x28

Somewhere out on the internet, I found the formula for the LS1 to be
KEY = 934D - SwapHiLo(Seed)
So the formula goes like this
SEED = 0A69
KEY = 934D - SwapHiLo(SEED)
KEY = 934D - SwapHiLo(0A69)
KEY = 934D - 690A
KEY = 2A43
If resulting number is negative, use 1934d.

The above formula also uses Algo x28

3) Something isn't perfect though. I tried a known seed/key combo from my vehicle and it was unable to find which ALGO was used. If anyone has some seed/key combos for me to try I'll run them though my program to see if the Algo can be found.

 

I just played around with this some more. I guess what I confirmed is that this formula

KEY = 934D - SwapHiLo(Seed)
So the formula goes like this
SEED = 0A69
KEY = 934D - SwapHiLo(SEED)
KEY = 934D - SwapHiLo(0A69)
KEY = 934D - 690A
KEY = 2A43
If resulting number is negative, use 1934d.

Uses algorithm 28 00000208 24 14 52 01 7E 38 97 2A BE 38 98 D4 28 $.R.~8.*.8..( from the GM seedKey.doc
as long as you replace
0x2A = Complement – if HH>LL use 2’s complement, else use 1’s complement
with
0x2A = Complement – if HH<LL use 2’s complement, else use 1’s complement


Edit
Sort of interesting. Using Algo 28 with Seed 0000 equals Key 934D. This math stuff is neat

 

I wrote this a couple months back for the 3rd gen Pcm's...it may or may not apply to the 4th gen one's too.
https://github.com/LegacyNsfw/PcmHac...yAlgorithm.txt

There is 1 issue reported you may want to look at that pertains to what I wrote but it comes down to the programming language and type of calculation being used as to what method works for you it seems like. I use 1934D in Android but have done very little on 4th gen pcm's so it may not work on those.

 

Would like to let everyone know the AVT 853 interface also works on tuner pro rt and ls1 flash,
I'm using it with the lantronic com port redirect software as the board is using a lantronic serial to ethernet server.
I was able to read cal from my 12200411 pcm with pcm hacking flash app , I then used dimenteds ls1 flash ver 1.0.0.0 and read cal , compared the 2 ok then reflashed cal , downloaded cal again and compared all good.
Yesterday I did brick my test pcm when I committed 2 sins 1 my lab supply was set at 11.9v and secondly I loaded a different cal file.
Cannot talk to pcm now, does nayone know how demented was able to unbrick ther pcm I've read post's that talk about grounding an address pin but I've tried this unsucessfully.
also read the specs on the flash chip that talks about suppling 12v to rp in to fource into flash mode, I havn't tried this but not sure how the software would respond
would be great if someone could explain this as bricking a pcm is part of the learning process as I found out.

 

Well it depends on how bad its bricked. There is a soft brick where the pcm can be recovered with software if it's still able to talk but it's gibberish. If the pcm isn't talking and it's unresponsive then it's a hard brick and needs to be done at the hardware level.

As you found out the ls flash doesn't check to see if a calibration and pcm OS match and will brick a pcm if cross flashed as you did.

if you'd like help with this you can PM me or create a thread specifically about fixing it and give me a link. I'd be happy to walk you through the various methods but unless you have access to commercial tools the fastest and easiest way will be to do it with a BDM tool. There is 1 type in particular that works well on these pcm's....its pretty cheap and can full write a bricked pcm in about 15 seconds but it does require some decent soldering skills to install. To give you an idea how full proof it is, ive been working on a method to stack 512k bins on a 1mb pcm with it. The word brick doesn't even to begin to describe a pcm after flashing a stacked bin file on it. Bdm has it back up and running in seconds with out an issue