NefMoto

anyone know how to do this properly?

i tried:

boot ecu with bootpin, soldered chip still in place, dump file. bad file.
boot ecu with bootpin with no flash/encryption board, reattach flash/encryption board, dump file.

the second method got what looked to be a good file. but upon closer inspection it was not good. and after flashing the file, the ecu was a brick. guess i should mention i desoldered the pin header and soldered the 29f800 directly to the ecu.

parts of the bootloader (?, hex 0-9fff) were different. so i cut and paste the hex from a stock file. the ecu would boot enough for vagcom to log in but the part # showed as THIS-IS-THE (RAM-PROGRAM). so there were other parts in the file that were no good. i tried a few more copy/paste but gave up after a short while because i just did not have the time to screw with it.

i know its possible to dump a good decrypted file using the encryption board but i had not so much luck with it. i just got a psop44 adapter in the mail today for my programmer so i wasnt able to try that method. is that the only way to get it done?

I don`t think the PSOP44 adapter will help you since the file in the flash must be encripted, I never tried to read this encripted boards.

i think the adapter will help. the data has to be read off the flash decrypted by the ecu. so the encrypted data passes through the board and comes out decrypted. it would be the same as reading it with a programmer. theres some revo patents floating around the internet that talk about it. how thats one of the flaws of the encryption boards.

Depend of what kind of protection board is used, there are diferent makes, good luck  ;)

Keep us updated

well its mostly moot at this point. since i i soldered the soldered the psop44 to the ecu and flashed over the "encrypted" tune that was on it.

i need a new soldered ecu to play with. ;)

You just need a good bin file.  You will have to boot flash the ECU or remove the prom and flash it in a burner.   What ECU code is it?  I may have a stock bin file.

it was an m box. i did bootpin and reflashed it that way. the ecu is already back in the hands of the customer.

I have dumped chips in encryption sockets by reading them through the ecu using boot mode and KWP2000.

I tried putting the encryption socket into my eeprom reader and I got garbage.

I got a small program called Descrambler that I used a couple of times with great success. its mostly to descramble Superchips, Dimsport, and a couple of other types of files. It can actually scramble the file again after its modified and use the same board again. :P

Where can I get this Descrambler program ?

I have an ECU with no label that contains an garbage Encripted file... I Want to put the original file there, but no way of know even for sure what version it´s originaly... so I want to decript to see the Bosch numbers and put the original back

@ overspeed :

if you can do a 'in the car' or bench-diagnose-job via vag-com, you can actually get the numbers and software-revision from the ecu.
I've yesterday successfully read-out a socketed (and perhaps also encrypted) chip from a Seat-ecu. This was
done via a home-made ME7 bench-flash-cable, KWP2000+ box and the special version from chiptunawarehouse's ME7 edition
of the kpw2000 software. Took 10 minutes (512Kb chip), and i was expecting garbage, but the file is 100% correct :) .

@  ktech :  I would like to have a look to that 'Descrambler' program of yours. Would you be so kind to
                PM me abouth it ? Purely for educational purposes ofcourse. I found a list of supported encryptions i think of the
                software-program you mean.

@ k0mpresd  : It's been a while, since we've spoken via email (almost a year). Thanks for the audi-tt ecu-immo-solution.
                    I've got hold of a different programmer for the chip and all is fine and working ! Thanks for that ;) 
                    If you still have that encrypted socket, perhaps i can help you out...

Well... that´s what I done at the end...  as I didn´t know what car it belongs (as I said no label, the ECU was a gift from a friend who receveid it as a trade UAhUAHau)... I finally used VAG in bench to get the version...

I Still can´t  "see" the file as it is encrypted... but I can say it´s garbage because the first owner trade it because after the chip service the car never runs good... he lives in a very small city and decides to buy a new one... but this ECU had no labels e he didn´t ask the code for the guy in the car shop...

We tried to read an APR chip today, was about to get it to read in boot mode - but the data was not good.

So we removed it:

(http://www.vwot.org/community/modules/Gallery/albums/album1070/chipsNbeer.jpg)

I haven't had any luck reading the APR EMCS modules in boot mode either.

You could read any of these "encrypted" chips by making a chip reader that will start on the address the MCU requests on a reset and then proceed randomly from there.  None of the encrypted chips I've seen are using very complicated logic devices.  They don't have enough logic to parse the contents of the ROM in order to predict a jump - at the best, they can watch the speed at which requests come and check for too many sequential accesses. 

I have two other projects to finish first then this is next for me.  Hopefully have it done by summertime lol.

Instead of trying to steal this stuff, why dont you spend the effort to tune your own file? You never know, it might even be better!

Steal is a strong word. No one has said anything about copying and selling pirated copies, or anything like that. This is just a discussion of how to bypass security protections. There may be many reasons an owner of the ECU software may want to do this.

What if you are pretty happy with a tune and want to change your maf or injectors?  Are you stealing?

And what exactly am I stealing to begin with?  I guess you could argue that APR's EMCS is actual code that you would steal if that was your intent.  Everything else is Audi and/or Bosch's code that the tune vendor stole out of the ECU in the first place.  Last time I checked, when I bought a tune, I was paying for a service, not IP.  So I don't feel in the least bit guilty of reading my tune out or even sharing it.

Nice first post. *hugs*

I don't think a single person here is advocating stealing tunes.

Many of us paid for tunes that needed refinement, and I believe it is just as unethical to sell buggy software and attempt to prevent customers from taking corrective actions as it is to steal software. 

Starting over was the best thing I ever did.  I just wish this wealth of ME7 knowledge was as accessible 5 years ago as it is now.

@ dubnuts -> stealing...    HAAH!  ;D

No man, this will never be the sole purpose of +90% of the forum-members
over here. Try to first browse around, and see that this is a proper forum.

Have fun while hanging around this 'knowledge-centre' !

It gets better and better by the day.

Really !

On-topic again : there is a way to read-out these things i guess. A german guy
on another forum was successfull with the known 101key (DIL 28) from EVC and
the solution from grautech (DIL 28). He used a atmega processor-board :

http://www.seeedstudio.com/blog/2010/09/22/clearance-get-your-seeeduino-mega-for-only-39/

Perhaps with slight adaption in the software programmed into the atmega, we can use this to descramble the flashrom-based anti-copy-boards ? And ofcourse extra datawire-hooking up.

If interesed, i can proive a weblink to the specific forum-thread, if Tony permits. 

Cheers,

PvL

The one board I have dealt with had a PIC processor to detect pulling DQ4 low to enable boot mode, and it would disable the flash when it thought boot mode was detected.

I suspect this board is not as complex as some others but its something to look for with encryption boards.

Provide away.  ;D

Another thing a lot of people don't seem to know about, is all of the tools that support boot strapping the C166/C167 processor. I used MiniMon to do all of my boot mode reading before Galletto existed. MiniMon even has a scripting and macro environment with support for loading user code into RAM and calling into it from the script on the PC.

Infineon: Home > Microcontrollers > Development Tools, Software and Kits> C166/XC166 Development Tools and Software> Software Downloads

http://www.infineon.com/cms/en/product/channel.html?channel=ff80808112ab681d0112ab6b50fe07c9

Keil Third Party Flash Utilities:

http://www.keil.com/flash/utilities.asp

This is very similar to what Colby+others @ OpenECU did with the Subaru and Evo ECUs.  The reflash procedure on these is done by a custom boot-mode "operating system" that is loaded into RAM and then executed to complete the flash procedure.  Thanks a lot for posting those links Tony.  Very useful.

Tony, could you provide a Minimon ready-to-use driver for reading/writing external flash AM29F200BB in SAK-C167CR-LM processor system (i.e. C167CR_AM29F200BB.ini)?
I have a thread concerning this: http://www.nefariousmotorsports.com/forum/index.php?topic=365.0
Your help is much appreciated!

Gentlemen, have a look over here :

http://www.ecuconnections.com/forum/viewtopic.php?f=22&t=3719&p=24637&hilit=protection#p24637

I think it's quite interesting.

Feedback wanted.....

Cheers,

PvL

I attached the version of MiniMon I used along with my config file for flashing my 2001 Audi S4 ECU. I still need to find the memory driver I wrote for the 29F800 flash chip though, because MiniMon only came with drivers for the 29F400 flash chip.

Keep in mind I haven't looked at this stuff in a couple years.

Here is universal 400/800 minimon driver witch i used a long time ago.
It's not optimal and slow, but it works...
Кеер in mind I wrote it 10 years ago in 30 minutes.  :)

Thank you, but .ini/.hex don't work in my case.

Of course you must properly edit your [Memory] section in ini-file to use this driver.
Something like that (this was for minimon version 19).

NAME=FLASH
TYPE=FLASH
BLANK=0xFF
BURSTSIZE=0x0040
SECTION(0).STARTADDRESS(0)=0x100000
SECTION(0).LENGTH(0)=0x100000
SECTION(1).STARTADDRESS(0)=0x800000
SECTION(1).LENGTH(0)=0x100000
DRIVER.PATH=!\MYPGM.HEX
DRIVER.BUFFERADDRESS=00FC80
DRIVER.FEATURES=PROGRAM,ERASE

Set your path to driver directory.
HTH.

I found useful info rearding discussed problem here: http://www.keil.com/forum/20221/

To prove this, on a dissasembled ECU, I routed the data lines between C167-proc and AMD-flash. Here is the result:

C167CR-LM	AMD29F200BB
AD0	DQ4
AD1	DQ12
AD2	DQ5
AD3	DQ13
AD4	DQ6
AD5	DQ14
AD6	DQ7
AD7	DQ15
AD8	DQ11
AD9	DQ3
AD10	DQ10
AD11	DQ2
AD12	DQ9
AD13	DQ1
AD14	DQ8
AD15	DQ0

So, the problem with write/erase fails is that the data lines are crossed (for routing simplification): when the C167 "wants" to write the "sequences" (see the AMD datasheet), the memory doesen't see the right values.

Actually, this problem is well known in Siemens automotive ECU units.

For example, in some cases you must write "44h" on the proc side, if you want the memory to see part of the unlock sequence "A0h".

So, I have to rewrite (and recompile) the minimon driver in order to correct the memory patterns.

Progs as WinOls and ECM2001 have integated option to code/decode dumps BIN<->SIE, due to swapped data lines.

For comparision, find two attached files: one is in-circuit read with Minimon, the other is read by eeprom programmer (flash chip desoldered).

Could someone help me to write a new driver for AMD29F200BB and AMD29F400BB, which will work in the case with swapped data lines?

Thanks.

Lifting old thread!

I take it that you can use a suitable ECU in boot mode to read any EPROM from any ecu if you use boot mode, since the ECU will not use the code in the EPROM at all when booting in boot mode?

Then, what ECU would be suitable to read a 27c256 chip? Could you even use a ECU that normally holds a 27c512 chip?