Pages: 1 ... 5 6 [7]
Author Topic: Disassembling MED/EDC17  (Read 74975 times)
fragolas
Jr. Member
**

Karma: +16/-0
Offline Offline

Posts: 39


« Reply #90 on: January 28, 2024, 01:33:56 PM »

i have tried bindiff with ida pro, unfortunately it does not transfer variable names from bin_a to Bin_b. it seems to be a bug that has not yet been solved since version 7 of bindiff. this mainly concerns users that want to reverse me7, since guidra does not support c167.
Logged
prj
Hero Member
*****

Karma: +914/-424
Offline Offline

Posts: 5825


« Reply #91 on: January 28, 2024, 02:58:55 PM »

dismissing writing a tool to automate it basically and suggesting that you might as well use a plugin instead, he's just being cranky

There's nothing being automated, that's the thing.
In the time he wrote those python scripts he could have loaded the bin in ida 20 times.

Automation is detecting the code areas, detecting the global variables.
Not putting a bunch of hardcoded addresses into a .py file.

You guys are pretty spoiled by MED9.1 and Simos18 where everything is the same.
Same flash layout, same globals, same everything.

Try doing that on a slightly larger scale, between different vehicle manufacturers...
You will end up anyway loading the binaries in IDA to find the globals, to find the flash layout etc. And at that point you can just run bindiff directly.

Around MED17/EDC17 is where the Bosch ECU's got all very different, the current approach here is not any better than running bindiff directly from ida pro or Ghidra.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
elias
Full Member
***

Karma: +17/-3
Offline Offline

Posts: 59


« Reply #92 on: March 30, 2024, 02:31:28 PM »

Quote
In the time he wrote those python scripts he could have loaded the bin in ida 20 times.
If i would know that its possible with IDA-Pro at that time, i would have done that.

Quote
Automation is detecting the code areas, detecting the global variables.
What do you mean by global vars? What kind of variables do you consider "global"?
Do you mean registers?

Detecting registers on MED9 is pretty straight forward, as you just have to disassemble the whole file and then search the asm output for something like "lis R2, <address>". It should be similar in Tricore arch. You just have to figure out more registers like A1, A10 etc..

Detecting Code-Areas is more complicated, but i suspect you can use some Bosch-Signatures on that.


Quote
Try doing that on a slightly larger scale, between different vehicle manufacturers...
Really not my goal as i am working in my free time.



Quote
the current approach here is not any better than running bindiff directly from ida pro or Ghidra.

At least in Ghidra there is no option for transfering detected vars from one project to another. You have to run your own scripts. Havent tried this yet in IDA Pro.
Logged
prj
Hero Member
*****

Karma: +914/-424
Offline Offline

Posts: 5825


« Reply #93 on: March 30, 2024, 03:47:17 PM »

What do you mean by global vars? What kind of variables do you consider "global"?
Do you mean registers?
They are universally called globals. On PPC it's usually R2, R13, R14, R15. On ISA just R2 and R13 most of the time. It's up to the compiler where it assigns them.
Quote
Detecting registers on MED9 is pretty straight forward, as you just have to disassemble the whole file and then search the asm output for something like "lis R2, <address>". It should be similar in Tricore arch. You just have to figure out more registers like A1, A10 etc..
But you did not do it. You just hardcoded values.
Quote
Detecting Code-Areas is more complicated, but i suspect you can use some Bosch-Signatures on that.
And what happens if you try a non-bosch ECU?
The real answer is statistical analysis. Run an analysis of most used opcodes and you can do a frequency table based on certain bytes that will give you a pretty good idea.
It's not trivial, but doable.
Quote
Really not my goal as i am working in my free time.
There is a certain pattern I see. You post things on github that have no real value, and then you make a hype post on the forum about it.
I don't understand the reasoning behind it.

Don't get me wrong, it's always good if people work on stuff and share. But "oversharing" stuff that nobody has any use for also does not have a point.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
elias
Full Member
***

Karma: +17/-3
Offline Offline

Posts: 59


« Reply #94 on: March 30, 2024, 04:22:32 PM »

Quote
They are universally called globals. On PPC it's usually R2, R13, R14, R15. On ISA just R2 and R13 most of the time. It's up to the compiler where it assigns them.
I was thinking that its behaviour of the compiler and there is no real name to this. Thanks for clarifying

Quote
But you did not do it. You just hardcoded values.
Yes i did, and i admit it. I am too lazy to write that script. On VAG MED91 the globals are always same, so i had no need to find them.

Quote
The real answer is statistical analysis. Run an analysis of most used opcodes and you can do a frequency table based on certain bytes that will give you a pretty good idea.
Great idea, but for now i stick to bindiff as its giving me the results which i want. Usually its enough to do a so called "A2L Transfer" from Bin A to Bin B.


Quote
There is a certain pattern I see. You post things on github that have no real value, and then you make a hype post on the forum about it.
I don't understand the reasoning behind it.
Your right, that should end. Reason is, that i try to resolve a Problem which i have and do it in a way that can benefit others. I would like to make things that matter to people, but unfortunately nobody cares about MED91 (anymore). Do you have a idea where i should move to? I dont see much demand in any of the work which i have done.







Logged
prj
Hero Member
*****

Karma: +914/-424
Offline Offline

Posts: 5825


« Reply #95 on: March 31, 2024, 03:08:25 AM »

Your right, that should end. Reason is, that i try to resolve a Problem which i have and do it in a way that can benefit others. I would like to make things that matter to people, but unfortunately nobody cares about MED91 (anymore). Do you have a idea where i should move to? I dont see much demand in any of the work which i have done.
You can always do as little or as much as you want - you don't owe anyone anything.

My remark was more towards the quality of stuff posted. If you make something super specific that is useful in one tiny use case, then it's not going to be very useful for anyone.
There's not really any point posting up code that solves some super specific task, which no one except you most likely has need for.

For example:
For VAG MED9.1 almost every hex/a2l is available in a large damos pack that got leaked.
9.1.1 and others is a different story, but your stuff does not work for it, because it's just a bunch of hardcoded values.
Your topics mostly just say "MED9", which is kinda misleading.

Then we get back to the fact bindiff/symbols in the first place are useful only for those of us who actually modify code.
Everyone else uses WinOLS to quickly transfer the needed maps and be done with it, because that doesn't require a comp-sci background to be successful.
And logging wise my product solves the issue, and again does not require a degree to use. Hell, even those who are perfectly capable of writing similar software use it, because there is zero point in reinventing the wheel.

So if you ask - what to do that is beneficial for others, then the answer is mostly not "some kind of python contraption that requires a degree to use", when there's alternative solutions already available for free or for a small fee.
Doing things that are really beneficial require a significant amount of time, at which point it becomes a full time job. Because for it to be beneficial it has to cover 90% of cases, not a single narrow 1% use case, and the devil is always in the details.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
jcsbanks
Full Member
***

Karma: +17/-3
Offline Offline

Posts: 126


« Reply #96 on: April 01, 2024, 04:37:12 AM »

Do you have a idea where i should move to? I dont see much demand in any of the work which i have done.

Are you wanting to make a career out of work related to disassembling ECU code? I did and left a career in medicine to do it full time, and still (mostly) love it, it started from a hobby and many things I experimented with over 18 years of doing it have ended up monetized. Mostly the challenges for me were to give people what they want, better than the alternatives so they want to pay you, in a way you can support and enjoy, like any business.
Logged
prj
Hero Member
*****

Karma: +914/-424
Offline Offline

Posts: 5825


« Reply #97 on: April 01, 2024, 05:09:11 AM »

I also left my fulltime software development job to do this. Learned calibration, ICE theory and practice etc. Built up a successful company. Then at some point quit the day-to-day tuner job.
Went back to developing software, but this time for automotive, because there was a niche in the market for datalogging, which I now filled.

John actually has a very valid point here.
Are you looking to make this stuff a full time job?
Logged

PM's will not be answered, so don't even try.
Log your car properly.
elias
Full Member
***

Karma: +17/-3
Offline Offline

Posts: 59


« Reply #98 on: April 02, 2024, 04:12:36 AM »

Quote
Are you looking to make this stuff a full time job?
No, not at all. At least for now, i am really settled with my fulltime job and work on the ecu projects in my free time. I am just wondering if i can make a few bucks on the side writing ECU-code. Reselling Other people work is something which i try to avoid, so the classic "file reseller"-career is not for me. I am more interessted in more complicated and sophisticated stuff.
Logged
Pages: 1 ... 5 6 [7]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 2.547 seconds with 17 queries. (Pretty URLs adds 0.04s, 0q)