Anti .dll Injection

Page 2 of 3 1 2 3
10/19/2012 01:31 3Angle#16
Auch wenn ich ein elendiger Coder wäre, trotzdem darf ich wohl meine Projekte vorstellen.
Nimm es jetzt nicht direkt so übel :)
10/21/2012 13:30 Ende!#17
Quote:
Originally Posted by 3Angle View Post
Übertreib mal nicht so extrem! Ich will erstmal sehen wie du einen gelöschten Einstiegspunkt eines Programmes nutzten willst...
Warum sagst du direkt, dass dieser "Schutz" komplett sinnlos ist... Du hast wohl nicht ganz so viel Erfahrung mit solchen Dingen, wenn man sowas behauptet...

In Google finde ich keinen C&P Source...
1) So leicht war das Coden nicht.
2) Da du nicht genau weißt, wie mein Source klappt, kannst du ebenfalls nicht bewerten, ob es leicht zu umgehen ist.
1) Interessiert keinen, wenn sie trotzdem einfach zu umgehen ist.
2) Ich schätze du meinst damit die Methode, bei der man Teile der ntdll überschreibt, damit mit CreateRemoteThread erstellte Threads nicht mehr korrekt initialisiert werden. Das zu umgehen ist easy going: Target-Process suspenden, .text Segment der Remote-ntdll mit dem der ntdll aus dem eigenen Prozess überschreiben, checken ob die ntdll im Remote-Process an der selben Basisadresse geladen ist, wenn nicht gegebenenfalls noch eben die Relocs fixuppen, den Prozess wieder resumen und schon rennt der Hund wieder. Alles in allem eine Sache von rund 'ner Viertelstunde.
10/21/2012 14:03 3Angle#18
Du meinst bestimmt sowas? Da sowas schon längst öffentlich zu finden ist, ist sowas mitterweile für Hacker kein Hinderniss mehr und deshalb habe ich diese Technik auch nicht benutzt.
Code:
#include <windows.h>
#include "stdafx.h"
BOOLEAN BlockAPI( HANDLE, CHAR*, CHAR* );

void main()
{
	void AntiInject () ;
 
}


void AntiInject () 
{ 
	
   HANDLE hProc = GetCurrentProcess(); 
   while (TRUE) { 
      BlockAPI(hProc, "NTDLL.DLL", "LdrLoadDll"); 

      Sleep (100); 
   } 
} 

 
BOOLEAN BlockAPI (HANDLE hProcess, CHAR *libName, CHAR *apiName) 
{ 
   CHAR pRet[]={0xC3}; 
   HINSTANCE hLib = NULL; 
   VOID *pAddr = NULL; 
   BOOL bRet = FALSE; 
   DWORD dwRet = 0; 
 
   hLib = LoadLibraryA (libName); 
   if (hLib) { 
       pAddr = (VOID*)GetProcAddress (hLib, apiName); 
       if (pAddr) { 
           if (WriteProcessMemory (hProcess, 
                            (LPVOID)pAddr, 
                            (LPVOID)pRet, 
                            sizeof (pRet), 
                            &dwRet )) { 
              if (dwRet) { 
                 bRet = TRUE; 
              } 
           } 
       } 
       FreeLibrary (hLib); 
   } 
   return bRet; 
}
Ich habe etwas komplett anderes genutzt.
10/21/2012 14:28 Ende!#19
Auch wenn diese Variante denkbar schlecht implementiert ist, ja, sowas in der Art meinte ich. Mir stellt sich die Frage, was du mit diesem Thread hier erreichen willst. Wenn du deine Methoden auf Sicherheit überprüfen willst, dann poste eine HackMe.exe und lass die Leute versuchen, sie zu umgehen - diese Videos bringen exakt gar nichts. Security through obscurity kann maximal ein zusätzliches Mittel sein.
10/21/2012 14:58 3Angle#20
Okay, dann werde ich in den nächsten Tagen eine HackMe Executable posten und sie hacken lassen, und dies ebenfalls auf Hackforums, wo ein paar sehr erfahrene Reverser sind(Nicht weil es hier keine guten gibt).
Was ist direkt anmerken muss, dass es möglich ist, dass die Execuatable direkt crasht weil ich es nur auf 64Bit System angepasst habe(Windows 7).
10/21/2012 16:36 Dr. Coxxy#21
juchhu, nen ac der nur auf 64 bit läuft^^
10/21/2012 17:36 tnd0#22
Quote:
Originally Posted by Dr. Coxxy View Post
juchhu, nen ac der nur auf 64 bit läuft^^
früher oder später wird 32bit wohl entgültig wegfallen - kommerziell macht es für non-top-titel keinen sinn 64bit vorrauszusetzen, aber die meisten AAA-games setzen doch bereits GHz-Werte vorraus, die kein 32bit Prozessor erreicht. Und wer mit nem 64Bit Prozessor unter WindowsXP x32 unterwegs ist fährt imho mit angezogener Handbremse und redet sich ein XP wäre besser als 7.

Sogar 49 von 52 Offices für die ich Software schreibe haben kein 32Bit OS mehr, und das obwohl die PCs dort nur zum eintippen und auslesen von Informationen benutzt werden. Kann mir gut vorstellen, dass das übernächste Windows kein 32Bit-Subsystem mehr hat. 64-Bit-only Software ist keineswegs schlecht.

Was aber tief blicken lässt ist die eigentliche Aussage

Quote:
Was ist direkt anmerken muss, dass es möglich ist, dass die Execuatable direkt crasht weil ich es nur auf 64Bit System angepasst habe(Windows 7).
Wer Ahnung hat weiss, dass eine 64Bit Executable NIEMALS auf einem 32Bit OS laufen wird, und dass eine 32Bit Executable auf einem 32Bit OS keine Probleme verursachen kann, weil es eben genau dafür gedacht ist. Glaube ja kaum, dass deine "auf 64Bit angepasste Version" in meinem Ubuntu laufen wird, obwohls auch 64Bit benutzt..

Das einzige was Probleme machen kann ist wohl die API-Version für die ein Programm angepasst ist, die hat aber nun rein garnichts mit der Prozessorarchitektur zu tun...
10/21/2012 21:58 Saedelaere*#23
Quote:
Originally Posted by 3Angle View Post
Okay, dann werde ich in den nächsten Tagen eine HackMe Executable posten und sie hacken lassen, und dies ebenfalls auf Hackforums, wo ein paar sehr erfahrene Reverser sind(Nicht weil es hier keine guten gibt).
Challenge accepted :pimp:
10/21/2012 22:25 MrSm!th#24
Quote:
früher oder später wird 32bit wohl entgültig wegfallen - kommerziell macht es für non-top-titel keinen sinn 64bit vorrauszusetzen, aber die meisten AAA-games setzen doch bereits GHz-Werte vorraus, die kein 32bit Prozessor erreicht. Und wer mit nem 64Bit Prozessor unter WindowsXP x32 unterwegs ist fährt imho mit angezogener Handbremse und redet sich ein XP wäre besser als 7.
64Bit CPUs gibts doch schon wesentlich länger als Win7 und erst mit Win7 kam von MS das erste massentaugliche 64bit OS oO
10/21/2012 22:34 3Angle#25
Ich meinte mit meiner Aussage, dass ich die Executable auf 32Bit kompiliert habe, sie aber sehr wahschreinlich nur auf 64Bit läuft. Also ein 32Bit Programm das für 64Bit Betriebssysteme erstellt wurde.
Da es einige Sicherheitunterschiede zwischen 32Bit und 64Bit kompilierten Programmen gibt .
10/21/2012 22:44 MrSm!th#26
Die da wären?
Vor allem hast du doch für 32bit kompiliert, also sollten diese Unterschiede hier irrelevant sein, du hast ja kein 64bit Programm geschrieben.
10/21/2012 23:13 3Angle#27
Ausschlaggebend ist es, weil ein 64Bit System Programme anders ausführt als ein 32Bit System, auch wenn es die gleiche 32Bit Executable ist.
Der Unterschied darin liegt, wie das System mit den Prozessen klar kommt: Größe der Speicheradresse, Performance, halt die Bitlänge und sowas ist ausschlaggebend für mein Tool.

EDIT: [Only registered and activated users can see links. Click Here To Register...]
HackMe hochgeladen...
10/23/2012 10:58 Tyrar#28
Quote:
Originally Posted by 3Angle View Post
Ausschlaggebend ist es, weil ein 64Bit System Programme anders ausführt als ein 32Bit System, auch wenn es die gleiche 32Bit Executable ist.
Der Unterschied darin liegt, wie das System mit den Prozessen klar kommt: Größe der Speicheradresse, Performance, halt die Bitlänge und sowas ist ausschlaggebend für mein Tool.

EDIT: [Only registered and activated users can see links. Click Here To Register...]
HackMe hochgeladen...
der unterschied ist, dass bei einer 32bit executable auf 64bit systemen, wenn ich richtig informiert bin(!), der code emuliert wird. ob die aussage richtig ist sei mal dahin gestellt, es ist und bleibt trotzdem der exakt gleiche code der ausgeführt wird! (abgesehen von einigen modulen die nicht dazu gehören, diese werden aber auch keine fehler enthalten, da das die windoof eigenen sind!)
10/23/2012 21:34 Nightblizard#29
WOW64

Da ändert sich schon einiges in der PE, wenn du von x86 auf x64 wechselst. Wenn man das nicht sauber runterprogrammiert (das hat Microsoft alles sauber getypedefd), dann gibts halt Probleme beim Wechsel.
Jedoch frage ich mich - einfach nur aus interesse, will mich dem Mob nicht anschließen -, warum du überhaupt eine x86 .exe erstellst, wenn es eh nur für x64 ausgelegt ist?

Funktioniert es denn sauber mit ner x64 PE? Was genau hast du überhaupt gemacht? Das klingt alles doch schon sehr merkwürdig.
10/24/2012 19:47 MrSm!th#30
Quote:
Originally Posted by Nightblizard View Post
WOW64

Da ändert sich schon einiges in der PE, wenn du von x86 auf x64 wechselst. Wenn man das nicht sauber runterprogrammiert (das hat Microsoft alles sauber getypedefd), dann gibts halt Probleme beim Wechsel.
Jedoch frage ich mich - einfach nur aus interesse, will mich dem Mob nicht anschließen -, warum du überhaupt eine x86 .exe erstellst, wenn es eh nur für x64 ausgelegt ist?

Funktioniert es denn sauber mit ner x64 PE? Was genau hast du überhaupt gemacht? Das klingt alles doch schon sehr merkwürdig.
Aber hast du schonmal von nem für 32bit kompilierten aber nur auf 64bit funktionierenden Executable gehört? :|
Page 2 of 3 1 2 3