i plan on starting to use assembly in linux; and i'm struggling in choose which assembler. I see fasm, nasm have linux support. Which of these would be a good choice under linux? It doesnt seem like nasm is being updated much anymore but it is still widely used. Fasm is getting updates and there is a little more support for it. What are your opinions? Which other assemblers are good under a linux platform?
Would the syntax be the same on a windows and linux platform for nasm/fasm; just a different layout for each binary?
Would the syntax be the same on a windows and linux platform for nasm/fasm; just a different layout for each binary?
FASM is still been developed and supports 64-bit. NASM supports 16 and 32-bit modes, but not 64-bit mode. NASM has more or less reached its design goal as an assembler for some time now, so it has been in "maintenance status" (bug fixes) ever since.
Both are open-source. FASM is written in FASM (self-assembles, but pretty much locked to running on the x86). NASM is written in C, and designed to be portable, which is why it is still widely used.
YASM is another assembler that you might be interested in. It is suppose to pick-up where NASM left-off. YASM supports NASM syntax, GAS (AT&T) syntax and 64-bit Long Mode.
As for the differences between Windows and Linux, as long as you are dealing with 32-bit Protected Mode or 64-bit Long Mode, there is not much difference. API calls work generally the same, they just do different things and have different effects on the system. The syntax has more to do with the x86 architecture than the platform it runs on.
As for my personal opinion. I've dealt with both FASM and NASM, and I tend to favor NASM as the syntax and macro facilities make more sense to me (simple, yet powerful). I also tend to favor NASM because the documentation supporting it is clear, concise... and abundant :P
You'll have to figure out which syntax you like and go with NASM/YASM or FASM. You can also take a look at THIS LINK for tutorials and pointers on ASM under Linux.
Have fun :)
Both are open-source. FASM is written in FASM (self-assembles, but pretty much locked to running on the x86). NASM is written in C, and designed to be portable, which is why it is still widely used.
YASM is another assembler that you might be interested in. It is suppose to pick-up where NASM left-off. YASM supports NASM syntax, GAS (AT&T) syntax and 64-bit Long Mode.
As for the differences between Windows and Linux, as long as you are dealing with 32-bit Protected Mode or 64-bit Long Mode, there is not much difference. API calls work generally the same, they just do different things and have different effects on the system. The syntax has more to do with the x86 architecture than the platform it runs on.
As for my personal opinion. I've dealt with both FASM and NASM, and I tend to favor NASM as the syntax and macro facilities make more sense to me (simple, yet powerful). I also tend to favor NASM because the documentation supporting it is clear, concise... and abundant :P
You'll have to figure out which syntax you like and go with NASM/YASM or FASM. You can also take a look at THIS LINK for tutorials and pointers on ASM under Linux.
Have fun :)
oh that seems good; since yasm is similiar to nasm, will the same syntax used in nasm work in yasm? so i would be able to assemble any nasm scripts in yasm.
With exception of 64-bit instructions, yes.
As for the rest, YASM's homepage explains it all ;)
As for the rest, YASM's homepage explains it all ;)
might i know what of NASM syntax makes more sense than in FASM to you?
I can take it about macrosyntax, it's "senseness" is matter of opinion. To me, all macrofeatures of FASM are really simple, the hard thing is how to combine them. Unfortunatelly i haven't dealt with NASM macrosyntax to compare.
and, until i see NASM macro to encrypt part of resulting binary with RSA, i consider FASM's macrosystem at least more powerful
I can take it about macrosyntax, it's "senseness" is matter of opinion. To me, all macrofeatures of FASM are really simple, the hard thing is how to combine them. Unfortunatelly i haven't dealt with NASM macrosyntax to compare.
and, until i see NASM macro to encrypt part of resulting binary with RSA, i consider FASM's macrosystem at least more powerful
FASM's macro power was never in question, this is a natural attribute of any complex tool.
As for "makes more sense to me", it is just that in general... something that clicks with *me* and makes me more comfortable using.
I've dealt with FASM's macro syntax and capabilities when I was designing an include file for FASM support in the Win32ASM Project. Although I began to understand how powerful it was, it didn't help because I still didn't like it. NASM has the right level of complexity for me.
I wouldn't dive into any philosophical debate as to why. It is as simple as "personal taste" ;)
As for "makes more sense to me", it is just that in general... something that clicks with *me* and makes me more comfortable using.
I've dealt with FASM's macro syntax and capabilities when I was designing an include file for FASM support in the Win32ASM Project. Although I began to understand how powerful it was, it didn't help because I still didn't like it. NASM has the right level of complexity for me.
| MASM | vs. | TASM | vs. | NASM | vs. | FASM |
| Pepsi | vs. | Shasta | vs. | Coke | vs. | RC Cola |
| Intel | vs. | 3DFX | vs. | nVidia | vs. | ATI |
I wouldn't dive into any philosophical debate as to why. It is as simple as "personal taste" ;)
just a detail: was you dealing with it when it had nested macros using fix? like
macro a {
macro b m_
blabla
_m
}
m_ fix {
_m fix }
because that WAS real hell, fortunatelly we conviced tomasz (nicer version: tomasz realized) that it's not good approach.
Now it is much clearer
macro a {
macro b m_
blabla
_m
}
m_ fix {
_m fix }
because that WAS real hell, fortunatelly we conviced tomasz (nicer version: tomasz realized) that it's not good approach.
Now it is much clearer
I'm a bit mixed wrt. FASM's macro system.
It clearly is very poweful, and I like it's use of curly brackets... but the whole 'equ' vs. '=' vs. 'fix' can be a bit confusing, and the system does seem a bit "ad hoc". I also miss masm-style EXITM in fasm and nasm macros, it sometimes means that instead of writing functionality once, you need to build it into various things.
It clearly is very poweful, and I like it's use of curly brackets... but the whole 'equ' vs. '=' vs. 'fix' can be a bit confusing, and the system does seem a bit "ad hoc". I also miss masm-style EXITM in fasm and nasm macros, it sometimes means that instead of writing functionality once, you need to build it into various things.
until i see NASM macro to encrypt part of resulting binary with RSA, i consider FASM's macrosystem at least more powerful
I personally don't have the time to code it, but it can be done in NASM. The NASM %ASSIGN directive allows you to preform algorithmic computations. I'm sure it would be a very complex project, but I don't see any reason why it couldn't be done. For example, there is a macro for NASM which can calculate Win32 symbol hashes, shown below.
; HASH - NASM macro for calculating win32 symbol hashes
; Author - Anonymous
; Usage: HASH instruction, 'SymbolName'
;
%macro HASH 2
%assign i 1 ; i = 1
%assign h 0 ; h = 0
%strlen len %2 ; len = strlen(%2)
%rep len
%substr char %2 i ; fetch next character
%assign h \
(h<<0x13) + \
(h>>0x0d) + \
char ; rotate and add
%assign i i+1 ; increment i
%endrep
%1 h ; return instruction with hash
%endmacro
;
; Examples:
;
HASH push, 'LoadLibraryA' ; push dword 0xec0e4e8e
HASH {mov eax,}, 'LoadLibraryA' ; mov eax,0xec0e4e8e
HASH dd, 'LoadLibraryA' ; dd 0xec0e4e8e
HASH dd, 'ExitProcess' ; dd 0x73e2d87eThis code was designed for the newer versions of NASM which support %strlen and %substr.
Regards,
Bryant Keller
Synfire: that functionality would still have been prettier in MASM though, because of EXITM. It's a shame that FASM and NASM macrosystems weren't built from the start to support that, since it's a very powerful feature.
Oh, and stuff like crypting output (FASM) will only work if you output directly to PE, as far as I can tell. But it does show that fasm can do some "pretty cute stuff". It's the natural choice for the init stubs of my packer/crypter :)
Oh, and stuff like crypting output (FASM) will only work if you output directly to PE, as far as I can tell. But it does show that fasm can do some "pretty cute stuff". It's the natural choice for the init stubs of my packer/crypter :)
I agree, EXITM would be a great addition to NASM.
From what i know, inline macros are only MASM's non-subjective advantage against FASM. Even tomasz grysztar agreed it is "problem" of FASM philosophy. I still believe it could be supported, but it wouldn't be very clear to FASM logic... i believe it is not clean in MASM too. Even MASM philosophy, which allows this, can on other side be confusing, because you don't have preprocessing and assembling clearly separated.
about "=" vs. "equ" vs. "fix"... i don't see no confusion. there was some with "equ" vs. "fix" some time ago, but not now. all "fix"es are replaced before doing anything else. This can be called pre-preprocessing. "fix" is used to alternate macro syntax, for example if you don't like word macro and you like %define, you can change all %defines to macros. Now, "fix" is just a thingy to alter macro syntax, not really useful...
After that, eg. after everything is "fix"ed, comes preprocessing stage. Here, "equ" takes effect. After some equation is defined (like a equ 123), any "a" symbol (that is not part of command for preprocessor), will be replaced. Here can be some confusion with "that is not part of command for preprocessor", but this cannot be avoided. How is it with replacing equates inside preprocessor commands (like macro definition) in MASM?
"=" is assembly time and doesn't cause any trouble against "equ". This is much more confusing in MASM, where "a equ 3+b" can be defintion of both numeric constant (always "=" in FASM) or textual substition (always "equ" in FASM), depending on whether right side is computable, so
and
and you also have no way to define textual substition for expression that is computable.
And more to FASM over MASM, you have macro overloading opposed to recursive macro, which is a great advantage. You can create recursive macros with overloading, but not vice versa. And when you want to "extend" instruction functionality in MASM, you have to assemble it yourself... MazeGen could tell...
PS: sorry if my knowledge of MASM if wrong, i know this from discussion with others, not from my personal experience, so i am not sure if things work the way i say...
about "=" vs. "equ" vs. "fix"... i don't see no confusion. there was some with "equ" vs. "fix" some time ago, but not now. all "fix"es are replaced before doing anything else. This can be called pre-preprocessing. "fix" is used to alternate macro syntax, for example if you don't like word macro and you like %define, you can change all %defines to macros. Now, "fix" is just a thingy to alter macro syntax, not really useful...
After that, eg. after everything is "fix"ed, comes preprocessing stage. Here, "equ" takes effect. After some equation is defined (like a equ 123), any "a" symbol (that is not part of command for preprocessor), will be replaced. Here can be some confusion with "that is not part of command for preprocessor", but this cannot be avoided. How is it with replacing equates inside preprocessor commands (like macro definition) in MASM?
"=" is assembly time and doesn't cause any trouble against "equ". This is much more confusing in MASM, where "a equ 3+b" can be defintion of both numeric constant (always "=" in FASM) or textual substition (always "equ" in FASM), depending on whether right side is computable, so
a equ 3+b
b equ 3
dd a*5 ;gives 3+b*5, evaluated to 18and
b equ 3
a equ 3+b ;evaluates to 6
dd a*5 ;gives a*5, evaluated to 30and you also have no way to define textual substition for expression that is computable.
And more to FASM over MASM, you have macro overloading opposed to recursive macro, which is a great advantage. You can create recursive macros with overloading, but not vice versa. And when you want to "extend" instruction functionality in MASM, you have to assemble it yourself... MazeGen could tell...
PS: sorry if my knowledge of MASM if wrong, i know this from discussion with others, not from my personal experience, so i am not sure if things work the way i say...