Wie bereits in dem News-Post angekündigt habe ich mich an einem Keygen-Me versucht. Ziel dabei war es ein Keygen-Me zu erstellen, welches nicht durch stumpes Rückrechnen zu knacken ist, sondern vielmehr Verständnis für den Algorithmus erfordert. Die Idee zu diesem Keygen-Me ist in einer Mathevorlesung entstanden, aber das sollte euch nicht abschrecken, die hier verwendete Mathematik sollte jederman bekannt sein.

Die Schwierigkeit dieser Herrausforderung ist schwer einzuschätzen, aber ich behaupte das jeder fortgeschrittene Reverser der genug Zeit hat diese Challange schafft.

Zum Abschluss noch wichtige Informationen: Da es gewollt zu einem Präzisionsverlust des Keys kommt, findet man bei längeren Usernamen weniger Keys. Hier eine Tabelle für, an der ihr Euch orientieren könnt, entstanden aus 1000 random Keys:

LENGTH | VALID RATIO
4       | 100%
5       | 100%
6       | ~93%
7       | ~20%
8       | ~8%
9       | ~5%
10      | ~1.7%

Screenshot: (wer sich über die hässlige GUI beschwert sollte mir lieber danken, dass ich die Save/Restore Values Buttons eingebaut habe )

Download: KeygenMe 1 (304)

Viel Erfolg!

P.S. Inzwischen ist ein Writeup erschienen

8 people like this post.

Like

Unlike

Kommunizieren kann Apex also auch noch! Nur leider noch nicht so ganz mit dem Reverser. Denn in diesem Post geht es um das Netzwerkprotokoll und natürlich wie Apex da mit drin hängt. Es werden aber auch die Apex-Module angeschnitten, die bereits in den letzen Posts Erwähnung fanden.

Ein direkter Mitschnitt von Netzwerktraffic ist schwer möglich, da auf jedes Packet auf eine ganz abscheuliche (und ziemlich schwer nachzuvollziehende) weiße von XOR und Bitshifting-Operationen gequält wird. Daher muss auf andere Wege zurückgegriffen werden, um das Netzwerkprotokoll zu durchschauen. In der CShell-Module finden sich eine Menge netter Strings, wie z.B:

CS_CH_GETUSERID_REQ

Die XRefs von IDA Pro führen auf eine Funktion, in der dieser String verwendet wird. Der interessante Teil beschränkt sich zunächst auf folgende Zeilen:

.text:0069D723                 call    memcpy
.text:0069D728                 mov     ecx, someGlobalManager
.text:0069D72E                 add     [ebp+var_C], esi
.text:0069D731                 add     dword_15BEF24, ebx
.text:0069D737                 mov     eax, [ecx]
.text:0069D739                 mov     eax, [eax+2D8h]
.text:0069D73F                 add     esp, 0Ch
.text:0069D742                 lea     edx, [ebp+Dst]
.text:0069D748                 push    edx
.text:0069D749                 call    eax
.text:0069D74B                 mov     eax, GlobalILTClient
.text:0069D750                 add     dword_15BEF24, ebx
.text:0069D756                 mov     ecx, [eax]
.text:0069D758                 mov     edx, [ecx+18h]
.text:0069D75B                 push    offset aCs_ch_getuseri ; "CS_CH_GETUSERID_REQ"
.text:0069D760                 push    eax             ; Args
.text:0069D761                 call    edx

Wie unschwer zu erkennen ist, wird ein statischer Zeiger geladen und dessen Pointer in EAX gespeichert. Dort wird im Anschluss die Adresse einer virtuellen Funktion geladen (ECX + 2D8h) und diese mit einem Argument in EDX aufgerufen. Wie sich später herrausstellt ist in EDX das eigentliche Packet gespeichert. Im Anschluss wird nochmals eine virtuelle Funktion geladen und aufgerufen, dieses mal allerdings zu Logzwecken. Wie können wir uns das zu nutze machen? Wir hooken beide Funktionen und loggen so alle Packete die Packetnamen in ein Logfile. Und das alles, bevor irgendetwas verschlüsselt wird .

Weiterlesen

4 people like this post.

Like

Unlike