Reverse engineering Perl-kompatible regulære uttrykk

Thomas Chopitea

2014-05-09 22:24:10 UTC

view on stackexchange narkive permalink

Jeg har med et skadelig programvare å gjøre som bruker omfattende PCRE (Perl-kompatible regulære uttrykk). Normalt kunne jeg lese dem, men det ser ut til at de er i et slags binært format (kompilert, kanskje?). De starter alle med ERCP (sjekk hexdumpen nedenfor); FWIW, jeg mistenker sterkt at språket som genererte denne koden var C ++.

  00000150 00 00 00 00 11 00 5e 00 00 00 00 00 00 00 45 52 | ...... ^ ....... ER | 00000160 43 50 56 00 00 00 00 00 80 00 04 00 00 00 01 00 | CPV ............. | 00000170 00 00 00 00 74 00 28 00 00 00 00 00 00 00 00 00 | .... t. (......... | 00000180 00 00 00 00 00 00 5e 00 2a 5f 00 06 00 01 1a 54 | ..... . ^. * _..... T | 00000190 00 05 1c 2e 55 00 0b 1c 61 1c 61 1c 61 1c 61 1c | .... U ... aaaa | 000001a0 61 1c 61 1c 61 1c 61 1c 2e 1c 6e 1c 65 1c 74 1b | aaaa..net | 000001b0 55 00 2a 00 00 00 00 00 8d ff a5 95 0a 2d 2d 2d | U. * ..........--- |  kode>

I dette eksemplet ser det ut til at regex samsvarer med en streng knyttet til et internettdomene, aaaaaaa.net.

Mitt spørsmål er: gitt en binær blob som dette, er det mulig å gå tilbake til en "menneskelig lesbar" (dekompilert?) PCRE? ( ie ^ aaaaaa \ .net $ ) Hvis ja, hvordan skal jeg gjøre det?

/ * Magisk nummer for å gi en liten sjekk mot å bli utlevert skrot. Brukes også til å oppdage om et mønster ble samlet på en rekke forskjellige endianness. * / # define MAGIC_NUMBER 0x50435245UL / * 'PCRE' * / < ... snip ... > / * Det virkelige formatet for starten av pcre-blokken; indeksen over navn og kodevektoren kjøres så lenge som nødvendig etter slutten. Vi lagrer en eksplisitt forskyvning i navnetabellen, slik at hvis en regex blir samlet på en vert, lagret og deretter kjørt på en annen der størrelsen på pekere er forskjellig, kan alt fortsatt være bra. Når det gjelder kompilert-på-4 og kjør-på-8, inkluderer vi en ekstrapointer som alltid er NULL. For fremtidssikring var noen få dummyfelt opprinnelig inkludert - selv om du aldri kan få denne planleggingen riktig - men det er bare ett igjen nå. gjøres på slutten, og noe tidligere (f.eks. et nytt flagg i alternativene eller et av dummyfeltene) skulle indikere at nyfeltene er til stede. For øyeblikket setter PCRE alltid dummyfeltene til null. MERKNAD MERKNAD: * / typedef struct real_pcre {pcre_uint32 magic_number; pcre_uint32 størrelse; / * Totalt som ble malloced * / pcre_uint32 alternativer; pcre_uint32 dummy1; / * For fremtidig bruk, kanskje * / pcre_uint16 top_bracket; pcre_uint16 top_backref; pcre_uint16 førstebyte; pcre_uint16 req_byte; pcre_uint16 navn_tabelloffset; / * Offset til navnetabellen som følger * / pcre_uint16 name_entry_size; / * Størrelse på eventuelle navneelementer * / pcre_uint16 name_count; / * Antall navnelementer * / pcre_uint16 ref_count; / * Referansetall * / const usignerte tegn * tabeller; / * Peker til tabeller eller NULL for std * / const usignert røye * nullpad; / * NULL padding * /} real_pcre;

dd 'PCRE'; magisk_nummer dd 56h; størrelse dd 800000h; opsjoner dd 4; dummy1 dw 1; toppbrakett dw 0; top_backref dw 0; first_byte dw 74h; req_byte dw 28h; navn_tabelloffset dw 0; navn_innføringsstørrelse dw 0; navn_telling dw 0; ref_count dd 0; tabeller dd 0; nullpad