Copy Link
Add to Bookmark
Report
Assembly Programming Journal Issue 01
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::. Oct/Nov 98
:::\_____\::::::::::. Issue 1
::::::::::::::::::::::.........................................................
A S S E M B L Y P R O G R A M M I N G J O U R N A L
http://asmjournal.freeservers.com
asmjournal@mailcity.com
T A B L E O F C O N T E N T S
----------------------------------------------------------------------
Introduction...................................................mammon_
"VGA Programming in Mode 13h".............................Lord Lucifer
"SMC Techniques: The Basics"...................................mammon_
"Going Ring0 in Windows 9x".....................................Halvar
Column: Win32 Assembly Programming
"The Basics"..............................................Iczelion
"MessageBox"..............................................Iczelion
Column: The C standard library in Assembly
"_itoa, _ltoa and _ultoa"...................................Xbios2
Column: The Unix World
"x86 ASM Programming for Linux"............................mammon_
Column: Issue Solution
"11-byte Solution"..........................................Xbios2
----------------------------------------------------------------------
+++++++++++++++++++++++Issue Challenge++++++++++++++++++++
Write a program that displays its command line in 11 bytes
----------------------------------------------------------------------
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::..............................................INTRODUCTION
by mammon_
Welcome to the first issue of Assembly Programming Journal. Assembly language
has become of renewed interest to a lot of programmers, in what must be a
backlash to the surge of poor-quality RAD-developed programs (from Delphi, VB,
etc) released as free/shareware over the past few years. Assembly language
code is tight, fast, and often well-coded -- you tend to find fewer
inexperienced coders writing in assembly language than you do writing in, say,
Visual Basic.
The selection of articles is somewhat eclectic and should demonstrate the
focus of this magazine: i.e., it targets the assembly-language programming
community, not any particular type of coding such as Win32, virus, or demo
programmimg. As the magazine is newly born and much of its purpose may seem
unclear, I will devote the rest of this column to the most common questions I
have received via email regarding the mag.
How often will an issue be released?
------------------------------------
Barring hazard, an issue will be released every other month.
What types of articles will be accepted?
----------------------------------------
Anything to do with assembly language. Obviously repeats of previously
presented material are not necessary unless they enhance or clarify the
earlier material. The focus will be on Intel x86 instruction sets; however
coding for other processors is acceptable (though out of courtesy it would be
good point to an x86 emulator for the processor you write on).
Personally I am looking for articles on the areas of asembly language that
interest me: code optimization, demo/graphics programming, virus coding, unix
and other-OS asm coding, and OS-internals.
Demos (with source) and quality ASCII art (for issue covers, column logos,
etc) are especially welcome.
For what level of coding experience is the mag intended?
--------------------------------------------------------
The magazine is intended to appeal to asm coders of all levels. Each issue
will contain mostly beginner and intermediate level code/techniques, as these
will by nature be of the greatest demand; however one of the goals of APJ is
to include enough advanced material to make the magazine appeal to "pros" as
well.
How will the mag be distributed?
--------------------------------
Assembly Programming Journal has its own web page at
http://asmjournal.freeservers.com
which will contain the current issue and an archive of previous issues. The
page also contains a guestbook and a disucssion board for article writers and
readers.
An email subscription may be obtained by sending an email to
asmjournal@mailcity.com
with the subject "SUBSCRIBE"; starting with the next issue, Assembly
Programming Journal will be emailed to the address you sent the mail from.
Wrap-up
-------
That's the bulk of the "faq". Enjoy the mag!
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
VGA Programming in Mode 13h
by Lord Lucifer
This article will describe how to program VGA graphics Mode 13h using assembly
language. Mode 13h is the 320x200x256 graphics mode, and is fast and very
convenient from a programmer's perspective.
The video buffer begins at address A000:0000 and ends at address A000:F9FF.
This means the buffer is 64000 bytes long and that each pixel in mode 13h is
represented by one byte.
It is easy to set up mode 13h and the video buffer in assembly language:
mov ax,0013h ; Int 10 - Video BIOS Services
int 10h ; ah = 00 - Set Video Mode
; al = 13 - Mode 13h (320x200x256)
mov ax,0A000h ; point segment register es to A000h
mov es,ax ; we can now access the video buffer as
; offsets from register es
At the end of your program, you will probably want to restore the text mode.
Here's how:
mov ax,0003h ; Int 10 - Video BIOS Services
int 10h ; ah = 00 - Set Video Mode
; al = 03 - Mode 03h (80x25x16 text)
Accessing a specific pixel int the buffer is also very easy:
; bx = x coordinate
; ax = y coordinate
mul 320 ; multiply y coord by 320 to get row
add ax,bx ; add this with the x coord to get offset
mov cx,es:[ax] ; now pixel x,y can be accessed as es:[ax]
Hmm... That was easy, but that multiplication is slow and we should get rid of
it. That's easy to do too, simply by using bit shifting instead of multiplica-
tion. Shifting a number to the left is the same as multiplying by 2. We want to
multiply by 320, which is not a multiple of 2, but 320 = 256 + 64, and 256 and
64 are both even multiples of 2. So a faster way to access a pixel is:
; bx = x coordinate
; ax = y coordinate
mov cx,bx ; copy bx to cx, to save it temporatily
shl cx,8 ; shift left by 8, which is the same as
; multiplying by 2^8 = 256
shl bx,6 ; now shift left by 6, which is the same as
; multiplying by 2^6 = 64
add bx,cx ; now add those two together, whis is
; effectively multiplying by 320
add ax,bx ; finally add the x coord to this value
mov cx,es:[ax] ; now pixel x,y can be accessed as es:[ax]
Well, the code is a little bit longer and looks more complicated, but I can
guarantee it's much faster.
To plot colors, we use a color look-up table. This look-up table is a 768
(3x256) array. Each index of the table is really the offset index*3. The 3
bytes at each index hold the corresponding values (0-63) of the red, green,
and blue components. This gives a total of 262144 total possible colors.
However, since the table is only 256 elements big, only 256 different colors
are possible at a given time.
Changing the color palette is accomplished through the use of the I/O ports of
the VGA card:
Port 03C7h is the Palette Register Read port.
Port 03C8h is the Palette Register Write port
Port 03C9h is the Palette Data port
Here is how to change the color palette:
; ax = palette index
; bl = red component (0-63)
; cl = green component (0-63)
; dl = blue component (0-63)
mov dx,03C8h ; 03c8h = Palette Register Write port
out dx,ax ; choose index
mov dx,03C9h ; 03c8h = Palette Data port
out dx,al
mov bl,al ; set red value
out dx,al
mov cl,al ; set green value
out dx,al
mov dl,al ; set blue value
Thats all there is to it. Reading the color palette is similar:
; ax = palette index
; bl = red component (0-63)
; cl = green component (0-63)
; dl = blue component (0-63)
mov dx,03C7h ; 03c7h = Palette Register Read port
out dx,ax ; choose index
mov dx,03C9h ; 03c8h = Palette Data port
in al,dx
mov bl,al ; get red value
in al,dx
mov cl,al ; get green value
in al,dx
mov dl,al ; get blue value
Now all we need to know is how to plot a pixel of a certain color at a certain
location. Its very easy, given what we already know:
; bx = x coordinate
; ax = y coordinate
; dx = color (0-255)
mov cx,bx ; copy bx to cx, to save it temporatily
shl cx,8 ; shift left by 8, which is the same as
; multiplying by 2^8 = 256
shl bx,6 ; now shift left by 6, which is the same as
; multiplying by 2^6 = 64
add bx,cx ; now add those two together, whis is
; effectively multiplying by 320
add ax,bx ; finally add the x coord to this value
mov es:[ax],dx ; copy color dx into memory location
; thats all there is to it
Ok, we now know how to set up Mode 13h, set up the video buffer, plot a pixel,
and edit the color palette.
My next article will go on to show how to draw lines, utilize the vertical
retrace for smoother rendering, and anything else I can figure out by that
time...
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
SMC Techniques: The Basics
by mammon_
One of the benefits of coding in assembly language is that you have the option
to be as tricky as you like: the binary gymnastics of viral code demonstrate
this above all else. One of the viral "tricks" that has made its way into
standard protection schemes is SMC: self-modifying code.
In this article I will not be discussing polymorphic viruses or mutation
engines; I will not go into any specific software protection scheme, or cover
any anti-debugger/anti-disassembler tricks, or even touch on the matter of the
PIQ. This is intended to be a simple primer on self-modifying code, for those
new to the concept and/or implementation.
Episode 1: Opcode Alteration
----------------------------
One of the purest forms of self-modifying code is to change the value of an
instruction before it is executed...sometimes as the result of a comparison,
and sometimes to hide the code from prying eyes. This technique essentially
has the following pattern:
mov reg1, code-to-write
mov [addr-to-write-to], reg1
where 'reg1' would be any register, and where '[addr-to-write-to]' would be a
pointer to the address to be changed. Note that 'code-to-write- would ideally
be an instruction in hexadecimal format, but by placing the code elsewhere in
the program--in an uncalled subroutine, or in a different segment--it is
possible to simply transfer the compiled code from one location to another via
indirect addressing, as follows:
call changer
mov dx, offset [string] ;this will be performed but ignored
label: mov ah, 09 ;this will never be perfomed
int 21h ;this will exit the program
....
changer: mov di, offset to_write ;load address of code-to-write in DI
mov byte ptr [label], [di] ;write code to location 'label:'
ret ;return from call
to_write: mov ah, 4Ch ;terminate to DOS function
this small routine will cause the program to exit, though in a disassembler it
at first appears to be a simple print string routine. Note that by combining
indirect addressing with loops, entire subroutines--even programs--can be
overwritten, and the code to be written--which may be stored in the program as
data--can be encrypted with a simple XOR to disguise it from a disassembler.
The following is a complete asm program to demonstrate patching "live" code;
it asks the user for a password, then changes the string to be printed
depending on whether or not the password is correct:
; smc1.asm ==================================================================
.286
.model small
.stack 200h
.DATA
;buffer for Keyboard Input, formatted for easy reference:
MaxKbLength db 05h
KbLength db 00h
KbBuffer dd 00h
;strings: note the password is not encrypted, though it should be...
szGuessIt db 'Care to guess the super-secret password?',0Dh,0Ah,'$'
szString1 db 'Congratulations! You solved it!',0Dh,0Ah, '$'
szString2 db 'Ah, damn, too bad eh?',0Dh,0Ah,'$'
secret_word db "this"
.CODE
;===========================================
start:
mov ax,@data ; set segment registers
mov ds, ax ; same as "assume" directive
mov es, ax
call Query ; prompt user for password
mov ah, 0Ah ; DOS 'Get Keyboard Input' function
mov dx, offset MaxKbLength ; start of buffer
int 21h
call Compare ; compare passwords and patch
exit:
mov ah,4ch ; 'Terminate to DOS' function
int 21h
;===========================================
Query proc
mov dx, offset szGuessIt ; Prompt string
mov ah, 09h ; 'Display String' function
int 21h
ret
Query endp
;===========================================
Reply proc
PatchSpot:
mov dx, offset szString2 ; 'You failed' string
mov ah, 09h ; 'Display String' function
int 21h
ret
Reply endp
;===========================================
Compare proc
mov cx, 4 ; # of bytes in password
mov si, offset KbBuffer ; start of password-input in Buffer
mov di, offset secret_word ; location of real password
rep cmpsb ; compare them
or cx, cx ; are they equal?
jnz bad_guess ; nope, do not patch
mov word ptr cs:PatchSpot[1], offset szString1 ;patch to GoodString
bad_guess:
call Reply ; output string to display result
ret
Compare endp
end start
; EOF =======================================================================
Episode 2: Encryption
---------------------
Encryption is undoubtedly the most common form of SMC code used today. It is
used by packers and exe-encryptors to either compress or hide code, by viruses
to disguise their contents, by protection schemes to hide data. The basic
format of encryption SMC would be:
mov reg1, addr-to-write-to
mov reg2, [reg1]
manipulate reg2
mov [reg1], reg2
where 'reg1' would be a register containing the address (offset) of the
location to write to, and reg2 would be a temporary register which loads the
contents of the first and then modifies them via mathematical (ROL) or logical
(XOR) operations. The address to be patched is stored in reg1, its contents
modified within reg2, and then written back to the original location still
stored in reg1.
The program given in the preceding section can be modified so that it
unencrypts the password by overwriting it (so that it remains unencrypted
until the program is terminated) by first changing the 'secret_word' value as
follows:
secret_word db 06Ch, 04Dh, 082h, 0D0h
and then by changing the 'Compare' routine to patch the 'secret_word' location
in the data segment:
;===========================================
magic_key db 18h, 25h, 0EBh, 0A3h ;not very secure!
Compare proc ;Step 1: Unencrypt password
mov al, [magic_key] ; put byte1 of XOR mask in al
mov bl, [secret_word] ; put byte1 of password in bl
xor al, bl
mov byte ptr secret_word, al ; patch byte1 of password
mov al, [magic_key+1] ; put byte2 of XOR mask in al
mov bl, [secret_word+1] ; put byte2 of password in bl
xor al, bl
mov byte ptr secret_word[1], al ; patch byte2 of password
mov al, [magic_key+2] ; put byte3 of XOR mask in al
mov bl, [secret_word+2] ; put byte3 of password in bl
xor al, bl
mov byte ptr secret_word[2], al ; patch byte3 of password
mov al, [magic_key+3] ; put byte4 of XOR mask in al
mov bl, [secret_word+3] ; put byte4 of password in bl
xor al, bl
mov byte ptr secret_word[3], al ; patch byte4 of password
mov cx, 4 ;Step 2: Compare Passwords...no changes from here
mov si,offset KbBuffer
mov di, offset secret_word
rep cmpsb
or cx, cx
jnz bad_guess
mov word ptr cs:PatchSpot[1], offset szString1
bad_guess:
call Reply
ret
Compare endp
Note the addition of the 'magic_key' location which contains the XOR mask for
the password. This whole thing could have been made more sophisticated with a
loop, but with only four bytes the above speeds debugging time (and, thereby,
article-writing time). Note how the password is loaded, XORed, and re-written
one byte at a time; using 32-bit code, the whole (dword) password could be
written, XORed and an re-written at once.
Episode 3. Fooling with the stack
---------------------------------
This is a trick I learned while decompiling some of SunTzu's code. What
happens here is pretty interesting: the stack is moved into the code segment
of the program, such that the top of the stack is set to the first address to
be patched (which, BTW, should be the one closest to the end of the program
due to the way the stack works); the byte at this address is the POPed into a
register, manipulated, and PUSHed back to its original location. The stack
pointer (SP) is then decremented so that the next address to be patched (i
byte lower in memory) is now at the top of the stack.
In addition, the bytes are being XORed with a portion of the program's own
code, which disguises somewhat the actual value of the XOR mask. In the
following code, I chose to use the bytes from Start: (200h when compiled)
up to --but not including-- Exit: (214h when compiled; Exit-1 = 213h).
However, as with SunTzu's original code I kept the "reverse" sequence of the
XOR mask such that byte 213h is the first byte of the XOR mask, and byte 200h
is the last. After some experimentation I found this was the easiest way to
sync a patch program--or a hex editor--to the stack-manipulative code; since
the stack moves backwards (a forward-moving stack is more trouble than it is
worth), using a "reverse" XOR mask allows both filepointers in a patcher to be
INCed or DECed in sync.
Why is this an issue? Unlike the previous two examples, the following does not
contain the encrypted version of the code-to-be-patched. It simply contains
the source code which, when compiled, results in the unencrypted bytes which
are then run through the XOR routine, encrypted, and then executed (which, if
you have followed thus far, will immediately demonstrate to be no good...
though it is a fantastic way of crashing the DOS VM!).
Once the program is compiled you must either patch the bytes-to-be-decrypted
manually, or write a patcher to do the job for you. The former is more
expedient, the latter is more certain and is a must if you plan on maintaining
the code. In the following example I have embedded 2 CCh's (Int3) in the code
at the fore and aft end of the bytes-to-be-decrypted section; a patcher need
simply search for these, count the bytes in between, and then XOR with the
bytes between 200-213h.
Once again, this sample is a continuation of the previous example. In it, I
have written a routine to decrypt the entire 'Compare' routine of the previous
section by XORing it with the bytes between 'Start' and 'Exit'. This is
accomplished by seeting the stack segment equal to the code segment, then
setting the stack pointer equal to the end (highest) address of the code to be
modified. A byte is POPed from the stack (i.e. it's original location), XORed,
and PUSHed back to its original location. The next byte is loaded by
decrementing the stack pointer. Once all of the code it decrypted, control is
returned to the newly-decrypted 'Compare' routine and normal execution
resumes.
;===========================================
magic_key db 18h, 25h, 0EBh, 0A3h
Compare proc
mov cx, offset EndPatch[1] ;start addr-to-write-to + 1
sub cx, offset patch_pwd ;end addr-to-write-to
mov ax, cs
mov dx, ss ;save stack segment--important!
mov ss, ax ;set stack segment to code segment
mov bx, sp ;save stack pointer
mov sp, offset EndPatch ;start addr-to-write-to
mov si, offset Exit-1 ;start sddr of XOR mask
XorLoop:
pop ax ;get byte-to-patch into AL
xor al, [si] ;XOR al with XorMask
push ax ;write byte-to-patch back to memory
dec sp ;load next byte-to-patch
dec si ;load next byte of XOR mask
cmp si, offset Start ;end sddr of XOR mask
jae GoLoop ;if not at end of mask, keep going
mov si, offset Exit-1 ;start XOR mask over
GoLoop:
loop XorLoop ;XOR next byte
mov sp, bx ;restore stack pointer
mov ss, dx ;restore stack segment
jmp patch_pwd
db 0CCh,0CCh ;Identifcation mark: START
patch_pwd: ;no changes from here
mov al, [magic_key]
mov bl, [secret_word]
xor al, bl
mov byte ptr secret_word, al
mov al, [magic_key+1]
mov bl, [secret_word+1]
xor al, bl
mov byte ptr secret_word[1], al
mov al, [magic_key+2]
mov bl, [secret_word+2]
xor al, bl
mov byte ptr secret_word[2], al
mov al, [magic_key+3]
mov bl, [secret_word+3]
xor al, bl
mov byte ptr secret_word[3], al
;compare password
mov cx, 4
mov si, offset KbBuffer
mov di, offset secret_word
rep cmpsb
or cx, cx
jnz bad_guess
mov word ptr cs:PatchSpot[1], offset szString1
bad_guess:
call Reply
ret
Compare endp
EndPatch:
db 0CCh, 0CCh ;Identification Mark: END
This kind of program is very hard to debug. For testing, I substituted 'xor
al, [si]' first with 'xor al, 00h', which would cause no encryption and is
useful for testing code for final bugs, and then with 'xor al, EBh', which
allowed me to verify that the correct bytes were being encrypted (it never
hurts to check, after all).
Episode 4: Summation
--------------------
That should demonstrate the basics of self-modifying code. There are a few
techniques to consider to make development easier, though really any SMC
programs will be tricky.
The most important thing is to get your program running completely before you
start overwriting any of its code segments. Next, always create a program that
performs the reverse of any decryption/encryption code--not only does this
speed up comilation and testing by automating the encryption of code areas
that will be decrypted at runtime, it also provides a good tool for error
checking using a disassembler (i.e. encrypt the code, disassemble, decrypt the
code, disassemble, compare). In fact, it is a good idea to encapsulate the SMC
portion of your program in a separate executable and test it on the compiled
"release product" until all of the bugs are out of the decryption routine, and
only then add the decryption routine to your final code. The CCh 'landmarks'
(codemarks?) are extremely useful as well.
Finally, do your debugging with debug.com for DOS applications--the debugger
is quick, small, and if it crashes you simply lose a Windows DOS box. The
ability to view the program address space after the program has terminated but
before it is unloaded is another distinct advantage.
More complex examples of SMC programs can be found in Dark Angel's code, the
Rhince engine, or in any of the permutation engines used in ploymorphic
viruses. Acknowledgements go to Sun-Tzu for the stack technique used in his
ghf-crackme program.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Going Ring0 in Windows 9x
by Halvar Flake
This article gives a short overview over two ways to go Ring0 in Windows 9x in
an undocumented way, exploiting the fact that none of the important system
tables in Win9x are on pages which are protected from low-privilege access.
A basic knowledge of Protected Mode and OS Internals are required, refer to
your Assembly Book for that :-) The techniques presented here are in no way a
good/clean way to get to a higher privilege level, but since they require only
a minimal coding effort, they are sometimes more desirable to implement than a
full-fledged VxD.
1. Introduction
---------------
Under all modern Operating Systems, the CPU runs in protected mode, taking
advantage of the special features of this mode to implementvirtual memory,
multitasking etc. To manage access to system-critical resources (and to thus
provide stability) a OS is in need of privilege levels, so that a program can't
just switch out of protected mode etc. These privilege levels are represented
on the x86 (I refer to x86 meaning 386 and following) CPU by 'Rings', with
Ring0 being the most privileged and Ring3 being the least privileged level.
Theoretically, the x86 is capable of 4 privilege levels, but Win32 uses only
two of them, Ring0 as 'Kernel Mode' and Ring3 as 'User Mode'.
Since Ring0 is not needed by 99% of all applications, the only documented way
to use Ring0 routines in Win9x is through VxDs. But VxDs, while being the only
stable and recommended way, are work to write and big, so in a couple of
specialized situations, other ways to go Ring0 are useful.
The CPU itself handles privilege level transitions in two ways: Through
Exceptions/Interrupts and through Callgates. Callgates can be put in the LDT or
GDT, Interrupt-Gates are found in the IDT.
We'll take advantage of the fact that these tables can be freely written to
from Ring3 in Win9x (NOT IN NT !).
2. The IDT method
-----------------
If an exception occurs (or is triggered), the CPU looks in the IDT to the
corresponding descriptor. This descriptor gives the CPU an Address and Segment
to transfer control to. An Interrupt Gate descriptor looks like this:
--------------------------------- ---------------------------------
D D
1.Offset (16-31) P P P 0 1 1 1 0 0 0 0 R R R R R +4
L L
--------------------------------- ---------------------------------
2.Segment Selector 3.Offset (0-15) 0
--------------------------------- ---------------------------------
DPL == Two bits containing the Descriptor Privilege Level
P == Present bit
R == Reserved bits
The first word (Nr.3) contains the lower word of the 32-bit address of the
Exception Handler. The word at +6 contains the high-order word. The word at +2
is the selector of the segment in which the handler resides.
The word at +4 identifies the descriptor as Interrupt Gate, contains its
privilege and the present bit. Now, to use the IDT to go Ring0, we'll create a
new Interrupt Gate which points to our Ring0 procedure, save an old one and
replace it with ours.
Then we'll trigger that exception. Instead of passing control to Window's own
handler, the CPU will now execute our Ring0 code. As soon as we're done, we'll
restore the old Interrupt Gate.
In Win9x, the selector 0028h always points to a Ring0-Code Segment, which spans
the entire 4 GB address range. We'll use this as our Segment selector.
The DPL has to be 3, as we're calling from Ring3, and the present bit must be
set. So the word at +4 will be 1110111000000000b => EE00h. These values can
be hardcoded into our program, we have to just add the offset of our Ring0
Procedure to the descriptor. As exception, you should preferrably use one that
rarely occurs, so do not use int 14h ;-)
I'll use int 9h, since it is (to my knowledge) not used on 486+.
Example code follows (to be compiled with TASM 5):
-------------------------------- bite here -----------------------------------
.386P
LOCALS
JUMPS
.MODEL FLAT, STDCALL
EXTRN ExitProcess : PROC
.data
IDTR df 0 ; This will receive the contents of the IDTR
; register
SavedGate dq 0 ; We save the gate we replace in here
OurGate dw 0 ; Offset low-order word
dw 028h ; Segment selector
dw 0EE00h ;
dw 0 ; Offset high-order word
.code
Start:
mov eax, offset Ring0Proc
mov [OurGate], ax ; Put the offset words
shr eax, 16 ; into our descriptor
mov [OurGate+6], ax
sidt fword ptr IDTR
mov ebx, dword ptr [IDTR+2] ; load IDT Base Address
add ebx, 8*9 ; Address of int9 descriptor in ebx
mov edi, offset SavedGate
mov esi, ebx
movsd ; Save the old descriptor
movsd ; into SavedGate
mov edi, ebx
mov esi, offset OurGate
movsd ; Replace the old handler
movsd ; with our new one
int 9h ; Trigger the exception, thus
; passing control to our Ring0
; procedure
mov edi, ebx
mov esi, offset SavedGate
movsd ; Restore the old handler
movsd
call ExitProcess, LARGE -1
Ring0Proc PROC
mov eax, CR0
iretd
Ring0Proc ENDP
end Start
-------------------------------- bite here -----------------------------------
3. The LDT Method
-----------------
Another possibility of executing Ring0-Code is to install a so- called callgate
in either the GDT or LDT. Under Win9x it is a little bit easier to use the LDT,
since the first 16 descriptors in it are always empty, so I will only give
source for that method here.
A Callgate is similar to a Interrupt Gate and is used in order to transfer
control from a low-privileged segment to a high-privileged segment using a CALL
instruction.
The format of a callgate is:
--------------------------------- ---------------------------------
D D D D D D
1.Offset (16-31) P P P 0 1 1 0 0 0 0 0 0 W W W W +4
L L C C C C
--------------------------------- ---------------------------------
2.Segment Selector 3.Offset (0-15) 0
--------------------------------- ---------------------------------
P == Present bit
DPL == Descriptor Privilege Level
DWC == Dword Count, number of arguments copied to the ring0 stack
So all we have to do is to create such a callgate, write it into one of the
first 16 descriptors, then do a far call to that descriptor to execute our
Ring0 code.
Example Code:
-------------------------------- bite here -----------------------------------
.386P
LOCALS
JUMPS
.MODEL FLAT, STDCALL
EXTRN ExitProcess : PROC
.data
GDTR df 0 ; This will receive the contents of the IDTR
; register
CallPtr dd 00h ; As we're using the first descriptor (8) and
dw 0Fh ; its located in the LDT and the privilege level
; is 3, our selector will be 000Fh.
; That is because the low-order two bits of the
; selector are the privilege level, and the 3rd
; bit is set if the selector is in the LDT.
OurGate dw 0 ; Offset low-order word
dw 028h ; Segment selector
dw 0EC00h ;
dw 0 ; Offset high-order word
.code
Start:
mov eax, offset Ring0Proc
mov [OurGate], ax ; Put the offset words
shr eax, 16 ; into our descriptor
mov [OurGate+6], ax
xor eax, eax
sgdt fword ptr GDTR
mov ebx, dword ptr [GDTR+2] ; load GDT Base Address
sldt ax
add ebx, eax ; Address of the LDT descriptor in
; ebx
mov al, [ebx+4] ; Load the base address
mov ah, [ebx+7] ; of the LDT itself into
shl eax, 16 ; eax, refer to your pmode
mov ax, [ebx+2] ; manual for details
add eax, 8 ; Skip NULL Descriptor
mov edi, eax
mov esi, offset OurGate
movsd ; Move our custom callgate
movsd ; into the LDT
call fword ptr [CallPtr] ; Execute the Ring0 Procedure
xor eax, eax ; Clean up the LDT
sub edi, 8
stosd
stosd
call ExitProcess, LARGE -1
Ring0Proc PROC
mov eax, CR0
retf
Ring0Proc ENDP
end Start
-------------------------------- bite here -----------------------------------
Well, that's all for now folks. This method can be easily changedto use the GDT
instead which would save a few bytes in case you have to optimize heavily.
Anyways, do use these methods with care, they will NOT run on NT and are
generally not exactly a clean or stable way to do these things.
Credits & Thanks
----------------
The IDT-Method taken from the CIH virus & Stone's example source at
http://www.cracking.net.
The LDT-Method was done by me, but without IceMans & The_Owls help I would
still be stuck, so all credits go to them.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................WIN32.ASSEMBLY.PROGRAMMING
Win32 ASM: The Basics
by Iczelion
The required tools:
-Microsoft Macro Assembler 6.1x : MASM support of Win32 programming
starts from version 6.1. The latest version is 6.13 which
is a patch to previous version of 6.11. Win98 DDK includes MASM
6.11d which you can download from Microsoft at
http://www.microsoft.com/hwdev/ddk/download/win98ddk.exe
But be warned, this monstrosity is huge, 18.5 MB in size. MASM 6.13
patch can also be downloaded from
ftp://ftp.microsoft.com/softlib/mslfiles/ml613.exe
-Microsoft import libraries : You can use the import libraries from
Visual C++. Some are included in Win98 DDK.
-Win32 API Reference : You can download it from Borland's site:
ftp://ftp.borland.com/pub/delphi/techpubs/delphi2/win32.zip
Here's a brief description of the assembly process.
MASM 6.1x comes with two essential tools: ml.exe and link.exe. ml.exe is the
assembler. It takes in the assembly source code (.asm) and produces an object
file (.obj) . An object file is an intermediate file between the source code
and the executable file. It needs some address fixups which are the services
provided by link.exe. Link.exe makes an object file into an executable file by
several means such as adding the codes from other modules to the object files
or providing the address fixups, addingr esouces, etc.
For example:
ml skeleton.asm ---> this produces skeleton.obj
link skeleton.obj ---> this produces skeleton.exe
The above lines are simplification of course. In the real world, you must add
several switches to ml.exe and link.exe to customize your application. Also
there will be several files you must link with the object file in order to
create your application.
Win32 programs run in protected mode which is available since 80286. But 80286
is now history. So we only have to concern ourselves with 80386 and its
descendants. Windows run each Win32 program in separated virtual space. That
means each Win32 program will have its own 4 GB address space. Each program is
alone in its address space. This is in contrast to the situation in Win16. All
Win16 programs can *see* each other. Not so in Win32. This feature helps reduce
the chance of one program writing over other program's code/data.
Memory model is also drastically different from the old days of the 16-bit
world. Under Win32, we need not be concerned with memory model or segment
anymore! There's only one memory model: Flat memory model. There's no more 64K
segments. The memory is a large continuous space of 4 GB. That also means you
don't have to play with segment registers. You can use any segment register to
address any point in the memory space. That's a GREAT help to programmers. This
is what makes Win32 assembly programming as easy as C.
We will examine a miminal skeleton of a Win32 assembly program. We'll add more
flesh to it later. Here's the skeleton program. If you don't understand some of
the codes, don't panic. I'll explain each of them later.
.386
.MODEL Flat, STDCALL
.DATA
<Your initialized data>
......
.DATA?
<Your uninitialized data>
......
.CONST
<Your constants>
......
.CODE
<label>
<Your code>
.....
end <label>
That's all! Let's analyze this skeleton program.
.386
This is an assembler directive, telling the assembler to use 80386 instruction
set. You can also use .486, .586 but the safest bet is to stick to .386.
.MODEL FLAT, STDCALL
.MODEL is an assembler directive that specifies memory model of your program.
Under Win32, there's only on model, FLAT model. STDCALL tells MASM about
parameter passing convention. Parameter passing convention specifies the order
of parameter passing, left-to-right or right-to-left, and also who will
balance the stack frame after the function call.
Under Win16, there are two types of calling convention, C and PASCAL C calling
convention passes parameters to the function from right to left, that is , the
rightmost parameter is pushed on the stack first. The caller is responsible for
balancing the stack frame after the call. For example, in order to call a
function named foo(int first_param, int second_param, int third_param) in C
calling convention the asm codes will look like this:
push [third_param] ; Push the third parameter
push [second_param] ; Followed by the second
push [first_param] ; And the first
call foo
add sp, 12 ; The caller balances the stack frame
PASCAL calling convention is the reverse of C calling convention. It pushes
parameters on the stack from left to right and the callee is responsible for
the stack balancing after the call.
Win16 adopts PASCAL convention because it produces smaller codes. C convention
is useful when you don't know how many parameters will be passed to the
function as in the case of wsprintf(). In the case of wsprintf(), the function
has no way to determine beforehand how many parameters will be pushed on the
stack, so it cannot balance the stack correctly. The caller is the one who
knows how many bytes are pushed on the stack so it's right and proper that it's
also the one who balances the stack frame after the call.
STDCALL is the hybrid of C and PASCAL convention. It pushes parameters on the
stack from right to left but the callee is responsible for stack balancing
after the call. Win32 platform use STDCALL exclusively. Except in one case:
wsprintf(). You must use C calling convention with wsprintf().
.DATA
.DATA?
.CONST
.CODE
All four directives are what are called sections. You don't have segments in
Win32 anymore, remember? But you can divide your entire address space into
logical sections. The start of one section denotes the end of the previous
section. There are two groups of section: data and code. Data sections are
divided into 3 categories:
* .DATA This section contains initialized data of your program.
* .DATA? This section contains uninitialized data of your program.
Sometimes you just want to preallocate some memory but doesn't want to
initialize it. This section exists for that purpose.
* .CONST This section contains declaration of constants used by your
program. Constants in this section can never be modified in your
program. They are just *constant*.
You don't have to use all three sections in your program. Declare only the
section(s) you want to use.
There's only one section for code: .CODE. This is where your codes reside.
Example:
<label>
end <label>
...where <label> is any arbitrary label is used to specify the extent of your
code. Both labels must be identical. All your codes must reside between
<label> and end <label>
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................WIN32.ASSEMBLY.PROGRAMMING
MessageBox Display
by Iczelion
We will create a fully functional Windows program that displays a message box
saying "Win32 assembly is great!".
Windows prepares a wealth of resources for use by Windows programs. Central to
this is the Windows API (Application Programming Interface). Windows API is a
huge collection of very useful functions that resides in Windows itself, ready
to be used by any Windows programs.
These functions are stored in several dynamic-linked libraries (DLLs) such as
kernel32.dll, user32.dll and gdi32.dll, to name a few. Kernel32.dll contains
API functions that deal with memory and process management. User32.dll controls
the user interface aspects of your programs. Gdi32.dll is responsible for
graphics operation. Other than "the main three", there are other DLLs that your
program can make use of, provided you have enough information about the desired
API functions stored in them.
Windows programs dynamically link to these DLLs, i.e. the codes of API
functions are not included in the executable file. This is very different from
what's called static linking in which actual codes from software libraries are
included in the executable files. In order for programs to know where to find
the desired API functions at runtime, enough information must be embedded into
the executable file for it to be able to select the correct DLLs and correct
functions. That information is in import libraries. You must link your
programs with the correct import libraries or it will not be able to locate
the desired API functions.
There are two types of API functions: One for ANSI and the other for Unicode.
The name of API functions for ANSI are postfixed with "A", eg. MessageBoxA.
Those for Unicode are postfixed with "W" (for Wide Char, I think).
Windows 95 natively supports ANSI and Windows NT Unicode. But most of the time,
you will use an include file which can determine and select the appropriate API
functions for your platform. Just refer to the API function name without the
postfix.
I'll present the bare program skeleton below. We will fill it out later.
.386
.model flat, stdcall
.data
.code
Main:
end Main
Every Windows program must call an API function, ExitProcess, when it wants to
quit to Windows. In this respect, ExitProcess is equivalent to int 21h, ah=4Ch
in DOS.
Here's the function prototype of ExitProcess from winbase.h:
void WINAPI ExitProcess(UINT uExitCode);
-void means the function does not return any value to the caller.
-WINAPI is an alias of STDCALL calling convention.
-UINT is a data type, "unsigned integer", which is a 32-bit value under Win32
(it's a 16-bit value under Win16)
-uExitCode is the 32-bit return code to Windows. This value is not used by
Windows as of now.
In order to call ExitProcess from an assembly program, you must first declare
the function prototype for ExitProcess.
.386
.model flat, stdcall
ExitProcess PROTO :DWORD
.data
.code
Main:
invoke ExitProcess, 0
end Main
That's it. Your first working Win32 program. Save it under the name msgbox.asm.
Assuming ml.exe is in your path, assemble msgbox.asm with:
ml /c /coff /Cp msgbox.asm
/c tells MASM to assemble the source file into an object file only. Do not
invoke Link.exe automatically.
/coff tells MASM to create .obj file in COFF format.
/Cp tells MASM to preserve case of user identifiers
Then go on with link:
link /SUBSYSTEM:WINDOWS /LIBPATH:c:\masm\lib msgbox.obj
kernel32.lib
/SUBSYSTEM:WINDOWS informs Link.exe on which platform the executable is
intended to run
/LIBPATH:<path to import library> tells Link where the import libraries
are. In my PC, they're located in c:\masm\lib.
Now that you get msgbox.exe. Go on, run it. You'll find that it does nothing.
Well, we haven't put anything interesting in it yet. But it's a Windows
program nonetheless. And look at its size! In my PC, it is 1,536 bytes.
The line:
ExitProcess PROTO :DWORD
is a function prototype. You create one by declaring the function name followed
by the keyword "PROTO" and lists of data types of the parameters prefixed by
colons. MASM uses function prototypes to type checking which will prevent nasty
stack errors that may pass unnoticed otherwise.
The best place for function prototypes is in an include file. You can create an
include file full of frequently used function prototypes and data structures
and include it at the beginning of your asm source code.
You call the API function by using "invoke" keyword:
invoke ExitProcess, 0
INVOKE is really a kind of high-level call. It checks number and types of
parameters and pushes parameters on the stack according to the specified
calling convention (in this case, stdcall). By using INVOKE instead of a normal
call, you can prevent stack errors from incorrect parameter passing. Very
useful. The syntax is:
INVOKE expression [,arguments]
where expression is a label or function name.
Next we're going to put a message box in our program. Its function declaration
is:
int WINAPI MessageBoxA(HWND hwnd, LPCSTR lpText, LPCSTR lpCaption, UINT
uType);
-hwnd is the handle to parent window
-lpText is a pointer to the text you want to display in the client area of the
message box
-lpCaption is a pointer to the caption of the message box
-uType specifies the icon and the number and type of buttons on the message
box
Under Win32 , HWND, LPCSTR, and UINT are all 32 bits in size.
Let's modify msgbox.asm to include the message box.
.386
.model flat, stdcall
ExitProcess PROTO :DWORD
MessageBoxA PROTO :DWORD, :DWORD, :DWORD, :DWORD
.data
MsgBoxCaption db "Our First Program",0
MsgBoxText db "Win32 Assembly is Great!",0
.const
NULL equ 0
MB_OK equ 0
.code
Main:
INVOKE MessageBoxA, NULL, ADDR MsgBoxText, ADDR MsgBoxCaption, MB_OK
INVOKE ExitProcess, NULL
end Main
Assemble it by:
ml /c /coff /Cp msgbox.asm
link /SUBSYSTEM:WINDOWS /LIBPATH:c:\masm\lib msgbox kernl32.lib
user32.lib
You have to include user32.lib in your Link parameter, since link info of
MessageBoxA is in user32.lib.
You'll see a message box displaying the text "Win32 Assembly is Great!". Let's
look again at the source code:
We define two zero-terminated strings in .data section. Remember that all
strings in Windows must be terminated with zero (ASCIIZ).
We define two constants in .const section. We use constants to improve the
clarity of the source code.
Look at the parameters of MessageBoxA. The first parameter is NULL. This
means that there's no window that *owns* this message box.
The operator "ADDR" is used to pass the address of the label to the function.
This operator is specific to MASM. No TASM-equivalent exists. It functions like
"OFFSET" operator but with some differences:
1. It doesn't accept forward reference. If you want to use "ADDR foo",
you have to declare "foo" before using ADDR operator.
2. It can be used with a local variable. A local variable is the
variable that is created on the stack. OFFSET operator cannot be
used in this situation because the assembler doesn't know the true
address of the local variable at assemble time.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::........................THE.C.STANDARD.LIBRARY.IN.ASSEMBLY
The _itoa, _ltoa and _ultoa functions
by Xbios2
ATTENTION I:
This is based on Borland's C++ 4.02. Whenever possible I've checked it with any
other library / program containing the specific functions, but differences may
exist between this and your version of C. Also this is strictly 32-bit code,
Windows compiler. No DOS or UNIX.]
ATTENTION II:
Size comparisons are extremely easy to do. Speed comparison's aren't. The diff-
erences in speed I give are based on RDTSC timings, but they DON'T take into
account extreme cases. That's why I don't give exact clock cycles. Of course if
you need exact clock cycles for your Pentium II, you can always buy me one :)
The C language offers three functions to convert an integer to ASCII:
char *itoa(int value, char *string, int radix);
char *ltoa(long value, char *string, int radix);
char *ultoa(unsigned long value, char *string, int radix);
_itoa and _ltoa do _exactly_ the same thing. This is because an integer _is_ a
long in 32-bit code. Yet they are different: _itoa has some _completely_
useless code in it (in 16bit this code would sign-extend value if radix=10).
Yet the result is always the same, so _ltoa from here on means both _ltoa and
_itoa. _ultoa is exactly the same as _ltoa and _itoa, except when radix=10 and
value < 0.
Anyway all these functions call this function:
___longtoa(value, *string, radix, signed, char10)
The first three parameters are passed 'as is', signed is set to 1 by _ltoa if
radix=10 else it is set to 0 and char10 is the character that corresponds to 10
if radix>10, and is always set to 'a' (___longtoa is also used by printf, which
has an option to have uppercase chars in Hex).
___longtoa does the following (and it does it with badly written code):
1. Checks that 2<=radix<=36, if it isn't returns '0'
2. If signed=1 and value<0 add a '-' to the string and neg the value
3. Loop1: create a pseudo-string in the stack, reversed
4. Loop2: convert and copy the pseudo-string into string
The check on radix is necessary because:
radix=0 would generate an INT0 (divide by zero)
radix=1 would put the program in an infinite loop, destroying the stack
radix=37 for value=36 would return '}', the character after 'z'
The two loops are necessary because of the way the conversion is done (see code
later). To implement a single-loop conversion, the number of digits should be
calculated in advance, which results in less efficient code (the number of
digits in value is n=(int)(log(value)/log(radix))+1, but using one more loop is
much faster).
Including the disassembly of C's functions would create a really large article,
and anyway they're just examples of really bad code. So straight to the result:
ltoa proc
cmp dword ptr [esp+0Ch], 10
sete ch
mov cl, 'a'-'0'-10
jmp short longtoa
ultoa:
mov cx, 'a'-'0'-10
longtoa:
push ebx
push edi
push esi
sub esp, 24h
mov ebx, [esp+3Ch] ; radix
mov eax, [esp+34h] ; value
mov edi, [esp+38h] ; string
cmp ebx, 2
jl short _ret
cmp ebx, 36
jg short _ret
or eax, eax
jge short skip
cmp byte ptr ch, 0 ; _ltoa ?
jz short skip
mov byte ptr [edi], '-'
inc edi
neg eax
skip: mov esi, esp
loop1: xor edx, edx
div ebx
mov [esi], dl
inc esi
or eax, eax
jnz loop1
loop2: dec esi
mov al, [esi]
cmp al, 10
jl short nochar
add al, cl
nochar: add al, '0'
stosb
cmp esi, esp
jg short loop2
_ret: mov byte ptr [edi], 0
mov eax, [esp+38h]
add esp, 24h
pop esi
pop edi
pop ebx
ret
ltoa endp
This is a 3 into 1 procedure. ltoa and ultoa take the same parameters as the
standard C functions. longtoa was changed to take from the stack the same
parameters as ltoa and ultoa, while signed and char10 are passed in CH and CL
respectively. This way ltoa and ultoa 'see' longtoa as 'their' code, not as a
different procedure (this is to avoid a common problem in C, procedures that
just 'forward' their parameters to another function).
This code compiles to 102 bytes (and it could be optimized to gain some more
bytes) whereas the standard C code takes 270 bytes. Specifically:
function C size Asm size
------------------------------
itoa 60 0
ltoa 40 12
ultoa 27 4
longtoa 143 86
------ ------
total 270 102
It also runs 2x faster than ltoa. And of course, this is a fully C-compatible
version of ltoa and ultoa. Of course it can be changed from C-compatible to
suit specific needs (e.g make it stdcall instead of cdecl, or if speed and size
are needed remove the check for the radix, and so on...)
Anyway, it is rather strange that you'll ever use values of radix other than 2,
8, 10 or 16. So if speed or size is of essence, a better, more specific routine
can be written. For example, consider this routine which stores the value of
EAX as a binary number at the address specified by EDI:
ultob proc
mov ecx, 32
more1: shl eax, 1
dec ecx
jc more2
jnl more1
more2: setc dl
add dl, '0'
shl eax, 1
mov [edi], dl
inc edi
dec ecx
jnl more2
mov [edi], al
ret
ultob endp
This runs 14x faster than C ltoa, and 7x faster than Asm ltoa, and is only 29
bytes long. But this article is long enough, so wait for another article on
specific 'ltoa' functions (who knows, maybe if I decide to write a 'printf'
function in Asm, which would use them...).
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::............................................THE.UNIX.WORLD
x86 ASM Programming for Linux
by mammon_
Essentially this article is an excuse to combine two of my favorite coding
interests: the Linux operating system and assembly language programming. Both
of these need (or should need) no introduction; like Win32 assembly, Linux
assembly runs in 32-bit protected mode...however it has the distinct advantage
of allowing you to call the C standard library functions as well as any of the
usual Linux "shared" library functions. I have begun with a brief introduction
on compiling assembly language programs in Linux; for greater readability you
may want to skip over this to the "Basics" section.
Compiling And Linking
---------------------
The two main assemblers for Linux are Nasm, the (free) Netwide Assembler, and
GAS, the (also free) Gnu Assembler which is integrated into GCC. I will focus
on Nasm in this article and leave GAS for a later date, as it uses the AT&T
syntax and thus would require a lengthy introduction.
Nasm should be invoked with the ELF format option ("nasm -f elf hello.asm");
the resulting object is linked with GCC ("gcc hello.o") to produce the final
ELF binary. The following script can be used to compile ASM modules; I wrote
it to be very simple, so all it does is take the first filename passed to it
(I recommend naming it with a ".asm" extension), compile it with nasm, and
link it with gcc.
#!/bin/sh
# assemble.sh =========================================================
outfile=${1%%.*}
tempfile=asmtemp.o
nasm -o $tempfile -f elf $1
gcc $tempfile -o $outfile
rm $tempfile -f
#EOF ==================================================================
The Basics
----------
It is best, of course, to start off with an example before launching into the
OS details. Here is a very basic, "hello-world"-style program:
; asmhello.asm ========================================================
global main
extern printf
section .data
msg db "Helloooooo, nurse!",0Dh,0Ah,0
section .text
main:
push dword msg
call printf
pop eax
ret
; EOF =================================================================
A quick rundown: the "global main" must be declared global--and since we are
using the GCC linker, the entrypoint must be named "main"--for the OS loader.
The "extern printf" is simply a declaration for the call later in the program;
note that this is all that is needed; the parameter sizes do not need to be
declared. I have sectioned this example into the standard .data and .text
sections, though this is not strictly necessary--one could get by with only a
.text segment, just as in DOS.
In the body of the code, note that you must push the parameters to the call,
and in Nasm you must declare the size of all ambiguous (i.e. non-register)
data: hence the "dword" qualifier. Note that just as inother assemblers, Nasm
assumes that any memory/label reference is intended to mean the address of the
memory location or label, not its contents. Thus, to specify the address of
the string 'msg' you would use 'push dword msg', while to specify the contents
of the string 'msg' you would use 'push dword [msg]' (note this will only
contain the first 4 bytes of 'msg'). As printf requires a pointer to a string,
we will specify the address of 'msg'.
The call to printf is pretty straightforward. Note that you must clean up the
stack after every call you make (see below); thus, having PUSHed a dword, I
POP a dword from the stack into a "throwaway" register. Linux programs end
simply with a RET to the OS, as each process is spawned from the shell (or PID
1 ;) and ends by returning control to it.
Notice that in Linux you use the standard shared libraries that are shipped
with the OS in lieu of an "API" or Interrupt Services. All external references
will be taken care of by the GCC linker which takes a lot of the workload off
the asm coder. Once you get used to the basic quirks, coding assembly in Linux
is actually easier than on a DOS-based machine!
The C Calling Syntax
--------------------
Linux uses the C calling convention--meaning that arguments are pushed onto the
stack in reverse order (last arg first), and that the caller must cleanup the
stack. You can do this either by popping values from the stack:
push dword szText
call puts
pop ecx
or by directly modifying ESP:
push dword szText
call puts
add esp, 4
Results from the call are returned in eax or edx:eax if the value is greater
than 32-bit. EBP, ESI, EDI, and EBX are all saved and restored by the caller.
Note that you must preserve any other registers you use, as the following will
illustrate:
; loop.asm ========
=========================================================
global main
extern printf
section .text
msg db "HoodooVoodoo WeedooVoodoo",0Dh,0Ah,0
main:
mov ecx, 0Ah
push dword msg
looper:
call printf
loop looper
pop eax
ret
; EOF ======================================================================
On first glance this looks pretty simple: since you are going to use the same
string on the 10 printf() calls, you do not need to clean up the stack. Yet
when you compile this, the loop never stops. Why? Because somewhere in the
printf() call ECX is being used and isn't saved. So to make your loop work
properly you must save the count value in ECX before the call and restoe it
afterwards, as so:
; loop.asm ================================================================
global main
extern printf
section .text
msg db "HoodooVoodoo WeedooVoodoo",0Dh,0Ah,0
main:
mov ecx, 0Ah
looper:
push ecx ;save Count
push dword msg
call printf
pop eax ;cleanup stack
pop ecx ;restore Count
loop looper
ret
; EOF ======================================================================
I/O Port Programming
--------------------
But what about direcr hardware access? In Linux you need a kernel-mode driver
to do anything really tricky...this means your program will end up being two
parts, one kernel-mode that provides the direct-hardware functionality, the
other user-mode to provide an interface. The good news is that you can still
access ports using the IN/OUT commands from a user-mode program.
To access the I/O ports your program must be granted permission by the OS; to
do that, you must make an ioperm() call. This function can only be called by a
user with root access, so you must either setuid() the program to root or run
the program as root. The ioperm() has the following syntax:
ioperm( long StartingPort#, long #Ports, BOOL ToggleOn-Off)
which means that 'StartingPort#' specifies the first port number to access (0
is port 0h, 40h is port 40h, etc), '#Ports' specifies how many ports to access
(i.e., 'StartingPort# = 30h' and '#Ports = 10' would provide access to ports
30h-39h), and 'ToggleOn-Off' enables access if TRUE (1) or disables access if
FALSE (0).
Once the call to ioperm() is made, the requested ports may be access as
normal. The program can call ioperm() any number of times and does not need to
make a subsequent ioperm() call (though the example below does so) as the OS
will take care of this.
; io.asm ====================================================================
BITS 32
GLOBAL szHello
GLOBAL main
EXTERN printf
EXTERN ioperm
SECTION .data
szText1 db 'Enabling I/O Port Access',0Ah,0Dh,0
szText2 db 'Disabling I/O Port Acess',0Ah,0Dh,0
szDone db 'Done!',0Ah,0Dh,0
szError db 'Error in ioperm() call!',0Ah,0Dh,0
szEqual db 'Output/Input bytes are equal.',0Ah,0Dh,0
szChange db 'Output/Input bytes changed.',0Ah,0Dh,0
SECTION .text
main:
push dword szText1
call printf
pop ecx
enable_IO:
push word 1 ; enable mode
push dword 04h ; four ports
push dword 40h ; start with port 40
call ioperm ; Must be SUID "root" for this call!
add ESP, 10 ; cleanup stack (method 1)
cmp eax, 0 ; check ioperm() results
jne Error
;---------------------------------------Port Programming Part--------------
SetControl:
mov al, 96 ; R/W low byte of Counter2, mode 3
out 43h, al ; port 43h = control register
WritePort:
mov bl, 0EEh ; value to send to speaker timer
mov al, bl
out 42h, al ; port 42h = speaker timer
ReadPort:
in al, 42h
cmp al, bl ; byte should have changed--this IS a timer :)
jne ByteChanged
BytesEqual:
push dword szEqual
call printf
pop ecx
jmp disable_IO
ByteChanged:
push dword szChange
call printf
pop ecx
;---------------------------------------End Port Programming Part----------
disable_IO:
push dword szText2
call printf
pop ecx
push word 0 ; disable mode
push dword 04h ; four ports
push dword 40h ; start with port 40h
call ioperm
pop ecx ;cleanup stack (method 2)
pop ecx
pop cx
cmp eax, 0 ; check ioperm() results
jne Error
jmp Exit
Error:
push dword szError
call printf
pop ecx
Exit:
ret
; EOF ======================================================================
Using Interrupts In Linux
-------------------------
Linux is a shared-library environment running in protected mode, meaning there
are no interrupt services. Right?
Wrong. I noticed an INT 80 call on some GAS sample source code with the
comment "sys_write(ebx, ecx, edx)". This function is part of the Linux syscall
interface, which means that the interrupt 80 must be a gate into the syscall
services. Poking around in the Linux source code (and ignoring warnings to
NEVER use the INT 80 interface as the function numbers may be changed at any
time), I found the "system call numbers" --that is, what function # to pass on
to INT 80 for each syscall routine-- in the file UNISTD.H. There are 189 of
them, so I will not list them here...but if you are going to be doing Linux
assembly, do yourself a favor and print this file out.
When calling INT 80h, eax must be set to the desired function number. Any
parameters to the syscall routine must be placed in the following registers in
order:
ebx, ecx, edx, esi, edi
so that parameter one is placed in ebx, parameter 2 in ecx, etc. Note that
there is no stack used to pass values to a syscall routine. The result of the
call will be returned in eax.
Other than that, the INT 80 interface is the same as regular calls (only a bit
more fun ;). The following program demonstrates a simple INT 80h call in which
a program checks and display its own PID. Note the use of printf() format
string-- it is best to psuedocode this as a C call first, then make the format
string a DB and to push each variable passed (%s, %d, etc). The C structure
for this call would be
printf( "%d\n", curr_PID);
Note also that the escape sequences ("\n") are not all that reliable in
assembly; I had to use the hex values (0Ah,0Dh) for the CR\LF.
;pid.asm====================================================================
BITS 32
GLOBAL main
EXTERN printf
SECTION .data
szText1 db 'Getting Current Process ID...',0Ah,0Dh,0
szDone db 'Done!',0Ah,0Dh,0
szError db 'Error in int 80!',0Ah,0Dh,0
szOutput db '%d',0Ah,0Dh,0 ;weird formatting is for printf()
SECTION .text
main:
push dword szText1 ;opening message
call printf
pop ecx
GetPID:
mov eax, dword 20 ; getpid() syscall
int 80h ; syscall INT
cmp eax, 0 ; there will never be PID 0 ! :)
jb Error
push eax ; pass return value to printf
push dword szOutput ; pass format string to printf
call printf
pop ecx ; cleanup stack
pop ecx
push dword szDone ; ending message
call printf
pop ecx
jmp Exit
Error:
push dword szError
call printf
pop ecx
Exit:
ret
; EOF =====================================================================
Final Words
-----------
Most of the trouble is going to come from getting used to Nasm itself. While
nasm does come with a man page, it does not by default install it, so you must
move it (cp or mv) from
/usr/local/bin/nasm-0.97/nasm.man
to
/usr/local/man/man1/nasm.man
The formatting is a little messed up, but that is easily fixed using the nroff
directives. It still does not give you the entire Nasm documentation, however;
for that, copy nasmdoc.txt from
/usr/local/bin/nasm-0.97/doc/nasmdoc.txt
to
/usr/local/man/man1/nasmdoc.man
Now you cam invoke the nasm man page with 'man nasm' and the nasm documentation
with 'man nasmdoc'.
For further information, check out the following:
Linux Assembly Language HOWTO
Linux I/O Port Programming Mini-HOWTO
Jan's Linux & Assembler HomePage (bewoner.dma.be/JanW/eng.html)
Also I owe a bit of thanks to Jeff Weeks at code^x software (gameprog.com/codex)
for forwarding me a couple of GAS hello-world's in the dark days before I
found Jan's page.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................ISSUE.CHALLENGE
11-byte Program Displays Its Command-Line
by Xbios2
The Challenge
-------------
Write an 11-byte program that displays its command line.
The Solution
------------
Before saying that these programs won't work, try them. Some of them work only
after you've run them twice. Anyway, they' ve been tested both under Windows
and plain DOS and they work. Believe it or not, these are the first programs
I've ever written in DOS, so I just tried various ideas until some worked, even
thought I thought they wouldn't... :)
The command line in DOS is found in the PSP (Program Segment Prefix) which in
.COM files occupies the first 100h bytes in the segment. At offset 80h, a
<count, char> string (first byte is length of string, and n bytes follow)
contains everything typed after the filename. The last character in this string
is a CR (carriage return).
The requested program should be composed of three parts:
1. set up pointers to data
2. display data
3. exit
Actually all the following programs DON'T include part 3, but read on. The
data (command line) can be printed either as a single string, or character by
character.
APPROACH 1: Print single string
-------------------------------
For the first approach there are two interrupts:
1. INT 21, 9 ; write $ terminated string
2. INT 21, 40 ; write to file using handle
For the first case, part 2 would be:
mov ah, 9
mov dx, 81h
int 21h
that makes 7 bytes, leaving only 4 bytes to replace the last CR with a '$',
which are too few. (Actually, if the user would type a $ as the last character
in the comand line, this would make the smallest possible program.) The short-
est program I managed to write is:
shr si,1 ; D1 EE
lodsb ; AC
push si ; 56
add si,ax ; 03 F0
mov byte ptr [si],'$' ; C6 04 24
xcgh bp,ax ; 95
pop dx ; 5A
int 21 ; CD 21
For the second case, the smallest program would be this:
; Solution I
mov dx, 81h ; BA 81 00
mov cl, ds:[80h] ; 8A 0E 80 00
mov ah, 40h ; B4 40
int 21h ; CD 21
The first two lines are part 1 (set up pointers) and the other two are part 2
(display string). If you think that something is missing you're right: we don't
set BX (the handle).
APPROACH 2: Print char by char
------------------------------
For the second approach there are two interrupts:
1. INT 21, 2 ; write char in dl
2. INT 29 ; write char in al
Of course the second interrupt is better, since there is no need to load ah
with a function value. In addition, INT 29 reads the char from AL, so it can be
used together with LODSB.
The first way to implement this approach is to minimize part 2 (display loop).
A program that does this is the following:
; Solution II
mov si, 80h ; BE 80 00
lodsb ; AC
mov cl, al ; 8A C8
more: lodsb ; AC
int 29h ; CD 29
loop more ; E2 FB
This program printed CX characters. The second way to print the string is to print up to the CR. Here is how:
; Solution III
mov si, 81h ; BE 81 00
more: lodsb ; AC
int 29h ; CD 29
cmp al, 13 ; 3C 0D
jne more ; 75 F9
nop ; 90
Yes, the last instruction IS a NOP. So we have an 11-byte program that works,
and even has a NOP in it. Removing the NOP creates an even crazier program that
is 10 bytes long, displays it's command line AND waits for a key press before
terminating... Actually solution II, by substituting MOV SI,80h with SHR SI,1,
does the same thing (10 bytes that display the command line and wait for the
user to press a key).
BTW: I really don't know why these programs work, though I have one or two
theories...
Next Issue Challenge
--------------------
Write the smallest possible PE program (win32) that outputs it's command line.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::.......................................................FIN
