pcmhacking.net

antus - Thank you - Yes - all good information. But as you say- the algorithm is the "key". I also can't find any info regarding the security levels. 27 01 vs 27 05 etc. Are these for different areas or actually for different capabilities as "levels" would suggest? Or even just different hardware .
Still - one needs the algorithm.

Yes. The algo, and the security levels are proprietary, only ford or their OEMs with access to their information would know what is what. Or people who have reverse engineered it.

The UDS spec has this to say about the levels:

The purpose of this service is to provide a means to access data and/or diagnostic services, which have
restricted access for security, emissions, or safety reasons. Diagnostic services for downloading/uploading
routines or data into a server and reading specific memory locations from a server are situations where
security access may be required. Improper routines or data downloaded into a server could potentially
damage the electronics or other vehicle components or risk the vehicle’s compliance to emission, safety, or
security standards. The security concept uses a seed and key relationship.
A typical example of the use of this service is as follows:

⎯ client requests the “Seed”,
⎯ server sends the “Seed”,
⎯ client sends the “Key” (appropriate for the Seed received),
⎯ server responds that the “Key” was valid and that it will unlock itself.

The 'requestSeed' subfunction parameter value shall always be an odd number and the corresponding
‘sendKey' subfunction parameter value for the same security level shall equal the 'requestSeed' sub-function
parameter value plus one.

Only one security level shall be active at any instant of time. For example, if the security level associated with
requestSeed 0x03 is active and a tester request is successful in unlocking the security level associated with
requestSeed 0x01, then only the secured functionality supported by the security level associated with
requestSeed 0x01 shall be unlocked at that time. Any additional secured functionality that was previously
unlocked by the security level associated with requestSeed 0x03 shall no longer be active. The security levels
numbering is arbitrary and does not imply any relationship between the levels.

Yes - So it can be done -- and somebody knows !!!

acln99 wrote:Yes - So it can be done -- and somebody knows !!!

It certainly can be done, many different tuning companies and other custom software places have reverse engineered the algos.

Usually it is obtained by either reverse engineering the factory software, or the desired modules firmware. Both have their challenges, and usually takes a bit of time to figure out. Perfect example of this is the clippings I have posted a couple pages back here for the Ford EECV stuff.

Thanks Tazzi - Yes - I have been able to log the seed/keys from doing HPT VCM read. I could only log CAN bus. I don't have a J2534 that would let me log NGC3 - SCI. Also have tried the SBEC3 algorithm on the NGC but it either is different or possibly it is for EEprom, not Flash.

So - I am kind of stuck on what to try next. Any direction or suggestions are greatly appreciated !!

Below are some notes...




challenger
7E8 8 2 50 85 0 0 0 0 0
7E0 8 2 27 5 0 0 0 0 0
7E8 8 4 67 5 8C 98 0 0 0
7E0 8 4 27 6 4C EE 0 0 0
7E8 8 3 67 6 34 98 0 0 0
7DF 8 2 3E 2 0 0 0 0 0
7E0 8 10 8 34 80 0 0 0 0

7E8, 8 2 50 85 0 0 0 0 0
7E0, 8 2 27 5 0 0 0 0 0 2008 ram
7E8, 8 4 67 5 41 CD 0 0 0
7E0, 8 4 27 6 1A 7 0 0 0
7E8, 8 3 67 6 34 CD 0 0 0
7DF, 8 2 3E 2 0 0 0 0 0
7E0, 8 10 8 34 80 0 0 0 0


7E8, 8 2 50 85 0 0 0 0 0
7E0, 8 2 27 5 0 0 0 0 0 2008 ram
7E8, 8 4 67 5 DB 89 0 0 0
7E0, 8 4 27 6 A3 78 0 0 0
7E8, 8 3 67 6 34 89 0 0 0
7DF, 8 2 3E 2 0 0 0 0 0
7E0, 8 10 8 34 80 0 0 0 0



7E0, 8 2 27 5 0 0 0 0 0 2008 ram
7E8, 8 4 67 5 CD 79 0 0 0
7E0, 8 4 27 6 DB 93 0 0 0
7E8, 8 3 67 6 34 79 0 0 0
7DF, 8 2 3E 2 0 0 0 0 0


ID: 7E0, Data: 82 27 5 0 0 0 0 0 2010 challenger
ID: 7E8, Data: 84 67 5 7F 30 0 0 0
ID: 7E0, Data: 84 27 6 2D D3 0 0 0
ID: 7E8, Data: 83 67 6 34 30 0 0 0
ID: 7DF, Data: 82 3E 2 0 0 0 0 0

7E0 8 2 27 5 0 0 0 0 0
7E8 8 4 67 5 D F6 0 0 0
7E0 8 4 27 6 E9 4 0 0 0
7E8 8 3 67 6 34 F6 0 0 0
7DF 8 2 3E 2 0 0 0 0 0


7E0 8 2 27 5 0 0 0 0 0 2010 challenger
7E8 8 4 67 5 57 C3 0 0 0
7E0 8 4 27 6 87 14 0 0 0
7E8 8 3 67 6 34 C3 0 0 0
7DF 8 2 3E 2 0 0 0 0 0


<7E0,82,27,5,0,0,0,0,0,> 2009 charger
<7E8,84,67,5,F0,BB,0,0,0,>
<7E0,84,27,6,81,63,0,0,0,>
<7E8,83,67,6,34,BB,0,0,0,>
<7DF,82,3E,2,0,0,0,0,0,>

<7E0,82,27,5,0,0,0,0,0,> 2010 challenger
<7E8,84,67,5,B7,AE,0,0,0,>
<7E0,84,27,6,23,BF,0,0,0,>
<7E8,83,67,6,34,AE,0,0,0,>
<7DF,82,3E,2,0,0,0,0,0,>



<7E0,82,27,5,0,0,0,0,0,> ram
<7E8,84,67,5,4B,B3,0,0,0,>
<7E0,84,27,6,FB,E9,0,0,0,>
<7E8,83,67,6,34,B3,0,0,0,>
<7DF,82,3E,2,0,0,0,0,0,>



<7E8,82,50,85,0,0,0,0,0,> challenger
<7E0,82,27,5,0,0,0,0,0,>
<7E8,84,67,5,B7,AE,0,0,0,>
<7E0,84,27,6,23,BF,0,0,0,>
<7E8,83,67,6,34,AE,0,0,0,>
<7DF,82,3E,2,0,0,0,0,0,>
<7E0,810,8,34,80,0,0,0,0,>

<7E8,82,50,85,0,0,0,0,0,> charger
<7E0,82,27,5,0,0,0,0,0,>
<7E8,84,67,5,F0,BB,0,0,0,>
<7E0,84,27,6,81,63,0,0,0,>
<7E8,83,67,6,34,BB,0,0,0,>
<7DF,82,3E,2,0,0,0,0,0,>

<7E8,82,50,85,0,0,0,0,0,> 2008 aspen
<7E0,82,27,5,0,0,0,0,0,>
<7E8,84,67,5,C7,44,0,0,0,>
<7E0,84,27,6,F5,2A,0,0,0,>
<7E8,83,67,6,34,44,0,0,0,>
<7DF,82,3E,2,0,0,0,0,0,>
<7E0,810,8,34,80,0,0,0,0,>


TX: 27 01 28 <- Request EEPROM access
RX: 67 01 F8 2C 8C <- Seed=0xF82C
TX: 27 02 B6 98 77 <- Key=0xB698
RX: 67 02 69 <- Key accepted


TX: 27 05 CS <- Request Flash access
RX: 67 05 41 55 CS <- Seed=0x4155
TX: 27 06 59 29 CS <- Key=0x5929
RX: 67 06 CS <- Key accepted

I believe most reverse engineer from Chrysler factory software.
You'll need to start understanding how to pull apart java files and windows exe files to go further into it!

kur4o wrote:rtf have the benefit of color encoding send/recieve data, so you don`t need to guess.

I think you made major discovery why tazzi test pcm always send 2 byte seed starting with zero.

Pcm needs to see mode 31 A0 requested before seed request.

Since we got it working now I made little test script, to confirm some stuff.

The goal is to make pcm enter high speed so tazzi can test the harware. If we can`t make pcm goes to high speed, we can use mdi set it to high speed and made a loop to send some data each 0.5 seconds. So some scope can be hooked and testing can be done.

To use the script

COnnect with mdi, click "upload script" button and select the script text file that is attached.

I noticed that you add the crc byte when you send messages, taken from the elm log. There is no need and it may bog the message.

So you just send only

64 10 F1 31 A0 00 D8 01 00
or
64 10 F1 27 01

Thank you, still a logger error. I am not complaining, great work. Just feedback as I have time.

That was using the last .txt script you posted. I did also use the last .xdf too. I could easily be screwing it up

Just for memory purposes, reminder I am using a y cable to capture data, which I hope mdi can do.

Hmmm... Kuro, might need to gave the MDI disable trying to send PWM IFR (Inter frame response). Since MDI might actually try inject an IFR while monitoring since I believe its on by default?

Tazzi wrote:I believe most reverse engineer from Chrysler factory software.
You'll need to start understanding how to pull apart java files and windows exe files to go further into it!

Tazzi - Thank you for your input ! Do you think algorithm can be reversed from Flash file itself ? All Flash files would have this same piece of code .