Are there any low-level asm tutorials? I'm a total n%b and all I've found is stuff that uses invoke commands but that makes me code in C... When I open a neato program written in lowest level asm I find these blocks of code like mov ax,bx and then lea eax,[dword ptr something] and I guess asm needs more commands in a row for what would be one line in C code (i.e. to open a file, C has fopen(); but in asm I need to PUSH stuff then CALL stuff, etc. and that's the part I just don't get :'(), so is there a good noob-friendly tutorial or explanation? Asm looks so spiffy, I wanna learn it. :toothy
Btw I'm not a spambot, that's how all my posts sound... People usually get used to it. :cheekygreen: :green2 :green2
The one my Paul A. Carter looks pretty good. Unfortunately, it's for nasm, but the basics are all there.
look for nasm tutorials. i had the misfortune of having to use that language at school last term.. local variables and parameters can not be named but only referred to as offsets from ebp once the stack frame has been set up. but it sounds like that is the kind of stuff you are looking for
maybe if you are really interested, start ripping apart some of your C programs in OllyDbg and you'll get the sort of code you're looking for. it might be hard at first but that's how i learnt assembly
ps. personally i still think art of assembly is the best book for learning about assembly ( not necessarily learning how to code asm though )
Thanx for replies. I have a C compiler, I have OllyDbg, I'm gonna get on that :bg and I'll search for NASM tutorials.
I've already taken a look before at AoA but as far as I can see it's about HLA and that's not really what I'm interested in. :boohoo: What I just don't get is how to do operations in asm, as example, in C if I want to open a file I use fopen, kinda logical. But I saw once in ASM I need to push some zeros, then offset with file name, then some zeros again... Are those parameters or what? :toothy I don't really get it, should I learn those sequences by heart or there's some logic I fail to perceive? Well anyway I'm gonna look at Dr. Paul Carter's tuts now, whatever I read is gonna improve my knowledge since I don't really know anything in this field. :toothy I don't even know why am I so attracted to assembly, I guess there must be an explanation. :U
Quote from: ThexDarksider on June 10, 2009, 12:42:18 AM
Thanx for replies. I have a C compiler, I have OllyDbg, I'm gonna get on that :bg and I'll search for NASM tutorials.
I've already taken a look before at AoA but as far as I can see it's about HLA and that's not really what I'm interested in. :boohoo: What I just don't get is how to do operations in asm, as example, in C if I want to open a file I use fopen, kinda logical. But I saw once in ASM I need to push some zeros, then offset with file name, then some zeros again... Are those parameters or what? :toothy I don't really get it, should I learn those sequences by heart or there's some logic I fail to perceive? Well anyway I'm gonna look at Dr. Paul Carter's tuts now, whatever I read is gonna improve my knowledge since I don't really know anything in this field. :toothy I don't even know why am I so attracted to assembly, I guess there must be an explanation. :U
Yes it is right, the pushed value can be mean many thing depend on what the API need it.
For example,
.data
x dword 0
y dword 0
test 25 dup (0)
invoke Test,x,y,addr test
On Flat Assembler where you are interested on it will be
lea eax,test ; get the address of buffer named test
push eax ; push it to stack
push y ; push y to stact
push x ; push x to stack
call test ; call it
add esp,12 ; we pushed 12 bytes to stack so the stack must be balancing to zero, current stack is -12
Not low-level :
http://win32assembly.online.fr/tutorials.html
I think that is Iczelion's judging by the address but thx anyway, I didn't check Paul Carter's NASM stuff yet because I don't have adobe reader installed (lol) but I'll do it as soon as I get home, I believe that MASM and NASM are somewhat similar. :bg
Hi ThexDarksider,
Try Foxit Reader 3.0 for Windows (http://www.foxitsoftware.com/pdf/reader/) It's a small and fast PDF viewer. Not bloated like Adobe Reader.
I'm very thankful for that, I have ~100 MB left on my system drive, a small PDF viewer is just the thing I need! :green2
Quote from: ThexDarksider on June 10, 2009, 06:45:49 PM
I'm very thankful for that, I have ~100 MB left on my system drive, a small PDF viewer is just the thing I need! :green2
i'm lucky than you~~ i still have 685mb free on my 2gb C:P 'cause i put almost everything in the second 2gb disk D: - ust leave masm,radasm & od in C:
and foxit is right what i need now, thanks for that
That reader is so cool, I downloaded the zip and didn't even have to install! :toothy
Low-level assembly: it boils down to this, instead of using INVOKE, push the parameters on the stack and call the function. Instead of using any other macros, replace them with the equivalent code.
There are a few times when using push and call is advantageous versus INVOKE, and there are times when not using a macro is advantageous, but other than those times, I don't know why would you want to do this?
You could go the next step and program with a hex editor and opcodes too. ::) :lol
ThexDarksider,
The way I learned the basics was to output the .cod file from a C compile. I guess, depending on the compiler, the output is mixed C source lines (as commentary), and the generated asm code. Experiment with optimization and see what the compiler does to simplify the code (for size and speed) (and remember, "beauty is in the eye of the beholder" when viewing the "simplified" code).
Then start looking at the many examples in MASM32 and read the timing forums in the lab.
Dave.
I'd suggest downloading the trial for emu8086. It uses 16-bit MASM syntax, so the stuff you learn from using it will easily transfer to MASM32. Plus, the interactive debugger will teach you a lot. Nothing compares to seeing your code execute in slow motion, and seeing how each line affects the registers and stack as it does it.
Tread carefully with the assumptions that 16 bit DOS software translates well to 32 bit assembler, as a matter of fact it does not. 16 bit DOS code suffered the ugly complexity of segment/offset addressing, severe restrictions on instruction use, no register preservation convention and the assumptions of a non-re-entrant architecture.
32 bit code is a joy in comparison, 4 gig linear addressing, nearly unlimited instruction choice apart from privileged instructions, a multitasking architecture where you have more than one process running at the same time, a manufacturer/OS vendor register preservation convention and this makes cleaner, simpler, faster and more powerful code. Also remember that under 32 bit Windows you have over 12000 system function available.
Leave DOS code where it belongs, on the scrapheap of programming history, don't waste your life and time with this old junk.
If I knew of a 32-bit MASM syntax emulator or interactive debugger that was as helpful in teaching assembly, I would have suggested it instead. As far as I know though, such a program doesn't exist. 32-bit may be better in every way imaginable, but that doesn't make it easier to learn considering that it doesn't have near as many tools and tutorials as 16-bit.
Yeah, the specifics won't transfer to MASM. The general knowledge gained from learning about the stack, registers, instruction set, ect. will though.
Besides, it's not like he is going to start out writing complex windows programs that use 32-bit to its fullest potential. He is probably going to start out with simple console programs, which will easily transfer over to MASM32.
QuoteLeave DOS code where it belongs, on the scrapheap of programming history, don't waste your life and time with this old junk.
awwww - lol
i miss its simplicty, though
DOS on a 8088/8087 machine - easy to master
XP on a pentium 4 - i'll probably never master it
i can still make it do stuff, though
Quote from: Slayer706 on June 13, 2009, 05:14:00 PM
If I knew of a 32-bit MASM syntax emulator or interactive debugger that was as helpful in teaching assembly, I would have suggested it instead. As far as I know though, such a program doesn't exist. 32-bit may be better in every way imaginable, but that doesn't make it easier to learn considering that it doesn't have near as many tools and tutorials as 16-bit.
Yeah, the specifics won't transfer to MASM. The general knowledge gained from learning about the stack, registers, instruction set, ect. will though.
Besides, it's not like he is going to start out writing complex windows programs that use 32-bit to its fullest potential. He is probably going to start out with simple console programs, which will easily transfer over to MASM32.
try ollydbg i think you'll love it if you haven't met it already
Emulators will never perform like a processor due to interpretation problems, missing bits and hardware limitations. The viable alternative if you want single step instructions is a debugger, Olly, SoftIce and its successors, various Microsoft tools and a few others. Nor is it the only way to learn instructions, after working with assembler language programmers for the last 11 years with MASM32 and commercial assembler language programming before that I know that going through DOS is a serious mistake, start with true 32 bit and don't learn all of the old bad habits from an ancient clapped out architecture.
DOS tools are old junk designed to work in a non-re-entrant monotasking environment, in 32 bit Windows you have multitasking so you can run multiple processes at the same time, debuggers without TSR task switching, stress testing at the same time, direct result outputs, processor usage measures, all of thos things that are not possible under DOS.
16Bit DOS asm is a cruise compared to 32bit Winasm.
16Bit Dos comes with a small set of Interrupt functions geared for old (very old) computers. 16Bit Dos is probably the most stable OS ever produced by MS, but with advances in technology, this cannot be guaranteed nowdays.
32bit Windows comes with a gazillion 'APIs'=more learning effort, and requires more exact programming due to the 'psuedo parallism'. Windoze is not 'stable' due to the OS itself, and incorrect developer software.
Prevention is better than cure === Never assume anything and always make sure - this is probably the most common mistake made by software developers
As Hutch says.. be careful
the processor was much simpler as well
many people had a hard time with segmented addressing
i thought that was nothing compared to all the ins and outs of a pentium
Hi
I have been reading this thread with interest so I thought I would put my 2 cents worth in.
I started learning assembly in the late 70's on a 8 bit zilog Z80 cpu (anyone heard of it??). In those days we had to do our own display routines with text and graphics through interrupts and direct video memory access. Many of the functions that we take for granted now through the use of API calls were not available so they had to be coded.
Later I moved to the 8088 where things programming wise hadn't really changed that much. Writing a complex bug free program was quite a big undertaking however the plus side was that there were some excellent tools available for debugging which I admit was a lot easier.
After a break of about 15 years and having forgotten a lot I decided to get back into as now I have a lot more time.
After deciding to use MASM32 I downloaded some source and had a look at what was gong on these days.
Wow what a difference - with a few lines of code I can make a pretty window with lots of controls, play music, show pictures and do all sorts of clever things.
What I am trying to say is over the last 30 years the basic principle of assembly programming hasn't change regardless if you use 16, 32, or 64 bit cpu's even the instruction set hasn't changed that much apart from the addition of specific instructions.
The basic registers still follow the same format from my 8 bit days, just now they are getting larger and most other common instruction appear to be pretty much the same.
The huge difference now is assemblers are more user friendly and the most important thing now is 90% of the work is done for you through the use of API calls. The only problem I have these days is understanding the complexity's of some of the API calls
not the assembly language itself.
For those who think 16 bit assembly is easier try writing a routine that displays a dialog box with controls the same as you find in Windozes dialog :bg
The bottom line is assembly programming in the windoze environment is much easier now and gives the amateur programmer the ability to write software that not so long ago would have been a daunting undertaking.
If you want to learn on a 16 bit environment go for it, it's good learning ground and I must admit I had the most fun programming in those days (last century lol) however if you want to produce windows app then go with the 32bit environment as its the way the future is going for now
Cheers
JayPee