Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Software-Projekte der Mitglieder (https://www.delphipraxis.net/26-software-projekte-der-mitglieder/)
-   -   Portable Executable File Unit (https://www.delphipraxis.net/95095-portable-executable-file-unit.html)

ErazerZ 30. Jun 2007 19:05


Portable Executable File Unit
 
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
ich habe mich des öfteren mit Microsofts PE-Format beschäftigt und deswegen dachte ich mir das ich mal eine Unit mache die die Arbeit mit dem PE-Format erleichtern sollte :). Die Unit wird von mir täglich mit neuen Funktionen erweitert!
Unit Version: 1.3
Funktionen:
  • Allgemeines
  • LoadFromFile - Laden einer Datei.
  • SaveToFile - Speichern einer Datei.
  • ValidHeaders - Überprüft ob die DOS + NTHEADERS in ordnung sind.
  • ReadPeHeaders - Ließt alle Sektionen und Header ein.
  • Align - Align :).
  • SectionToString - Gibt den Namen einer Sektion in String zurück.
  • StringToSection - Setzt einen neuen Namen einer Sektion.
  • SetAddressOfEntryPoint - Setzt einen Neuen EntryPoint.
  • SetImageBase - Setzt eine neue ImageBase.
  • CopyMemoryToBuffer - Damit kann man den Speicher der geladenen Datei ändern.
  • CopyMemoryFromBuffer - Damit kann man aus dem Speicher der geladenen Datei lesen.

    Umrechnungen
  • RvaToFileOffset - Berechnet die Relative Virtuelle Adresse in die Physikalische Adresse um.
  • FileOffsetToRva - Berechnet die Physikalische in die Relative Virtuelle Adresse um.
  • VaToFileOffset - Berechnet die Virtuelle Adresse in unserem Speicher in die Physikalische Adresse um.
  • FileOffsetToVa - Berechnet die Physikalische Adresse in die Virtuelle Adresse in unserem Speicher um.
  • VaToRva - Berechnet die Virtuelle Adresse in unserem Speicher in die Relative Virtuelle Adresse.
  • RvaToVa - Berechnet die Relative Virtuelle Adresse in der Virtuellen Adresse in unserem Speicher.
  • RvaToSection - Liefert anhand der Relativen Virtuellen Adresse die Nummer der Sektion in der sie sich befindet.
  • FileOffsetToSection - Liefer anhand der Physikalischen Adresse die Nummer der Sektion in der sie sich befindet.

    Hinzufügen/Entfernen
  • InsertBytes - Fügt x Bytes im Speicher der Datei.
  • DeleteBytes - Löscht x Bytes im Speicher der Datei.
  • FindCodeCaves - Sucht nach sogenannten "Code-Höhlen" (0-Bytes) im Speicher der Datei.

    Sektionen
  • AddSection - Fügt eine neue Sektion hinzu. Hier wird jedoch geprüft ob noch Platz für eine neue Sektion vorhanden ist, falls nein wird neuer angelegt.
  • DeleteSection - Löscht eine bestimmte Sektion aus der PE Datei.
  • GetCharacteristics - Liefert die Characteristics in String einer Sektion.
  • GetCodeSection - Liefert die Nummer der Sektion in der sich die Code-Sektion befindet.
  • GetDataSection - Liefert die Nummer der Sektion in der sich die Data-Sektion befindet.
  • GetResourceSection - Liefer die Nummer der Sektion in der sich die Ressourcen-Sektion befindet.
  • GetImportAddressTable - Liefert alle Importe einer Datei (Zurzeit Normale IAT, Delayed IAT, Bound IAT).
  • GetExportsAddressTable - Liefert die Exports einer Datei.
  • GetThreadLocalStorage - Liefert Informationen zu TLS.
  • GetResources - Liefert alle Ressourcen der Datei (Ressourcen-Typen, Resourcen-Namen).
  • GetDebugDirectory - Liefert Informationen zu der Debug Directory.
  • GetLoadConfigDirectory - Liefert Informationen zu der Load Config Directory.
  • GetEntryExceptionDirectory - Liefert Informationen zu Entry Exception Directory.
  • DumpSection - Damit kann man eine Sektion auf der Festplatte speichern.
  • GetHighestSectionSize - Liefert die "größte"/letzte Sektion (also PointerToRawData + SizeOfRawData).
  • GetDataFromEOF - Damit kann man die Daten die sich nach Ende aller Sektionen befinden auslesen und zwischenspeichern.
  • RecalcImageSize - Damit lässt sich die SizeOfImage neu berechnen.
  • ResizeSection - Damit kann man einzelne Sektionen vergrößern! Achtung: Ressourcen (OffsetToData) werden angepasst!
  • CalcChecksum - Damit wird die Check-Summe der PE Datei berechnet.
  • RecalcCheckSum - Berechnet automatisch die Check-Summe und ändert diese gleich in den Headern.
  • WriteImageSectionHeader - Schreibt alle ImageSections in dem Speicher!

    Neu Dabei
  • AddSection - RawSize hinzugefügt, VirtualSize entfernt - wird automatisch von RecalcImageSize berechnet,
    lpData und dwDataLength hinzugefügt (das heißt, dass man die neue Sektion gleich mit Daten füllen kann).
  • DeleteSection - ImageSize wird über RecalcImageSize berechnet, ruft RecalcCheckSum am Ende der funktion auf!
  • ResizeSection - Damit kann man einzelne Sektionen vergrößern! Achtung: Ressourcen (OffsetToData) werden angepasst!
  • GetResources - Überarbeitet (RVA wurde falsch berechnet!), neue Struktur (enthält größe des Entries)
  • Resources Beispiel - Angepasst an die neue Struktur und Dump funktion hinzugefügt!
  • CalcChecksum - Damit wird die Check-Summe der PE Datei berechnet.
  • RecalcCheckSum - Berechnet automatisch die Check-Summe und ändert diese gleich in den Headern.
  • WriteImageSectionHeader - Schreibt alle ImageSections in dem Speicher!

    Beispiele
  • IAT - Ein Beispiel Programm um die Imports einer Anwendung auszulesen und auszugeben.
  • EAT - Ein Beispiel Programm um die Exports einer DLL-Datei auszulesen und auszugeben.
  • Resources - Ein Beispiel Programm um die Ressourcen einer Anwendung auszulesen und auszugeben. Man kann auch die ausgewählte Ressource dumpen!
  • Sections - Ein Beispiel Programm um die Sektionen einer Anwendung auszulesen und auszugeben.
  • ExeLoader - Ein ganz kleiner Exe-Loader der die Code-Sektion mittels XOR verschlüsselt. Er fügt einen neuen Loader in einer neuen Sektion hinzu,der zur Laufzeit die Code-Sektion entschlüsselt und zum Original Entry Point springt.


Beispiel-Aufruf:
Delphi-Quellcode:
uses untPeFile;
...
procedure TForm1.FormCreate(Sender: TObject);
var
  PE: TPeFile;
  x: Word;
  Imports: TImportsArray;
const
  sSection = 'Name: %s' + #13#10 +
            'Sektion: %d/%d' + #13#10 +
            'Start der Sektion: %d' + #13#10 +
            'Größe der Sektion: %d';
  sImports = 'Bound Import Lib: %s';

begin
  PE := TPeFile.Create;
  // Datei Laden ..
  if PE.LoadFromFile('C:\WINDOWS\Notepad.exe') then
  begin
    // Alle Sektionen ausgeben
    for x := Low(PE.ImageSections) to High(PE.ImageSections) do
      ShowMessage(Format(sSection, [PE.SectionToString(PE.ImageSections[x]), x, PE.NumberOfSections -1, PE.ImageSections[x].PointerToRawData, PE.ImageSections[x].SizeOfRawData]));
    // Imports Auslesen
    PE.GetImportAddressTable(Imports);
    // Nur die Bound IAT ausgeben
    for x := Low(Imports) to High(Imports) do
      if Imports[x].ImportType = itBound then
        ShowMessage(Format(sImports, [Imports[x].LibraryName]));
    // Neue Sektion anlegen
    PE.AddSection('NewSec', $200);
    // Die angelegte Sektion wieder entfernen
    PE.DeleteSection(PE.NumberOfSections -1);
    // Speichern ...
    PE.SaveToFile('C:\NOTEPAD_TMP.exe');
  end;
  // Freigeben...
  PE.Free;
end;
Falls ihr Verbesserungsvorschläge habt, dann nur her damit!

lbccaleb 30. Jun 2007 19:15

Re: Portable Executable File Unit
 
ich werde sie mal testen thx dafür, wie siehts denn aus mit dem copyright???

nur credits bei verwendung!!?? und wie siehts aus mit dem bearbeiten???

ErazerZ 30. Jun 2007 19:25

Re: Portable Executable File Unit
 
Zitat:

Zitat von lbccaleb
ich werde sie mal testen thx dafür, wie siehts denn aus mit dem copyright???

nur credits bei verwendung!!?? und wie siehts aus mit dem bearbeiten???

Naja wenn du willst kannst du mir auch ruhig Geld dafür geben :P. Ist ja "nur" Code und ich bin damit zufrieden wenn mein Name in den Credits steht :).

ErazerZ 13. Jul 2007 21:52

Re: Portable Executable File Unit
 
Habe gerade eben eine neue Version (mit Beispielen) raufgeladen.

Zitat:

Zitat von ErazerZ
  • Neu Dabei
  • DumpSection - Damit kann man eine Sektion auf der Festplatte speichern.
  • CopyMemoryBuffer - Damit kann man die geladene Datei im Speicher bearbeiten.
  • IAT-Auslesen verbessert.

    Beispiele
  • IAT - Ein Beispiel Programm um die Imports einer Anwendung auszulesen und auszugeben.
  • EAT - Ein Beispiel Programm um die Exports einer DLL-Datei auszulesen und auszugeben.
  • Resources - Ein Beispiel Programm um die Resourcen einer Anwendung auszulesen und auszugeben.
  • Sections - Ein Beispiel Programm um die Sektionen einer Anwendung auszulesen und auszugeben.
  • ExeLoader - Ein ganz kleiner Exe-Loader der die Code-Sektion mittels XOR verschlüsselt. Er fügt einen neuen Loader in einer neuen Sektion hinzu, der zur Laufzeit die Code-Sektion entschlüsselt und zum Original Entry Point springt.


quantum 13. Jul 2007 23:05

Re: Portable Executable File Unit
 
Gute Arbeit :thumb:

jbg 14. Jul 2007 00:46

Re: Portable Executable File Unit
 
Du machst dir da ja ein menge Arbeit. Ich habe dafür bis jetzt immer die JclPeImage Unit benutzt.

mschaefer 14. Jul 2007 08:08

Re: Portable Executable File Unit
 
Moin, moin

Ja, das mit den zugehörigen Beispielen hat was! Programme zum verschlüsseln von Programmteilen kosten oft deutlich Geld. Hier sieht man auch noch wie vieles funktioniert. Das Projekt lässt jedenfalls auf deutlich Geduld und Ausdauer schliessen.

Viele Grüße // Martin

Relicted 14. Jul 2007 09:33

Re: Portable Executable File Unit
 
huhu!

mal eine ganz beschränkte frage:

was tut es und wofür braucht man es? :-)


gruß
reli

ErazerZ 14. Jul 2007 09:38

Re: Portable Executable File Unit
 
Zitat:

Zitat von Relicted
huhu!

mal eine ganz beschränkte frage:

was tut es und wofür braucht man es? :-)


gruß
reli

Ließ nochmal den Ersten Beitrag. Damit kann Portable Executable Dateien (Anwendungen sozusagen) bearbeiten.

Relicted 14. Jul 2007 09:40

Re: Portable Executable File Unit
 
jo da hatte ich gerade kurz mal drüber gelesen :-)
mir war nur der sinn nicht 100%ig klar :-)
d.h. man könnte in einer bestehenden datei z.b. noch eine andere "datei" unterbringen durch eine neue section und diese dann später wieder auslesen?

gruß
reli

ErazerZ 14. Jul 2007 10:16

Re: Portable Executable File Unit
 
Zitat:

Zitat von Relicted
jo da hatte ich gerade kurz mal drüber gelesen :-)
mir war nur der sinn nicht 100%ig klar :-)
d.h. man könnte in einer bestehenden datei z.b. noch eine andere "datei" unterbringen durch eine neue section und diese dann später wieder auslesen?

gruß
reli

Du kannst damit zum Beispiel, einen neuen Code in die Anwendung "einschleusen" und diesen beim Start ausführen lassen. Oder zum Beispiel die Importe der Anwendung auslesen, also die WinAPI die vom Programm benutzt wird.

sirius 14. Jul 2007 10:41

Re: Portable Executable File Unit
 
Zitat:

Zitat von Relicted
jo da hatte ich gerade kurz mal drüber gelesen :-)
mir war nur der sinn nicht 100%ig klar :-)
d.h. man könnte in einer bestehenden datei z.b. noch eine andere "datei" unterbringen durch eine neue section und diese dann später wieder auslesen?

gruß
reli

Du kannst zum Beispiel deine Kunden ärgern, indem du sowas nettes wie hier in Beitrag #19 (Anhang: orignal.exe und encrypted.exe machst. Dabei wird bei encrypted.exe der Code in der Exe erst entschlüsselt, wenn man das richtige Passwort eingegeben hat (da zum entschlüsseln das Passwort notwendig ist).

Relicted 14. Jul 2007 11:38

Re: Portable Executable File Unit
 
coole sache... aber ich glaube sowas mögen kunden generell nicht :-p

Luckie 14. Jul 2007 11:41

Re: Portable Executable File Unit
 
Was sagen eingentlich Virenscanner dazu, wenn man die Exe-Datei modifiziert oder verschlüsselt?

ErazerZ 14. Jul 2007 11:50

Re: Portable Executable File Unit
 
Und ich hab schon wieder eine Neue Version hochgeladen.
Zitat:

  • Neu Dabei
  • CopyMemoryBuffer - Damit kann man die geladene Datei im Speicher bearbeiten.
  • RecalcImageSize - Damit lässt sich die SizeOfImage neu berechnen.
  • CopyMemoryBuffer = CopyMemoryToBuffer - Damit kann man den Speicher der geladenen Datei ändern.
  • CopyMemoryFromBuffer - Damit kann man aus dem Speicher der geladenen Datei lesen.
  • GetHighestSectionSize - Liefert die "größte"/letzte Sektion (also PointerToRawData + SizeOfRawData).
  • GetDataFromEOF - Damit kann man die Daten die sich nach Ende aller Sektionen befinden auslesen und zwischenspeichern.
  • AddSection - Jetzt wird geprüft ob sich Daten nach dem Ende aller Sektionen befinden, falls ja werden diese gespeichert und wieder angehängt.


ErazerZ 14. Jul 2007 11:52

Re: Portable Executable File Unit
 
Zitat:

Zitat von Luckie
Was sagen eingentlich Virenscanner dazu, wenn man die Exe-Datei modifiziert oder verschlüsselt?

Wenn es keine Trojaner sind dann wird er auch nichts sagen :). Und das war doch nur ein kleines Beispiel für die Unit.

sirius 14. Jul 2007 11:57

Re: Portable Executable File Unit
 
Zitat:

Zitat von Relicted
coole sache... aber ich glaube sowas mögen kunden generell nicht :-p

Das glaube ich auch.

Zitat:

Zitat von Luckie
Was sagen eingentlich Virenscanner dazu, wenn man die Exe-Datei modifiziert oder verschlüsselt?

Meiner sagt nix :? Lad dir doch mal die Beispieldatei von mir runter!

brechi 14. Jul 2007 12:01

Re: Portable Executable File Unit
 
Die sagen nichts, du kannst jeden Virus crypten und der wird nicht mehr erkannt. Jedenfalls so lange bis der crypter auf die Blacklist kommt. (vereinzelt zeigen die halt an, dass die Datei möglicherweise ein Virus ist)

Olli 14. Jul 2007 12:33

Re: Portable Executable File Unit
 
Zitat:

Zitat von Luckie
Was sagen eingentlich Virenscanner dazu, wenn man die Exe-Datei modifiziert oder verschlüsselt?

Hängt davon ab.

Zitat:

Zitat von brechi
Die sagen nichts, du kannst jeden Virus crypten und der wird nicht mehr erkannt. Jedenfalls so lange bis der crypter auf die Blacklist kommt. (vereinzelt zeigen die halt an, dass die Datei möglicherweise ein Virus ist)

Also erstens verstand ich Luckies Frage eher in der Richtung, daß man es auf einem System mit Virenscanner macht, wo es dann eben nur bei aktivem Behavioral Blocking aufgehalten würde.

Allerdings muß ich dir etwas widersprechen. Das Thema wurde zwar auf dem Antivirus-Tester-Workshop hier in Reykjavík im Mai auch angesprochen, aber allgemein ist es eben nicht so, daß Packer/Crypter geblacklisted werden. Bei einigen AV-Firmen gibt es allerdings diese Tendenz, was auch rege am zweiten Tag in der Podiumsdiskussion diskutiert wurde. Auch war man sich weitgehend darüber einig, daß bei einem Packer/Crypter der quasi nur von Malware benutzt wird, ein Blacklisting bis zur Analyse und Implementierung im Emulator der AV-Engine gerechtfertigt werden kann. Übrigens hatte diese Diskussion ein Kollege von Kaspersky Niederlande angeregt, weil er sowas in seinem Vortrag am Rande erwähnt hatte - das (zumindest temporäre Blacklisting) sei übliche Praxis bei Kaspersky.

Ist der Packer erstmal effektiv in der Engine implementiert, braucht der Emulator sich bekanntlich nicht mehr durch den Entpackcode durchwühlen und damit werden solche Viren dann doch erkannt. Du (brechi) solltest doch eigentlich wissen, wie AVs implementiert sind, zumindest oberflächlich.

Abgesehen davon reden wir hier vermutlich noch nichtmal von Viren im traditionellen Sinn, weil die bekanntlich nur noch den kleinsten Teil ausmachen. Auch Skiptkiddies sind schließlich nur Benutzer vorgefertigter Lösungen ;)

ErazerZ 14. Jul 2007 12:51

Re: Portable Executable File Unit
 
Zitat:

Zitat von brechi
Die sagen nichts, du kannst jeden Virus crypten und der wird nicht mehr erkannt. Jedenfalls so lange bis der crypter auf die Blacklist kommt. (vereinzelt zeigen die halt an, dass die Datei möglicherweise ein Virus ist)

Ja genau oder man benutzt kleine Exploits um den Emulator (Heuristics, Sandbox) des AV-Systems dazu zu zwingen das scannen abzubrechen. Aber Back to Topic.

brechi 16. Jul 2007 09:54

Re: Portable Executable File Unit
 
Hi Olli, ich weiß dass wie die AV Programme in der Regel aufgebaut sind. Als Cheatprogrammierer kenn ich zumindest die Hooktechniken und teste so auch mal die ein oder anderen AV Programme. Ich hab mir aber schon länger nicht mehr KAV usw. getestet, daher kann ich nur aus Erfahrungen sprechen.
Bei Antivir war es z.b. so, dass ich ein mit UPX gepacktes Programm hatte, was nach dem entpacken und wieder packen mit UPX und einem anderen Komprimierungslevel schon die Exe nicht mehr erkannt hat. Da war wohl einfach eine Signatur für die Exe eingebaut, entpackt wurde sie wohl nicht. (Obwohl Antivir dafür ja eine entpackroutine hat). Hat mich nur geweundert warum sie da eine einfache Signatur gemacht haben und nicht auf die entpackte Exe. Naja gut, wird sich wohl mitlerweile geändert haben.
Dann das Beispiel Morphine. Wird ja größtenteils für Viren use bwneutzt und da bin ich mir doch eben sicher, dass zumindest zu meiner Zeit wo ichs mir angeschaut habe, generell alle mit Morphine gepackten Dateien als Virus eingestuft wurden. Ist mir auch relativ verständlich. Immerhin ist es OpenSource und man kann da immer kleine Änderungen machen und die gleiche gepackte Datei sieht auch immer anders aus. Macht mein Crpyter ja genauso, und denke nicht, dass die AV Programmierer für irgend welche kleinen Crypter jedesmal einen ALgorithmus entwicklen wollen der das Teil entpackt.
Und dann kommen wir noch zu Execryptor ( http://www.strongbit.com/execryptor_inside.asp ) ein kommerzielles Programm zum crypten. Die selbe Exe sieht auch immer anders aus, und entpacken kann man es nicht. Würd mich aml interessieren wie du dagegen vorgehen würdest. Bleibt ja dann auch nur für jeden Virus eine Signatur zu erstellen. Nur der Virenschreiben muss jedesmal die Exe neu durch den Crypter jagen und jedesmal wird sie nicht mehr erkannt.
Ein interessantter (wenn auch meienr Meinung nach unschön gelöster) Ansatz hjat ja asquared. Also API hooking um dann zu schaun ob man einen Virus hat. Dies könnten die AV Hersteller eigentlich super für jeglichen gecrypteten Code anwenden. Nur als Beispiel wieder Morphine, wo einige AV Hersteller ja wohl lange Zeit Probleme hatten den Programmcode zu entcrpyten. Ein Hook auf VirtualProtect (bzw. VirtualProtectNt) und man kann die Adresse vom entschlüsselten Code direkt vom Stack ablesen. Und dann darauf eben eine Signatur anlegen. Weiß nicht inwiefern die AV Hersteller das Scannen von ausgeführten Dateien überwachen. Damit kann man schon Viren die gecrypted sind erkennen ohne großartig für jede Version des Crypters den Entschlüsselunsgcode anzupassen. die ganzen Morphine Viren können so während der Laufzeit gecheckt werden, und der VirtualProtect Hook funktioniert für alle Morhpine Versionen.
http://uall.cheat-project.com/files/...ine_source.zip

Olli 16. Jul 2007 14:50

Re: Portable Executable File Unit
 
Zitat:

Zitat von brechi
Dann das Beispiel Morphine. Wird ja größtenteils für Viren use bwneutzt und da bin ich mir doch eben sicher, dass zumindest zu meiner Zeit wo ichs mir angeschaut habe, generell alle mit Morphine gepackten Dateien als Virus eingestuft wurden.

Denkbar, aber mit welchen der insgesamt 2 dutzend AV-Engines die es so gibt? :)

Zitat:

Zitat von brechi
Ist mir auch relativ verständlich. Immerhin ist es OpenSource und man kann da immer kleine Änderungen machen und die gleiche gepackte Datei sieht auch immer anders aus. Macht mein Crpyter ja genauso, und denke nicht, dass die AV Programmierer für irgend welche kleinen Crypter jedesmal einen ALgorithmus entwicklen wollen der das Teil entpackt.

Wollen nicht, oft ist es aber notwendig und oftmals sind zumindest die Packalgos wiederverwendbar.

Zitat:

Zitat von brechi
Und dann kommen wir noch zu Execryptor ( http://www.strongbit.com/execryptor_inside.asp ) ein kommerzielles Programm zum crypten. Die selbe Exe sieht auch immer anders aus, und entpacken kann man es nicht. Würd mich aml interessieren wie du dagegen vorgehen würdest. Bleibt ja dann auch nur für jeden Virus eine Signatur zu erstellen. Nur der Virenschreiben muss jedesmal die Exe neu durch den Crypter jagen und jedesmal wird sie nicht mehr erkannt.

Hmm, also ich wuerde sagen, dass dieses Produkt nur von paranoiden Idioten eingesetzt wird, die ihren Anwendern langsame Programme anbieten wollen, und eben von Malware-Autoren welche die "frei erhaeltliche" Version benutzen. So gesehen waere das einer der Packer, wo ich sogar fuer eine generelle Erkennung und Einstufung als potentielle Malware waere. Gibt da noch weniger als ein halbes dutzend anderer Kandidaten, fuer die aehnliches zutrifft. Bei Themida waeren es eben die Spielehersteller und die Malware-Autoren.

Zitat:

Zitat von brechi
Ein interessantter (wenn auch meienr Meinung nach unschön gelöster) Ansatz hjat ja asquared. Also API hooking um dann zu schaun ob man einen Virus hat. Dies könnten die AV Hersteller eigentlich super für jeglichen gecrypteten Code anwenden. Nur als Beispiel wieder Morphine, wo einige AV Hersteller ja wohl lange Zeit Probleme hatten den Programmcode zu entcrpyten. Ein Hook auf VirtualProtect (bzw. VirtualProtectNt) und man kann die Adresse vom entschlüsselten Code direkt vom Stack ablesen. Und dann darauf eben eine Signatur anlegen.

Eines der ersten Gebote in der AV-Branche: Niemals boesartigen Code ausfuehren, den man erkennen kann. Du weisst so gut wie ich, dass man solchen Hooks ueblicherweise einfach entgehen kann. Die Emulatoren haben im Zusammenhang mit Signaturen aber aehnliche Dinge eingebaut. Ist also nicht so, dass hier die Signaturen von gepackten Dateien hinzugefuegt werden muessen, wenn man denn einen Entpacker hat oder der Emulator die Datei entpacken kann.

Zitat:

Zitat von brechi
Weiß nicht inwiefern die AV Hersteller das Scannen von ausgeführten Dateien überwachen.

Meinst du nach dem Laden?

Zitat:

Zitat von brechi
Damit kann man schon Viren die gecrypted sind erkennen ohne großartig für jede Version des Crypters den Entschlüsselunsgcode anzupassen.

Packer erkennen heisst aber noch nicht entpacken. Und bei unserem Emulator ist es so, dass der die EXE auch aufm PPC-Mac oder irgendwelcher anderen exotischen Hardware "ausfuehrt" (also emuliert). Hooks sind zumindest fuer die Kern-Engine bei uns einfach zu systemspezifisch.

Luckie 16. Jul 2007 14:54

Re: Portable Executable File Unit
 
Ich hatte nachgefragt, weil ich morphine kenne und weiß, dass das von Antivren-Programmen erkannt6 wird. Aber was nützt es mir, wenn mein Virenscanner nicht anschlägt, aber dann der von Kunden? Und dann hängt das ja noch von der Definitionsdatei ab.

Der beste Schutz ist immer noch eine bedingte Kompilierung und entsprechend Funktionen nicht einkompilieren bei Shareware Versionen. Denn was im Kompilat nicht drin ist, kann nicht gecrackt werden.

Olli 16. Jul 2007 15:03

Re: Portable Executable File Unit
 
Zitat:

Zitat von Luckie
Der beste Schutz ist immer noch eine bedingte Kompilierung und entsprechend Funktionen nicht einkompilieren bei Shareware Versionen. Denn was im Kompilat nicht drin ist, kann nicht gecrackt werden.

Bingo!

ErazerZ 17. Jul 2007 17:35

Re: Portable Executable File Unit
 
Zitat:

  • Neu Dabei
  • AddSection - RawSize hinzugefügt, VirtualSize entfernt - wird automatisch von RecalcImageSize berechnet,
    lpData und dwDataLength hinzugefügt (das heißt, dass man die neue Sektion gleich mit Daten füllen kann).
  • DeleteSection - ImageSize wird über RecalcImageSize berechnet, ruft RecalcCheckSum am Ende der funktion auf!
  • ResizeSection - Damit kann man einzelne Sektionen vergrößern! Achtung: Ressourcen (OffsetToData) werden angepasst!
  • GetResources - Überarbeitet (RVA wurde falsch berechnet!), neue Struktur (enthält größe des Entries)
  • Resources Beispiel - Angepasst an die neue Struktur und Dump funktion hinzugefügt!
  • CalcChecksum - Damit wird die Check-Summe der PE Datei berechnet.
  • RecalcCheckSum - Berechnet automatisch die Check-Summe und ändert diese gleich in den Headern.
  • WriteImageSectionHeader - Schreibt alle ImageSections in dem Speicher!

ResizeSection hat Probleme gemacht aber geht schon :D

Luckie 6. Mai 2008 13:58

Re: Portable Executable File Unit
 
Zitat:

Zitat von ErazerZ
Du kannst damit zum Beispiel, einen neuen Code in die Anwendung "einschleusen" und diesen beim Start ausführen lassen.

Gibt es dazu auch ein Beispiel?

Um neuen Code einzuschleusen, reicht es da in die neue Sektion eine kompilierte Exe zu kopieren und dann den Einsprungspunkt umzubiegen?

ErazerZ 6. Mai 2008 17:42

Re: Portable Executable File Unit
 
ExeLoader.dpr ist ein Beispiel dazu. Das ist ein einfacher Execrypter der nichts anderes macht wie einen Code in einer anderen Exe-Datei einzuschleusen und dann beim ausführen ausgeführt wird und er zurück zum originellen Einsprungpunkt zurückspringt.

Luckie 6. Mai 2008 17:47

Re: Portable Executable File Unit
 
Gut, dann muss ich mir das noch mal genauer angucken.

darknes 16. Aug 2010 13:42

AW: Portable Executable File Unit
 
Mir ist klar das dieses thema schon sehr alt ist aber schon zu 2003 konnte man Execrypter entpacken(mupen).
Allso @ brechi ist das hier "Und dann kommen wir noch zu Execryptor ( http://www.strongbit.com/execryptor_inside.asp ) ein kommerzielles Programm zum crypten. Die selbe Exe sieht auch immer anders aus, und entpacken kann man es nicht"
Reiner müll vonwegen nicht entpacken das ich nicht lache.
Du hast dich zwar sehr viel mit av´s befasst,aber wenn du dich nur ein monat oder zwei mit dem manuel unpacking befasst denkst du dir das die routine eines av´s programmes ein witz gegen über von manuel unpacking ist.
@ErazerZ könntest du ein bsp:coden wo bestimmte sectionen gelöscht werden.


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:48 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz