i can decompile and diassemble code with ollydbg
and see functions
but i cant analize it in my mind
which instrction is case,repeat,.....
i cant write pascal code from diassembly code
any body have a way for analize and realization this codes
can i find book for this qustion?
thanks

I'm new here, but I expect they are going to advice you to write and compile small applications and open these in your debugger/dissambler of choice.

As Hutch, so rightly pointed out:

---------------- snip -------------------------

Once you assemble a simple program of this type, immediately dis-assemble
it and have a look at your program as it has been converted from binary back
to code again. This will train your eye into the relationship between your
written code and the results of dis-assembly.

This will help to develop the skill to dis-assemble programs and read them
when you don't have the source code. Once you start on the mountain of DOS
com files available, you will find that much of the code is very similar to
what you have written yourself and you get to see an enormous quantity of
well written code that you can learn from without having to pay one brass
razoo for the privilege.

Some people are slightly bemused by the +ORC's reference to Zen yet if it is
understood in the sense that the human brain processes data at a rate that
makes fast computer processors look like snails racing down a garden bed,
you will start to get the idea of "feeling" the code rather than just
munching through it like a computer does.

As you read and write more code your brain will start "pattern matching"
other bits of code that you have already digested and larger blocks of
code will start to become very clear.

Once you go past a particular threshold, the process of "data mapping" and
"model fitting" starts to occur. This is where you know enough to project
a model of what is happening and then test it to see if it work the way
you have modelled it. The rest is just practice and a willingness to keep
learning.

------------------ snip -------------------------

Have Phun

http://programmedlessons.org/AssemblyTutorial/
start there.

BanMe, I don't think pointing him to a MIPS tutorial is ideal :\

As an extension to this, what kind of practice techniques should one use to reach Zen? I will often catch myself falling back into the instruction by instruction way of reading code especially when I am looking at a construct that isn't familiar to me.

Lol@my haste and my need to please..>.<

I couldn't find a 'similar' style to 'programmed~lessons' for x86..though I would enjoy it greatly if someone 'could'..

I tried googling 'programmed lessons XP masm'

good stuph
http://www.freebyte.com/programming/assembler/
http://jimweller.com/jim-weller/jim/vc98asmqs/vc98asmqs.pdf

this is a good reference.
http://en.wikibooks.org/wiki/X86_Assembly...

ZEN is not something that can be quantified as it is a ever 'moving' subject, it can only be attained with thorough analysis and the ability to see the 'big' picture without ever seeing the whole picture..It's having a idea on how things are done, and running numerous tests to see if the 'idea' was correct. If it was correct, then how can it be used to accomplish the goal you have in mind..I am still a student..and I have 'very much to learn'.

kindest regards
[signature]

I keep 2 books close at hand when I am reversing. One is the Win32 Programming API Bible and the other is the MASM programmer's reference, which has a handy ASCII chart as well (yes...I actually bought MASM at one time).

Of course, it is vital to download the Intel Assembly reference literature, which explains in detail how Assembly works, both as software and hardware. Iczelion's assembly tutes, or equivalent, help as well. Stay away from a book by Horowitz titled (I think), The Art of Assembly. He has managed to confuse the language completely.

Each time I encounter an Assembly instruction I'm not sure about, I look it up. If you take a piece of code, and dissect it one instruction at a time, you'll soon get used to what is going on. Of course, the compliler adds code at the beginning of sections that doesn't make a lot of sense till you understand what it is doing. After a while, you can just ignore the first few steps of code and get right into what is going on.

It is vital to understand how functions are called in the C based language and how parameters are pushed onto the stack, and retrieved by the RET instruction. You can read about that almost anywhere on the Net. Also, there are various jump and call functions with many different formats.

I think object-oriented programming is a curse on mankind. If you have been trained in that nonsense, without understanding there is actually real hardware it is hiding, you will be lost in understand Assembly. Assembly is related to hardware, not some abstraction like a container or an object. Go to the Intel site and find their excellent volumes on the Assembly language. Those manuals will help you understand how Assembly relates to a REAL processor.

If you want to really understand Assembly you MUST learn how a processor works. You MUST understand registers, interrupts, busses, memory, etc. Processors run on machine language, which is codes developed from 1's and 0's. In a processor, the 1's and 0's are voltages and that's all a processor can understand.

Machine language is essentially binary, but it is easier to understand binary string using hexadecimal. Each hexadecimal code represents an instruction in a processor and Assembler is nothing more than a collection of hexadecimal instructions. For each instruction like JMP, ADD, RET, etc., there is an equivalent hexadecimal code.

A big mistake made by people using a debugger or a disassembler is leaving the code turned off. In IDA, for example, the code can be turned on so that you can see the Assembly code for each instruction. I don't know how Olly works, but with softice, you can turn the codes on and off.

check out "IDA PRO Palace", they have good samples of what the different types of functions looks like in assembly.