pcmhacking.net

Gatecrasher wrote:

bubba2533 wrote: Did I miss something? I'm not sure what this is referring to? If you have more insights I'm happy to learn more.

My comment about the VIN change tool yesterday morning.

correct, sorry about that

Ah, ok that makes sense.

After staring at the Ghidra disassembly for awhile now I've already found 2 functions that return true and do nothing else. I'm quite surprised that the complier they were using didn't optimize those away. Not that important, but just an interesting observation.

I've found quite a lot of those.

Speaking of compilers, it looks like they made a major change in 2017. They enabled the VLE function. I had a ton of stuff that wouldn't disassemble until I figured that out. Ghidra still won't detect it automatically, and it gives me an error when I try to set the VLE register for that huge block of code. So now I'm having to hunt through it manually. This is gonna suck.

Gatecrasher wrote:I've found quite a lot of those.

Speaking of compilers, it looks like they made a major change in 2017. They enabled the VLE function. I had a ton of stuff that wouldn't disassemble until I figured that out. Ghidra still won't detect it automatically, and it gives me an error when I try to set the VLE register for that huge block of code. So now I'm having to hunt through it manually. This is gonna suck.

I just recently managed to get a full disassembly for a e92a. It uses mixed vle and non vle code.
Newer stuff is only vle and easier to make it, but mixed mode was real nightmare to figure. Only managed to make it work with IDA 7.7 version.

Need to do some clean fresh one, so it can be used for template.

If one of us can figure out a Ghidra script to walk through the function tables for the different diagnostic modes, I think that could automated a big chunk of this. In the OS I'm looking at, there's 1252 PIDs, and each one has a lookup function in a nice linear table. There's similar lookup tables for all the different diagnostic modes, and all the mode 6 data. among other things. It'd save a lot of time if we can just figure out how to iterate through it.

Ok, so I'm not sure what I'm doing with Universal Patcher.

I downloaded latest from github (0.22.6.0) and I'm not seeing the same when following those steps.

The filters is not populated when loading that xml profile. I'm not sure if they are supposed to be or not.

It appears to be working (although I'm still getting the duplicate transmit messages). This is so much nicer than sending raw CAN messages :)

Try this.. to the right of the config and plus sign is a drop down menu. click the drop down and select LOOP_BACK and then click the plus sign to the left.

In the config box you should see LOOP_BACK = 1.. Change the 1 to a zero so it says LOOP_BACK = 0..

now go ahead and connect and see if that got rid of the duplicate messages..

You can add LOOP_BACK = 0 at configs dialog as ironduke stated.
Looking at the timestamps, it looks like an issue with the openport, like it sends back the request and reply at the same time.

We will need some debug log to filter it, the flags that are added to the duplicate message.

It could be a simple config too, that is supported by openport.

I tried LOOP_BACK = 0 and didn't see a difference. It might be in the openport then, which makes sense about the timestamps being the same.

Also, is there a way to see all the traffic on the Bus even when configured for ISO15765? I might be setting up the filtering wrong, but I've tried a bunch of different ways.