[Assembler] Warum wird der Stack-Pointer hier mit 0x28 subtrahiert?

  • Sonstige

Es gibt 4 Antworten in diesem Thema. Der letzte Beitrag () ist von rwCapt.

    [Assembler] Warum wird der Stack-Pointer hier mit 0x28 subtrahiert?

    Moin Moin,

    ich finde mich gerade etwas in Assembler ein und habe im Internet einen sehr kleinen und einfachen Assembler-Code gefunden, der bereits alles "vor eingestellt" hat, quasi keine Verlinkungen durch einen Linker mehr braucht, sondern nur noch kompiliert, also von der Assemblersprache in den Zahlencode übersetzt werden muss. Dazu nutze ich nasm und es funktioniert prima. Das kleine Programm stellt eine ganz einfache MessageBox dar.

    Was ich mich aber frage ist, warum der Stack Pointer (also das Register rsp) um 0x28 subtrahiert werden muss. Lasse ich die Zeile sub rsp, 5 * 8 weg, kann ich im Task-Manager sehen, dass mein kleines Programm mit einem Fehler startet (diese Windows-Fehlerdiagnose öffnet sich, was nur im Task-Manager sichtbar ist).

    Hier mal der ganze Code:

    Quellcode

    1. EntryPoint:
    2. sub rsp, 5 * 8 ; 48 83 EC 28 ; Um diese Zeile geht es
    4. mov r9d, 0 ; 41 B9 00
    5. mov r8d, Title_ + DATADELTA ; 41 B8 00 30 40
    6. mov edx, Caption + DATADELTA ; BA 0D 30 40 00
    7. mov ecx, 0 ; B9 00
    8. call [__imp__MessageBoxA] ; 00 FF 14 25 88 20 40
    10. exit:
    11. mov ecx, 0 ; B9 00
    12. call [__imp__ExitProcess] ; 00 FF 14 25 78 20 40


    Bei der Gelegenheit würde ich auch noch mal eine zweite Frage stellen: Warum braucht ein Prozess einen Aufruf der Funktion "ExitProcess()"? Ich vermute, dass das Betriebssystem die Info braucht, wann das Programm beendet ist.

    Vielen Dank vorab für die Hilfe!

    rwCapt schrieb:

    Was ich mich aber frage ist, warum der Stack Pointer (also das Register rsp) um 0x28 subtrahiert werden muss


    Die Antwort findest du hier im Kapitel 11:
    nasm.us/xdoc/2.14.01rc1/html/nasmdo11.html


    All known 64-bit platforms except some embedded platforms require that
    the stack is 16-byte aligned at the entry to a function. In order to
    enforce that, the stack pointer (RSP) needs to be aligned on
    an odd multiple of 8 bytes before the CALL
    instruction.

    So sollte der Beitrag eigentlich nicht aussehen. Naja, machen wir halt mal Lückenraten ;)

    Das hätte ich wohl nie gefunden. Ich bin eigentlich so an die Sache ran gegangen, mich mit Assembler zu beschäftigen, dabei aber kaum ein Augenmerk auf das Übersetzungstool zu legen (NASM), was ja auch so einiges gut beschreibt.

    Das ist jetzt etwas zusammenhangslos, aber ich frage einfach mal. Die EXE, die ich da quasi "nackt" und ohne Kompiler/Linker schreibe, orientiert sich . Das in einem beliebigen Hexadezimal-"fähigen"-Editor eingegeben, ergibt das im Eingangspost beschriebene Programm.

    Wenn ich dieses Programm nun aber in Visual Studio mit C zu erstellen versuche und dann mit einem Hexadezimal-Editor öffne, steht da deutlich mehr drinne als es eigentlich sollte. Ich habe die Konfiguration auf "Release" gestellt und die Zielplattform x86 ausgewählt und mich bei den Projekteinstellungen hieran orientiert. Das reduzierte das ganze um einiges, es bleibt aber trotzdem noch ein Rest in der imports-Section der EXE, der im Code auf dem nicht vorhanden ist.
    Naja, halb so tragisch, wenigstens ist die EXE so klein, dass man damit arbeiten/lernen kann. Allerdings ähnelt sich der Code der EXE aus dem Visual Studio kaum mit dem aus dem . Ich schlussfolgere daraus, dass eine EXE zumindest in ihren einzelnen sections (außer eben der Code-section, denn da geht nur reinste Assembler-Sprache) bspw. von der "Benennung" ihrer Imports sehr unterschiedlich sein kann, also je nach Linker. Gibt es da ein System hinter, das man irgendwie verstehen kann? So, wie es im im Anhang gemacht wurde, ist es für mich am einfachsten.
    Bilder

    • imports-section.png

      77,72 kB, 877×698, 84 mal angesehen

    Bin ich grad überfragt, wenn ich deine EXE hätte könnte ich das unter die Lupe nehmen. Aber du kannst das auch selbst, mit der Explorer Suite(CFF Explorer), das wird vermutlich am einfachsten sein. Nützliches Tool um PE's zu untersuchen, wie auch verändern.
    ntcore.com/?page_id=388



    rwCapt schrieb:

    Wenn ich dieses Programm nun aber in Visual Studio mit C zu erstellen versuche


    Du kannst auch mit VS kompileren, ohne das die VC-Runtime benötigt bzw. dazu was mit rein kommt. Hab das aber nie probiert(ausser für Arduino). Alternativ, kannste auch die GCC verwenden, da ist dann weniger Ballast im kompilat.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Takafusa“ ()

    Vielen Dank nochmal @Takafusa , der CFF Explorer hat mir bisher sehr weitergeholfen. Mit Ghidra ist es ein unglaublich nützliches Werkzeug, um sich zurecht zu finden.

    Ich habe nun so in etwa verstanden, was der Stack Pointer so macht. Ist es also so, dass wenn ich etwas auf den Stack verfrachten (bspw. mov qword [rsp + 0x08], 0x110) möchte, ich den Stack Pointer quasi um 8 Bytes nach hinten "stellen" muss (sub rsp, 8 * 1)?

    Ich habe es geschafft, die WNDCLASSEXW-Struktur so auf den Stack zu bekommen, dass ich die Funktion RegisterClassExW(...) damit füttern kann. Ich habe gemerkt, dass die Argumente der Funktionen aus der user32.dll in der Reihenfolge übergeben werden sollten: 1. Parameter: rcx, 2. Parameter: rdx, 3. Parameter: r8, 4. Parameter: r9, [jetzt wird es spannend] 5. Parameter [rsp + 0x20].

    Und genau ab dem fünften Parameter bin ich mir unsicher. Das hat jetzt mit RegisterClassExW (hat ja auch nur ein Argument, das über das Register rcx übergeben wird) geklappt, aber mit CreateWindowExW klappt es nicht. Da gibt mir GetLastError den Fehlercode, den ich mir mit wsprintfA in einer MessageBox habe ausgeben lassen, 998 für No_Memory_Access aus. Ich habe auch hier wieder sämtliche Parameter nach dem obigen Schema übergeben. Auch ein Blick in die user32.dll und in die Funktion CreateWindowExW bestätigt mir, dass das Übergabeformat, wie ich es aufgestellt habe, richtig ist. Trotzdem erhalte ich kein gültiges Handle (hWnd = 0).

    Spoiler anzeigen

    Quellcode

    1. sub rsp, 8 * 22 ; <-- Ich bin hier am zweifeln, worauf ich den Stack Pointer stellen soll
    3. ; Constans
    4. SW_SHOWDEFAULT equ 0xA
    6. WNDCLASSEXW.size equ 0x50
    7. CS_VREDRAW equ 0x1
    8. NULL equ 0
    9. COLOR_3DSHADOW equ 0x10
    10. IDI_APPLICATION equ 0x7F00
    11. IDC_ARROW equ 0x7F00
    13. MB_OK equ 0x00
    15. CW_USEDEFAULT equ 0x80000000
    16. WS_OVERLAPPEDWINDOW equ 0xCF000000
    17. WS_VISIBLE equ 0x10000000
    19. ; HINSTANCE hInstance
    20. hInstance equ 0x70
    22. ; LPSTR CommandLine
    23. CommandLine equ 0x78
    25. ; WNDCLASSEXW wc
    26. wc equ 0x20
    27. wc.cbSize equ 0x20
    28. wc.style equ 0x24
    29. wc.lpfnWndProc equ 0x28
    30. wc.cbClsExtra equ 0x30
    31. wc.cbWndExtra equ 0x34
    32. wc.hInstance equ 0x38
    33. wc.hIcon equ 0x40
    34. wc.hCursor equ 0x48
    35. wc.hbrBackground equ 0x50
    36. wc.lpszMenuName equ 0x58
    37. wc.lpszClassName equ 0x60
    38. wc.hIconSm equ 0x68
    40. ; HWND hwnd
    41. hwnd equ 0x70
    43. ; MSG msg
    44. msg equ 0x78
    45. msg.hwnd equ 0x78
    46. msg.message equ 0x80
    47. msg.wParam equ 0x84
    48. msg.lParam equ 0x8B
    49. msg.time equ 0x93
    51. mov rcx, NULL ; hInstance = GetModuleHandle(NULL)
    52. call [__imp__GetModuleHandleW] ; <--
    53. mov [rsp + hInstance], rax ; <--
    55. call [__imp__GetCommandLineW] ; CommandLine = GetCommandLineW()
    56. mov [rsp + CommandLine], rax ; <--
    58. push SW_SHOWDEFAULT ; WinMain(hInstance, NULL, CommandLine, SW_SHOWDEFAULT)
    59. lea rax, [rsp + CommandLine] ; <--
    60. push rax ; <--
    61. push NULL ; <--
    62. mov rax, [rsp + hInstance] ; <--
    63. push rax ; <--
    64. call WinMain ; WinMain = EntryFunction
    66. WinMain:
    67. pop rcx
    68. pop rdx
    69. pop r8
    70. pop r9
    72. mov dword [rsp + wc.cbSize], WNDCLASSEXW.size ; sizeof(WNDCLASSEXW) = 80
    73. mov dword [rsp + wc.style], CS_VREDRAW ; style = CS_VREDRAW | 1 = CS_VREDRAW
    74. mov rax, NULL ; lpfnWndProc = NULL
    75. mov [rsp + wc.lpfnWndProc], rax ; <--
    76. mov dword [rsp + wc.cbClsExtra], NULL ; cbClsExtra = NULL
    77. mov dword [rsp + wc.cbWndExtra], NULL ; cbWndExtra = NULL
    78. mov [rsp + wc.hInstance], rcx ; hInstance = hInstance [param]
    79. mov qword [rsp + wc.hbrBackground], COLOR_3DSHADOW ; hbrBackground = COLOR_3DSHADOW | 16 = COLOR_3DSHADOW
    81. mov rax, ClassName + DATADELTA ; lpszClassName = "MeineClass"
    82. mov [rsp + wc.lpszClassName], rax ; <--
    84. mov rdx, IDI_APPLICATION ; hIcon = LoadIconW(NULL, IDI_APPLICATION)
    85. xor rcx, rcx ; <--
    86. call [__imp__LoadIconW] ; <--
    87. mov [rsp + wc.hIcon], rax ; <--
    88. mov [rsp + wc.hIconSm], rax ; <--
    90. mov rdx, IDC_ARROW ; hCursor = LoadCursorW(NULL, IDC_ARROW)
    91. xor rcx, rcx ; <--
    92. call [__imp__LoadCursorW] ; <--
    93. mov [rsp + wc.hCursor], rax ; <--
    95. lea rcx, [rsp + wc] ; if (!RegisterClassExW(&wc)) { MessageBoxA(NULL, "Ein Fehler ist aufgetreten.", "Fehler", MB_OK); }
    96. call [__imp__RegisterClassExW] ; <--
    98. cmp rax, 0 ; <--
    99. jne RegistrationSuccessful ; <--
    100. je RegistrationNotSuccessful ; <--
    102. RegistrationNotSuccessful: ; <--
    103. mov r9d, MB_OK ; <--
    104. mov r8d, MessageBox_Error_Registration.Title + DATADELTA ; <--
    105. mov rdx, MessageBox_Error_Registration.Caption + DATADELTA ; <--
    106. mov rcx, 0 ; <--
    107. call [__imp__MessageBoxA] ; <--
    109. jmp Exit
    111. RegistrationSuccessful:
    112. mov rcx, NULL
    113. mov rdx, ClassName + DATADELTA
    114. mov r8, AppName + DATADELTA
    115. mov r9, (WS_OVERLAPPEDWINDOW + WS_VISIBLE)
    116. mov dword [rsp + 0x20], CW_USEDEFAULT
    117. mov dword [rsp + 0x28], CW_USEDEFAULT
    118. mov dword [rsp + 0x30], 0x280
    119. mov dword [rsp + 0x38], 0xe6
    120. mov dword [rsp + 0x40], NULL
    121. mov dword [rsp + 0x48], NULL
    122. mov rax, [rsp + hInstance]
    123. mov [rsp + 0x50], rax
    124. mov dword [rsp + 0x58], NULL
    125. call [__imp__CreateWindowExW] ; <-- Fehler = 998: Invalid access to memory location.
    127. cmp rax, 0
    129. jnz Exit
    131. call [__imp__GetLastError]
    133. lea rcx, [rsp + 0x80]
    134. mov rdx, Format + DATADELTA
    135. mov r8, rax
    136. call [__imp__wsprintfA]
    138. mov r9d, MB_OK ; <--
    139. mov r8d, MessageBox_Error_Registration.Title + DATADELTA ; <--
    140. lea rdx, [rsp + 0x80] ; <--
    141. mov rcx, 0 ; <--
    142. call [__imp__MessageBoxA] ; <--
    144. Exit:
    145. mov rcx, 0 ; ExitProcess(0)
    146. call [__imp__ExitProcess]


    Edit:

    Verflucht, mein Fehler war es, einen char* statt eines wchar_t* als Class-Name (lpszClassName) anzugeben. Dadurch scheint die Funktion den Nullterminator nicht gefunden zu haben, also ein kaputter String, wenn man so will. Naja, jetzt funktioniert es und ich habe ein Fenster in Assembler erstellt ^^

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „rwCapt“ ()

Facebook
Telefonspende