[c++] GetModuleHandle(NtDll) 64Bit

Ende! · 08/02/2012, 18:08

Versuch's mal manuell ausm PEB auszulesen.

Mit __readfsbyte(0x30) kommst du an die Adresse des PEBs, der Rest sollte eigentlich klar sein. Falls du nicht MSVC verwendest, müsstest du dafür auf inline ASM zurückgreifen.

Mi4uric3 · 08/02/2012, 18:48

Danke an tnd0 & Ende!, ich probiere beides mal aus!

@Ende!:
Gegen Inline hab ich nichts.
Ja stimmt die Methode nutze ich ebenfalls für etwas anderes, dass ich darauf noch nicht gekommen bin.. Das Problem dabei ist nur, dass ich nur weiß, wie ich den DLL-Namen auslesen kann Flink und Blink war da irgendwas, aber nicht, wie ich an den Pfad komme..

link · 08/02/2012, 18:58

Hey neji, wo ist deine Signatur?
Mochte die so gerne..

Quote:

Originally Posted by Mi4uric3

Also mit Cheat Engine (64 Bit) habe ich Zugriff darauf & kann auch darin Opcodes ändern.. Das versuche ich halt auch mit dem Prozess selbst, dass er halt selbst darin was verändert, so wie Cheat Engine es extern macht..

Das ist dann aber auch 64-bit Assembly, das ist dir aufgefallen, oder?
64-bit Assembly wird teilweise anders kodiert, deswegen kannst du da unter Umständen nicht einfach den gleichen 32-bit Asm Code injizieren, den du in ein 32-bit Modul reinbringen würdest.

Quote:

Originally Posted by Mi4uric3

Tu ich, hat leider nicht den gewünschten Effekt.
Wenn ich es mit Cheat Engine mache, also die System32\Ntdll.dll modifiziere tritt der gewünschte Effekt auf.

Etwas genauer?

Quote:

Originally Posted by Dr. Coxxy

aber die 32 bit applikation wird die 64 bit version von der ntdll nie (direkt) benutzen, wieso modifizierst du nicht einfach die 32bit ntdll?

Wieso steht das "direkt" in Klammern? Benutzt wird sie schon, nur halt indirekt durch Weiterleitungen.

Jeder 32-bit Prozess hat sowohl eine 32-bit ntdll.dll, als auch eine 64-bit ntdll.dll gemappt, da die 32-bit Funktionen lediglich über einen Wrapper zu den 64-bit Funktionen gelangen, da der Kernelmode ausschließlich 64-bit ist und auch die entsprechenden 64-bit Parameter und Aufrufkonvention erwartet. Der Wrapper kann aber intern sozusagen Funktionen umleiten, sodass in der 32-bit ntdll.dll die Funktion X gecallt wird und man erwarten würde, dass die gleiche Funktion auch in der 64-bit ntdll.dll gecallt wird, es durch den Wrapper aber zur Funktion Y umgeleitet wird bzw. andersherum.

Und die Adresse der 64-bit ntdll.dll liegt im Bereich einer 4 Byte Zahl, da über einen Far Jump zu den 64-bit Modulen gewechselt wird, den es nur mit einem Word-Segment und einer absoluten Dword-Adresse kodiert gibt.

Hab's gerade mit dem PEB ausprobiert, anscheinend hat der 32-bit Prozess wirklich nur Zugriff auf die Liste der geladenen 32-bit Images.
Du müsstest dir also einen 64-bit Wrapper schreiben, den du halt mit deiner PID aufrufst und der dir dann die Adresse des geladenen 64-bit Moduls zurückgibt.

TH32CS_SNAPMODULE liefert auch nur die 32-bit Dlls und TH32CS_SNAPMODULE32 ist unter 32-bit undefiniert.

Mi4uric3 · 08/02/2012, 19:23

Quote:

Originally Posted by link

Das ist dann aber auch 64-bit Assembly, das ist dir aufgefallen, oder?
64-bit Assembly wird teilweise anders kodiert, deswegen kannst du da unter Umständen nicht einfach den gleichen 32-bit Asm Code injizieren, den du in ein 32-bit Modul reinbringen würdest.

Wie gesagt, mit Cheat Engine konnte ich den Effekt erzielen, somit weiß ich wohl, wie ich die Stelle gewünscht modifiziere :)

Quote:

Originally Posted by link

Etwas genauer?

Ich ändere mit Cheat Engine eine Routine in der NtDll an die der Prozess selbst nicht rankommt. Nur so wird der gewünschte Effekt erreicht. Ändere ich es in der NtDll, an die der 32Bit Prozess selbst auch drankommt, tritt der gewünschte Effekt nicht auf. Das wichtige dabei ist, dass nicht der Prozess selbst diese Funktion nutzt, sondern ein Externer, welcher scheinbar die 64-Bit Version direkt nutzt.

Quote:

Originally Posted by link

Du müsstest dir also einen 64-bit Wrapper schreiben, den du halt mit deiner PID aufrufst und der dir dann die Adresse des geladenen 64-bit Moduls zurückgibt.

Okay keine Ahnung was genau ein Wrapper ist und wie er funktioniert, bzw wie ich in Coden soll, aber ich versuch mich mal schlau zu machen..

link · 08/02/2012, 20:52

Sowas mein ich mit Wrapper:

Test.asm:

Code:

format PE GUI 4.0
entry start

include 'win32a.inc'

section '.code' code readable executable

  start:
        ; hole momentane prozess id
        call    [GetCurrentProcessId]
        push    10
        push    _pid
        push    eax
        call    [itoa]
        add     esp,0Ch

        ; gebe vollständige commandline aus
        push    MB_OK
        push    0
        push    _cmdline
        push    0
        call    [MessageBox]

        ; starte prozess und warte auf rückgabewert
        mov     [_si.cb],sizeof.STARTUPINFO
        xor     eax,eax
        push    _pi
        push    _si
        push    eax
        push    eax
        push    eax
        push    eax
        push    eax
        push    eax
        push    _cmdline
        push    eax
        call    [CreateProcess]
        push    -1
        push    [_pi.hProcess]
        call    [WaitForSingleObject]
        sub     esp,4
        push    esp
        push    [_pi.hProcess]
        call    [GetExitCodeProcess]
        mov     eax,[esp]
        add     esp,4

        ; zeige rückgabewert an
        push    eax
        push    _x64
        push    _fmt
        push    _buf
        call    [wsprintf]
        add     esp,0Ch
        push    MB_OK
        push    0
        push    _buf
        push    0
        call    [MessageBox]

        ; hole modul adresse via getmodulehandle
        push    _ntdll
        call    [GetModuleHandle]

        ; und zeige sie an
        push    eax
        push    _x86
        push    _fmt
        push    _buf
        call    [wsprintf]
        add     esp,10h
        push    MB_OK
        push    0
        push    _buf
        push    0
        call    [MessageBox]

        push    0
        call    [ExitProcess]

section '.data' data readable writeable

  _x64 db 'x64',0
  _x86 db 'x86',0
  _cmdline db 'Getx64Base.exe ntdll.dll '
  _pid rb 11
  _fmt db '%s ntdll: %.8X',0
  _ntdll db 'ntdll.dll',0
  _buf rb 256

  _pi  PROCESS_INFORMATION
  _si  STARTUPINFO

section '.idata' import data readable

  library kernel32,'KERNEL32.DLL',\
          user32,'USER32.DLL',\
          msvcrt,'MSVCRT.DLL'

  include 'api\kernel32.inc'
  include 'api\user32.inc'

  import msvcrt,\
         itoa,'_itoa'

Getx64Base.asm:

Code:

format PE64 GUI 5.0
entry start

include 'win64a.inc'

TH32CS_SNAPMODULE = 8
MAX_MODULE_NAME32 = 255

struct MODULEENTRY32
  dwSize        rd 1
  th32ModuleID  rd 1
  th32ProcessID rd 1
  GlblcntUsage  rd 1
  ProccntUsage  rd 2
  modBaseAddr   rq 1
  modBaseSize   rd 2
  hModule       rq 1
  szModule      rb MAX_MODULE_NAME32+1
  szExePath     rb MAX_PATH
                rd 1
ends

section '.code' code readable executable

  start:
        sub     rsp,8*(4+1)
        call    [GetCommandLineW]
        lea     rdx,[argc]
        mov     rcx,rax
        call    [CommandLineToArgvW]
        mov     [rsp+8*4],rax
        or      rcx,-1
        cmp     [argc],3
        jnz     .fin
        lea     rsi,[rax+8]
        mov     rcx,[rsi+8]
        call    [wtoi]
        mov     rdi,[rsi]
        mov     rsi,[rsi]
        mov     rdx,rdi
        mov     ecx,eax
    .unicode_to_ascii:
        lodsw
        stosb
        test    al,al
        jnz     .unicode_to_ascii
        call    GetDllBase
        mov     rcx,rax
    .fin:
        mov     rbx,rcx
        mov     rcx,[rsp+8*4]
        call    [LocalFree]
        mov     rcx,rbx
        call    [ExitProcess]

proc GetDllBase pid,dll
        push    r12
a       =       2                       ; number of pushed registers
b       =       4                       ; number of qwords reserved for API
c       =       sizeof.MODULEENTRY32    ; stack frame in bytes
d       =       (c+7)/8                 ; stack frame in qwords
e       =       (a+b+d+1) and 1         ; alignin stack 16
        sub     rsp,8*(b+d+e)

virtual at rsp+8*4
me32    MODULEENTRY32
end virtual

        mov     [dll],rdx
        mov     edx,ecx
        mov     ecx,TH32CS_SNAPMODULE
        call    [CreateToolhelp32Snapshot]
        test    rax,rax
        je      .err
        mov     r12,rax
        mov     [me32.dwSize],sizeof.MODULEENTRY32
        lea     rdx,[me32]
        mov     rcx,rax
        call    [Module32First]
        test    eax,eax
        je      .close
    .compare:
        lea     rdx,[me32.szModule]
        mov     rcx,[dll]
        call    [strcmpi]
        test    eax,eax
        je      .found
        lea     rdx,[me32]
        mov     rcx,r12
        call    [Module32Next]
        test    eax,eax
        je      .close
        jmp     .compare
    .found:
        mov     rcx,r12
        call    [CloseHandle]
        mov     rax,[me32.modBaseAddr]
        jmp     .fin
    .close:
        mov     rcx,r12
        call    [CloseHandle]
    .err:
        xor     eax,eax
    .fin:
        add     rsp,8*(b+d+e)
        pop     r12
        ret
endp

section '.data' data readable writeable

  argc rd 1

section '.idata' import data readable

  library kernel32,'KERNEL32.DLL',\
          shell32,'SHELL32.DLL',\
          msvcrt,'MSVCRT.DLL'

  include 'api\kernel32.inc'

  import shell32,\
         CommandLineToArgvW,'CommandLineToArgvW'

  import msvcrt,\
         strcmpi,'_strcmpi',\
         wtoi,'_wtoi'

Exen sind angehängt.

Quote:

Originally Posted by Mi4uric3

Ich ändere mit Cheat Engine eine Routine in der NtDll an die der Prozess selbst nicht rankommt. Nur so wird der gewünschte Effekt erreicht. Ändere ich es in der NtDll, an die der 32Bit Prozess selbst auch drankommt, tritt der gewünschte Effekt nicht auf.

Um was für eine Funktion und Änderung handelt es sich denn? Weiß nämlich immer noch nicht genau, was du meinst.
Handelt es sich z.B. um irgendwelche CRC-Checks, weswegen du die Funktionen in der 32-bit ntdll nicht direkt verändern kannst?

Quote:

Originally Posted by Mi4uric3

Das wichtige dabei ist, dass nicht der Prozess selbst diese Funktion nutzt, sondern ein Externer, welcher scheinbar die 64-Bit Version direkt nutzt.

Wie geschrieben, die 32-bit Funktionen sind nur Wrapper für die eigentlichen 64-bit Funktionen. Ein 32-bit Syscall ist nur ein Pseudo-Syscall, der in Wirklichkeit entweder zum 64-bit Äquivalent führt, wo dann der eigentlich Syscall ausgeführt wird, der in den Kernelmode wechselt, oder nochmals zu einem diesmal 64-bit Wrapper, der dann erst noch Änderungen vornimmt.

PS:
Mit "TH32CS_SNAPMODULE32 ist unter 32-bit undefiniert" war gemeint, dass es unter x64 die Möglichkeit gibt, entweder 32-bit oder 64-bit Module zu enumerieren.
Unter x86 liefert TH32CS_SNAPMODULE von sich aus 32-bit Module zurück, TH32CS_SNAPMODULE32 ist undefiniert und sowas wie TH32CS_SNAPMODULE64 gibt es nicht.

Edit:

Quote:

Originally Posted by tnd0

Edit: Also ja du findest sie zwar, sie ist gemapped aber jeder zugriff darauf endet in einer AV oder sogar GPF. D.h. sie ist zwar augenscheinlich da, aber weder der Prozess an sich noch ein externer Prozess können damit etwas anfangen, es sei denn man sucht nach alternativen ein Programm unsauber und schnell zu beenden.

Nein, wieso sollte man darauf nicht zugreifen können?
Wenn eine 64-bit Dll in Reichweite gemappt wird, und 32-bit Code enthält, kann sie ganz normal ausgeführt werden. Wenn sie 64-bit Code enthält, kannst du die CPU in den x64 Mode switchen und den 64-bit Code ganz normal ausführen.
Wie würde der 32-bit Emulator von Windows sonst funktionieren, wenn jeder Zugriff eine Exception auslösen würde?

Dr. Coxxy · 08/02/2012, 21:41

Quote:

Originally Posted by link

Wieso steht das "direkt" in Klammern? Benutzt wird sie schon, nur halt indirekt durch Weiterleitungen.

eben deshalb habe ich es in klammern gesetzt, weil die app die funktionen nie direkt aufrufen wird, sondern ausschließlich indirekt, wie du beschrieben hast^^

MrSm!th · 08/02/2012, 22:07

Quote:

Originally Posted by tnd0

Das ganze 64/32Gating/Node System hat auch noch weitere nebeneffekte. Wenn du zb. versuchst die ntdll aus System32 mit deinem Browser auf z.b. virusscan.jotti.org hochzuladen, lädt er die ntdll aus SysWow64 hoch - obwohl der Pfad eindeutig System32 sagt. Vorrausgesetzt du verwendest einen 32bit Browser wie Chrome und Firefox, glaube der internet explorer hat ne 64bit version, da würde er die korrekte Datei hochladen.

Wat? oO Selbst bei ganz normalem File I/O der nix mit 64bit Mapping zu tun hat, wird auf die SysWOW64 Ntdll geladen?

Mi4uric3 · 08/02/2012, 22:13

Quote:

Originally Posted by MrSm!th

Wat? oO Selbst bei ganz normalem File I/O der nix mit 64bit Mapping zu tun hat, wird auf die SysWOW64 Ntdll geladen?

Sofern ich dich richtig verstanden habe, hast du etwas falsch verstanden..
Ich möchte ja auf die NtDll im System32\ Ordner zugreifen, nicht auf die SysWOW64\ ..

MrSm!th · 08/02/2012, 22:23

Nein, das bezog sich auf einen völlig anderen Teil, ich bearbeite das Quote mal.

link · 08/02/2012, 23:11

@Dr. Coxxy:
Packt man nicht eher entbehrliche Informationen in Klammern, die man sich auch wegdenken könnte?
Ohne das "direkt" stimmt deine Aussage nämlich nicht mehr, deswegen käme das ohne Klammern unmissverständlicher und expliziter.

@MrSm!th:
"Selbst bei ganz normalem File I/O der nix mit 64bit Mapping zu tun hat, [...]"
Was meinst du damit?
Damit keine Kompatibilitätsprobleme auftreten, ist bei jedem 32-bit Prozess "system32" ein Alias und verlinkt auf SysWOW64, wo die eigentlichen 32-bit Dlls drinnen sind.
So kann der Pfad "system32" weiterhin allgemein benutzt werden. Wenn man via GetOpenFileName eine 64-bit Datei aus system32 öffnen will, wird als Pfad "\system32\" zurückgeliefert, was dann beim Zugriff zu "\SysWOW64\" wird.
Deswegen müsste man sich, wenn man einen x86-Browser benutzt, die 64-bit Dateien aus'm system32-Ordner erst einmal auf den Desktop kopieren (oder die Redirection deaktivieren).
Ungefähr das gleiche gibt es auch bei der Registry, was nötig ist, damit 64-bit und 32-bit Anwendungen unabhängig koexistieren können.

s.

und

@Mi4uric3:
Funzt es denn jetzt oder bist du damit nicht zufrieden?

MrSm!th · 08/02/2012, 23:57

Achso, alles klar, als ich tnd0s Post las, dachte ich, diese Redirection beziehe sich nur auf das Mapping beim Laden der Module.

Mi4uric3 · 08/03/2012, 09:06

Quote:

Originally Posted by link

@Mi4uric3:
Funzt es denn jetzt oder bist du damit nicht zufrieden?

Nun, ich danke dir für den Beispielcode, sofern ich das richtig erkennen kann startet das einen x64-Prozess, der einfach aus seinem Arbeitsspeicher die Adresse der System32\NtDll.dll ausliest, diese ausgibt und der x32-Prozess den Output liest und somit die Adresse hat, korrekt? :)

tnd0 · 08/03/2012, 12:57

Quote:

Achso, alles klar, als ich tnd0s Post las, dachte ich, diese Redirection beziehe sich nur auf das Mapping beim Laden der Module.

Im Prinzip ist es so, dass CreateFile auf Treiberebene bei 32bit Apps den Pfad völlig transparent für den User von System32 auf SysWow64 ändert. Das hat Microsoft so gemacht, um zu verhindern, dass ältere 32-Bit Programme die z.b. \Windows\System32\ hardcoded haben, nicht versuchen irgendwelche 64Bit Dll's zu binden, die im Windows verzeichnis liegen.

Und CreateFile benutzt der FireFox z.b. um eine Datei zum lesen zu öffnen, damit die Daten daraus via send() im HttpPostFormat an den Server übertragen werden können. Das bezieht sich speziell bei System32/SysWow64 nicht nur auf DLLs, allerdings auch nicht auf alle Dateien/Subdirectories.

MrSm!th · 08/05/2012, 22:03

#moved