Re: Nasm lgdt and lidt
- From: Markus Wichmann <nullplan@xxxxxxxxxxxxxxxxxxx>
- Date: Wed, 16 Nov 2011 14:46:09 +0100
On 16.11.2011 08:31, hopcode wrote:
Il 15.11.2011 21:10, Markus Wichmann ha scritto:
assemblers do have some freedom when choosing their encoding. And I
don't know of any use case were the specific encoding is so important.
imho, they shouldnt choose their encoding.
You are not making sense. If I want to
add ecx, edx
in 32 bit mode or higher, the assembler can choose to encode the stuff as
It both means the same and it's the assembler's job to choose an
encoding. What do you mean by "they shouldnt choose"? Should they
present you with the choice? How long do you wish to click or type
through dialogs until you have actually assembled a sizable project?
there is any asseembler out in the world that let you
customize opcode outputting.
Some stuff you actually can do in NASM. There is the "strict" keyword.
The example given in the documentation is that usually, NASM would assemble
push dword 21h
(in 32 bit mode). However, some people might want, for some reason like
leaving enough space to be filled in later, to have the full length
operand encoding. So you can write
push strict dword 21h
which gets assembled to
68 21 00 00 00
i had on external
forum discussion about that some time ago.
my assembler let you choose the "fingerprint"
at every possible evaluable instruction (i am thinking
to extend the feature as scriptable)
this has many advantages, for example:
1) applies a sort of steganography on the output object.
( i sign my object with my name :-)
Nice feature, but pretty obscure. I'd simply write my name into the data
section and do something with it.
2) indirectly simplifies copy protection technics on that object.
What do you mean by that? Do you think a skilled reverse engineer is
uncapable of making sense of a specially crafted code?
3) the dumb eurihstic of antivirus software doesent mark the object
as "virus", because of the fact other malware was done from the same
"fingerprint" of your object.
Well, that's a problem for the anti virus industry. I stopped using AV
software "agents" long ago and resorted to monthly scans of the hard
drive. That's easier than writing my code just so that it doesn't tip
off the AV. That problem is not unique to assembly either: I once
tripped over the AV of my school (by, that's some time ago...) while
coding Pascal. I changed some condition to its equivalent (i.e. make "if
(x > 0)" to "if (0 < x)") and it worked again. But I started thinking at
that time, that AV software only relies on two checks: fingerprints and
heuristics. The more fingerprints are gathered into the database the
more bit patterns are suddenly forbidden. At some point the trouble
caused by false positives is bound to be more expensive than any damage
a virus could do.
As for heuristics, the word is derived from something greek that
translates roughly as "quick test". Which is also prone to false positives.
Plus, as long as there is an industry out there that relies on viruses
to exist, there won't be any real solutions.
What is more important, assembler, especially when used as
back-end, should not raise error from the following code,
nestlevel equ 127
only because "nestlevel" is out of range (0-31)
Well, I'd want a warning issued there, but only at request.
Intels docs tell us it is an _imm8_
Yeah, and that it's masked automatically to five bits. Which is
something someone might have overlooked.
C8 iw ib ENTER imm16, imm8 Create a nested stack frame for a procedure
then CPU microoperations of ENTER, applies internally a mod 32
on that imm8.
my reasons against that warning/error from the compiler are:
1) future eventual extension of that instruction from Intel
That's what actively developed assemblers are for.
2) "nestlevel" maybe be used later in the code for other purpouses.
True. NASM however would allow you to suppress the warning entirely by
enter 20h, nestlevel&31
Also, i am fudamentally for a WYSIWYG assembler.
And when in doubt apply hardware specification,
not the assembler native encoding.
Again, no sense in there. The problem with the catch phrase WYSIWYG here
is that WYS is necessarily some textual representation of WYG, and there
is no bijective function between the two. In particular, the same
mnemonics may have multiple encodings.
I never liked that term, either. I saw it applied to HTML designers and
could make the whole class stare in amazement by simply pointing w3m to
the site they created. What they got was nothing like they saw before.
- Re: Nasm lgdt and lidt
- From: hopcode
- Re: Nasm lgdt and lidt
- Prev by Date: Re: Nasm lgdt and lidt
- Next by Date: Re: Nasm lgdt and lidt
- Previous by thread: Re: Nasm lgdt and lidt
- Next by thread: Re: Nasm lgdt and lidt