pcmhacking.net

daniel2345 wrote:Why would key switch undo the changes?

New seed&key is in ram. Key turned, ram written to eeprom. Remember in car, the ecu is not instantly tuned off since it has always battery terminal 30 connected. It switches itself to "sleep" when everything is done.

If you hardcut power on desk, that might not work.


Also the writing of ram to eeprom can be triggered on various events, such as diagnostic writes.
Maybe this is done here.
99% of runtime in lifecycle no such event apart from key cycle occurs.

But remember, im only talking about what might be common.
My eep section has not moved while writing VIN and it has been said it is always on the same position in E38 files?


Edit: wait. I just re read and saw that the "fluctuation" is from 0xC000..0xFFFF. Two sections with 0x2000.

That might be possible, i saw this whole block as eeprom and did not check what is where...

In other GM modules like radios ect, when rewriting the VIN, they do not take full affect until doing a proper ignition off/on. On those systems, they do not have a dedicated ignition wire and rely on communication from BCM to tell it to turn off/on. But the VIN in the RAM will be blank, but will not write to memory until full ignition.

What I was thinking is if RAM is written to memory on every key cycle for the ECU, the RAM contents would overwrite changes made to that section. But It wouldnt make sense that it overwrites that section every time.. it must only occur under specific conditions maybe like you said maybe. But its over two sections so it would make sense it copies from one to the other each time.

What also needed is a pointer to the active section if two section concept is used.


I did not saw it in code, nor is anything changing...

Or it checks an init char != 0xFF on both section in 0xC000..0xFFFF.

daniel2345 wrote:What also needed is a pointer to the active section if two section concept is used.


I did not saw it in code, nor is anything changing...

Or it checks an init char != 0xFF on both section in 0xC000..0xFFFF.

It might be a FF check I think.

If both at FF's, probably goes into recovery mode.

*edit
I have a bit of a hackery with sockets at the moment with flashchips so I can recover so I can try erase that section and see what the PCM does. Id assume it wont fully brick.

Looking at that E98 cals, I get the following.
Its interesting to see it talks about 2nd MPU. Looking at the board I can only assume its talking about that chip at the top left Random note... 2000posts

It checks for a5a0 checkword stored at specific location in the eerom area, Usually it checks location a and if there is no match it checks location b which is location a+2000, than it knows where eeprom data is stored and loads the usual stuff to memory locations.
The update is done before the pcm goes to sleep on ignition off. Preventing the possibility for corruptions. Also updating in that area is made by 64 bytes chunks or pages. At least that is on the earlier amd flash chips. There is a good write up the amd manual. Of course that newer technology chip can use different strategy.

I don`t think blanking the full area is a good idea. At least find the a5a0 pointer and keep it there, so pcm boots happily. It is +1be on the dump you have made.


I am trying to find a ram memory dump of the pcm. Mainly interested in the 3f a0 90 - 3f e0 90 area. I guess it won`t be hard to read that area with the flash routine you have made. A full dump of ram will also be very helpful, you can blank the area where the flash routine is stored.



I found a slave file and made a dissasembly of it. I got 20 different variations of the processor and just choose a random one. Is there a print on the slave cpu that can be read out. Have no clue how it can be read. At least writing is readily available for hacking.

kur4o wrote:It checks for a5a0 checkword stored at specific location in the eerom area, Usually it checks location a and if there is no match it checks location b which is location a+2000, than it knows where eeprom data is stored and loads the usual stuff to memory locations.
The update is done before the pcm goes to sleep on ignition off. Preventing the possibility for corruptions. Also updating in that area is made by 64 bytes chunks or pages. At least that is on the earlier amd flash chips. There is a good write up the amd manual. Of course that newer technology chip can use different strategy.

I don`t think blanking the full area is a good idea. At least find the a5a0 pointer and keep it there, so pcm boots happily. It is +1be on the dump you have made.


I am trying to find a ram memory dump of the pcm. Mainly interested in the 3f a0 90 - 3f e0 90 area. I guess it won`t be hard to read that area with the flash routine you have made. A full dump of ram will also be very helpful, you can blank the area where the flash routine is stored.



I found a slave file and made a dissasembly of it. I got 20 different variations of the processor and just choose a random one. Is there a print on the slave cpu that can be read out.

12605899_slave_operatingsystem_fullOFFSET.rar

Have no clue how it can be read. At least writing is readily available for hacking.

Ok, I will get it to scan for the A5A0 checkword to identify which offset the eeprom section is at.

Next, I can add a function to dump ram if thatll help? My kernel runs in 3F 80 00 and goes through to 3F E0 00. ... so it might overwrite stuff in that area potentially??

The slave chip is: MC9S12C32MPBE25
I believe Ida shows the S12C32 option in there.

Next, I can add a function to dump ram if thatll help? My kernel runs in 3F 80 00 and goes through to 3F E0 00. ... so it might overwrite stuff in that area potentially??

So we aren`t going to have a virgin dump of that area. I am interested mainly because on the newer sps event, 2010-on, that areas is cleared before the flash begins. Wanted to find what is in there. Maybe some remnants of the copied to ram eeprom data.

A5a0 method is not 100%, because on different OSs, it is at different locations. Maybe using the 3 byte ascii version at the start [+7 bytes]will yield better results.

Looking through all the data sheets... I think this E98 is using the 55xx or 56xx series processor based on the upload address it sends to which lines up with the ram addresses for those.

Should be able to get the CPU to report its part number to identify its exact model.

SO I was wondering why the GM kernel wasnt disassembling nicely.. and its cause its not just standard ppc. Its the new addition of PPC with VLE (variable length encoding).

So just when I was getting the hang of.. they throw a curve ball

basically the same, but there can be a mix of 16bit and 32bit instructions in the bin. I need to go through and understand a bit more what the GM one is doing.. but after that should be able to code something up for dumping it.

realistically... one could write the whole thing in normal PPC. At least from what I understand all previous PPC commands are still supported, there is just the 16bit vle commands which I assume is to help reduce size.

Ok, did a quick hack kernel for the E98, and got it to spit out a CAN frame instantly and exit. So.. proof of concept for that is done.
Will leave that alone for now and go back to the software. Probably making it more advanced then it needs to be for the first time round, as Im implementing libraries/classes/definitions setup so that new ecus can be easily added.