Page 2 of 3
Posted: Thu Aug 11, 2005 3:50 pm
by thefool
well to call procedures/functions using CALL, you PUSH the parameters to the stack!
basically the api's are called from dll's as user32.dll and kernel32.dll.
so this can be used for all dll's, and the kernel/windows dll's that is holding the api functions too.!
The reason [afaik] killswitch wanted to know how to do it using winapi is, that he is programming an scripting language, and as a good programmer he doesnt just wrap the pb functions for calling dll's.
Posted: Thu Aug 11, 2005 3:56 pm
by Kale
like:
Code: Select all
variableone=0
variabletwo=292991
variableone=variabletwo
Where is the memory reserving there?
Easy, as soon as you use a var its defaulted to a long (4 bytes). in this case 4 bytes are allocated to store the integers in both vars.
in this code:
Code: Select all
GetCurrentDirectory=GetProcAddress_(module,"GetCurrentDirectoryA")
size.l=512
CurDir.l= 0
ptrDir.l = @CurDir
!PUSH [v_ptrDir]
!PUSH [v_size]
!CALL [v_GetCurrentDirectory]
Debug PeekS(@CurDir)
My confusion:
1). CurDir.l is a long.
2). ptrDir.l is a long holding the pointer to the long contained in CurDir.
3). No memory allocation for the string is taking place.
4). After the procedure call the string is stuffed into the memory pointed to by ptrDir overwriting the long contained in CurDir?
5). CurDir now holds a string and im thinking an overflow has occured?
6). Confused.
I dont suppose anyone wants to treat me like a child and give me a break down of what going on?
Posted: Thu Aug 11, 2005 3:58 pm
by thefool
NO!
curdir now holds an array of chars in decimal value! its STILL not a string.
Posted: Thu Aug 11, 2005 4:03 pm
by Kale
thefool wrote:NO!
curdir now holds an array of chars in decimal value! its STILL not a string.
surely thats still alot of data in just 32 bits? Have you any links to internet articles or tutorials describing decimal char arrays? just never heard of that before.
Posted: Thu Aug 11, 2005 4:04 pm
by Dare2
Kale, I think this is the same as or something like:
(Maybe the pars are wrong way round, I didn't check)
But I think this returns the address of the string into the area pointed to by ptrDir.
PtrDir has the address of curDir. The function uses this address as the place where it will store the address of the string.
But ...
... don't quote me.
Posted: Thu Aug 11, 2005 4:07 pm
by thefool
well in assembler:
or something like that will store ascii values in hex for those 3 chars.
a string is simply just a ROW of hex chars, wich can be in decimal too.
string arrays are a common thing. just read every beginners assembly tutorial!
string, quoted string
Text enclosed in apostrophes is called "string". In general, "string" is array of characters. Term used for string inside source code is called "quoted string".
http://www.decard.net/article.php?body ... chapter=01
However for storing a lot of data like that, i dunno how he does that.
@dare2: i doubt that it simply holds a string, as he is peeking directly at curDir [the @] not at what adress it is holding.
Posted: Thu Aug 11, 2005 4:08 pm
by Kale
i always thought in:
ptrDir is a long pointer to a zero terminated string.
Posted: Thu Aug 11, 2005 4:09 pm
by thefool
not afaik. read my previous post!
Posted: Thu Aug 11, 2005 4:13 pm
by Kale
Yep seen that and understand about storing chars as hex, but this:
would store 3 bytes in ascii
in the example which im having trouble with:
is somehow capable of holding up to 511 chars!
Posted: Thu Aug 11, 2005 4:15 pm
by Dare2
SDK wrote:GetCurrentDirectory
The GetCurrentDirectory function retrieves the current directory for the current process.
DWORD GetCurrentDirectory(
DWORD nBufferLength,
LPTSTR lpBuffer
);
Parameters
nBufferLength
[in] Length of the buffer for the current directory string, in TCHARs. The buffer length must include room for a terminating null character.
lpBuffer
[out] Pointer to the buffer that receives the current directory string. This null-terminated string specifies the absolute path to the current directory.
To determine the required buffer size, set this parameter to NULL and the nBufferLength parameter to 0.
I read that as being the 2nd par (I did have them wrong way round)
receives the address of a buffer. But I guess it could mean it is the address of the buffer.
lol.
Edit:
thefool wrote:@dare2: i doubt that it simply holds a string, as he is peeking directly at curDir [the @] not at what adress it is holding.
But then don't we end up with the question of where or how the space was safely allocated for >4 bytes of string data?
Paul is probably going to laugh his elbow off when he reads all this stuff.
Posted: Thu Aug 11, 2005 4:22 pm
by thefool
i read it as the parameter gets the adress of a buffer wich gets feeded with the info.
@kale: what is the difference? it doesnt! the Assembler will make them into hex chars in the produced file. the ascii VALUES gets written in the file.
Posted: Thu Aug 11, 2005 4:24 pm
by Kale
thefool wrote:i read it as the parameter gets the adress of a buffer wich gets feeded with the info.
correct!
@kale: what is the difference? it doesnt! the Assembler will make them into hex chars in the produced file. the ascii VALUES gets written in the file.
Code: Select all
GetCurrentDirectory=GetProcAddress_(module,"GetCurrentDirectoryA")
size.l=512
CurDir.l= 0
ptrDir.l = @CurDir
!PUSH [v_ptrDir]
!PUSH [v_size]
!CALL [v_GetCurrentDirectory]
Debug PeekS(@CurDir)
in the procedure call the argument being passed is a pointer to a long and not a pointer to a string buffer, thats my confusion.
Posted: Thu Aug 11, 2005 4:26 pm
by thefool
the ascii chars just gets feeded to the long. however how the long can hold so much info i dunno.
Posted: Thu Aug 11, 2005 4:46 pm
by Kale
thefool wrote:the ascii chars just gets feeded to the long. however how the long can hold so much info i dunno.
Which leads me to believe a buffer overflow is taking place.
Posted: Thu Aug 11, 2005 4:58 pm
by thefool
probably. but is that really a good thing here? i mean, sometimes it is used wisely, sometimes not