NefMoto

Hi, people!  :)
This is question to anyone who succesfully dissasembled and identified maps with ida pro. I'm kinda stuck trying to identify PROKANAL bits @ 198xx. In my disassembled bin they show up as db xxx, where xxx is hex number same as winols. How do I start to identify all the CDxxx and CWxxx maps from the prokonal section? Could someone rundown a small tutorial on how to succesfully identify for example map at 18194?

Also, how do I rename segments? (seg009 - seg023 > 01 - 0F)

May be I got you wrong but you cant identify maps just by disassembling with Idapro,   you have to understand what the code does to identify maps, even then I have no clue how people identified all these maps unless you have some sort of OEM connections.

I think that in assembler language all maps should look similar in structure... Also that way you can see maps axes and if they're shared between few maps... But what I really need is to understand how to identify prokonal bits... they should be somehow referenced in DTC table since function that checks CDxxx maps also sets DTC's... or am I wrong? I can't not figure out how to start and where to start...

.

are there any decompilers for C166/7 out there?
If not, is it possible to translate C166 code in arm or x86 ASM code where decompilers exist?

Code in Me7 is written in C for sure.

No, they can't exist.
And it doesn't matter if it's written in C or not.

If you know how to reverse engineer things you will not ask these questions, you will not know what to do.
If you don't know how to reverse engineer things, there is a very high chance that:
a) You will take 5 or more years to learn
b) It is not in your mental capacity

I don't mean at all to offend. But the same way, that only the best can race in Formula 1, only the best coders can reverse engineer systems from machine code.
It just takes a special mind to see the patterns. I don't care how much you are willing to learn...

I've been doing this for 10 years and even when I know quite well what to do, the amount of time you need to sink into this to get anywhere in a white room environment is crazy.
Only the people who have an idea how this is done appreciate what for example Tony has went through... (I've picked apart 8 bit Motronic without any OEM data whatsoever, and this C166 stuff is harder).

Excuse the rambling.
TL;DR:
If you need to ask such questions, you will never get there, forget it.

I am 100% aware of the hard work to reverse, but I disagree with you in some points.

Of course decompilers do exist, as well as disassemblers get better and aid more and more.
for many tasks you don't have to analyse the image competely.

I reversed some 68k code in the later 80's, so I know at least some ideas of the techniques.

Really? I haven't seen a single one that can produce proper code.
It's like saying you can build an image out of a hash. No, you can try to find a collision, but not build the original image.
The only thing that can do some analysis is the hex rays plugin for x86 code, but even then that's just pseudocode.

And we are talking ASM to a higher level language here. We are not talking kids stuff like Java or Delphi.

ASM code is for sure not a kind of hash of a c source ;)

decompilers are not perfect and will never be, but they can help to compact the disassembled code for a much better overview and understanding.

Please show me a single ASM -> C decompiler, which provides code that can be compiled back into the same thing.
And I don't mean just quoting ASM instructions in C.

Saying this or that exists, does not make it true.

no they don't exist in your meaning.
but asm -> decompile -> compile will produce code that will run and work the same as the original.
so it cannot be compared with a hash.

Thank you.

but it has still nothing in common with the primay question and if decompilers help to reengineer ;)

from Reversing: Secrets of Reverse Engineering
Published by Wiley Publishing, Inc.

Native Code Decompilation: An Unsolvable Problem?

Compilation is a more or less well-defined task. A program source file is analyzed
and is checked for syntactic validity based on (hopefully) very strict
language specifications. From this high-level representation, the compiler generates
an intermediate representation of the source program that attempts to
classify exactly what the program does, in compiler-readable form. The program
is then analyzed and optimized to improve its efficiency as much as possible,
and it is then converted into the target platform’s assembly language. There
are rarely question marks with regard to what the program is trying to do
because the language specifications were built so that compilers can easily
read and “understand” the program source code.
This is the key difference between compilers and decompilers that often
makes decompilation a far more indefinite process. Decompilers read machine
language code as input, and such input can often be very difficult to analyze.
With certain higher-level representations such as Java bytecode or .NET MSIL
the task is far more manageable, because the input representation of the program
includes highly detailed information regarding the program, particularly
regarding the data it deals with (think of metadata in .NET). The real
challenge for decompilation is to accurately generate a high-level language
representation from native binaries such as IA-32 binaries where no explicit
information regarding program data (such as data structure definitions and
other data type information) is available.
There is often debate on whether this is even possible or not. Some have compared
the native decompilation process to an attempt to bring back the cow
from the hamburger or the eggs from the omelet. The argument is that highlevel
information is completely lost during the compilation process and that the
executable binary simply doesn’t contain the information that would be necessary
in order to bring back anything similar to the original source code.
The primary counterargument that decompiler writers use is that detailed
information regarding the program must be present in the executable—otherwise,
the processor wouldn’t be able to execute it. I believe that this is true, but
only up to a point. CPUs can perform quite a few operations without understanding
the exact details of the underlying data. This means that you don’t
really have a guarantee that every relevant detail regarding a source program is
bound to be present in the binary just because the processor can correctly execute
it. Some details are just irretrievably lost during the compilation process.
Still, this doesn’t make decompilation impossible, it simply makes it more difficult,
and it means that the result is always going to be somewhat limited.
It is important to point out that (assuming that the decompiler operates correctly)
the result is never going to be semantically incorrect. It would usually be
correct to the point where recompiling the decompiler-generated output
would produce a functionally identical version of the original program. The
problem with the generated high-level language code is that the code is almost
always going to be far less readable than the original program source code.
Besides the obvious limitations such as the lack of comments, variable names,
and so on. the generated code might lack certain details regarding the program,
such as accurate data structure declarations or accurate basic type identification.

Additionally, the decompiled output might be structured somewhat differently
from the original source code because of compiler optimizations. In this
chapter, I will demonstrate several limitations imposed on native code decompilers
by modern compilers and show how precious information is often eliminated
from executable binaries.

All this is very nice and fine, but the only thing that gets anywhere close to helping understand code in the *real world* is the hex-rays plugin for IDA Pro.
And in reality, most of the time for me it is easier to just read ASM.

You asked specifically if there are "decompilers" for C167/C166.
Answer is: "no", and there will not be any.

I asked you - do decompilers exist for any architecture to create C code from ASM that will compile back into ASM?
And I mean without basically using pretty much only ASM within the C code. I personally have never seen anything like this in the ten years or so that I have been disassembling stuff.

You are struggling to find one it seems as well. So what is the point of copy pasting a wall of text, which is completely useless for anything practical in here?
How much actual reverse engineering have you done and how much you have accomplished by doing this?
My personal background is reverse engineering x86 programs... and some time ago I started by reverse engineering most of the 8051 based Motronic.
And now moving to the C166/167 based on Motronic, as there is pretty much nothing left for me to do with the 8051 one after extracting more than 300hp/liter from it, adding launch control, NLS, switchable meth settings, hot film MAF etc...
It is nice such things have already been done and shared for the newer ECUs.

My point is - you need to learn to understand ASM and see patterns. There is no magic bullet for reverse engineering, and there never will be.
Any kind of things that an automatic decompiler could do, your mind can do better after you get used to seeing the patterns that compilers generate for certain expressions.

Seeing this, I feel that I have walked through many difficult paths. There are no shortcuts in learning, but methods and practice are very important. All efforts will be rewarded. I think everyone here is my teacher! thank you!