[hassmaschine]

Originally Posted by Terraphantm

How were you trying to implement the bypass Chris? There's probably at least a hundred ways it could be done, but if your way didn't work, maybe try this one:

I didn't even see this post - but yes, after looking through the code some more, that's basically what I did. I'm not sure, but I think anything > 0 will work, but I just set it to 0 for now.

it looks like what that code does is load the RSA key pointer (0x20 on MSV70 for 1024 bits), and at that branch condition it compares it to 0x20 (and it would also match if it were 0x10 for the 512bit keys). If it matches, it goes to the right which is the actual RSA key verification.

Assuming r3 = 0 is what I want, then I don't see why it wouldn't work.

I don't think the MS45 way works on MSV70 because r3 wasn't neccesarily being set to 0 (or whatever it is that it needs to be on MS45). So even though it was skipping the RSA check, it was still failing security authorization..

[hassmaschine]

Originally Posted by rjahl

Great work, if you got s coding error it will still run. Ask my how I know. I used the wrong 0da file as a donor once before.

Maybe I just forgot to reboot it, but when I pulled a RAM dump it was all set to 0, and I don't think it would talk to INPA - it was late though, and I was tired, so I decided to stop and try something new.

[rjahl]

Are you using winfkp for both the program and calibration file? Or did you use a BDM for the program?

[hassmaschine]

BDM for now - I think the patch I sent you worked (that's the one I got the coding/version error on), but again, you can't really change that via OBD. So instead, I need something that modifies the boot sector where we can actually write to it.

[rjahl]

Originally Posted by hassmaschine

BDM for now - I think the patch I sent you worked (that's the one I got the coding/version error on), but again, you can't really change that via OBD. So instead, I need something that modifies the boot sector where we can actually write to it.

OK, SO I cut Pin 7 and 8 on my cable and it made zero difference on the flash speed. I could set up fast Baud Rate without a communication error however flashing a custom file but it still took 4 minutes.

I did about 4 flashes and for some reason one took 8 minutes. No idea why. Could be battery voltage but I'm testing for speed without a charger. Battery is close to three years old and not too good but I don't think that is the problem.

Of course a 4 minute flash without removing the DME is not really that bad. one could call us "picky"

[Terraphantm]

What kind of cable do you have?

[rjahl]

Originally Posted by Terraphantm

What kind of cable do you have?

Frankly I don't remember. I bought on eBay like four years ago. Never had any driver or latency issues so I've stuck with it

Edit: this is the Same cable I use to bench flash an 0PA file in 45 seconds.

[Taskmaster]

Originally Posted by rjahl

Frankly I don't remember. I bought on eBay like four years ago. Never had any driver or latency issues so I've stuck with it

Edit: this is the Same cable I use to bench flash an 0PA file in 45 seconds.

I have one of those too.

[hassmaschine]

I'm using a dcan cable with the green pcb.. 0da writes are definitely under a minute.

Well, modified 0da writes are working with the new patch, but the modified 0pa failed with the key references changed. Going to try one more time, and then work on some other ideas.

[rjahl]

Originally Posted by hassmaschine

I'm using a dcan cable with the green pcb.. 0da writes are definitely under a minute.

Well, modified 0da writes are working with the new patch, but the modified 0pa failed with the key references changed. Going to try one more time, and then work on some other ideas.

Are your write speeds in the car or on the bench?

I have few ideas to help but I'm done for the evening.

Edit: are you using my tool to create the 0da files?

[hassmaschine]

Bench. Dont want to do a car test until i have it working 100%.

I have the same cable as you BTW. The label is even peeling off just like that.

Trying the 0pa at normal speed. If that doesnt work, i might need to make up my own segments, its still looking for 5 in the code even if the header only says there are two..

[Terraphantm]

Originally Posted by hassmaschine

Bench. Dont want to do a car test until i have it working 100%.

I have the same cable as you BTW. The label is even peeling off just like that.

Trying the 0pa at normal speed. If that doesnt work, i might need to make up my own segments, its still looking for 5 in the code even if the header only says there are two..

Did you zero out the other addresses and lengths? Despite what it looks like, the number of segments and the locations of the pointers are hard coded.

Also, I found myself an MSV70 for $30 on eBay, so soon I'll be able to get in on some of the fun

[hassmaschine]

Yeah. I think my mistake was changing the number of segments. Made a new file with it set to 5.

Good thing is its way easier to modify that than go through the hell of recalculating the boot sector checksums fo the smallest tweak..

[Terraphantm]

Originally Posted by hassmaschine

Yeah. I think my mistake was changing the number of segments. Made a new file with it set to 5.

Good thing is its way easier to modify that than go through the hell of recalculating the boot sector checksums fo the smallest tweak..

Having fewer segments should work okay, as long as the extra ones are zero'd out (particularly the lengths). Can you post what you changed the pointers to?

[hassmaschine]

yeah it does reference the # of segments - anyway, after I gave up and went to bed, a light went on in my head..

in the program segments, they are referenced by their memory locations like they are in the file - ie 0x80000 - except for the MPC563 internal flash which is 0x400000.

But the data segments are referenced by their internal memory locations, which are all offset by 0x400000 - so 0x840000, 0x85EAFF, etc.

When I copied them over, I left them as internal memory references, rather than external file references, and I think that's why it's failing - because it's looking in the wrong locations..

All I have to do is change it from (00840000 - 008400FF, 00840240 - 0085EAFF) to (00040000 - 000400FF, 00040240 - 0005EAFF).

[rjahl]

Originally Posted by hassmaschine

yeah it does reference the # of segments - anyway, after I gave up and went to bed, a light went on in my head..

in the program segments, they are referenced by their memory locations like they are in the file - ie 0x80000 - except for the MPC563 internal flash which is 0x400000.

But the data segments are referenced by their internal memory locations, which are all offset by 0x400000 - so 0x840000, 0x85EAFF, etc.

When I copied them over, I left them as internal memory references, rather than external file references, and I think that's why it's failing - because it's looking in the wrong locations..

All I have to do is change it from (00840000 - 008400FF, 00840240 - 0085EAFF) to (00040000 - 000400FF, 00040240 - 0005EAFF).

That makes sense, It's what I've been assuming when trying to analyze what my tool is doing.

[Terraphantm]

Originally Posted by hassmaschine

All I have to do is change it from (00840000 - 008400FF, 00840240 - 0085EAFF) to (00040000 - 000400FF, 00040240 - 0005EAFF).

I was wondering about that, but I feel like either way should work; I would think the memory map is setup somewhere in boot 1.

When you're using WinKFP, are you using comfort mode or expert mode? With the MS45, I was using expert mode. I wonder if comfort mode erases both sections before starting the program write.

[hassmaschine]

Well, yes, but why else would they reference them differently if it doesn't matter? I think the program references are different because of the internal flash segment - if it didn't use the differing offsets, it could get confused with writing over parts of the external flash. And anyway, it definitely didn't work with them set to the internal memory references.

I'm using expert mode. I'm importing my custom files and selecting them manually. It doesn't look like it erases anything, after a flash fails I can reboot the DME and it will try again.

Actually, experimenting a bit I think it would be very difficult to brick the DME. I even powered it down in the middle of a flash to see what would happen. basically, unless you did it at the very moment it is copying the new boot code over the original boot code, you can't brick it. and 0da writes are extremely safe, you could probably write a file full of garbage and you could still get it to flash again.

[Terraphantm]

If you're using expert mode it shouldn't be an issue, maybe it is the memory map. Or there is an extra layer of protection somewhere. I was just thinking if the data section was erased before starting the program write, that would explain why an RSA check wouldn't work there (since you'd be hashing a bunch of FFs). But even if that was the case, that would only apply in comfort mode (and I'm not convinced that's the case anyway)

[hassmaschine]

ah. no I don't think it touches the data section at all unless you write an 0da. I also made sure I wrote a stock 0da file just to make sure the RSA hash would be right. I'm convinced it's my references that were wrong, either that or it's not going to work at all.

[rjahl]

Originally Posted by hassmaschine

ah. no I don't think it touches the data section at all unless you write an 0da. I also made sure I wrote a stock 0da file just to make sure the RSA hash would be right. I'm convinced it's my references that were wrong, either that or it's not going to work at all.

Every time I tried a full flash in comfert mode, it was two steps. First was the program and second was the calibration file. You actually get a confirmation request for the UIF write in the data space on the second step.

[Terraphantm]

I was just double checking my MS45 program RSA bypass, and my format is essentially equivalent to what I posted earlier:

00000002 00840000 008400FF 00840240 0085EAFF 00000000 00000000 00000000 00000000 00000000 00000000 00000100 0001E8C0 00000000 00000000 00000000

So I would try just using the internal addressing scheme instead of the 008xxxxx, but if that doesn't work, there's probably something else going on.