Recent Posts

41

Using NASM / Re: How does linker know the location of the function?

« Last post by Korybut on February 19, 2021, 02:15:59 PM »

I've found out that (as supposed to be) situation depends on linker. GoLink actually scans the DLL for the functions. Other linkers may use LIB files

42

Using NASM / Re: RET n vs POP

« Last post by debs3759 on February 18, 2021, 09:22:49 PM »

The first code example looks like the only correct way to me. You restore the original values that you had saved. ret 4 would then alter the stack again, which would leave it in a different state to what it was before the call. The third example leaves ES and DI with different values to before the call, which could break other code.

ret n is only useful if you had passed arguments on the stack, and need to clean it up (such as, for example, the case of routines like printf).

43

Using NASM / RET n vs POP

« Last post by mik3ca on February 18, 2021, 09:13:26 PM »

I'm trying to figure out if when returning from a function if I should pop variables that I pushed, or if I should use a parameter with RET or both.

I'll give an example. When I normally code, I do something like this:

Code: [Select]

somesegment dw 123h
someoffset dw 123h

somefunction:
push ES
push DI
mov AX,1234h
mov ES,[CS:somesegment]
mov DI,[CS:someoffset]
int 0AAh
pop DI
pop ES
ret

No this code shouldn't be executed as-is because I did not setup correct segment and offset values. This code is meant to demonstrate that I was protecting sensitive registers and that the interrupt needed a string stored at ES:DI for processing.

But I'm wondering, should I also include a parameter at the end of RET? so my code becomes this?

Code: [Select]

somesegment dw 123h
someoffset dw 123h

somefunction:
push ES
push DI
mov AX,1234h
mov ES,[CS:somesegment]
mov DI,[CS:someoffset]
int 0AAh
pop DI
pop ES
ret 4 ;added 4 because the size of DI and ES (both pushed onto stack) variables combined is 4.

Then again, when I read stuff online, one could probably get away with the following code but to me it doesn't make sense. Have a look:

Code: [Select]

somesegment dw 123h
someoffset dw 123h

somefunction:
push ES
push DI
mov AX,1234h
mov ES,[CS:somesegment]
mov DI,[CS:someoffset]
int 0AAh
ret 4 ;added 4 because the size of DI and ES (both pushed onto stack) variables combined is 4.

So which is best?
Should I push/pop variables with return including number?
Should I push only and return including number?
Should I continue my way and push and pop variables and use no number for return?

I know the variables are called registers in assembly but I say variables because its easier to understand. Please advise.

Thanks

44

Using NASM / Re: How does linker know the location of the function?

« Last post by fredericopissarra on February 17, 2021, 01:01:54 AM »

Many thanks for answers. Please correct me if I am wrong. Using some sort of PE Explorer I can look through all the functions that one can call from DLL and linker goes through this information and replaces my labels in Object file with actual offsets from PE headers in DLL.

Looking at disassembled code I've never seen usage of "LoadLibrary" and "GetProcAddress" (except 'wglGetProcAddress" but it is completely different story) is this because in majority of cases early binding was chosen?

To the first question, not exactly... take a look at this tiny example:

Code: [Select]

; hello.asm for x86-64
  bits  64
  default rel

  section .rodata

msg:
  db  `Hello\n`
msg_len equ $ - msg

  section .text

  extern __imp_GetStdHandle
  extern __imp_WriteConsoleA
  extern __imp_ExitProcess

  global _start

_start:
  mov   ecx,-11   ; STD_OUTPUT_HANDLE
  call  [__imp_GetStdHandle]

  mov   ecx,eax
  lea   rdx,[msg]
  mov   r8d,msg_len
  xor   r9d,r9d
  push  byte 0
  call  [__imp_WriteConsoleA]
  add   rsp,8

  xor   ecx,ecx
  jmp   [__imp_ExitProcess]
To compile:

Code: [Select]

$ nasm -fwin64 -o hello.o hello.asm
$ x86_64-w64-mingw32-ld -s -o hello.exe hello.o -lkernel32This was compiled with mingw64 on Linux (but works with m$ linker as well with different command line - probably _start isn't the default entrypoint with link.exe).

If you Search for these 3 functions names on your executable you'll find the 3 function names as in the picture attached. That's because the loader will early bind them. But notice the symbols used in the code has the `__imp_` prefix (these are the symbols defined in the imported static library kernel32.lib (or libkernel32.a, in case of linux).

To the second question... Yes, you don't see LoadLibrary/GetProcAddress/FreeLibrary because of early binding.

And, please, notice: I don't deal with Windows since 2007.

45

Using NASM / Re: How does linker know the location of the function?

« Last post by Korybut on February 16, 2021, 07:49:07 PM »

Many thanks for answers. Please correct me if I am wrong. Using some sort of PE Explorer I can look through all the functions that one can call from DLL and linker goes through this information and replaces my labels in Object file with actual offsets from PE headers in DLL.

Looking at disassembled code I've never seen usage of "LoadLibrary" and "GetProcAddress" (except 'wglGetProcAddress" but it is completely different story) is this because in majority of cases early binding was chosen?

46

Using NASM / Re: How does linker know the location of the function?

« Last post by fredericopissarra on February 16, 2021, 02:54:10 PM »

Each time you compile a source code to an object file is assigned a "virtual address" (a "relative" address) to each memory reference in your code. Example:

Code: [Select]

bits 32

section .data

x:  dd  0

section .text

  global f
f:
  inc dword [x]
  retIf you compile this you'll get:

Code: [Select]

$ nasm -l test.lst test.asm
$ cat test.lst
 1                          bits 32
 2                         
 3                          section .data
 4                         
 5 00000000 00000000        x: dd 0
 6                         
 7                          section .text
 8                         
 9                            global f
10                          f:
11 00000000 FF05[00000000]    inc dword [x]
12 00000006 C3                retNotice `x` get the offset 0 in `.data`section. and `f` got offset 0 on `.text` section. (and the offset in inc instruction is [00000000]).

When the linker is used with multiple modules it atributes different offsets to these references... Let's say you have another module (test2.asm) defining `y` as DWORD... to that object file `y` will get the offset 0 as well, but the linker puts `x` and `y` in the same section, assignining a different offsets for these 2 symbols.. The same to function's entrypoints...

Notice, also, that CALL/JMP and conditional jumps use relative addressing (relative to EIP ou RIP)...

In the case of DLLs, when they are loaded, the offset is avaliable in PE file format. In Windows, when you use GetProcAddress you get this address and assign to a function pointer to do an indirect call (late binding). Or the linker do this for you (early binding).

As for DLLs with functions with the same name, in early binding it can be problematic, but with late biding it has no problem, since the same is used only to find the address where the function is...

47

Using NASM / Re: How does linker know the location of the function?

« Last post by Korybut on February 16, 2021, 07:33:17 AM »

How about the casewhen two dll have functions with identical names? Is it strictly forbidden?

According to the Manual (section 8.4.4) there is "import" directive which specifies the location of the functions in libraries. It is pretty much the same as FASM has except order of argument difference.

48

Using NASM / Re: How does linker know the location of the function?

« Last post by debs3759 on February 15, 2021, 10:09:53 PM »

I have never created a multi file assembler project, but I can tell you that the assembler only needs to know which routines are in external files, and the linker needs to know which library files to find external routines in. That seems to be what your link shows. I can't speak for how other assemblers declare the same routines.

49

Using NASM / How does linker know the location of the function?

« Last post by Korybut on February 15, 2021, 07:41:29 PM »

Hello,

I am new to NASM (I used to program on FASM) and currently on the stage of careful manual reading. However there is some point that is not clear. Creating application in FASM I need to tell the assembler in which dll my function is stored. Doesn't matter if I created this dll myself or it isprovided by OS. 

On the opposite side looking at examples like https://forum.nasm.us/index.php?topic=2365.15
I've noticed that there is no such information in the code or no other files where such information might be provided. Perhaps I'm missing something

How does it work?

50

Example Code / Re: Reversing string at high speed

« Last post by fredericopissarra on February 14, 2021, 09:14:08 PM »

Not so simple...

Even if the pair ES:SI is normalized (SI is lower as possible), what will happen if SI or DI overflows (or underflows)?