Es folgt der versprochene Beitrag zur Crypto-Analyse eines Usernet Account-Checkers. Dieser erlaubt es, den Account-Status per BB-Code in andere Seiten grafisch einzubinden. Klingt eigentlich nach einer netten Sache… Wenn dabei nur nicht die Account-Daten übergeben werden! Denn das PHP-Skript, welches das Bild erzeugt nimmt Usenet Username und Passwort als GET-Parameter entgegen. Um zu verhindern, dass die Accountdaten ausgelesen werden, wird der Accountname verschlüsselt.

Ein solcher Include-Link sieht folgendermaßen aus:

usenext-check/image.php?a=vLjWqt+jvNGWm9S54bU==&p=dGVzdA==

Mit dem scharfen Kryptoanalyse-Blick stellt man fest, dass a (der Accountname) und p (das Passwort) Base64 encodiert sind. Während das Passwort einfach ASCII-Encoded ist, bekommt man beim Decoden von Parameter a zunächst Probleme. Denn es hängt ein Gleichheitszeichen zu viel hinten dran! Wenn man dieses überflüssige Zeichen entfernt lassen sich die Daten zwar encodieren, aber es handelt sich nicht um einen ASCII-String. Anscheinend ist der Accountname verschlüsselt.

Nun haben wir den großen Vorteil zu einem Accountnamen den Chiptertext generieren können. Also haben wir eine Known-Plaintext-Attack und kommen mit etwas Glück auf den Key. Füttern wir den Account-Checker mit ein paar Werten und schauen uns das Resultat an. Vielleicht stellen wir ja Gesetzmäsigkeiten fest…

Weiterlesen

9 people like this post.

Like

Unlike

Heute geht es mal wieder um Malware, genauer gesagt um das Android Remote-Administration-Tool DroidJack. Für dieses überteuerte Tool wird es zwar keinen Leak geben, aber dafür ein paar Infos über den Crackschutz. Getreu nach dem Motto: “Guter Ansatz, schlechte Implementierung”.

DroidJack wirft dem Benutzer beim Öffnen des Programms einen Login-Bildschrim entgegen. Durch sniffen wird schnell klar, dass die Logindaten mitsamt Hardware-ID an die Access/DJ4.php des Servers geschickt wird. Ein Punkt gibts bereits Abzug, es wird kein HTTPS verwendet

Java-Programme lassen sich, ähnlich wie .NET, einfach analysieren. Zumindest solange der Java-Zwischencode nicht verunstaltet wurde, denn in dem Fall versagen die gängigen Decompiler. Die meisten dieser Codeverunstalter-Tools (Obfuscatoren) ändern die Typenbezeichner, Klassennamen, Methoden und alles sonst, was Informationen enthalten könnte. Der hier verwendete Obfuscator schaffte es aber zugleich, Fehler beim Decompilen zu erzeugen. Somit musste ich mich mit dem Java-VM-Bytecode arbeiten, der ähnlich wie MSIL aufgebau ist. Da mir das zu blöd war, schaute ich mir erstmal die DJ4.php Datei an.

Weiterlesen

5 people like this post.

Like

Unlike

Heute geht es um präzise tickende Maschienen und ein Projekt, das nun doch ziemlich komplex geworden ist. Ein Stämme Bot!

Doch zunächst etwas in eigener Sache: Vielleicht bist Du hier, weil Du mehr oder weniger freiwillig von Keller-Elite auf diese Seite weitergeleitet wurdest. Hoschi111 war so nett, nach der Schließung von Keller-Elite die User hier her zu leiten. Ist eine große Ehre für mich und ich hoffe es gibt hier den ein oder anderen Artikel der Dich interessiert.

Ich weis nicht, ob Du schon Erfahrung im Browsergame “Die Stämme” gemacht hast. Wenn nein, hier eine kurze Einführung: Um ein anderes Dorf zu erobern (im Stämmejargon auch “adeln”) muss man zwischen 3 und 5 erfolgreiche Angriffe mit einem Adelsgeschlecht auf das Dorf führen. Jedes Adelsgeschlecht (kurz AG) senkt die Zustimmung der Bevölkerung um 20-35 Prozent. Nach und nach sind die Dorfbewohner gewillt zum Angreifer überzulaufen. Dies möchte der Verteidiger natürlich verhindern und schickt allerei Defensive Einheiten in den Kampf um das Dorf zu verteidigen. Manchmal ist die Übermacht aber so groß, dass die eigene Verteidigung nicht standhält. Und dann tritt Plan B in der Kraft: Das “raustimen”. Da die große Offensive vor den AGs angreifen muss, um das Dorf von jeglicher Verteidigung zu befreien, laufen verschiedene Angriffswellen auf ein Dorf. Zumeist sind das ein bis zwei große Offensiven und direkt dahinter die AGs. Die AGs greifen meist mit nur geringem “Begleitschutz” an, denn eigentlich ist das Dorf ja leer. Und meist werden alle verfügbaren Einheiten bei der großen Offensive gebraucht.

Der Clou ist nun das “Timen” dieser Angriffe. Man möchte dem Verteidiger möglichst wenig Chancen geben, zwischen den beiden Angriffswellen (Offensive und AGs) Unterstützung im Dorf zu plazieren. Also folgen die Angriffe im Optimalfall wenige Zehntelsekunden aufeinander. Da man 4 Angriffe für die AGs möglichst Zeitnahe aufeinander losschicken muss, wird die Sache spannend. Es gibt extra Tools im Internet zum üben des “Timens” dieser Angriffe. Doch in was in der Computer uns weit vorraus? Richtig, Timing!

Aus einem Tool, das lediglich Planngszwecke erfüllen sollte, ist so ein mehr oder weniger komplexer Bot geworden. Ein paar Bilder sagen wie immer mehr als Worte:

Weiterlesen

8 people like this post.

Like

Unlike

Form Grabbing in Firefox. Das ist nichts neues und es gibt zuhauf Beispiele mit dokumentierem Sourcecode. Warum also ein Artikel drüber verfassen? Ein guter Bekannter zeige mir ein Video von einem Form-Grabber in Firefox und fragte mich wie das geht. Ich hatte mich nie damit beschäftigt und nur ein paar Ansätze im Kopf, doch das interesse war geweckt. Wie schaffen es Bots, Daten aus Website-Formularen so gezielt auszulesen?

In dem folgenden Artikel wird ein Proof of Concept von einem Form-Grabber mit injecteter DLL erstellt. Das besondere im Vergleich zu den 100 anderen Proof of Concepts ist hierbei, dass die injectete DLL Managed ist und somit erst ein CLRHost für das Ausführen von .NET Code reingeladen werden muss. Das Konzept sollte aus den vorherigen Artikeln wie diesem und diesem bekannt sein.

Fangen wir mit etwas Theorie an: Es gibt zwei Wege Daten aus Webformularen auszulesen. Diese Formulare sind intern auch nur Textfelder, die man markieren und kopieren kann wie man es aus Windows gewohnt ist. Das heißt im Umkehrschluss auch, dass diese Felder ein Handle und eine Windows-Klasse besitzen müssen. Mit diesem Handle können wir von externen Programmen Firefox dazu auffordern, uns den Textinhalt dieses Handles zurückzugeben. Der große Nachteil ist, dass man sich erstmal zu diesem Handle “Vorzuhangeln” muss. Hier muss man über mehrere UI Elemente und Knoten mit Unterknoten laufen, bis man am gewünschten Ziel angekommen ist. Sehr elegant ist das nicht und für jede Seite müsste dieser Pfad eingeprogrammiert werden! Wer weiteres über diesen Ansatz lesen möchte, dem sei die WM_GETTEXT Message und dieser Stackoverflowpost ans Herz gelegt. Eleganter, und vor allem universal für jede Seite ist das Abfangen von der GET/POST Request bevor diese über SSL unkenntlich gemacht wird. Und genau dieser Ansatz ist verblüffend einfach und zielführend!

Die später geschriebene DLL hängt sich an die sog. PR_Write Funktion der nss3.dll von Firefox. Diese wird verwendet, um Streams jeder Art zu beschreiben. Sei es ein Filestream welcher auf die Festplatte schreibt, oder ein Netstream welcher an eine TCP Verbindung gerichtet ist. Wie unschwer zu erkennen ist, nimmt diese Funktion drei Parameter entgegen. Der erste ist das Stream-Handle, was nicht weiter besprochen wird. Das zweite Argument enthält einen Zeiger auf einen Buffer (Zwischenspeicher), in welchem sich die zu schreibenden Daten befinden. Das dritte Argument gibt schließlich an, wieviele Daten aus dem Zwischenspeicher in den Stream geschrieben werden sollen.

Setzt man mit OllyDBG einen Breakpoint an der PR_Write Funktion, so lassen sich alle drei Argumente schön im Stack anschauen. Das deutet daraufhin, dass es sich bei der PR_Write Funktion um eine cdecl-Calling-Convention handelt. Die später für uns wichtige Calling Convention gibt an, wie die Parameter der Funktion übergeben werden. Dabei gibt es viel Möglichkeiten: Parameter können sich in Registern befinden oder auch der Reihe nach auf den Stack geladen werden. Letzeres ist wohl hier der Fall.

Schön zu sehen sind die 3 Stackargumente in umgekehrter Reinfolge. Die Return-Adresse befinder sich ganz Oben auf dem Stack, danach folgt der Zeiger auf den Stream und der Zeiger auf den Buffer. Als drittes Argument kann man die Länge des Buffers, in diesem Fall 0×221 Bytes sehen. Links im Stack Window ist die Buffer-Adresse geöffnet. Hier sieht man klar die POST Request die gesendet wird, mit allen GET und POST Parametern. (GetParam=NotSoSecret, PostParam=VeryS3cret).

Weiterlesen

11 people like this post.

Like

Unlike

Annährend 3 Monate ist es her, dass ich mich an einem Keygen Me versucht habe. Ziel war es ein “Algorithmus” zu entwickeln, den man nicht durch simples Rückrechnen der Rechenoperationen brechen kann. Blogpartner tr4ceflow hat einen Artikel dazu gewidmet, der schon gute Ansätze beinhaltet. In der Zukunft werden Keygen Mes mit einem nicht so überladenen Compiler wie Visual Studio kompiliert, da viel zu viel verwirrender Mist reinkommt. Das habe ich auch dadurch gelernt

Alle 3-4 Tage werden hier neue Lösungshinweise erscheinen. Wieviele es insgesammt werden weiß ich nocht nicht.

13.09.2014:

Alle Infos von tr4ceflows Blogpost zusammengefasst: Per GetDlgItem und GetWindowTextA wird der Text aus den Textboxen Name, Serial1 und Serial2 ausgelesen. Diese werden an eine Funktion, die den eigentlichen Keycheck vornimmt übergeben (0x1E1C60). Nun muss gelten: usernameLength - 1 == strlen(key1)/4). Der Key wird nun in 4er Blöcke zerlegt und in shorts (2 byte) gespeichert. Aus 01234567 wird 0×0123 und 0×4567 . Dieses wird zu einem Float umgewandelt (0×0123 = 291d => 291.0f) und im Anschluss durch 100 geteilt. Nun wird gerechnet, und zwar mit Floats. Es werden nun alle Buchstaben durchlaufen. Dabei wird jeweils die Summe aus einer “Rechnung” gebildet und diese vom aktuellen Buchstaben abgezogen. Nun wird vergleichen, ob die Differenz in einem “Bereich” liegt, der durch die e-Funktion mit einem statischen Exponenten aus einem Array begrenzt wird. Wenn die Differenz kleiner als die expotentierte Zahl ist, so wird die Schleife Fortgesetzt. Wenn nein, so wird aus der Funktion rausgesprungen und der Key ist nicht gültig.

Ich möchte nochmal einen kleinen zusätzlichen Tipp geben: tr4ceflow hat eine Rechung aufgestellt, wie die Sache im ersten, zweiten und dritten Durchgang aussieht.

- berechne    - hex(e) / 100.0
              - hex(f) / 100.0
              - hex(g) / 100.0
- berechne die Summe 
	1. Durchgang :  hex(e) / 100.0 + hex(f) / 100.0 + hex(g) / 100.0
	2. Durchgang :  4*hex(e) / 100.0 + 2*hex(f) / 100.0 + hex(g) / 100.0
	3. Durchgang :  9*hex(e) / 100.0 + 3*hex(f) / 100.0 + hex(g) / 100.0
- hole einzelnen Buchstaben "a" aus Namen und berechne die Differenz

Schaut euch dabei mal die Vorfakoren der hex(e/f/g) an. Beim ersten Durchlauf ist dieser stets 1, beim zweiten durchlauf ist er 1,2,4, …, beim dritten Durchlauf 1,3,9,… . Kommen euch diese Folgen bekannt vor? Wenn ja, wo finden sie Anwendung? Vorallem im Zusammenhang mit einer Addition ! Dieser (relativ) große Tipp hilft hoffentlich, auf die richtige Spur zu kommen. Denn tra4ceflow hat bereits alle vorarbeit geleistet, jetzt gilt es nur noch 1+1 zusammenzuzählen.

16.09.2014:

Entspricht dem Polynom: f(x) = -0.054166*x^6 + 1.02083*x^5 -6.3125*x^4 + 10.0625*x^3 + 32.866*x^2 -106.583*x^1 + 138

Entspricht auch dem Usernamen: EASYSURF

Schaut euch mal den Y-Wert des Polynoms an den ganzen Zahlen an, also: f(1), f(2), … Vergleicht es mit EASYSURF!

18.09.2014:

Mit den obigen Zeilen ist der Hauptteil des Keygens, nämlich Key1 bereits errechnet. Das sind also einfach die Koeffizienten des Polynoms was den Usernamen bzw die ASCII Characters des Usernamens abzüglich dem letzten Buchstaben annährt. Hier der Beispielkey für EASYSURF.

Key1: fffb0066fd8903ee0cd6d65e35e7

Doch was ist mit Key 2? Dort wird ebenfalls ein Polynom verwendet. Doch welchen Wert muss es haben? Es ist ganz ähnlich. Doch das hebe ich mir für den nächsten und finalen Tipp auf

22.09.2014:

Abschliesend gibt es die volle Auflösung und auch den Sourcecode zum Keygen. Fangen wir mit dem zweiten Key an. Auch hierbei handelt es sich um encodierte Koeffizienten des Polynoms des “strlen(username) - 1″-Grades. Allerdings geht es hier auch noch um Grenzwertberechnung. Der Grenzwert Polynom2/Polynom1 gegen Unendlich muss gegen den letzten Buchstaben/10 gehen. Dabei ist bekanntlich nur größte Exponent entscheidend, welcher im Nenner, als auch im Zähler ausgeklammert wird. Beim oben genannten Key ist der größte Exponent 0xfffb, was nach umrechnen -0,0541 ergibt. Der Grenzwert, also der letzte Buchstabe, muss F = 70d sein. Die Gleichung umzustellen müsste jeder hinbekommen: x/-0,0541=7.0 => x = -0,0541*7.0 = -0.3787. Encodieren wir das wieder in unsere Short-Schreibweise, so erhalten wir: ffdb. Da die restlichen Exponenten egal sind, können wir da einfach die restlichen Koeffizenten von Key1 ranhängen. Damit erhalten wir als gültige Keykombination:
Key1 = fffb0066fd8903ee0cd6d65e35e7
Key2 = ffdb0066fd8903ee0cd6d65e35e7

Weiterlesen

3 people like this post.

Like

Unlike