hello. some of you may remember my post about what exactly a disassebler is. i found out (by reading art of disassebly) that a disassembler takes machine code (1s and 0s) and converts it to assembly (mov add je... etc.) now my question is.... what exactly does a debugger(like softice) do, and how does the debugger work? secondly, (and probably the most stupid question ever posted on this board) why can't we convert assembly to c++ (i know compilers convert from c++ -> assembly. why then cant we reverse the process?)

enough stupid questions for today,
ftothe3

-- thanks for the help

debuger lets you trace the executed code. You can actually see how the program is behaving in a particular situation (jumps, register values) and change them as desire. everything goes in real time - pressing F10 in SI executes the next instruction, while in dead-listeing (the one disassemblers give you) all you can see is the program code, you have to decide yourself if a jump is taken, register values, ect...



ever heard of one way functions ? why it`s impossible to decompose concrete back to water & cement ?
heard of a physics law about all systems spontaneously moving to the lowest energy level ? or maybe going backwards in time ? some things are simply irreversable

hmmm, theoreticaly it is possible to write a spohisticated piece of shit to produce a compilable source code out of a simple binary, noone has appeared to be _so_ crazy to do that so far

finaly u can always start reversing yourself, everything is possible in this case

Question 2

http://www.woodmann.net/forum/showthread.php?s=&threadid=2576&highlight=decompiler


Question 1

A debugger looks at a program while it is running. The variables hold real life values, the conditional jumps happen or not based on actual, real-time conditions, the loops go round and round as many times as a loop go round.
A debugger performs an exploratory surgery on a living program, a dissasembly is more like an autopsy.

thanks for the replies, ok the difference between debuggers and disassemblers is crystal clear to me.
but..... in naides's link to the other thread...


that doesnt make sense to me. Right now, i know vb and c++ and a little bit of assembly. for me, it is VERY hard to read through assembly and a LOT easier to read through c++ (isn't that why we dont just code in assembly, why we invent high level languages like c++?!) so then why do you say decompiliers provide little advantage?

don't worry, you're not in the wrong. i don't know what naides was thinking, other than "i can read asm as easily as c++". if that's the case though, then i guess his statement makes sense. in general, though, it's much "easier" (define "easier" however you like) to work with higher level languages than lower level.

so then r4g3 is right?
asm --> c++ is impossible .... just because!

I think, it is possible, less or more. Every compiler produce his own patterns, while building a code. If somebody might want to code asm to C convertor (?),
he definetely will have to find out all those patterns (C#, C++, Delphi, etc., etc.) and put in to the code. Other question, is it necessary? For RCE - it isn't I think, because, anyway, most protection routines are coded in asm, and therefore it is impossible to produce any C code from them. About reading the asm code- some years, and you will read it without problems .
Neviens.

Not really... just a huge hassle... take a look at the asm2pas thingy at dafixers dede page... but that's pretty much as good as it gets... basicly it just reformats the asm code so it looks like pascalish code...

as i said this i ment u can always rewrtite asm code back to c. the only question is how much time it would take for ya.
for one way functions: maybe there exist/will be discovered a sophisticated/very expensive method for concrete -> water + cement
someone one day just might get really pissed of a 0 from math exam and solve the DLP ....

I propose an experiment:

Write a simple program in C.
Should contain at least one function call and use pointers.

Compile it with one of the old Borland C compilers, then find, if you are lucky, the right Borland decompiler.

Now look at the source code and the decompiled code and you will see that the decompilation is quite less what one would expect.
The decompiled code is spagetti code mess, and you can hardly recognize any of the structures and functions you used in the original code.

Now think about a complex C++ with objects, ad hoc in-line functions etc etc, and you will get the picture. You will see that you stand a better chance of RE the code at the ASM level, instead of sifting through non-documented and fragmentary C-like code.

Dissasemblers are universal, decompilers are compiler specific.

If the coder used imported libraries and classes, which the rule in VC, Borland C and Delphi, you are out of luck!!!
They won't reverse into any remotely understandable C-like code, and more than likely most of the code will remain in ASM format.

Taht is what I meant when I said that RCE tinkering is better achieved using ASM.

Getting C like code that make sense out of an exe or a .dll file is an unrealistic expectation.

Very true, I recently used a VB3 decompiler to find out how it talked to a dongle and to emulate such dongle. Even though it did a good job of decompiling it, it was a complete nightmare to go through and I would have much preferred the ASM code instead, had the app not been compiled to P-Code. I suppose what added to the nightmare is that the dongle was tightly integrated into the app - not just a simple "is dongle there" but the dongle decided what data was displayed at what points, and in what formats. Changing a single byte in the dongle, for example, changed the entire program from English to German.

ftothe3 writes:


... opcodes (hex) -> asm representive

wow! this discussion exploded since ive last been here (i havnt been able to get on the board its been down for me) anyways, yea takes 1s and 0s to hex then gets opcodes i know what dissassembler does! anyway i understnad now that decompliers are hopeless and will neverexist (for now atleast) i just have so much trouble reading assembly (maybe im dyslexic) thanks for the input people. hope someday ill get better at assembly

Hum Asm -> c++ is possible, it would just require aloth of work

The main issue with ASM to C++ is that you must you must take in consideration all the compiler and all compiler optimisation.

There is a plugins for IDA pro named Desquirr that try to revert the asm code of a function into "C like" code...

A other reason is that most ppl that could write the software to do ASM to C++ could probably read ASM code better than C++ code so they have no real use of doing it

Anyway if ASM to C++ would be possible, they would probably start making some new laws to throw reverse engeneer into jail

Well, there is no reason a person couldn't make an Assembly -> C++ compiler. The only problem thus far is the logic required to do so. and for the record you can take concrete and separate it back out into it's parts, it just takes much more effort than it's worth. The problem with it is that C++ is much more dynamic than Assembly, allowing a person to complete more complex tasks in fewer lines of code. So, the challenge to making a Assm -> C++ converter would require that it do pattern matching to take the multiple lines of assembly and put them into one C++ command. Also there are a few things you can do in Assm that C++ just wouldn't like so you would have to handle that as well. Then you would have to do optimization on the code you created to make it at least somewhat readable. It's not something that can't be done, but for the work it would take and the problems it would create, I think it's just generally accepted as not worth while.

Hmmm.... Decompilers are surely not a dream: they do not exist just because money involved in not worth the time to spend to do some. Even only basic compiler techniques can bring outstanding results in the filed.

Also, if you don't trust me, have a look to REC - fully working C decompiler. Or just look at hxxp://boomerang.sourceforge.net for a better explanation of these topics .

Byez,
Polaris

Just a confirmation Polaris...

Have you sold to and re-packaged the product as LANTERN? (It comes for $190, I believe)

If so, good to know you've become rich

Have Phun

INQUISITION was sold in mid-october to a company which is not the one that produces lantern (sorry (for me) no real richness, just some cash...). I was told that INQUISITION was to be heavily specialized to deal with only one compiler to solve a single (but big, if it required automation) source code recovery...

However, I really don't know if it was reselled/adapted/more... I can't judge by the shots. Anybody has tried it?

Byez,

Polaris