Beiträge von DizzY_D

    Echt gute Frage... NOT
    Du fragtest doch nach einer Lösung für dein Problem. Und meine Vermutung ist es, dass am Ende ein Nullbyte fehlt.
    Denn die Steam.dll erwartet natürlich einen nunnterminerten String. Es kann auch sein, dass du die Size einfach um 1 erhöhen musst.

    Hier mal mein Projekt der letzten beiden Tage:
    Es handelt sich um einen Steampasswort Reader, der in MASM gecodet wurde.
    Ich weiÃ?, dass es sowas schon zu Hauf gibt. Es ging mir auch weniger um den Nutzen, sondern um den Lerneffekt.
    Wie man es von Assembler gewohnt ist, ist die filesize schön klein (3kb :)).
    Damit es auch UD ist, habe ich alle APIs und Strings verschlüsselt. Das Ergebnis ist 2/40, also akzeptabel.


    Der Source liegt natürlich bei, da er das eigentlich bei Assembler sowieso immer tut.
    ACHTUNG: Es handelt sich NICHT um einen Stealer. Das Passwort kann nur lokal ausgelesen werden!


    DL: http://rapidshare.com/files/25…teamReader_by_DizzY_D.rar

    Is doch logisch, denn die Exe muss ja erstmal fertig gedownloaded werden, bevor du sie ausführen kannst.
    Also bau nen kleinen Timer ein, der z.B. auf 5 sec eingestellt ist. In die Timerroutine packst du dann den Shellexecute (doch, der funtzt).

    G36KV;21184 schrieb:

    Darf man fragen welchen PE Editor/Rebuilder/Dumper du verwendest um die exe so schön hinzubekommen?


    Meine (Fiese) Vermutung ist ja, er hat einfach den OEP aus dem ersten UnpackMe kopiert und ihn in dieses eingefügt. :X
    Wenns net stimmt bitte net sauer sein !

    Das FastFlux-System wird bei Botnetzen eingesetzt, um Zombie-PCs als Vermittler zwischen dem Botnet und dem Masterserver zu nutzen. Meistens werden dafür Bots mit hoher Internetbadbreite und hoher Onlinezeit verwendet. Diese Bots tragen sich schnell abwechselnd für einen DNS-namen ein und aus, sodass der DNS-name ständig eine neue Zieladdresse hat. Das Ziel der Botnetzbetreiber ist es, ihre Identität zu schützen, um ohne gro�es Risiko Phishingseiten etc. zu betreiben.


    Frage #3 by DizzY_D
    [RE] Unpack this File
    - Skill
    2/10
    - Akzeptierte Lösung: Unpacked File ;)


    (Hab ne kleine Falle eingebaut ;))


    DL: http://rapidshare.com/files/251939023/notepad.exe


    Edit: Die Falle funktioniert so natürlich nicht (*Kopf gegen Wand hau*)
    Naja nächstes Mal ;)


    MfG

    Alan Layne;20359 schrieb:


    Apropos Heihachi, vielleicht bin ich auch nur ein bisschen paranoid, aber mir ist aufgefallen, dass ein user hier, den selben avatar wie er benutzt...bloÃ? Zufall oder steckt da doch mehr da hinter?


    Im Zweifelsfall stecken immer die Illuminaten dahinter. :ugly:
    Im Ernst: Der User von dem du sprichst ist auf keinen Fall Speedy. Wie blöd wäre er denn unter falschem Namen seinen Avatar von 1337 zu nehmen?

    LoadLibraryA und GetProcAddress sollten die Funktionen sein, die du brauchst.
    Du ermittelst den Pfad zur DLL und lädst dann die DLL mit Loadlibrary in den Prozessspeicher. Um die Adresse einer Funktion zu holen, rufst du GetProcAddress mit dem Modulhandle auf, das dir LoadLib geliefert hat ;)
    Danach halt einfach den Pointer aufrufen.

    Um "Runtime Support" zu gewährleisten, ist es momentan im Trend den Windows Loader zu emulieren. Das heißt, dass man praktisch die Arbeit, die der Windows Loader übernommen hätte, um die Datei zu starten, selbst übernimmt. Denn der Windows Loader ist nunmal dazu gedacht, PEs von der Festplatte zu starten und nicht aus dem Arbeitsspeicher.
    Meist nutzt man dazu eine zweite Applikation, in dessen Prozess man injeziert. CreateProcess wird also dazu benutzt, den "Victimprozess" zu erstellen und im weitern Verlauf der RunPE-Funktion, die Daten/PE Einstellungen so zu modifizieren, dass die zu injezierende exe in diesem Umfäld läuft.
    Hier ne kleine Liste, was der RunPE-Code macht:


    • Victimprozess im Suspended-Mode(damit der Prozess nicht startet) erstellen
    • Die Sectionpages "Unmappen"(um die in der zu injezierenden App vorhandenen Sections später an den richtigen Stellen schreiben zu können)
    • PE Header in den Prozess schreiben
    • Einzelnen Sections in den Prozess schreiben
    • Register anpassen
    • Prozess laufen lassen


    Ich hoffe das hat die Unklarheiten etwas behoben ;)

    Crypter bzw. auch andere "Low-Level"-Zugriffe in VB sind immer so ne sache. ;) Ich würd dir wirklich empfehlen, wenn dus wirklich verstehen willst und nich C&Pen willst, Delphi dafür zu lernen. Denn in VB muss man einige "Umwege" gehen, was aber nicht heißt, dass es nicht möglich ist. Wenn du VB lernst und ernsthaft programmierst wirst du früher oder später umsteigen müssen, was manchmal relativ nervig sein kann ;)

    mssl;19098 schrieb:

    interessant wären dann schon spezifischere themen


    Dafür braucht man dann aber keinen Live Stream sonden, wie bereits erwähnt, ist die Basis schon durch das Forumgegeben.
    Wenn jemand mehr über ein bestimmtes Thema erfahren will, kann sich jemand bereit erklären ein Tutorial zu machen. Dann postet er es hier und Fragen können dann direkt in den Thread gepostet werden.
    Zwar ne gute Idee, jedoch 1. schwer umsetzbar und 2. nicht notwendig.

    MrWellKnown;18649 schrieb:


    Richtig. Wenn die Abfrage früher oder später wieder in einem einfachen conditional jmp endet, lässt sich dass sehr einfach umgehen. Kenne auch einige Leute die einfach nen ExitProcess(0) nach der Abfrage des Antileaks benutzen (grö�te Protection einbauen aber dann per ExitProcess beenden^^) besser wäre es da einfach unbemerkt ein paar ASM-Register zu manipulieren und so einen Crash zu erzeugen. (was auf den 1. Blick aufjedenfall schwieriger zu entdecken ist..)


    =-0 Wenn du mal etwas geordneter schreiben würdest, hätte man auch mehr Lust es zu lesen.


    Wenn diese Leute die "grö�te Protection" einbauen, würde die Abfrage ja nicht in einem einfachen ExitProcess enden oder wo ist da die Logik ?
    Generell gilt es den eigendlichen Vergleich so gut wie möglich zu verbergen. Mit ASM-Register meinst du wohl die CPU-Register. Die Idee diese bei einem negativen Vergleich zu manipulieren und so eien Crash zu erzeugen, ist für den Anfang eher der falsche Ansatz.
    Es geht ja nicht darum das Beenden des Programms zu verbergen sondern den Vergleich, da der Reverser hier in den meisten Fällen Ansetzt.
    Zuerst sollte man z.B. lieber mehrere Abfragen einbauen, die den String Byte für Byte vergleichen ohne dabei nur einen Sprung zum Beenden des Programms zu verwenden. Man könnte die HWID auch so umwandeln, dass bei einer darauf volgenden Division ein "Division durch Null" Fehler auftritt und somit das Programm beendet wird.


    Das waren jetzt nur mal ein Paar kleine Beispiele aus tausenden von Möglichkeiten. Eigendlich wäre es das Beste, wenn jeder selber wüsste, wie die Reverser vorgehen, denn dann kann man die Schwachstellen seines Programms selber finden und wiederrum "Gegenmittel" einbauen.


    Etwas komplexere Schutzmechanismen werdet ihr in meinem Tut finden ;)

    Den Ultimativen Schutz gibt es sowieso net...
    HWID ist ja nicht der Schutz an sich sondern eher eine Methode sein Programm zu schützen. Wie sicher es ist liegt einzig und allein daran, wie man es implementiert.

    Wenn du mit PE anfangen willst solltest du dir zuerst volgende Fragen stellen:


    Habe ich überhaupt wirklich Interesse an der Materie?
    Ist mir klar, dass man sowas nicht von Heute auf Morgen kann?
    Besitze ich fortgeschrittene Programmierkentnisse in z.B. C++, Delphi ?
    Kann ich genug Zeit investieren?
    Bin ich bereit auch mal "das Rad neu zu erfinden" und nicht nur aus Bequemlichkeit fertigen Source zu verwenden?


    Wenn du auf alle Fragen JA Antworten kannst, kanns los gehen ;)
    Wenn nicht, lass es lieber.



    Unterm Strich ist das PE Format, wie ich finde, unerlässlich um tiefer in die Materie Windows einzudringen.

    Also aus Erfahrung kann ich sagen, dass die AVs da zimlich leicht auszutricksen sind. Vor Kurzem musste ich mich mit diesem "Problehm" auch auseinander setzten. Ich konnte es dann sehr schnell mit etwas Junk Code im Algo lösen.


    Beispiel:
    Original XOR Algo:

    Code
    1. 00404001 B8 88104000 MOV EAX, 00401088
    2. 00404006 8030 0F XOR BYTE PTR [EAX], 0F
    3. 00404009 40 INC EAX
    4. 0040400A 3D A41A4000 CMP EAX, 00401AA4
    5. 0040400F ^7E F5 JLE SHORT 00404006

    Wenn dieser Algo also direkt am EP liegt, erkennen es ein Paar AVs als "Crypted.Polymorph" oder so.
    Mein leicht veränderter aber trotzdem FUD Algo sieht so aus:


    JunkCode ist nichts anderes also Code, der im Endeffekt garnichts macht, aber die AVs erkennen so keine Signaturen mehr.


    Kurze Erklärung:
    1. Startadresse in EAX schreiben
    2. Eax Register mit dem Ecx Register austauschen
    3. Ecx + 10
    4. Ecx + 8
    5. Ecx -18
    6. Register wieder zurücktauschen


    Also ein Code der nur sinnlose Operationen macht um die AVs zu verwirren.
    Anstatt Inc EAX habe ich einfach erst eax um 6 addiert und dann wieder 5 abgezogen. Im Grunde macht dieser Code also auch hier das gleiche wie beim original Algo, nur mit anderen Befehlen.
    Der Rest des Algos ist gleich geblieben.
    Also keine kompexe Sache.


    Wenn ihr Manual Packing wirklich verstehen wollt bleibt euch nichts Anderes übrig als euch mit dem PE Format auseinander zu setzen.
    Dann könnt ihr auch mit den Begriffen Sections und Characteristics was anfangen.

    Man muss sich keine Passende Section suchen, man kann sie genau so gut passend machen. Die Section Characteristics anzupassen sollte ja kein Problehm sein.
    Um den XOR Also zu verschleihern reicht es meiner Meinung nach ihn mit Junk Code zu vermischen und Befehle umzuformen. Ich weiss jedoch net ob die AVs inzwischen so clever sind und das dann zur Runtime erkennen.
    Wenn du keine CodeCave findest oder sie zu klein ist, gibt es immernoch die Möglichkeit eine neue Section hinzu zu fügen.

    Kann viele Ursachachen haben.
    Installier am besten mal den Kompiler auf der VM und starte den Source im debug Modus dann siehst du wo der Fehler entsteht. Oder aber du kannst mit Olly umgehen und debugst damit :)