| Assembly and Cracking From the Ground Up |
| An Introduction by Greythorne the Technomancer |
|
by now you should to follow what it going on... ;**********************************************
;
; Command Line Reading: Part 1 (CLINE1.ASM)
;
; Compile with:
;
; TASM CLINE1.ASM
; TLINK /t CLINE1.OBJ
;
; Test run it like this:
;
; CLINE1 abcd efgh ijklmn
; CLINE1 abcd EF$ ghi
; CLINE1/abcdefg <-- note the '/' is a special case
;
; +gthorne'99
;
; ever wonder when you type "tlink /t filename"
; exactly where is stores the "/t" and "filename"
; so you can use that knowledge in your own code?
;
; the win32 guru HUTCH has started sending me some
; of his own command line code so i think i really
; need to post this stuff before he does all my work
; for me ;)
;
;**********************************************
; just a simple com program here...
COM_PROG segment byte public
ideal
assume cs:COM_PROG
org 100h
start: jmp MAIN_PROGRAM
;----------------------
; Your Data Here
;----------------------
CommandLen db 0
CommandLine db 128 dup (0)
;----------------------
MAIN_PROGRAM:
;---------------
; Your Code Here
;---------------
xor cx, cx ; set CX to zero (CL and CH are both zeroed)
mov cl, [80h] ; get length
mov [CommandLen], cl ; store length
jcxz @@Done ; if CX=0, skip the command line
; for each tasm compiled program in its PSP header...
; the command line entered by the user exists at 81h in RAM
; so assembly functions can read the string that sits there
; to get any command line switches or file names that are
; specified by the user ( in "tlink /t filename" for example,
; the arguments "/t" and "filename" are what we are extracting here)
; note that at 80h is the actual length of the command line
; but that length cannot exceed 128 bytes because thats all the
; space allocated to it by the compiler anyway - this is why
; the CommandLine buffer was set at 128 bytes in size above
; a hint... always copy the command line before doing anything
; else in your program, as this memory space is clobbered later
; and if you did not make a copy of it, you will have lost it
; before you have need of it (store it in a buffer for later use)
; i usually dont even make this a function call and do it directly
; before the main code even starts for safety sake
; for those of you who may have seen the symbiote program i wrote,
; it does a minimalist version of this and just gets the first
; argument from the command line (reads from 81h until it hits
; the end of a word, where it forces a end-of-string and ignores
; any further text) this is fine for a program that needs only one
; argument - which many command line programs often do - but for
; general purposes this is not enough (try typing dir /? sometime
; to see just how many command line options the directory command has)
mov si, 81h ; The source register points at the user's command line
mov di, offset CommandLine ; set up destination string buffer
cld ; allow string copy to commence
@@Loop: ; start of loop
lodsb ; copy a byte from string at SI into AL
cmp al, ' ' ; see if the byte stored in AL is a space (character 20)
jne @@NotSpace ; if not equal, go on
mov al, 0 ; otherwise, make it a zero
@@NotSpace:
stosb ; copy a byte from AL into string at DI
loop @@Loop ; decrement cx and loop again
; If we are here, we have completed the string copy
inc di ; putting a '$' after the end
mov al, '$' ; so it can be viewed with
stosb ; DOS INT 21, AH=9 (printstring)
;***********************
; display it for debugging (disable this in your own programs)
;***********************
mov dx, offset CommandLine
mov ah, 09h
int 21h
;***********************
; we have a huge amount of leeway here in assembler, and that
; should be taken into consideration -- if for instance our
; command line arguments need to be able to use the $, then it
; should be obvious that using it as the end-of-string character
; is a bad idea -- if say we were entering prices, the first dollar
; symbol that we hit is going to be treated like the end, and
; we never get to see the rest of it
; why did i do this then? two reasons... 1) to show you we can do
; whatever the heck we want with assembly, and 2) because it is
; nice and convenient to have our little dos printstring command
; display something for us whenever we need to debug our own code
; more useful would be to only use the 0 as end of string, since
; null (not zero which is ascii code 30 in hex) but actually code 00
; so we dont mistaken it for the number zero if it were to be typed in)
; that's fine since there are DOS considerations for ASCIIZ strings
; (techno-babble for strings that end with a zero byte) and just about
; any compiled language uses a zero as an end-of-string marker anyway
; how to enhance this further... include a check for character 09 (tab key)
; since sometimes users will hit a tab instead of the spacebar
@@Done:
;---------------
; now that we have stored our command line in a buffer,
; we can go onto the real guts of any program and use
; it any time we like - normally the next step is to
; have a command line parser function weed out which
; command line arguments start with / or - and which
; ones do not - the ones that do not are usually files
;---------------
mov ah,4ch ; quit to DOS
int 21h
ends COM_PROG
end start
if you are interested in learning how to make this stuff work for you, PLEASE attempt to do the small suggestions I place here and there in the lessons as to what should be attempted and you will realize exactly how easy most of the assembly basics really are once you get used to all the silly acronyms As always, feel free to use any code I give you in your own programs, the idea here is for you to take what i have and expand on it so that it suits the needs of your own applications Hopefully you are developing your own ideas as to what you want to do with all this |
| +gthorne'99 |