pcmhacking.net

rolls wrote:Mother fucker it appears to be an incompatibility with the OpenPort DLL and .NET 4.0, bug disappears if I roll back to 3.5. What a huge waste of time that was to figure out!

What about moving forward to 4.5?

Reinstall the .net4.0 framework again jsut to be certain its a clean install.

Tazzi wrote:

rolls wrote:Mother fucker it appears to be an incompatibility with the OpenPort DLL and .NET 4.0, bug disappears if I roll back to 3.5. What a huge waste of time that was to figure out!

What about moving forward to 4.5?

Reinstall the .net4.0 framework again jsut to be certain its a clean install.

Ok I solved the problem

Read here for the details.
http://stackoverflow.com/questions/4007 ... 0#40079720

rolls wrote:

MeZmeriZe wrote:Happy to help any way I can.. I've been working my way though howto's on dotnet, reverse engineering with IDA and reverse engineering PCM's.. lots of reading.. Then I had to port a two stroke and got distracted for a bit.

Then I discovered PerlNet http://docs.activestate.com/pdk/6.0/Per ... rview.html and thought.. ohhhhh.. I could be using perl code with dotnet libs.. I'm far far more at home with Perl than C# and it has some possibilities.. not the least of which is that Perl compiles down to Microsoft IL. And then there is this: http://search.cpan.org/dist/Win32-CLR/lib/Win32/CLR.pm

probably I should just learn C# but for trail and error and test stuff Perl has always been my go to girl.

Just saw the above. Personally my opinion is use the correct tool for the job. If your program is all regex/html parsing etc then perl is the way to go and stick with a perl console app. If you want to quickly script a console app with http/serial etc use python. If you want a GUI throw perl in the bin and write a proper .NET or C++ program with wxwidgets etc.

I have actually done the reverse before with embedding a perl script into a C# program. The script was for porting oldschool html help files to media wiki markup (about 400,000 help files for a gov project). I used a perl html converter and the awesome perl regex to build tables/replace fonts etc. The C# program then made a threaded program to bulk convert and upload to the wiki site running the perl code it its own container.

Yeah, can't argue with the logic... before I met you however, I actually had a test GUI working via perl and wxwidgets. (http://www.wxperl.it/) I've written tons of web apps (and shell) over the years, but never a win32 gui.. it was kind of a case of finding the quickest way to make something usable and it can be turned into an executable too if you are that way inclined though the main reason I liked it for testing is the same reason knocking up Perl to do stuff on Linux boxes is so handy.. instant testing gratification.. visual studio seems to have negated most of that now though and IL seems pretty cool. The irony being that I'd have had to convert to something better suited to GUI in the end anyway so might as well start there.

Hey rolls,

If I can help out, please let me know.
I have a 2008 FG G6E to play with.
8R29 / Orion / FG packed hex files.
A lot of information on the FG mid and high speed CAN bus.
Access to an Openport 2.0. I have ELMs and a VCM II.

I've checked out J2534DotNet but the Common, Plugin.FileFormat.PHF and Plugins projects are missing?

0xFFFF wrote:Hey rolls,

If I can help out, please let me know.
I have a 2008 FG G6E to play with.
8R29 / Orion / FG packed hex files.
A lot of information on the FG mid and high speed CAN bus.
Access to an Openport 2.0. I have ELMs and a VCM II.

I've checked out J2534DotNet but the Common, Plugin.FileFormat.PHF and Plugins projects are missing?

Yeah I stopped updating that project and I have it all in a private bitbucket project now as I've combined it with all my other libraries which I don't want to release just yet. It was more to leave it at a stage where others could use it to write their own program as all the security key unlock code and OBD/UDS code is still in that public github library.

I'll see if I can check in a version without all my other libraries that compiles later on in the week. If you want I can send you the common and plugin compiled dlls that you should be able to add as references? Depends what you want to do with the project I guess.

If you want to help out with testing I can send you a compiled version when I get the BA/BF read write with auto detect working. If you are looking at contributing I am open to opening up the project for others however will need to decide on what exactly others are working on etc so that merging/branching doesn't end up a mess.

I was hoping to have a new version out that people could test with on Sunday until I ran into a road block with the pinvokestack errors (check the stack overflow question for details). Problem is solved now, though it took me about 2 bloody days looking at it before and after work wherever I had spare time!.

Most likely will have something this weekend that will do ISO15765 sniffing with packet decoding (human readable strings), spanish/black oak read/write with auto detection of the vehicle and of the file type. I can include you on the PM when I finish this?

FYI once I send out this version the packet sniffing will mean if you have a Y cable and can sniff a silver/green oak flash read and write procedure I will be able to very easily add these into a future release. The sniffing only works with an OpenPort.

Another thing I found out is why the VCM2 didn't work! I had a stupid hard coded check if the VCM2 dll was being loaded and always returned false as the DLL was causing the program to crash. Since fixing the calling convention this is no longer the case.

So everyone who was testing with the VCM2 this should hopefully now work.

rolls wrote:Another thing I found out is why the VCM2 didn't work! I had a stupid hard coded check if the VCM2 dll was being loaded and always returned false as the DLL was causing the program to crash. Since fixing the calling convention this is no longer the case.

So everyone who was testing with the VCM2 this should hopefully now work.

Its always something little!
Looking forward to giving it a whirl.

Great news rolls!
Yes, please send me a PM when you're ready.
I'd prefer to use the VCMII but will purchase an OpenPort if it makes my life easier.

Compiled dlls are fine for now but I'll probably re-write my own if I don't have the source.
I might be able to help with development but I'm a car tinkerer (not an expert).

The binary is not parsed or verified and hence there is a real possibility of the PCM not working afterwards

I'll dump everything from my PCM before I try anything.

0xFFFF wrote:I'll dump everything from my PCM before I try anything.

Maybe a lovely nag box should be implemented.. simply saying "Make sure to perform a full read before writing".

Tazzi wrote:

0xFFFF wrote:I'll dump everything from my PCM before I try anything.

Maybe a lovely nag box should be implemented.. simply saying "Make sure to perform a full read before writing".

I do a compare of strategy and pcm type from the file you are writing to the connected vehicle. If the strategy doesn't match I warn/ask if you want to continue, if the pcm type doesn't match I abort.

A bunch of warnings regarding auto detect, eg if it fails or is unknown it will prompt you multiple times.

Also warns you to not write to a car you need to drive afterwards and that you should have not only a backup but another method to read/write in case of failure.

I'm quite confident it works without issue however it want to make sure people are aware it is ALPHA software and a bricked PCM won't be the end of the world for them on the odd chance it does occur.

I've tested writing all 0xFF, pulling the power to the PCM and also pulling the USB cable out half way through a write and it will recover fine. This is as I do a partial write, eg from 0x10000 on wards so the RTOS/boot loader isn't overwritten. The issue however is the BA starts at a different address, so you can brick the black oak PCM if you use a spanish oak write addresses, hence if the auto detect fails I don't give the option to write manually.

I've also introduced two methods of PCM detection. It polls the calibration address ptr from the PCM (same in black and spanish oak), if it is > 0x500000 and < 0x600000 it is a black, if it is greater than 0xExxxx and less than 0x100000 it is a spanish oak. I then also poll the strategy and compare that to a dictionary to see what PCM type that says. The dictionary I generated from bulk parsing the Ford PHF files.

Right, so its 'almost' bullet proof... or for better words... 'idiot' proof.

If someone goes out of their way to purposely flash the wrong sections or ECU in.. then really.. theres no-one to blame but them.