.

[NoUser]

.

[Dark]

Hallo,

es ist durchaus möglich eine bestimmte Sandbox zu erkennen. Es gibt jedoch verschiedene, die auch auf verschiedene Art und weisen arbeiten. Ich habe das nochmal als Grafik dargestellt:

Für den, der es lieber etwas größer hat: http://www.darkx-network.de/dl/calls2.png



So hier sieht man wieder die ganzen Schritte von OpenFile bis zum tatsächlichen öffnen der Datei.
1. Schritt, OpenFile ruft CreateFile in der Kernel32.dll auf
2. Schritt, CreateFile ruft NtOpenFile in der NtDLL.auf
Bis hier konnte man bereits 2 mal die Import Table und 2 mal den Code an sich abändern
Ab jetzt in Ring 0, in dem wir mit PureBasic ohne Treiber weder lesen noch schreiben können
3. Schritt, der SYSENTER Event Handler wird aufgerufen und schaut die Adresse für den NtOpenFile Befehl in der (S)SDT - (System) Service Descriptor Table nach.
4. Aufruf der Kernel Funktion NtOpenFile()

Sandboxie manipuliert so weit ich weiß, zum Beispiel die (S)SDT. Um wirklich alle Hooks erkennen zu können, müsstest du nun für alle Windows Versionen auf denen das Programm läuft für jeden Import, die (S)SDT usw. die Originalwerte wissen. Selbst wenn nun festgestellt würde, das etwas geändert wurde, muss das nicht eine Sandbox sein. Jeder Virenscanner wird sich zum Beispiel NtWriteFile/NtReadFile irgendwie hooken um zum Beispiel Downloads etc. auf Viren zu scannen.
Genauso wird auch fast immer NtOpenProcess / NtOpenThread gehooked sein, damit verhindert werden kann, das ein anderer Process das Recht bekommt den Virenscanner per TerminateProcess zu beenden.

Eine Sandbox muss sehr komplex sein und es ist durchaus möglich, das bei der ein oder anderen unter Umständen vergessen wurde, das man über IPC (Inter Process Communication) oder ähnliches merken kann, das man sich in einer Sandbox befindet, jedoch funktioniert dies dann wieder nur bei einer Sandbox.

mfg,
DarkPlayer

[Thorium]

Sandboxie ist sehr einfach zu erkennen, da es im Usermode arbeitet.
Hier 2 Erkennungsmethoden, eine ist generisch und checkt ob auf einer API-Function ein Inline-Hook liegt, die andere Testet spezifisch ob Sandboxie in den Prozess geladen wurde.

Sandboxie fummelt nicht an der SDT rumm, das patcht JMP-Instruktionen in die API-Function, das ist auch als Inline-Hook bekannt.

Code: Alles auswählen

EnableExplicit

Procedure.i IsSandboxieInjected()
  
  Protected.i Lib
  
  Lib = OpenLibrary(#PB_Any, "SbieDLLX.dll")
  CloseLibrary(Lib)
  
  If Lib <> 0
    ProcedureReturn #True
  Else
    ProcedureReturn #False
  EndIf
  
EndProcedure

Procedure.i IsHooked(Module.s, Function.s)
  
  Protected Lib.i
  Protected *FuncAddr.Ascii
  
  Lib = OpenLibrary(#PB_Any, Module)
  *FuncAddr = GetFunction(Lib, Function)
  CloseLibrary(Lib)
    
  If *FuncAddr <> 0
    
    If *FuncAddr\a = $E9
      ProcedureReturn #True
    Else
      ProcedureReturn #False
    EndIf
    
  EndIf
  
EndProcedure

If IsHooked("Ntdll.dll", "NtCreateFile") = #True
  MessageRequester("Hook Test", "NtCreateFile is hooked.")
EndIf

If IsSandboxieInjected() = #True
  MessageRequester("Sandboxie Injected Test", "Sandboxie is injected.")
EndIf

[Dark]

Code: Alles auswählen

EnableExplicit

Procedure.i IsSandboxieInjected()
  
  Protected.i Lib
  
  Lib = OpenLibrary(#PB_Any, "SbieDLLX.dll")
  CloseLibrary(Lib)
  
  If Lib <> 0
    ProcedureReturn #True
  Else
    ProcedureReturn #False
  EndIf
  
EndProcedure

Dies Überprüft jedoch nur, ob die DLL vorhanden ist, aber nicht ob man sich gerade in einer SandBox befindet. Ich denke nicht das er Kunden verbieten will Sandboxie installiert zu haben. Außerdem schlägt der Test bei mir fehl, da sich die DLL bei mir in einem anderen Verzeichniss befindet. Fakt ist, das die DLL auch nicht in den Process geladen wird, es ist also auf diese Methode NICHT möglich herauszufinden ob man sich in einer SandBox befindet.

Code: Alles auswählen

Procedure.i IsHooked(Module.s, Function.s)
 
  Protected Lib.i
  Protected *FuncAddr.Ascii
 
  Lib = OpenLibrary(#PB_Any, Module)
  *FuncAddr = GetFunction(Lib, Function)
  CloseLibrary(Lib)
   
  If *FuncAddr <> 0
   
    If *FuncAddr\a = $E9
      ProcedureReturn #True
    Else
      ProcedureReturn #False
    EndIf
   
  EndIf
 
EndProcedure

Hier haben wir das andere von mir erwähnte Problem:
Hook: JA!, Sanxbox? : Keine Ahnung
Ein Hook bedeutet ja nicht gleich das vorliegen einer Sandbox. Es ist nur EVENTUELL möglich, das man sich in einer Sandbox befindet.

mfg,
DarkPlayer

[Thorium]

Dies Überprüft jedoch nur, ob die DLL vorhanden ist, aber nicht ob man sich gerade in einer SandBox befindet. Ich denke nicht das er Kunden verbieten will Sandboxie installiert zu haben. Außerdem schlägt der Test bei mir fehl, da sich die DLL bei mir in einem anderen Verzeichniss befindet. Fakt ist, das die DLL auch nicht in den Process geladen wird, es ist also auf diese Methode NICHT möglich herauszufinden ob man sich in einer SandBox befindet.

Nein, du hast den Code falsch verstanden, es prüft ob die DLL in den Prozess geladen ist (injiziert wurde). Und das ist nur der Fall, wenn das Programm unter Sandboxie läuft, kannst es ja ausprobieren.

Hier haben wir das andere von mir erwähnte Problem:
Hook: JA!, Sanxbox? : Keine Ahnung
Ein Hook bedeutet ja nicht gleich das vorliegen einer Sandbox. Es ist nur EVENTUELL möglich, das man sich in einer Sandbox befindet.

Ja richtig. Ich hab ja geschrieben das es eine generische Prozedur ist. Damit muss man halt rummspielen bis man ne gute Kombination hat aus Prozeduren die getestet werden. Ein false positive ist bei generischen Prozeduren immer möglich.

[Thorium]

Wenn die DLL bei dir nicht in den Prozess geladen wird, hast du ne andere Version von Sandboxie oder irgenwas installiert, was Sandboxie verschleiert. Wo die DLL liegt spielt keine Rolle.

[Dark]

Hallo,

OpenLibrary() ist keine Überprüfung ob sich eine DLL in einem Process befindet, sondern ruft intern nur die Windows API LoadLibrary_() auf. Diese lädt eine DLL in einen Prozess rein, egal ob diese vorher schon im Process geladen ist oder nicht. Siehe MSDN: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

LoadLibrary Function

Loads the specified module into the address space of the calling process. The specified module may cause other modules to be loaded.

Um zu überprüfen ob eine DLL in einem Proces geladen ist musst du

Code: Alles auswählen

Lib = GetModuleHandle_("SbieDLLX.dll")

verwenden.
Dies schlägt aber Fehl, da dise DLL nicht in den Process geladen wird.

mfg,
DarkPlayer

[Thorium]

Hallo,

OpenLibrary() ist keine Überprüfung ob sich eine DLL in einem Process befindet, sondern ruft intern nur die Windows API LoadLibrary_() auf. Diese lädt eine DLL in einen Prozess rein, egal ob diese vorher schon im Process geladen ist oder nicht. Siehe MSDN: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

LoadLibrary Function

Loads the specified module into the address space of the calling process. The specified module may cause other modules to be loaded.

Um zu überprüfen ob eine DLL in einem Proces geladen ist musst du

Code: Alles auswählen

Lib = GetModuleHandle_("SbieDLLX.dll")

verwenden.
Dies schlägt aber Fehl, da keine DLL in den Process geladen wird.

mfg,
DarkPlayer

^^
Ist die DLL bereits geladen, gibt die Prozedur den Handle der DLL zurück und schlägt nicht fehl.
Ist die nicht bereits geladen und kann auch nicht geladen werden, so schlägt sie fehl. Da sie sich weder im Systemverzeichnis noch im Programmverzeichnis befindet kann sie nicht geladen werden.

Ich weis schon was ich mache. ^^

Und wie gesagt sie wird geladen, oder soll ich dir erst nen Screenshot von OllyDbg schicken?
Schaus dir doch einfach selbst an. Die DLL muss auch geladen werden, ansonsten würden die Inline-Hooks ins Nirvana springen und der Prozess würde crashen.
Möglich das sie bei dir anders heisst oder du hast ne Kernelmode-Version von Sandboxie oder was weis ich. Aber mit der Version, dessen Link du mir gegeben hast funktioniert das 100%.
Ich bin doch kein Noob.

[Dark]

^^
Ist die DLL bereits geladen, gibt die Prozedur den Handle der DLL zurück und schlägt nicht fehl.
Ist die nicht bereits geladen und kann auch nicht geladen werden, so schlägt sie fehl. Da sie sich weder im Systemverzeichnis noch im Programmverzeichnis befindet kann sie nicht geladen werden.

Ist Sandboxie aber installiert und befindet sich die DLL im Windows Verzeichniss, lädt er die DLL und du behauptest das Programm lief in einer Sandbox. Deshalb sollte man lieber den Befehl verwenden den ich geschrieben habe, da dieser es wirklich nur erkennt wenn die DLL auch im Prozess geladen ist. Das Sandboxie installiert ist, sollte ja nicht ein Grund sein die Ausführung des Programms zu verhindern.
Ich habe gerade selber mit OllyDebugger geschaut, Sandboxie scheint die Angewohnheit zu haben, von Version zu Version den Namen der DLL zu ändern, weshalb die Methode auch keine große Zuverlässigkeit bietet.

Außerdem ging es hierbei um eine sichere Methode eine Sandbox zu erkennen. Sandboxie hat erstmal kein Monopol auf diese Art von Technologie und zweitens könnte durchaus auch mal eine DLL mit gleichem Namen vorkommen.

Inlinke Hook Detection ist zwar durchaus eine Möglichkeit herauszufinden ob ewtas manipuliert wurde, aber auch Rootkit Unhooker zeigt mir Hooks bei Prozessen an die nicht in einer Sandbox laufen, ist also genau so wenig zuverlässig.
Zum Beispiel bei Firefox oder dem Explorer etc.

mfg,
DarkPlayer

[Thorium]

Bei der Version, die ich runtergeladen hab befindet sich die DLL nicht im Windowsverzeichnis. Sie befindet sich im Installationsverzeichnis von Sandboxie.

Aber is ja auch egal, der Punkt ist das es erkennbar ist und es hat mich grad mal 2 Minuten gekostet das rauszufinden. Ein Cracker würde so zwischen 10 und 20 Sekunden benötigen meine Prozedur zu cracken.
Alles in allem funktioniert beides nicht zuverlässig, weder das Erkennen noch das Sandboxen. Gild genauso für VM's.