Author Topic: command line arguments  (Read 14037 times)

nobody

  • Guest
command line arguments
« on: February 08, 2008, 02:53:48 PM »
Hi,

all the time I'm asking "where to access command line arguments" *argc or *argv I get [esp+4] and [esp+8].
OK, that's true for linux etc. but I'm working on Windows - and there this answer is wrong!
Anybody an idea where to address them on Windows?

Actually, I'm using the work arround __GetMainArgs from crtdll.dll

nobody

  • Guest
Re: command line arguments
« Reply #1 on: February 08, 2008, 07:29:18 PM »
Oh, Windows. Are you still using *that*??? :)

I don't do Windows, but Numit_or recently posted this example on the Yahoo group. It is intended to test MapAndLoad (which wasn't working on Alink-produced executables - Numit_or has patched Alink, too!), but gets a command line argument too. It may be useful...

Best,
Frank

; ---

[EXTERN GetCommandLineA]
[EXTERN WriteConsoleA]
[EXTERN GetStdHandle]
[EXTERN MapAndLoad]
[EXTERN UnMapAndLoad]
[EXTERN ExitProcess]
[EXTERN RtlZeroMemory]
[EXTERN lstrlen]

struc LOADED_IMAGE
.ModuleName resd 1
.hFile resd 1
.MappedAddress resd 1
.FileHeader resd 1
.LastRvaSection resd 1
.NumberOfSections resd 1
.Sections resd 1
.Characteristics resd 1
.fSystemImage resd 1
.fDOSImage resd 1
.Links resd 1
.SizeOfImage resd 1
endstruc

%define STD_OUTPUT_HANDLE -11 ; 0xFFFFFFF5

; --------------------------------------------------------
[section .bss]

StdHandle RESD 1
bytesWritten RESD 1
FileName RESB 256
li RESB LOADED_IMAGE_size

; --------------------------------------------------------
[section .data]

msg0 db "No filename passed",13,10,0
msg1 db "This program calls the MapAndLoad api",13,10,0
msg2 db "Image loaded",13,10,0
msg3 db "Image unloaded",13,10,0
msg4 db "Error!",13,10,0

; --------------------------------------------------------
[section .text]
; Numa Tortolero <numator@cantv.net>

global start
start:
push byte STD_OUTPUT_HANDLE
call GetStdHandle
cmp eax, -1
je near .exit

mov [StdHandle], eax

push msg1
call Print

; Get and process the command line:
call GetCommandLineA

push FileName
push eax
call ProcessCommandLine
or eax, eax
jne .loadimage

push msg0
call Print
jmp .exit

.loadimage:
push byte 1
push byte 0
push li
push byte 0
push FileName
call MapAndLoad
test eax, eax
je .error

push eax

push msg2
call Print

push li
call UnMapAndLoad

push msg3
call Print

.exit:
push byte 0
call ExitProcess

.error:
push msg4
call Print
jmp .exit


;; -------------------------


Print:
push ebp
mov ebp, esp

push dword [ebp+8] ; Numa Tortolero <numator@cantv.net>
call lstrlen
inc eax

push byte 0
push bytesWritten ; returns number of bytes written
push eax ; string length
push dword [ebp+8]
push dword [StdHandle]
call WriteConsoleA

pop ebp
ret

;; -------------------------

;; Process CommandLine
ProcessCommandLine:
push ebp
mov ebp, esp
push edi
push esi

; clear the bufer for first argument
mov edi, [ebp+12]
push dword 256
push edi
call RtlZeroMemory

mov esi, [ebp+8] ; addr into esi for strlen call
push esi
call lstrlen ; get length of string
mov ecx, eax

; find the begin of the first argument:
cdq
or edx, 0000D20h
.firstspace:
lodsb
cmp al, dl ; first space (20h)
jne .firstspace

cmp al, dh ; end of line (0Dh)?
je .return

.skipspace:
lodsb
cmp al, dl ; skip other spaces
je .skipspace

cmp al, dh ; end of line?
je .return

dec esi
mov eax, esi
rep movsb ; move the first argument to my buffer
cdq
mov [edi], dl ; add zero to the end of buffer

.return:
pop esi
pop edi
pop ebp
ret

nobody

  • Guest
Re: command line arguments
« Reply #2 on: February 08, 2008, 09:31:16 PM »
Yes, ok,
that's essentially the same solution using GetCommandLineA from kernel32.dll - an alternative solution, again using a windows "system call". But, I hoped to find a solution similar to [ebp+???] reading the command line string directly out of some memory location without loading ntdll.dll, kernel32.dll, crtdll.dll, etc.
Any idea about that?
Thx, green fix

nobody

  • Guest
Re: command line arguments
« Reply #3 on: February 09, 2008, 12:56:27 PM »
Oh, i mssed your initial comment ...
Yes, I'm still using *that* ... I have to, sorry ;-)
green fix