NefMoto

Hello,

I'm trying to figure out how to gain security access on an ME7.1.1 (MK4 VR6).  I can use ReadMemoryByAddress without security access on ME7.5. 

In an ME7Logger trace I can see that it tries to start a diagnostic session but gets an invalid response (7F).  It then re-tries with security access (0x27 0x01), calculates the key and re-transmits.  It gets a positive response and then connects with a diagnostic session again.

My question is: how can I gain security access for ReadMemoryByAddress, either with 0x01 or 0x03?  I thought that 0x03 was for read only access (which is what I need).

What is the calc for the key?

A lot of stuff on VAG was key = seed + constant.
If it's not, then you're gonna have to reverse the $27 service handler and find out what the algo is.
The explanation of the service table and how to find it can be found in my KWP2000 logging repo.

Different security access is for different services and sessions, I have no clue where you got that 0x03 is some "read only access", that's BS.

Also, for me development session on Mk4 VR6 worked without any security access.
When you connect to the ECU you are already in a diagnostic session. The default session.
You're gonna have to be a ton more specific.

At some point in time you are going to have to start to use your brain, and not throw your hands up in the air, and lose your head the moment CTRL+C, CTRL+V stops working ;)

I'll go through your repo.

There was a thread (http://nefariousmotorsports.com/forum/index.php?topic=4983.0) that detailed security 01 & 03.  I'll dig out the protocol sheet that details it but I may be wrong.

I'll post up the trace from the scope when I get home but that ECU definitely issued a negative response when trying to diag session and then ME7Logger attempts with security login, after which it's successful the diagnostic session is successful.

I'm trying to work out if it's seed + constant or if it's something else.

It's for MED9. You have ME7.

So how do you know what specifics the ECU wants?  The application says that the second bit is manufacture specific.  On the assumption it's 0x27 0x01, what calculation is then done to the seed to get the correct key?  In that instance, what is the difference between 01 and 03?  I get one is MED9 and ME7 but I'd have thought there would have been similarities.

I can likely help myself here by taking the handful of traces and calculating the difference.

3 options:
1. OEM documentation
2. Reversing the comms stack
3. Trial and error.

My lack of brains means it's option 3.

Thanks as always.

I never did flashing or looked into it, so I have no idea if ME7 also has SA2 or not.
Could well be, then just grab an SA2 implementation (for example bri3d has one in his repo) and then use that.
There was also one in C posted.
Then grab the algo from an sgo.

Usually ECU's don't need SA2 to read memory though, at least the later ones.

Got Security Access to work fine, but getting a service not supported when attempting to ReadByMemoryAddress.  Looks like ME7Logger tries too, which fails.

Is there a way to enable the service?

Switch to the correct session. In which session are you trying it?

Security access was 03 with key 0x11223344?

Workaround for RMBA is DDLI ($2C), you can define up to 10 identifiers.
If you need to read more, you can clear, define, read. 3x slower if the identifiers can only hold 1 location.

Diagnostic session: 0x86.  So init, get SA, get timing, diag session, RMBA.

Next daft question, how do you know what the identifier is?  I mean, how can you convert a variable to an identifier? 

The dynamically definable identifiers are from F0 to F9 on Bosch KWP2000 ECU's.
For DDLI syntax look at KWP2000 service layer standard.

You did not answer which SA you used btw.
Also you have never posted the file either. Use my repo to see where the service lookup table is and see if the ECU even has $23.

You're asking for help but it's like using a crowbar to pry information from you.
Every single question I ask is relevant. You answer only some, not all and you do not provide the basic info.
So I'm about to give up here.

Using a BG 0004 for reference. 

I'm using SA Level 1.  I get a positive response when bitshifting:
  for (byte i = 0; i < 5; i++) {
    if ((seed & 0x80000000) == 0x80000000) {                 // can’t check the bit overflow / carry bit directly, but if the MSB is high then we can infer the next shift will set the carry bit
      seed = (seedData[63] ^ ((seed << 1) | (seed >> 31)));  // since C doesn’t have a rotate as such, OR the << and >> to make a rotate
    } else {
      seed = ((seed << 1) | (seed >> 31));
    }
  }

Where seedData[63] = 0x5FBD5DBD.  I'm struggling to get the ECU ID to calculate to this however.

I slow init, get a response, request security access (0x27 0x01), get the seed, calculate using the above and re-submit.  I then get a positive response and gain SA.

I then start a diagnostic session with:
    txBuf[0] = 0x03;  //Message Length
    txBuf[1] = 0x10;  //StartDiagnosticSession
    txBuf[2] = 0x86;  //Development Session
    txBuf[3] = 0x14;  // 10400 baud

Which is successful.  Attempting to RBMA fails (0x23...), as does write.  Hope that makes sense.

This is SA2 algo you are doing. Usually this is for flashing.

Have you tried requesting 03? Does it send you a seed?

Your ROM has completely standard services, just like every other one.
Doing SA2 normally places the ECU into the ROM service layer, and that indeed does not have support for any of those services.

So I think you need to do 03 instead of 01.
I have never looked at it in ME7, but on Bosch 01 is always SA2 for flashing in the later ECU's.

Okay, thank you for looking at that, it's appreciated.

I'm waiting on the timeout clearing and I'll try 03.  Will report back.

Btw there is no need to do 10 86 14.
Just do 10 86, because you connect at 10400 every time anyway.

Baud rate list is published in the KWP2000 logging thread.

Ive had no time to investigate it, but a kind soul suggested that the 3/4 algo might simply look for the string "SECURITY".

Thats the lv1 Algo and it's all there on GitHub in nef flasher code.

FR 9.1 translates 3/4 to :
"Security level 3/4 is used to switch to developer mode and also to replace the previous login (coding 2). The available range of values is halved for the applications."
KLOGIN and SLOGIN are mentioned in the same paragraph, I couldn't figure out what it was talking about.

Applying MED9 logic to ME7 is a mistake.
But SLOGIN is the one on newer ECU's.

Although on MED9 RAM reading is just completely open via $2C, there is no need to use any security.

Struggling to get security access for level 3.

Bear with me here: I can't read the STOCK flash with Nef either.  Service not available.  Confirmed it is an ori but wondering if that's why the service is disabled.

It's not documented (that I can find here) on how to actually disable RequestUpload / Read, but is that a possiblity?  That I'm just not able to use RBMA because the stock file has it disabled?

If that is the case, how would you go about re-enabling it?

The service is in the service table.
You need to be in a development session for RMBA.

I am unable to read the STOCK file (attached above) on the bench, but can write it fine.  Confirmed fully stock.  Was the same story with an R32 too: can write stock fine but cannot read: "RequestUpload may have been disabled by aftermarket engine software."

Found: "09 0A 0B 0C 0F" where I'd think you'd replace 0F with 00 to disable (but it's already enabled). 

I think this is why I'm unable to use the service RBMA.  How would it be disabled in flash, and how do I go about re-enabling it?

Sigh.

Did you switch to development session successfully?
10 86?

Use bootmode with galletto on the bench to avoid trouble like that!

I spent 2 days looking at stock 7.1.1 code for a c166 and it looks like some service masks are applied to the tables depending on security level. So the RBMA is deflected to the service not available. I'm totally useless with assembler so what I said might not be correct. I also had a look at seed/key algos  but had no idea of where the code goes for level 3/4 key check. Level 1 stands out like dogs balls because it has a few XOR commands and because I knew of it before I recognized it. The code is near checks for KLOGIN and many other logins (which is a bunch of numbers in the flash) which confused me even more.
Modding your flash might be the quickest way to go, but it will not be a universal logger if you do that.
The algo should be in the code I attached, hopefully your assembler skills are better than mine. Share if you decipher it!

Yes, I am able to get into developer mode. 10 86.

Well, I don't have a such ECU, so can't tell you what's up, but in your dump $23 is deffo present.
Feel free to reverse it and see where it gets hung up on...

How much do you charge to help? :)

I'm not for hire.

Add A05B to seed!

This is different for different ECU types. It's SLOGIN I believe.

I think it's possible to bypass the security access entirely by abusing $2C and $3B to write the correct value into the security access status byte in the ECU.
SLOGIN sets it to 0x11 nad KLOGIN sets it to 0x10.

After that it should be possible to just switch session. Working on that now for my logger.

It is called CW_SECURITY_ACCESS_1 in the 7.1.1 I looked at.
Gets you into 3/4 but still blocks RBMA.
This ecu also has 5/6

Yeah just tested. RMBA is still blocked, but you can change baudrate.
You can also bypass this one by setting a certain ram value to FF via write, then it thinks it's already authenticated.

Tbh, $2C and $3B work well enough, and this unlocks the speed switch into dev session, so I think it's enough.

So about $23:
Besides the two service tables (pointers and table with offset to pointer table), there's another small table that gets copied into RAM from the flash.
I did not reverse it fully, but basically it's a large bitfield where it is possible to enable/disable services, based on some logic.

The bitfields are found in the flash, near the service table, and are loaded based on which diagnostic service is started.
For 40mhz 1.8T ($23 blocked):
97 05 86 10 07 48 0E
03 04 80 00 FF 48 0E
97 05 87 10 FF 4F 0C - loaded for development session
97 05 8F 10 FF EF 0C

And for 32mhz 2.7T ($23 not blocked):
97 05 87 10 07 48 0E
03 04 80 00 FF 48 0E
97 05 8F 10 FF EF 0C - loaded for development session

The development permissions are different. The last one on 40mhz gets loaded from StartDiagnosticSession as well, but I did not reverse far enough as to which session needs to be requested for it.
Since it is in RAM, it is possible to just write to this directly to force enable the services, and override whatever in the flash, after that $23/$3D should work, I also didn't test it, but I think setting the 4F to EF is enough.

Note, the ECU I checked does not have level 5 security access. Only 1 and 3 are supported.

I can confirm that  changing 4F to EF in the RAM, after having entered development mode, does indeed unblock $3D for both  level 1 and 3. in the 022906032CE st10.

PRJ, you're an absolute legend.  Thank you!

I also implemented the $2C/$3B workaround into my logger now, but I did not bother unlocking the RAM functions. I just stumbled onto this while doing the reversing.
This is because the moment I am in development session I use a custom handler that I upload anyway, so makes no difference to me.

For security access, delay always gets reset to 0x12C after you enter a wrong key, on powerup, and every time you request the seed (300 seconds).
So to bypass it just read RAM, then re-request seed every time and search for 0x12C or 0x12B in extram 0x380000-0x381000. Once you find it, wait for 1 second, then read it again.
If the value is now 0x12B or 0x12A, then you found your location. Set it to zero and the timeout is gone...

When I was writing a logger for my car, (since me7logger did not work on the st10), I came across the locked services very early on. In desperation $2C/$3B was experimented with and found hat it did the job.The only issue I found is that writing more than a certain number of bytes(30 something?) bytes causes the byte "F1" to be written to the ram, so a few commands are needed for such operations.

Yes, around 30-32 is the limit after that it starts to write garbage.

Need to do a bit more digging but the BG file already has EF.  I'll have a play tonight.

Dump the IRAM and check that this is what is loaded into it.

Got it working!

97 05 87 10 07 48 0E   
03 04 80 00 FF 48 0E   
97 05 8F 10 FF EF 0C
97 05 8F 10 FF EF 0C

On 022 906 032 EG & BG.