|
NathanBFXR6 |
|
||
|
Hi all
I am struggling to receive data from my him or cluster Atsp6 Atdp Atsh733 21 00 These work but as soonas I type 2100 it comes back with "no data" Can anyone help. Thank you |
||
Top | |
frankieh |
|
|||
|
NathanBFXR6 wrote: Hi all I am struggling to receive data from my him or cluster Atsp6 Atdp Atsh733 21 00 These work but as soonas I type 2100 it comes back with "no data" Can anyone help. Thank you Well it should return no data.. you haven't set 00 to anything yet, or are you trying to see if it has a default value? To set it for dual zone, put: 3B 00 55 after atsh733 and then try the 21 00 again. see how you go. cheers Frank |
|||
Top | |
Macca181818 |
|
||
|
Hotwire wrote: I have trans temp working for the BTR 4 sp!! Thanks to the help of this thread, I now have trans temp for the BTR to be able to be monitored via Torque: PID: 22092C Scale Factor: x1 Equation: (((A*256)+B)-32)*5/9 Header: <-- Blank Thanks for the guidance with regards to scaling & confirmation of location ive tried all the differnt option on this post to get the trans temp working and none of them ive me a value. im wanting to do it for a BF mk1 xt (4 speed btr). anyone got it working for a bf? |
||
Top | |
Hard_ware |
|
||
|
Almost 10yrs later ! post is still around
I stumbled upon forscan.org, the software allows module configuration using as built data as well as PATS programming. Will make re-configuring modules without a vcm. Need to have extended license, but its free. Works with the old McS1 eepod j2534 from back in 2007 |
||
Top | |
Robert_au |
|
|||
|
Hard_ware wrote: Almost 10yrs later ! I stumbled upon forscan.org, the software allows module configuration using as built data as well as PATS programming. Will make re-configuring modules without a vcm. Need to have extended license, but its free. Works with the old McS1 eepod j2534 from back in 2007 And it works a treat i have used it twice on module configuring with no problems at all, it even now allows you to match ICC/ACM modules
_________________ Current Ride |
|||
Top | |
frankieh |
|
|||
|
Robert_au wrote: Hard_ware wrote: Almost 10yrs later ! I stumbled upon forscan.org, the software allows module configuration using as built data as well as PATS programming. Will make re-configuring modules without a vcm. Need to have extended license, but its free. Works with the old McS1 eepod j2534 from back in 2007 And it works a treat i have used it twice on module configuring with no problems at all, it even now allows you to match ICC/ACM modules yeah, it's great. only think I've not seen in it yet that is super handy is being able to turn cruise control on and off in the PCM.. that's one of the only reasons I pull out my VCM anymore. I wish Lukeyson had actually saved more of his research in the forum.. and that the guys that promised to write apps had actually made them available, (beyond the cop mode one that aumatt made available I mean) |
|||
Top | |
Robert_au |
|
|||
|
frankieh wrote: Robert_au wrote: Hard_ware wrote: Almost 10yrs later ! I stumbled upon forscan.org, the software allows module configuration using as built data as well as PATS programming. Will make re-configuring modules without a vcm. Need to have extended license, but its free. Works with the old McS1 eepod j2534 from back in 2007 And it works a treat i have used it twice on module configuring with no problems at all, it even now allows you to match ICC/ACM modules yeah, it's great. only think I've not seen in it yet that is super handy is being able to turn cruise control on and off in the PCM.. that's one of the only reasons I pull out my VCM anymore. I wish Lukeyson had actually saved more of his research in the forum.. and that the guys that promised to write apps had actually made them available, (beyond the cop mode one that aumatt made available I mean) Give them time frankieh, even better catch all the data from your changes with the VCM2 and send it over to them so they can take a look and maybe implement it in the future. I'd like to see the ABS bleed feature implemented for the older 5.0 ABS units, they have it in there for the new units. Used it again the other weekend to get a car going with some of my spare equipment saved myself big $$
_________________ Current Ride |
|||
Top | |
rolls |
|
||
|
raptorthumper wrote: This is very likely wishful thinking, but does anyone know the algorithm for the seed/key pair on the BA and BF falcons.? This is the mode 27 security access seed/key request before the ECU grants security access for flashing.?? I have sniffed a working seed/key and I also have a copy of the binary of my ECU and I'm trying to find the seed/key algorithm within the PCM code. I am in the process of finding the memory address for the canbus register in the MPC565 from there I hope to find the canbus routine and hence find the routine that switches the commands eg 0x27 for security access, this however will be very time consuming. Do you or anyone else have any more information on this? I am in the process of making an open source (free) tuning platform for the ford powerpc ECUs in the BF/FG. My plan is to initially use a toyota VCM mini with external 18v supply (only $40) to the FEPS pin for flashing with support for other J2534 eg mongoose etc however they are the price of a HPT MVCI cable. I have already created some binary parsing software that will pull out all the maps and create a definition file automatically for unknown stategys. I have also reversed the checksum calculation and know how to recalculate and check this, I am currently however unsure of how to brute force or crack the seed/key algorithm. I figure once I find the algorithm in one binary it should make it easier to determine in others. I could try and download multiple strategys into my PCM using IDS and slowly build a seed key table but this is clumsy and I enjoy the reverse engineering challenge of figuring out the routine myself. Any information anyone has would be great, I'm happy to share what I have learnt so far in exchange. I believe an open community is much better than one that keeps the information for themselves. Once I have a master "definition" finished along with read functionality I will publish the open source code (be a few months away at least) Cheers edit: Here is my proof of concept program written in C# winforms. I am in the process of re-writing the GUI in WPF with a motec like interface where you can dynamically drag the windows around. This app is currently not useful to anyone as you require the binary for your ECU already. Does anyone know if the mongoose software will let you read your PCM to a raw binary file? If so can someone upload a copy of theirs (ba/bf/fg), I would like to see what format it is in and I could possibly support it in my application. |
||
Top | |
DStirrup |
|
||
|
Cadestal Lamps..
I remember quite a while ago I read about what codes you use in OBDC terminal mode to talk the the display cluster and disable the Traction indicator. I can no longer find that post in googling. Situation is that I have a BA mkII wagon XT which does not have traction control - no modulator or wiring fitted. The previous owner has installed a higher end cluster and center console but the ford dealer when programming it all up was unable to or did not bother to fix this error. As I understand things the PCM sends a status indicator which if the cluster does not see then it assumes the traction is faulty or whatever and lights up that led. I don't know whether the patch was a permanent one but the annoying thing is I went for a pink slip check and the guy won't pass it until I fix the indication problem. I tried to explain but he was not interested. Sigh.. |
||
Top | |
frankieh |
|
|||
|
Hi Rolls,
I'm gonna PM you as we are working on the same thing.. you are a bit ahead of me, but I think we can help each other. cheers Frank rolls wrote: raptorthumper wrote: This is very likely wishful thinking, but does anyone know the algorithm for the seed/key pair on the BA and BF falcons.? This is the mode 27 security access seed/key request before the ECU grants security access for flashing.?? I have sniffed a working seed/key and I also have a copy of the binary of my ECU and I'm trying to find the seed/key algorithm within the PCM code. I am in the process of finding the memory address for the canbus register in the MPC565 from there I hope to find the canbus routine and hence find the routine that switches the commands eg 0x27 for security access, this however will be very time consuming. Do you or anyone else have any more information on this? I am in the process of making an open source (free) tuning platform for the ford powerpc ECUs in the BF/FG. My plan is to initially use a toyota VCM mini with external 18v supply (only $40) to the FEPS pin for flashing with support for other J2534 eg mongoose etc however they are the price of a HPT MVCI cable. I have already created some binary parsing software that will pull out all the maps and create a definition file automatically for unknown stategys. I have also reversed the checksum calculation and know how to recalculate and check this, I am currently however unsure of how to brute force or crack the seed/key algorithm. I figure once I find the algorithm in one binary it should make it easier to determine in others. I could try and download multiple strategys into my PCM using IDS and slowly build a seed key table but this is clumsy and I enjoy the reverse engineering challenge of figuring out the routine myself. Any information anyone has would be great, I'm happy to share what I have learnt so far in exchange. I believe an open community is much better than one that keeps the information for themselves. Once I have a master "definition" finished along with read functionality I will publish the open source code (be a few months away at least) Cheers edit: Here is my proof of concept program written in C# winforms. I am in the process of re-writing the GUI in WPF with a motec like interface where you can dynamically drag the windows around. This app is currently not useful to anyone as you require the binary for your ECU already. Does anyone know if the mongoose software will let you read your PCM to a raw binary file? If so can someone upload a copy of theirs (ba/bf/fg), I would like to see what format it is in and I could possibly support it in my application. |
|||
Top | |
Nigel |
|
||
|
The Ford Seed/Codes are actually available and "out there" already on the internet - there is a proof of concept in C I think for unlocking. im sure its where Forscan got its functionality.
I did find and save it somewhere at Home - I'll have a look and see if I can find it. from memory, there are only a few Secrets that ford used, and its fairly easy to work through. Its all in a Doc on Hacking CAN networks (PDF) - by some guys at a Uni. the application they built is also available. Look here -> http://illmatics.com/car_hacking.pdf Around page 49. IDS was vulnerable in one version and the keys escaped. Cheers Nigel |
||
Top | |
rolls |
|
||
|
Excellent information guys, I'll have a good read this weekend.
Hopefully once I get the project to a point I am happy to put it on github (bug free) you can contribute to it. It is my aim to grow a community around it eventually, once (if) it gets big enough then there may be financial opportunity in releasing custom firmware with live tuning etc (there is enough spare ram in the ford ecus to do it). Something else is regarding definition creation, how have HPTuners and SCT originally created their definitions. Have they simply reversed IDS DMR logging to find what each address is and hence what the maps do? Or have they actually sat there and figured it out from scratch by getting electrical drawings and pulling the ECU apart. The latter would take much longer however doesn't require directly reverse engineering someone elses IP, the former is still reverse engineering however. Is it legal to use their software to create our own definitions, eg you change a parameter and save the binary, then compare and back calculate all of the addresses. This is reverse engineering however I suspect it is no different to what they have done to the Ford IDS software initially. I can do both however I want to use the quickest approach that is legal to create my own "master" definition which I will then use to automate the creation of others. I suspect using their software to help create definitions but with my own custom descriptions and naming is the only way to do so legally. Thoughts? What about interoperability, is it legal to reverse their dongles and cables to work with our own software? I won't be releasing any definitions until I can figure out what is and isn't legal. I also don't want to rip off other companies hard work however ultimately I suspect all the other players have simply ripped off Ford/IDS to get where they are so morally it isn't much different. Really curious on what you guys think. |
||
Top | |
frankieh |
|
|||
|
I use a commercial package called Binary Editor with a mongoose cable to do that now.
I don't like the fact that Holden has all sorts of free tools for fans, but ford has nothing that doesn't cost a ton.. so was writing one. rolls wrote: Excellent information guys, I'll have a good read this weekend.
Hopefully once I get the project to a point I am happy to put it on github (bug free) you can contribute to it. It is my aim to grow a community around it eventually, once (if) it gets big enough then there may be financial opportunity in releasing custom firmware with live tuning etc (there is enough spare ram in the ford ecus to do it). Something else is regarding definition creation, how have HPTuners and SCT originally created their definitions. Have they simply reversed IDS DMR logging to find what each address is and hence what the maps do? Or have they actually sat there and figured it out from scratch by getting electrical drawings and pulling the ECU apart. The latter would take much longer however doesn't require directly reverse engineering someone elses IP, the former is still reverse engineering however. Is it legal to use their software to create our own definitions, eg you change a parameter and save the binary, then compare and back calculate all of the addresses. This is reverse engineering however I suspect it is no different to what they have done to the Ford IDS software initially. I can do both however I want to use the quickest approach that is legal to create my own "master" definition which I will then use to automate the creation of others. I suspect using their software to help create definitions but with my own custom descriptions and naming is the only way to do so legally. Thoughts? What about interoperability, is it legal to reverse their dongles and cables to work with our own software? I won't be releasing any definitions until I can figure out what is and isn't legal. I also don't want to rip off other companies hard work however ultimately I suspect all the other players have simply ripped off Ford/IDS to get where they are so morally it isn't much different. Really curious on what you guys think. |
|||
Top | |
rolls |
|
||
|
Ah yes, the mongoose cable looks very useful.
Found the seed key algorithm as discussed in that paper. https://github.com/Self-Driving-Vehicle ... rdStuff.py |
||
Top | |
galapogos01 |
|
|||
Posts: 1139 Joined: 27th Feb 2005 Ride: Supercharged EF Fairmont Location: T.I. Performance HQ |
rolls, have you considered using TunerPro (or a similar open platform) as the editor and just building the software required to handle the Flash handshake and upload as a plugin?
It would limit you in some ways but save you time in others. Just a thought.
_________________ T.I. Performance - Ford Performance Parts & Tuning - J3 Chips & Tuning, Fuel Pumps & Injectors, Camshafts, Haltech ECUs and more! |
|||
Top | |
Who is online |
---|
Users browsing this forum: Google [Bot], Google Adsense [Bot] and 19 guests |