Is there no standard x86 assembly? What's with all the MASM, TASM, NASM nonsense?

[ThatWasFat]

Ugh. Trying to learn Assembly online is a joke. I go to a site, and I learn some ASM, I type it in, and I

as86 test.asm

Horrendous failure. Every site I go to, the assembly is different, and I get different errors.

Is there no "standard" x86 assembly language. One that will work in all compilers? Like the other languages. I mean, it's not like different C++ compilers are incompatable.

There has got to be some standard ASM language that I can learn. Any help?

 

[Nothinman]

Unless it's for a class (in which case they'd tell you which assembler (not compiler) you'd be using and you wouldn't have this problem) I wouldn't worry about learning assembly. Programming assembly is pretty much pointless unless you're doing a high-end 3d application (and even now OpenGL and Direct3D take care of most of this for you) or an OS, the rest of the time the compilers will do a better job of generating assembly than you will.

And with IA64 and x86-64 right around the corner regular x86 assembly is becoming less and less prevalent.

I mean, it's not like different C++ compilers are incompatable.

Generally no, but you will find incompatibilities. Like there's certain VC-only extentions and gcc-only extensions, most even have different notiation for embedding assembly in your code.

 

[ThatWasFat]

Arr..

Ok. I guess ASM is kind of pointless. But, do you guys know any place that is good to learn about the registers? And all that awesome manipulation of the system that ASM knowledgable people do? That's really what I wanted to get out of ASM, not the actual code. Just, registers and some deeper knowledge.

 

[singh]

Here is an online book to help you out: Art Of Assembly Language Programming

Assembly Language is very low-level, and as such the sytax may vary a bit depending on the Assembler you use. For x86, NASM and MASM are probably two of the most popular. NASM is totally free, and a lot of help is available on how to use it.

I think the web-site for NASM is: Here

I suggest you read the above book before going on to the actual programming. Assembly programming is not for the faint of heart; you need to have lots of time and patience to learn it. It is quickly becoming a lost art....

 

[ElDonAntonio]

I have to disagree with Nothinman on this one, I think that assembly language is still extremely important in several fields. Granted, for general purpose applications, you won't need much more than a compiler.
However, I can think of many situations where assembly language is CRUCIAL, like software security and imaging applications. Software security because if you don't know assembly, you'll never even have a remote chance of giving a challenge to crackers, and imaging applications because you often have to be able to visually analyse data, process the image with filters and extract information at a rate of 30fps. I already did an internship at Matrox Imaging in assembly optimization for an imaging API, and I can tell you we totally beat the compilers, espescially with MMX and SSE instructions.
I heard the Itanium with its tons of registers won't let you optimize by hand, but as it's going, AMD seems more popular with its 64 bit architecture which will support manual assembly language optimizations.

 

[Nothinman]

Software security because if you don't know assembly, you'll never even have a remote chance of giving a challenge to crackers,

Sorry, that's backwards. Programming in assembly just makes it a helluva lot easier for you to make a mistake and not realize it. It's easy to write stupidly insecure software in any language, but the more complex the language (asm itself isn't complex, but doing more than adding and subtracting in it is) the easier it is to screw up.

I would never trust software written in asm that was meant to be secure for several reasons, the main one being that inside-out knowledge of asm isn't abundant so fixes will take longer to come out (especially if the original author is busy with other things) and because I don't know assembly well enough to fix things myself. I'm no C guru but I can fumble my way around and make small patches, that will never happen with asm. And there's the small fact that it won't run on my UltraSparc or my Alpha.

I heard the Itanium with its tons of registers won't let you optimize by hand, but as it's going, AMD seems more popular with its 64 bit architecture which will support manual assembly language optimizations.

You can write IA64 asm by hand, but it's so complicated it'll drive you mad, atleast that's what the gcc people say.

AMD's 64-bit chip will be more popular with geek users, that's it. They have no server market share and that's the only place a 64-bit processor makes any difference (and most of the time it's pointless there). AMD's Hammer line looks cool (I'll probably get one to compliment my PC collection) but they need something other than hacked up legacy products to compete.

 

[Descartes]

<< Sorry, that's backwards. Programming in assembly just makes it a helluva lot easier for you to make a mistake and not realize it. It's easy to write stupidly insecure software in any language, but the more complex the language (asm itself isn't complex, but doing more than adding and subtracting in it is) the easier it is to screw up. >>



I actually agree w/ you on something; wonders never cease.

I rarely write in assembly anymore, but what I learned whilst doing so has helped me immensely. It may not help you with debugging at a high-level (with VS.NET, for example), but knowing x86 architecture, and x86 assembly, *will* help you very much indeed when debugging at a low-level. How else will you amaze your friends when you remove primitive shareware protection schemes when you simply NOP out the op codes for the jmp instructions to the check routine? j/k I also rarely construct Windows applications entirely from scratch in C, but learning how to do so has also helped me immensely. When programming in higher level languages (C#, VB(.NET)), I can conceptualize that which is abstracted for me (procedure pro/epilogs, stack creation/preservation, whatever) by the higher level language. Knowing what's happening "behind the scenes" ensures that nothing ever remains truly enigmatic, and that helps elucidate my development experience.

I still use MASM32's linker when compiling VC++ apps as it decreases the size of my deliverable significantly (I don't do this for production work, as it's not supported). Sometimes I'll write a DLL in MASM for fun as well, like a global keyboard hook or something. Windows programming in MASM is quite lucid. You have fairly lucid conditional statements (macros), invoke statements (macros), etc.. No pushing/popping the parameters just to call a simple routine, you simply "invoke" it. A popular resource for win32 assembly programming is located here.

 

[Strafe]

Steve Gibson has some good assembly pointers at http://grc.com/smgassembly.htm.

 

[ElDonAntonio]

Nothinman, I don't think you've ever actually tried to go into the assembly code of a software just for fun or to remove its protection (I'm no cracker, it's mostly for the challenge of it)? if yes, you'd realize that most of the time, the programmers had NO idea what assembly is and as a result you can circumvent the protection quite easily.
I think that the ideal solution in terms of time and efficiency would be to write a protection in a higher level language and then go and tweak it in assembly to make it harder for crackers.

As for the 64 bit thing, we'll talk about it again in a few years Come on, you know as well as I do that in maximum 2 years, no one will be bragging on AT that he has a 32 bit processor...

Anyways, I wouldn't discourage anyone to learn assembly language, I think it's a great way to know what's going on, and it's an excellent exercise in logic that will help you a lot when programmin in other languages (in terms of discipline).

 

[Nothinman]

Nothinman, I don't think you've ever actually tried to go into the assembly code of a software just for fun or to remove its protection (I'm no cracker, it's mostly for the challenge of it)? if yes, you'd realize that most of the time, the programmers had NO idea what assembly is and as a result you can circumvent the protection quite easily.

I guess this shows our backrounds and intentions pretty well, but I was talking about security as in 'you can't break into my web server' not security as in 'you can't use my product for more than 30 days'. I mostly use Linux/Open Source software so cracking programs doesn't even occur to me any more.

As for the 64 bit thing, we'll talk about it again in a few years

Years? I have as many 64-bit machines at home as I do 32-bit ones (well, running ones anyway). If you write your program with a large amount of asm I can't run it on my Alpha or my UltraSparc, and it makes porting to anything else a lot harder. Just because you don't own one, doesn't mean it's not relevant. And there's plenty of 32-bit non-x86 CPUs out there so it's not a 64-bit vs 32-bit thing.

 

[ElDonAntonio]

I guess this shows our backrounds and intentions pretty well

My background? I'm a computer engineer. My intentions? always learn more. I buy all my software, and those I try to crack is solely for the challenge (kind of the same satisfaction than when you disassemble a piece of hardware and understand things not intended for you to understand by the manufacturer).

For 64 bit machines, my sole point was that assembly is useful for optimizing code for specific architectures. You won't find any compiler that'll optimize your code for MMX or SSE (1 or 2), and I'm ready to bet that no compiler will be able to beat a good programmer in AMD's future 64 bit architecture.
As for Alpha and Ultrasparc machines, I don't think most mainstream software companies worry about compatibility on those. Of course I agree they're used a lot in r&d environments.

 

[Descartes]

<< if yes, you'd realize that most of the time, the programmers had NO idea what assembly is and as a result you can circumvent the protection quite easily. I think that the ideal solution in terms of time and efficiency would be to write a protection in a higher level language and then go and tweak it in assembly to make it harder for crackers. >>



You can't write an application in one language, then simply "tweak" it in assembly. Indeed, a binary has absolutely no reference to any programming language whatsoever, including assembly. The only reason you can "disassemble" a binary is because translating the opcodes of a binary into assembly instructions is simple. Each byte in a binary translates to an opcode (or an argument for an opcode), and for each opcode, there is a corresponding instruction in assembly (mov, lea, pop, push, jmp, jnz, whatever).

It's as simple as this; if your application uses *any* form of protection at the binary level, it can, and will (if your application is desirable) be removed. There are ways you can make protection removal more difficult, but still it's inevitable. Sometimes it's as simple as trying to register a shareware program and noting the error message returned. Often these error messages are stored as string literals in the binary (they end up in the .data section of a binary). A little disassembly can locate the address of the string literal in the binary. With that, you simply trace the opcodes preceding the literal finding the jmp instruction for the protection scheme, and NOP (no-op, i.e. ) it.

Protection schemes that limit by time are even easier. The ones that use keycodes are more difficult, but once you reverse engineer the algorithm, you can build a keygen.

The only true way to protect your application is to distribute a limited version. Modern development environments facilitate different builds for things like this.

 

[Nothinman]

You won't find any compiler that'll optimize your code for MMX or SSE (1 or 2),

Honestly that doesn't impact me much even if it is true, machines are fast enough now all those little tweaks have little noticable effect and I'd rather have a fully portable C program that runs on all my machines. And have you looked at Intel's compiler, it's supposedly real good at optimizing even very complex C and C++ code.

As for Alpha and Ultrasparc machines, I don't think most mainstream software companies worry about compatibility on those. Of course I agree they're used a lot in r&d environments.

All those people running databases, webservers, etc on Alphas and Sun Enterprise boxes aren't mainstream? My company has 3 Compaq Alpha GS160s and at ~$1M a piece they're not just for r&d.

 

[ElDonAntonio]

Honestly that doesn't impact me much even if it is true, machines are fast enough now all those little tweaks have little noticable effect and I'd rather have a fully portable C program that runs on all my machines. And have you looked at Intel's compiler, it's supposedly real good at optimizing even very complex C and C++ code.

Well from experience, I can tell you that the SIMD nature of MMX and SSE will give you pretty huge boosts in speed in algorithms that are well suited for that. For example, distributed software like Seti@home and others rely heavily on asm optimizations and MMX and SSE instructions. If not for them, these programs would probably run about half as fast as they actually do (if not more). There are lots of applications that are still dog slow, even on 2Ghz machines. Think of 3D rendering, video production, image analysis, signal analysis (seti@home for example, etc).
Intel's compiler may be excellent, but it won't use MMX or SSE instructions. You really need a human to understand the algorithm and pack the data in the registers for SIMD.
Programs that use special instructions like MMX first detect if your CPU supports it, if not it'll use standard instructions, so your code should still work on all machine, just better on those with MMX and SSE.

As for Alpha and Ultrasparc machine, you probably know more than me about them and their uses, so I won't argue