![[HaBo]](/styles/default/logoklein.png){kind=small}
Ganz "klassisch" wären Hooks auf jeweils nächsten API-Aufrufe (also in SystemDLLs)
"Klassisch für Geduldige" => Checksummen manipulieren (ok, könnte auch ein (signierter) Hash/Merkel-Tree - dann könnte man sich auch die Runtime anschauen).
Gibt's da ein neues Win-Feature mit den Diensten? DEP verhinderte bis jetzt ja nur, dass Code in Speicher-Pages ausgeführt wurde, die nicht den PAGE_EXECUTE Flag hatten.wird dir wohl die Datenausführungsverhinderung dazwischen grätschen bei dem Versuch. Wobei ich nicht weis ob mit "und Dienste" alle Dienste gemeint sind ?
--------------------------------------
Reden wir jetzt spezeill über VAC2 oder prinzipielle Möglichkeiten im Userspace?
Bei der simplen Injection hat man nur den zusätzlichen, einmaligen WriteProcessMemory Aufruf.
Wird der "Einbruch" in den Prozess an dieser Stelle nicht endeckt, wird der Aufwand ab diesem Moment imho zu hoch.
"Ohne Codeinjection" - damit ist ein Prozess gemeint, der mittels ReadProcessMemory(alternativ: GetThreadContext&Co) Werte ausliest, richtig?
(die Fälle mit Netzwerkdatenstream ablesen usw. mal außen vor).
Da fallen mir einige Möglichkeiten ein, so etwas zu entdecken.
Btw:
Was das aktuelle VAC2 "kann", weiß ich nicht (hey, ich hab' stattdessen PanzerGeneral 3D und SNES/N64 Emualtoren drauf
) Insofern würde/sollte ich an dieser Stelle lieber meine Finger stillhalten
Wen also teilweise veraltetes Zeug und das übliche allgemeine Geschwafel nicht interessiert, sollte jetzt aufhören zu lesen *g*
------------------------
OT:
Zu OpenProcess/CreateProcess + ReadProcessMemory:
Schon unter XP musste der Prozess entweder der Parent sein oder PROCESS_VM_READ
und ggf.(lange her, wer XP griffbereit hat, kann ja testen) SeDebugPrivilege haben.
Der Parentprozess lässt sich relativ leicht feststellen:
z.B CreateToolhelp32Snapshot => durchlaufen, PPID lesen.
"Process access rights" ablesen sollte über ein paar Verrenkungen gehen:
GetKernelObjectSecurity => irgendwo in den Tiefen von DACL/ACE, wobei ich dafür nicht meine Hand ins Feuer legen würde.
SeDebug: OpenProcessToken => ... => LookupPrivilegeValue.
Zudem braucht man zum Lesen ein Handle => NtQuerySystemInformation, HOWTO: Enumerate handles - Sysinternals Forums
Dass das Handle-Zeugs relativ flott läuft, kann man z.B im ProzessExplorer sehen.
D.h: prinzipiell können Prozesse, die PROCESS_VM_READ/SeDebugPrivilege haben, schon mal als verdächtig angesehen werden (hey, ich hatte auch mal ein Popel-Tool, welches VStudio als "Debugger, bitte schließen" angemeckert hat
)
Erst recht, wenn die für eine rel. hohe Last (wegen "polling") sorgen oder gar (rein absolut zufällig) der Parent sind/ein offenes Handle haben *g*
Exotischere Szenarien (die aber durchaus bei AVs/IndernetSuperSecurity-Packeten vorkommen) wären eine DLL Injection und Hook auf ProzessmanipulationsAPIs bzw. Kernelhooks.
Oder: Whitelists bzw. nur signierte Prozesse erlauben und DEP (Datenausführungsverhinderung) rigoros durchsetzen (1001 Tools, teilweise auch von den "Großen", die DEP immer noch nicht beherrschen, lassen grüßen ).
=> DB-Pflegeaufwand und mögliche False-Positives bei den üblichen 1001-Tools schrecken die Entwickler wohl noch ab.
Schon unter XP musste der Prozess entweder der Parent sein oder PROCESS_VM_READ
und ggf.(lange her, wer XP griffbereit hat, kann ja testen) SeDebugPrivilege haben.
Der Parentprozess lässt sich relativ leicht feststellen:
z.B CreateToolhelp32Snapshot => durchlaufen, PPID lesen.
"Process access rights" ablesen sollte über ein paar Verrenkungen gehen:
GetKernelObjectSecurity => irgendwo in den Tiefen von DACL/ACE, wobei ich dafür nicht meine Hand ins Feuer legen würde.
SeDebug: OpenProcessToken => ... => LookupPrivilegeValue.
Zudem braucht man zum Lesen ein Handle => NtQuerySystemInformation, HOWTO: Enumerate handles - Sysinternals Forums
Dass das Handle-Zeugs relativ flott läuft, kann man z.B im ProzessExplorer sehen.
D.h: prinzipiell können Prozesse, die PROCESS_VM_READ/SeDebugPrivilege haben, schon mal als verdächtig angesehen werden (hey, ich hatte auch mal ein Popel-Tool, welches VStudio als "Debugger, bitte schließen" angemeckert hat
)Erst recht, wenn die für eine rel. hohe Last (wegen "polling") sorgen oder gar (rein absolut zufällig) der Parent sind/ein offenes Handle haben *g*
Exotischere Szenarien (die aber durchaus bei AVs/IndernetSuperSecurity-Packeten vorkommen) wären eine DLL Injection und Hook auf ProzessmanipulationsAPIs bzw. Kernelhooks.
Oder: Whitelists bzw. nur signierte Prozesse erlauben und DEP (Datenausführungsverhinderung) rigoros durchsetzen (1001 Tools, teilweise auch von den "Großen", die DEP immer noch nicht beherrschen, lassen grüßen
).=> DB-Pflegeaufwand und mögliche False-Positives bei den üblichen 1001-Tools schrecken die Entwickler wohl noch ab.
Zu der "etwas über 0815"-Injection:
Eine saubere Injection bei einem "paranoiden" Schutz hat mehrere "Stufen" und schaut in etwa so aus:
1) simple DLL/Codeinjection in den Explorer (damit die P(arent)PID auch hübsch ist).
2) von hier aus: CreateProcess(Ziel ..., CREATE_SUSPENDED)
Zu diesem Zeitpunkt sollten nur die SystemDLLs gemappt, nichts läuft.
Bei Bedarf lässt sich Schritt 2 "verketten" (Explorer => Starter => Ziel usw.)
3) VirtualAllocEx oder (je nach Codegröße) sucht man einen Part in der SystemDLL der eh' nicht ausgeführt wird
(normalerweise hat man wegen Section-Alignment am Ende der jew. Section ausreichend Platz).
Code reinsetzen, ResumeThread.
"Have fun" bei der Erkennung
Damit hat man:
I. keine anderen Prozesse. PPID stimmt.
II. die Modulliste in PEB (ProzessEnvironmentBlock) ist "sauber", keine Debugflags u.ä.
III. der Code sitzt a) in einem Speicherbereich, b) in einer der legitimen DLLs oder c)
wenn man die Mögichkeit hat, den Prozess in die DEP-Ausnahmeliste einzutragen
braucht der reservierte Speicherbereich nur den PAGE_READ Flag.
Erkennung:
1. Injectionschritt selbst - wird im Userspace imho kompliziert - zumindest wenn nicht ständig alle Programme überwacht werden.
Die üblichenSnake-Oil SecuritySuits schaffen's ja immer noch nicht so richtig 
2. Nachträglich, wenn's läuft:
für III a)
mit VirtualQueryEx die jew. Speicherbereiche des "Ziels" abklappern und nebenbei mit der "offiziellen" Modulliste in PEB vergleichen.
Alles, was PAGE_EXECUTE Flag hat, sollte innerhalb einer DLL-Code-Section liegen (einfach DllBase+ImageSize reicht ja nicht aus).
Das schließt schon mal jegliche JITs aus und könnte bei der einen oder anderen legitimen DLL zu einem False-Positiv führen.
Ich wüsste jetzt auch nicht, wie man die Zugehörigkeit einer nachträglich allozierten Page im virt. Prozesspeicher einem konkreten Modul zuordnen könnte.
für III b) - wie vorher, man bräuchte allerdings schon die Checksummen oder andere Verifizierungsmöglichkeiten für ALLE
Module.
und für III c) fällt mir nur Heuristik samt schwarzer Magie ein - es müssten praktisch ALLE Speicherbereiche durchgescannt
und dann "möglicherweise böser, ausführbarer Cheat-Code festgestellt werden".
Eine saubere Injection bei einem "paranoiden" Schutz hat mehrere "Stufen" und schaut in etwa so aus:
1) simple DLL/Codeinjection in den Explorer (damit die P(arent)PID auch hübsch ist).
2) von hier aus: CreateProcess(Ziel ..., CREATE_SUSPENDED)
Zu diesem Zeitpunkt sollten nur die SystemDLLs gemappt, nichts läuft.
Bei Bedarf lässt sich Schritt 2 "verketten" (Explorer => Starter => Ziel usw.)
3) VirtualAllocEx oder (je nach Codegröße) sucht man einen Part in der SystemDLL der eh' nicht ausgeführt wird
(normalerweise hat man wegen Section-Alignment am Ende der jew. Section ausreichend Platz).
Code reinsetzen, ResumeThread.
"Have fun" bei der Erkennung
Damit hat man:
I. keine anderen Prozesse. PPID stimmt.
II. die Modulliste in PEB (ProzessEnvironmentBlock) ist "sauber", keine Debugflags u.ä.
III. der Code sitzt a) in einem Speicherbereich, b) in einer der legitimen DLLs oder c)
wenn man die Mögichkeit hat, den Prozess in die DEP-Ausnahmeliste einzutragen
braucht der reservierte Speicherbereich nur den PAGE_READ Flag.
Erkennung:
1. Injectionschritt selbst - wird im Userspace imho kompliziert - zumindest wenn nicht ständig alle Programme überwacht werden.
Die üblichen
2. Nachträglich, wenn's läuft:
für III a)
mit VirtualQueryEx die jew. Speicherbereiche des "Ziels" abklappern und nebenbei mit der "offiziellen" Modulliste in PEB vergleichen.
Alles, was PAGE_EXECUTE Flag hat, sollte innerhalb einer DLL-Code-Section liegen (einfach DllBase+ImageSize reicht ja nicht aus).
Das schließt schon mal jegliche JITs aus und könnte bei der einen oder anderen legitimen DLL zu einem False-Positiv führen.
Ich wüsste jetzt auch nicht, wie man die Zugehörigkeit einer nachträglich allozierten Page im virt. Prozesspeicher einem konkreten Modul zuordnen könnte.
für III b) - wie vorher, man bräuchte allerdings schon die Checksummen oder andere Verifizierungsmöglichkeiten für ALLE
Module.
und für III c) fällt mir nur Heuristik samt schwarzer Magie ein - es müssten praktisch ALLE Speicherbereiche durchgescannt
und dann "möglicherweise böser, ausführbarer Cheat-Code festgestellt werden".
Das ganze klingt jetzt komplizierter, als es ist:
Meine erste "größere" Codeinjection war die "Verrenkung" in der Art:
Codeinjection in den Adressraum einer einer SystemDLL -> Callback auf einen API-Aufruf
-> dieser Callback stoppte alles außer dem Mainthread, patchte die erforderliche Stelle mit <foobar, Callback2>
und der Callback2 machte dies wieder rückgängig.
Das war für den "X-Jahre-Ungeknackt" SW-Protector doch zu viel des Guten (und ließ einen den Mangel an Unpacking-Skills kaschieren )
obwohl "OpenProcess/WriteProcessMemory" bzw. ein "konstanter" Memory-Patch dank Anti-Debug und Checksummen durchaus abgefangen wurden.
Der Aufwand hielt sich in Grenzen, obwohl zusätzlich eine GUI-Ausgabe für den errechneten Key mit drin war
Codeinjection in den Adressraum einer einer SystemDLL -> Callback auf einen API-Aufruf
-> dieser Callback stoppte alles außer dem Mainthread, patchte die erforderliche Stelle mit <foobar, Callback2>
und der Callback2 machte dies wieder rückgängig.
Das war für den "X-Jahre-Ungeknackt" SW-Protector doch zu viel des Guten (und ließ einen den Mangel an Unpacking-Skills kaschieren
)obwohl "OpenProcess/WriteProcessMemory" bzw. ein "konstanter" Memory-Patch dank Anti-Debug und Checksummen durchaus abgefangen wurden.
Der Aufwand hielt sich in Grenzen, obwohl zusätzlich eine GUI-Ausgabe für den errechneten Key mit drin war