pcmhacking.net

Trunkz wrote:

Is that literally the front half of a BA/BF???

Now thats some serious simulation!

Hahaha Yeah I got sick of using my slow laptop and working outside in the rain (limited space in my small garage) so I thought Id cut it in half.

I spy with my little eye, the opened arduino project

Right on the mark

Whats happening on all those white boards, I see alot of mentions of BEMs happening there!

The Ba XR6T is an insurance write off. Somehow when it got delivered the key got "lost" So one of my missions is to disable/fool/figure the algorithm to the PATS system. Im currently exploring the BEM then on to PCM. Sharp eye you got there hahaha.

If you can get me the binary of the ECU I can tell you where the PATS bit is but I personally have not disabled it and I've been told there are other things that need doing as well as switching it off in the ECU.

Ive done it before need to enable pats switch, and disable pats alternate (opposite to standard for both). I always turn the steering pressure off and depends on the trans you need to change the speed sensor input.

Trunkz wrote:Hahaha Yeah I got sick of using my slow laptop and working outside in the rain (limited space in my small garage) so I thought Id cut it in half.

Just casually.. cut it in half Awesome

Trunkz wrote:The Ba XR6T is an insurance write off. Somehow when it got delivered the key got "lost" So one of my missions is to disable/fool/figure the algorithm to the PATS system. Im currently exploring the BEM then on to PCM. Sharp eye you got there hahaha.

If you jump back a couple pages, you can see a CAN log of the ECU only chatter. It spams out an algo of some sort constantly.

Im pretty sure this is what everything 'locks' to. Well.. at least the ICC and BEM that is.
So the BEM probably checks thats all golden and security linked with the ECU. Then probably checks key status, and sends of a validation message to the ECU to check if starting is allowed.

rolls wrote:One of the guys I'm working with found this product which might be useful for some of you looking for a cheap option to program other manufacturer vehicles using the openport. Seems very reasonably priced as well.

http://ecutools.eu/chip-tuning/pcmflash/

Trunkz wrote:Great work going on here Rolls and others that have pitched in! Awesome to see so much progress in such a small amount of time.

20161113_085541.jpg

Im currently working on replacing the ICC with 10" tablet arduino and a can bus shield over bluetooth. My thoughts after that is complete is to look into Read/Write to pcm. Im watching with enthusiasm. Cheers

Is the ICC the LCD screen you are talking about? I know one of the guys on here replaced it with a car PC which I think runs windows, simple but the result looks very good.

What about going raspberry pi? You get more hardware acceleration so you could play HD movies on it if you were that way inclined.

I'm the guy that did the windows thing. I'm actually a bit past that now. There appears to be a cga output on the main board of the icc. My plan now is to keep the main board of the icc and bin the rest. I just picked up a cga to vga adaptor to try. I want to use the cga output and the standard overlay so i can use the standard climate control displays if i want.. other than that i plan to put a ten inch samsung windows tablet i have here in its place, use a usb3 video input to display the icc overlay on the tablet screen. I used to be a custom interior builder for a few big car audio places so the dash mod fibreglassing and stuff isnt new to me. I'd prefer to use linux on the tablet. (Im a linux admin by day) but there is far more tuning software for windows.. If i can transparently run a windows vm in KVM with full j2534 connectivity and no timing issues I might do that anyway.

I've also got the drivers side dash loom of an FG xr6T and BCM/cluster. Ive already got the housings swapped over.. now just need to wire the FG bcm in as it's needed by the fg cluster unlike with the ba/bf versions.. wondering if i should wire it up beside the bf one with a programable filter between them or try to replace it entirely. (If the pin out on the fg bcm is similiar in connectivity to the ba/bf that would be the best option) Testing will tell which method works better.. I really like the look of the FG turbo cluster or id just bin the ba/bf one and just replace it with a widescreen tablet or two.. i may do that one day anyway as i could then just build a digital copy of the fg cluster and put it on the screen any time i want.. ( or an aston marton cluster.. or ferrari etc etc.. i have two respberry pi's too and the obligatory ardunio and can shield. But i dont actually think i'll need them for this. Usb to can interface should do most of the work for me.

MeZmeriZe wrote:I've also got the drivers side dash loom of an FG xr6T and BCM/cluster. Ive already got the housings swapped over.. now just need to wire the FG bcm in as it's needed by the fg cluster unlike with the ba/bf versions.. wondering if i should wire it up beside the bf one with a programable filter between them or try to replace it entirely. (If the pin out on the fg bcm is similiar in connectivity to the ba/bf that would be the best option)

Probably an entire development thread right there by it self to start nutting that one out.
Its the last thing on my todo list to see if I can get a FG cluster working in a BA/BF.. I can already tell theres gonna be some simulating required for some sensors/modules into the cluster.

Fitting the damn thing in to replace the BA cluster is a struggle

rolls wrote:If you can get me the binary of the ECU I can tell you where the PATS bit is but I personally have not disabled it and I've been told there are other things that need doing as well as switching it off in the ECU.

Played around with PTdiag's PATS functions? Might be of help there?

Tazzi wrote:

rolls wrote:If you can get me the binary of the ECU I can tell you where the PATS bit is but I personally have not disabled it and I've been told there are other things that need doing as well as switching it off in the ECU.

Played around with PTdiag's PATS functions? Might be of help there?

I've seen it but I don't have an MSC eepod to test with. Looked into trying to get the software to work with a J2534 cable however I didn't get very far. The exe seems to export all of the J2534 library functions and the eepod msc1 supports J2534 however it looks as though they talk a proprietary serial protocol to the device. Without actually getting one would be too much work to write an intermediate driver that translates it back to J2534 and if you counted your hours by the dollar probably cheaper to just buy an MSC1. One nice thing is ptDiag seems to have been written in C with minimal optimisation/no obfuscation many many years ago, this makes the ASM code extremely readable compared to recent C++ programs which are close to impossible to follow the ASM these days.

I know there is a bloke I was talking to who is buying one though, so might be interesting to see what it turns up on the sniffer during a PATS disable if he still gets it.

I know there is a bloke I was talking to who is buying one though, so might be interesting to see what it turns up on the sniffer during a PATS disable if he still gets it.

Would be interesting.

Ive order a tactrix open port, as soon as it gets in ill shot you a bin of my pcm. At the moment Im looking and comparing luke111 bin (which has had the PATS disabled) to a standard PCM seeing if theres any differences. Does anyone know which part of the bin I should be looking at?

Trunkz wrote:

I know there is a bloke I was talking to who is buying one though, so might be interesting to see what it turns up on the sniffer during a PATS disable if he still gets it.

Would be interesting.

Ive order a tactrix open port, as soon as it gets in ill shot you a bin of my pcm. At the moment Im looking and comparing luke111 bin (which has had the PATS disabled) to a standard PCM seeing if theres any differences. Does anyone know which part of the bin I should be looking at?

The addresses are different for every single strategy. A good start is search for the byte array 0x11333333" and the offset of the PATS enable/disable in HACCKGA is +0x38 from this address, the offset may change in other strategies however you can probably figure it out. It is stored in a massive array of constants, eg you'll find the low/high fuel slope and other interesting data (there are thousands of parameters) in a similar location.

If you want to see where the PATS enable is referenced you need to find the pointer of the constants location. Everything is then access as an offset to this pointer eg constants_pointer - offset = location of constant

For example in HACCKGA you have this line of code
lfs f28, -0x7564(r2)

Where r2 is the pointer to the constants data section and -0x7564 is the offset of this pointer of where the PATS enable byte is stored. Hence we know the PATS enable bit is now stored in f28 for that subroutine.

If you continue through this routine you can see it calls the spark routines which I believe is how it kills the engine. You can quickly burn days reverse engineering the binary to see exactly how it works. There are lots of magic constants also loaded during this routine, no doubt part of the security algorithm.

rolls wrote:If you want to see where the PATS enable is referenced you need to find the pointer of the constants location. Everything is then access as an offset to this pointer eg constants_pointer - offset = location of constant

For example in HACCKGA you have this line of code
lfs f28, -0x7564(r2)

Where r2 is the pointer to the constants data section and -0x7564 is the offset of this pointer of where the PATS enable byte is stored. Hence we know the PATS enable bit is now stored in f28 for that subroutine.

If you continue through this routine you can see it calls the spark routines which I believe is how it kills the engine. You can quickly burn days reverse engineering the binary to see exactly how it works. There are lots of magic constants also loaded during this routine, no doubt part of the security algorithm.

Be great to see more of this, really interesting!