How to learn Assembly

I'm trying to learn hacking starting with assembler. Is Randy Hydes Art of Assembley a good way to go or should I go just with striaght MASM syntax? Also, in a general way, how is a checked version of Windows useful?

dcow

Can't believe this hasn't been locked yet, well actually it really does all depend on what you mean by the term 'hacking', do you want to learn how to take apart your system and secure it?

Well anyways... if you want to learn Assembly, the book AoA (Art of Assembly) is really the way to go, if you want to learn win32asm (programming windows applications in asm (assembly)), then check out hxxp:///win32assembly.online.fr/
The AoA can been found at (I recommend the 16bit version and not the 32bit version due to HLA):
hxxp://webster.cs.ucr.edu/

Originally Posted by Nilrem

I recommend the 16bit version and not the 32bit version due to HLA

I 2nd this. While the 16bit book was excellent, I don't know what the author was thinking with the 32bit book, using HLA. It really ruined what could have been an excellent sequel.

The 16bit book is very DOS-centric (obviously), but if you start getting confused, just ignore the INTs at first and pay attention to the general syntax/rules.

Regards,
Satyric0n

Originally Posted by Nilrem

Can't believe this hasn't been locked yet, well actually it really does all depend on what you mean by the term 'hacking', do you want to learn how to take apart your system and secure it?
/

I have two goals here. I come from a UNIX background rather than from the Windows world. I gained much of my success in this world as a sysadmin because I was willing to explore the system at the deepest level available to me. When Linux and its source came out I moved in that direction because I continued to have access to the deepest internals of the system.

Windows is clearly different. The excellent Solomon texts take you a good chunk of the way but they are necessarily limited as to the topics they cover. Understanding what software is doing in the Windows world appears to require looking at disassembled code segments and learning from this what the code is attempting to do. Debuggers, disassemblers, folk lore, and gnostic peerings into a system that is only exposed in that way is not optimum but it appears to be the only way in Windows.

We are a small shop and we are a mixed environment consisting of UNIX (HP-UX, RH AS 2.1 and 3.0 and Windows 2000 server) Because I don't know the Windows stuff well my troubleshooting skills are weak in that world. Frequently I wind up trying to determine where problems might be in a chain that include HP-UX, Oracle, Apache, Forms Server, TCF Framework, network, Windows 2K, IE Explores and Jinitiator. The last 3 pieces are on windows and I just don't know the techniques for getting inside the process and figuring out what happened. Why, for instance, does IE 6 work from a desktop and produce a very strange error when the same laptop is taken home and run through a proxy based security product. Moving backwards to IE 5 solves the problem, but again why????? If you don't know the OS and you can't trace things you will never know. That's just one example.

So by hacking I mean a) understanding of the OS and b) good skills for debug trace and fix.

I was hoping that a checked version of Windows was a compilation of the system with debugging turned on.

Originally Posted by Satyric0n

I 2nd this. While the 16bit book was excellent, I don't know what the author was thinking with the 32bit book, using HLA. It really ruined what could have been an excellent sequel.
Satyric0n

I have the Irvine book for MASM syntax and issuses. I was thinking that the HLA stuff would minimize the scut and maximize the amount of technique I could absorb.

Thanks for the reply.
dcow

http://spiff.tripnet.se/~iczelion/

Plenty of asm tuts.

[ibro]

http://wasm.ru/
The best asm site I've ever seen...but in russian

[zEr0]

Iczelion's Win32 Assembly Homepage
at http://win32asm.cjb.net/ is very good

but if you prefer to program under WIN32 and sometimes under LINUX then choose NETWIDE ASSEMBLER

this compilator is available under LINUX too
http://sourceforge.net/projects/nasm
http://nasm.sourceforge.net/wakka.php?wakka=HomePage

for writing exploites for LINUX its very useful language

If you aren't opposed to good old-fashioned tomes, I found that "80X86 IBM PC and Compatible Computers: Assembly Language, Design, and Interfacing, Vols. 1 and 2" by Mazidi, et al. to be a pretty solid bottom-up assembly reference. It's getting a little out of date in some respects (lots of old DOS memory management stuff), but it's a good way to get started on assembly from the ground level. Currently about $35 on amazon. The 4th edition is there too, but it's $100 I suppose a clever person could figure out how to read the whole thing on amazon, but you'd need a good monitor, good eyesight, and a good deal more patience than me

I also started to read through AoA, but to be totally honest I was really put-off by the heavy (read: exclusive) use of HLA. Now don't get me wrong, maybe HLA is a good thing to learn for it's own sake, but for the most part it's not going to help you really understand things from a low-level debugging/disassembling standpoint. I laboured through a few chapters, skipping as much of the HLA stuff as I could before I finally decided that it just wasn't what I was looking for at the moment. That said, there's still a lot of good information here, it's just not about assembly, per se. I think a more apt name might be "The Art of System Archtecture and How to Monkey With it Using HLA". I'm still reading through his explanation of memory management, etc., but it's valuable stuff despite the aforementioned flaws.

Perhaps most importantly, there's the Intel specs themselves. Most people wouldn't suggest these as a good starting point, so maybe I'm just a freak. But I like to learn how a piece of technology works generically before getting into specific applications of it. The Intel specs are almost unquestionably the most complete documentation on what each and every opcode does, what it's syntax is, etc. The first volume is a good read for learning how things work from an application program (ring 3) standpoint. It also gives at least a basic explanation of how protected mode in general works, and gives a few slightly vague glimpses into how the OS/executable (ring 0) level works. The third volume gives all the gorey details of system software programming and all the higher privelege levels in protected mode. I haven't read very much of it yet, but there's really no more authoritative source for information on the mechanisms of memory management, task switching, interrupt/exception/trap handling, etc. Then, of course, the second volume is just a massive reference of every opcode, indexed by their mnemonic. Invaluable for finding the specifics of what an opcode does.

The only obvious "catch" with the Intel specs is that it requires a lot more thought to really "get" it. They tell you what everything is and does, but they don't really explain and give examples. You have to figure it out yourself. It also won't cover AMD specific extensions like 3DNow!, of course, but if you dig around you can find the documentation for those instruction sets on AMD's site (fair warning: I like AMD, but prior to the AMD64, their processor documentation can only be described as shitty. Be prepared to concatenate 3 or 4 archived documents and revisions in order to get a complete reference). From a beginner's perspective, I'd say just skim or skip the stuff about MMX, SSE/2/3, and 3DNow for the time being. You can always fill that gap when you actually encounter a need for it. I'm currently working from their P4 version of the IA-32 specs, and I'll just tackle 64-bit assembly when it becomes prevalent enough for me to care about it.
hxxp://developer.intel.com/design/Pentium4/documentation.htm
(check under the manuals section)

If/when you've digested all that, it's time to get into specifics. I'm coming to realize that knowing assembly really isn't enough to understand the disassembly/debuggery of a Windows program. You'll also need to know PE/COFF format so that you can understand how the loader creates the run-time environment for a program. Again, I like to go back to the source:
hxxp://www.microsoft.com/whdc/hwdev/hardware/pecoff.mspx
Yes, it's a PITA to read, but you'll wind up knowing more about PE/COFF than you ever wanted to know. Iczelion's win32asm tutorials have already been mentioned, but his tutorials on PE format are also highly worth reading in this regard.

Apart from that, you need to learn how different calling conventions work. I really can't make a good recommendation on that. Everything I've picked up so far has been from miscellaneous resources that I've hobbled together from googling for "calling conventions"

Oh, and this is kind of a random aside, but I just thought I'd also plug Firefox/Mozilla as valuable research tool. Trying to pop back and forth through 4 or 5 different manuals, specs, and tutorials at once would make you insane without a decent tabbed browser.

[gabri3l]

My 2cents:
I found Randy Hydes Art of Assembley to be a great book I even picked it up now that its been published. If you are anything like me I find having a book you can flip around in is much more condusive than reading it off a computer screen. If you however like to learn off the screen I'll agree with zero on http://win32asm.cjb.net/ an excellent resource of information.

Calling conventions are, well...hopelessly complicated

In a nutshell, when you call a procedure, it's rarely as simple as just executing a CALL statement, executing the procedure code, and then executing a RETN statement. The calling code and the procedure both have to agree on how to do several things:

• Which registers (if any) should be preserved through the procedure?
• How those registers will be preserved. Will the calling code save them before the call and restore them after the return, or will the procedure save them before executing it's own code and restore them before it returns?
• How will parameters be passed? Through registers? Through memory locations? By sticking data on the stack?
• If arguments are passed on the stack, are they pushed from left-to-right or from right-to-left?
• If arguments are passed on the stack, who is responsible for popping them off when the procedure is finished?

I'm sure that's not an all-inclusive list, but basically a calling convention is a set of rules (a protocol, if you will) that answers those questions.

For high-level languages, the calling convention also defines how the function name in the source code will get translated for the export section. This is particularly important for languages like C++ that support function overloading. That is, you have two or more functions declarations in your source code that are represented by the same symbol, but different arguments. Internally, the compiler actually gives each version of the function a unique name according to the name you gave it and the argument list in the function declaration. Then it looks at all the calls in your source code and changes them to the appropriate mangled name. Since the mangled names are what actually go in the export table, the mangling protocol is included in the calling convention.

Probably the most commonly used conventions are:

• STDCALL - the "native" calling mode for Win32 programs. Procedures generated by compilers for most languages in the Windows environment generate their procedures as STDCALL.
• CDECL - used by "C style" procedures. Mainly used for procedures that require a variable number of arguments. In contrast to most other conventions, stack cleanup is performed by the calling code because only the calling code knows how many arguments are actually being passed on the stack.
• FASTCALL - basically the same as STDCALL except that the first two arguments are passed in registers instead of on the stack. Generates slightly faster code because maniuplating registers is faster than PUSH/POP operations. Not really used that much in application programming unless the programmer was a real speed freak.
• THISCALL - Used to call procedures that belong to a C++ object. An offset to the object that the procedure belongs to is passed in ECX.

By the way, I'm just reciting this from my notoriously shakey memory, so it's probable that I've made a mistake somewhere. If I were you, I wouldn't count on it being entirely accurate

http://wasm.ru/ has english mirror site?

Originally Posted by slin777

http://wasm.ru/ has english mirror site?

I don't think it has an english mirror site, but you can use free online translation provided by some websites to help you.

[nulli]

What is this fowl word i hear? you want to learn assembly because you want to hack? ohh my god! Sorry but thats something i would expect from a skript kiddies mouth.

Programming in assembly is for the people who has a love for processors and their instruction sets. Not because you want todo hacking. Oh well.. if that is all you want todo feel free to go ahead. But the road to assembly is long and hard. Can you stick with it?

Here are some links to settle your curiosity:
http://www.masmforum.com/
http://board.win32asmcommunity.net/
http://board.win32asmcommunity.net/showthread.php?threadid=8984

You wanted to learn assembly.. well above are the best forums.. they however do not like hacking/cracking/blah.. topics. So choose your words carefully.

[JMI]

Actually, learning assembly language is a fairly essential skill because it is what is displayed in the debugger for most programming languages. Yes, I know that there are exceptions, but the majority of what one sees when using the standard debuggers is assembly language.

That said, it is not necessary that one actually learns how to "program" in assembly language, although it is certainly an advantage. However, what one needs to know is at least how to recognize assembly language code and have some basic understanding of what the code is telling you it is doing. You may not recognize that the assembly is setting up some procedure using or not using some API or another, but you better well recognize what the operand instructions are telling you is happening with the code.

By this, I simply mean you need to recognize and understand the use of registers to store information and pointers and many other things of interest to the reverser. If one does not understand what the various instructions actually do to whatever they are manipulating, one has little chance of figuring out what to look for and/or how it might be changed to make the desired result happen. This means it is fairly essential that one have a working understanding of the mnemonics displayed in SICE and/or OllyDbg and/or WinDBG., or whatever.

Without the understanding, one can not expect to even recognize what the debugger displays, let alone where, or how to change it, beyond following, by rote, someone elses tutorial, step by step. That is not actually learning anything, other than how to follow a receipt, such as from a cook book. One is not really learning how to cook, one is only learning how to follow what the cook said to do to make that particular thing the exact same way he/she said to make it.

There are many sources available on the net to acquire such basic knowledge "of" assembly language, aside from the acquiring of the knowledge of how to actually "program" in that language.

Works such as:

Iczelion's Win32 Assembly Tutorial Series; The Art of Assembly Language Programming; Assembly for Crackers; Assembly Language Reference by Dr. ME!; The cRACKER's n0TES

are but a few of those readly available sources for acquiring some basic knowledge and but a small part of the reference files I maintain on my computer archive. There are many more, as any simple search using "assembly language + tutorial" will find.

There is really very little substitue in Reverse Engineering for actually starting "at the beginning" and learning the basics of what the code is telling you when you look at it in the debugger. That is the primary tool and the primary method used to do this work and failure to spend the time necessary to acquire a basic understanding of these issues is a substantial impediment to further skill development.

Regards,