Bestandsencryptie reverse engineeren

[Douweegbertje]

Ik heb een aantal bestanden die geëncrypt zijn. Daarbij heb ik ook al de daadwerkelijke bestanden die nu gedecrypt zijn. In feite wil ik weten hoe je dit moet decrypten. Ik heb al eigenlijk geen idee waar ik precies kan beginnen. Behalve dat ik een grote dataset heb (en veel tijd om handen ) heb ik nog niet veel informatie.

De geëncrypte bestanden zijn identiek qua grootte als de uiteindelijk gedecrypte. De inhoud van de bestanden ziet er uit als

code:

Z&#8222;Õ:€O.ËZDY+ñL&#8212;¸«YIyWÇöuB&#710;ÒÐûá\&#8482;Ÿùõ>Û+i6ç¹·&#8221;§ú®&ýb¤²  R;bìÄ>¹%XA&#8250;¯uÑX¸"®ŸÍo|  l06/ÚÛw`7îJ<K_ø+Ÿm&#8222; &#402;Ÿ&#8216;À*a·l;Ö ³²×®¨#Í&#8249;ëi&#8212;Î8W¹°w-ïqÜ:Þ&#8250;&#8482;tR×|øy³DÀ5,&#8212;×¼Óîh?cfæ¸b&#8250;&#8216;ō~¶YŜjJûþð7|`Tù[ßOT¶i<§7Æ¿&#8211;N-A¿ÈIÇ&#8240;l^ùâ
Èóª8ë>¤_U8u¯zÃfnS   È]j"e

En die van de gedecrypte als

code:

65ea 451d b0fa ac86 8af0 436e fd24 451b
b0bb bd24 a1e1 5b75 fdeb 772e b492 87ab
dd60 8e3a f6ab 76bd 97e9 37ab 715e 35f5
757d a577 d2f6 def5 6c35 aaaf eddf 096d
512e 770f e97e 107b 774d 54d4 37d0 7ff5

_{FYI, dit is een klein stukje van een file}

De bestanden zelf hebben nog geen extensie.

Nu weet ik wel het één en ander van encryptie e.d. als het wat meer om strings gaat, maar puur bestanden.. nee dat wat minder.
Sterker nog heb ik geen idee waar ik zou moeten beginnen, dus als iemand wat pointers heeft waar ik het beste naar kan kijken dan kan ik weer verder met mn zoektocht

_{En ja, ik ben volledige eigenaar van alle bestanden.. puur alleen de decrypte methode is onbekend..}

[Gerco]

Hoe zijn die bestanden geencrypt? Heb je dat zelf gedaan en ben je de sleutel kwijt? Is het een test van iemand anders of is het door malware gedaan? Als de encryptie goed is (een bekend, standaard algoritme) is er helemaal niets wat je kan doen. Het bezitten van decrypted bestanden zal je niet helpen. Als het malware was heb je pech, die encryptie is over het algemeen goed gedaan en je hebt de key niet.

Als het een home grown encryptie is (variant op simpele xor met vaste key of zo) kun je verschillende keys uitproberen met diverse lengtes om te zien of het ergens op gaat lijken. Momenteel is dit topic veel te vaag om iets zinvols te zeggen.

[ Voor 23% gewijzigd door Gerco op 14-07-2015 16:36 ]

[Douweegbertje]

Jij vindt het vaag, maar dat komt omdat ik op een ander niveau zit en juist hier wat dieper op in wil gaan. Ik vraag ook niet om een kant en klaar antwoord maar:

als iemand wat pointers heeft waar ik het beste naar kan kijken dan kan ik weer verder met mn zoektocht

Maar om nog wat antwoorden te geven op je vragen:

Het is geencrypt door 3e partij als zijnde hun file (storage) system. Hoe/wat/ etc is onbekend. Het programma om het te decrypten heb ik wel maar dat gaat enorm ruk (lees: traag). Daarom wilde ik graag kijken of ik een eigen implementatie kan maken.

Men wilt echter geen informatie geven dan "het is een eigen encryptie in ons programma", dus achter de manier van encrypten ga ik niet via hun achter komen.

[orf]

Douweegbertje schreef op dinsdag 14 juli 2015 @ 17:00:
Het programma om het te decrypten heb ik wel maar dat gaat enorm ruk (lees: traag). Daarom wilde ik graag kijken of ik een eigen implementatie kan maken.

Men wilt echter geen informatie geven dan "het is een eigen encryptie in ons programma", dus achter de manier van encrypten ga ik niet via hun achter komen.

Kun je niet beter proberen om dat programma te decompilen?

[Soultaker]

Douweegbertje schreef op dinsdag 14 juli 2015 @ 17:00:
Het is geencrypt door 3e partij als zijnde hun file (storage) system. Hoe/wat/ etc is onbekend. Het programma om het te decrypten heb ik wel maar dat gaat enorm ruk (lees: traag). Daarom wilde ik graag kijken of ik een eigen implementatie kan maken.

Dan zou ik beginnen met hun implementatie te reverse-engineeren. Aan de invoer/gegenereerde uitvoer kun je praktisch niets afleiden.

[NMe]

Douweegbertje schreef op dinsdag 14 juli 2015 @ 17:00:
Het is geencrypt door 3e partij als zijnde hun file (storage) system. Hoe/wat/ etc is onbekend. Het programma om het te decrypten heb ik wel maar dat gaat enorm ruk (lees: traag). Daarom wilde ik graag kijken of ik een eigen implementatie kan maken.

Men wilt echter geen informatie geven dan "het is een eigen encryptie in ons programma", dus achter de manier van encrypten ga ik niet via hun achter komen.

Ehm...je realiseert je dat de traagheid van encryptie/decryptie juist bijdraagt aan hoe veilig die encryptie is? De kans is vrij groot dat het algoritme juist bewust zo traag is gemaakt en dat je het dus niet substantieel sneller gaat kunnen maken ongeacht hoeveel tijd je erin stopt. En stiekem moet je dat ook niet willen.

[Will_M]

Als de encryptie extern gedaan is dan is het niet onwaarschijnlijk dat de encryptiesleutel "random" gebaseerd is op een mix van factoren welke alleen dáár bekend/aanwezig is. Soort van "Bitlocker" op leveranciers niveau.

[Douweegbertje]

NMe schreef op dinsdag 14 juli 2015 @ 17:08:
[...]

Ehm...je realiseert je dat de traagheid van encryptie/decryptie juist bijdraagt aan hoe veilig die encryptie is? De kans is vrij groot dat het algoritme juist bewust zo traag is gemaakt en dat je het dus niet substantieel sneller gaat kunnen maken ongeacht hoeveel tijd je erin stopt. En stiekem moet je dat ook niet willen.

Sorry, nog een deel vergeten te zeggen dat er wel wat meer gebeurt dan alleen het decrypten.

Qua programmatuur is het ook gewoon 'crap'. Kan niet zoveel details geven, maar ik weet eigenlijk wel met 99% zekerheid dat het qua encryptie niet zo super deluxe in elkaar zit

wimmel_1 schreef op dinsdag 14 juli 2015 @ 17:10:
Als de encryptie extern gedaan is dan is het niet onwaarschijnlijk dat de encryptiesleutel "random" gebaseerd is op een mix van factoren welke alleen dáár bekend/aanwezig is. Soort van "Bitlocker" op leveranciers niveau.

Lijkt me sterk, als ik het zelf ook kan decrypten.

[ Voor 21% gewijzigd door Douweegbertje op 14-07-2015 17:19 ]

[Douweegbertje]

orf schreef op dinsdag 14 juli 2015 @ 17:03:
[...]


Kun je niet beter proberen om dat programma te decompilen?

Ja dat zal dan wellicht ooit nog een hobby projectje worden
Ik hoop gewoon dat ik iets kan vinden van een wat zwakkere encryptie methode zodat ik 'klaar' ben. Mocht het echt goed in elkaar zitten dan ben ik gewoon de sjaak

[_js_]

Als het heel simpel is, dan is het een xor key. Die is simpel te herleiden.
Bestand en string versleutelen is exact hetzelfde.
Bestanden blijven dezelfde grootte, hieruit kun je misschien de blocksize van de encryptie afleiden.
Je hoeft niet de hele executable te reversen, je kunt zoeken op bekende gegevens, zoals s-box waardes voor verschillende algoritmes. Daar zijn ook tools voor.

Debuggen/reversen lijkt me verreweg het makkelijkst.

p.s. Waarom post je encrypted data in een heel ander formaat dan de decrypted data?

[Will_M]

Kun je je bestanden ook decrypten op een machine welke volledig van een/het netwerk geïsoleerd is en/of nog nooit aan het netwerk gehangen heeft?

Als dat in beide gevallen het geval is dan moet je er, theoretisch gezien, uit kunnen komen met het de-compilen van de software en eventueel wat geheugendumps.

[ Voor 54% gewijzigd door Will_M op 14-07-2015 17:55 ]

[Douweegbertje]

_js_ schreef op dinsdag 14 juli 2015 @ 17:40:

p.s. Waarom post je encrypted data in een heel ander formaat dan de decrypted data?

Dat is het verschil tussen een ecrypted en decrypted bestand

wimmel_1 schreef op dinsdag 14 juli 2015 @ 17:46:
Kun je je bestanden ook decrypten op een machine welke volledig van een/het netwerk geïsoleerd is en/of nog nooit aan het netwerk gehangen heeft?

Geen idee. Als je hiermee bedoeld dat iets van het internet als entropie wordt gebruikt tenminste dan?

Gewoon in het kort. Ik heb een bestand. Geen extensie en wordt gezien als 'data'. Deze gaat door een programmatie, en wordt een bestand (nog geen extensie). Even hernoemen met de juiste extensie (vaak tif) en je kunt hem openen. Domweg het 'encrypted' bestand hernoemen met de extensie tif gaat dus niet werken.

[orf]

Douweegbertje schreef op dinsdag 14 juli 2015 @ 17:55:
[...]

Geen idee. Als je hiermee bedoeld dat iets van het internet als entropie wordt gebruikt tenminste dan?

Dat gaat er natuurlijk over of de key via internet opgehaald wordt (misschien zelfs per bestand) of dat de key lokaal in het programma aanwezig is.

[Douweegbertje]

Ah
Nee, dat kan ik wel met zekerheid zeggen dat dat niet het geval is.

[doskabouter]

Kan je zelf ook bestanden encrpypten?
Dan zou je misschien wat dingen kunnen afleiden, als je bv een bestand met 16 0-en of zo daar doorheen haalt

[Douweegbertje]

Nope. Helaas.

[Soultaker]

Douweegbertje schreef op dinsdag 14 juli 2015 @ 17:55:
Dat is het verschil tussen een ecrypted en decrypted bestand

Uhm, wil je beweren dat de ontcijferde variant een tekstbestand is met hexadecimale cijfers erin? In dat geval is het geen TIF bestand.

Het lijkt me sowieso handig om encrypted data hexadecimaal weer te geven, anders gaat er geheid informatie verloren bij het posten.

[Douweegbertje]

Soultaker schreef op dinsdag 14 juli 2015 @ 20:45:
[...]

Uhm, wil je beweren dat de ontcijferde variant een tekstbestand is met hexadecimale cijfers erin? In dat geval is het geen TIF bestand.

Het lijkt me sowieso handig on encrypted data hexadecimaal weer te geven, anders gaat er geheid informatie verloren bij het posten.

Ik zal morgen eens kijken wat voor bestand het is, 9 van de 10x is het tif.. wellicht toevallig dat het dit keer iets anders is..

[ Voor 8% gewijzigd door Douweegbertje op 14-07-2015 20:49 ]

[farlane]

Kijk in de input en de output naar patronen : ik zie in je input bijv &#8222 en verder &#8212 en er zijn er nog meer. Kun je dat matchen met iets in de output, iets dat een vergelijkbaar patroon heeft?

[nst6ldr]

Theorie en praktijk liggen hier niet ver uit elkaar, maar de hoeveelheid werk, tijd en CPU cycles die hier bij komt kijken is best groot. Mocht dat je niet afschrikken dan kan je de volgende dingen in het kader van bruteforcen proberen:

• CCA -
  Het komt er op neer dat je een geautomatiseerde procedure maakt die verschillende datasets aanbied aan het decrypt algoritme, en hier net zo lang mee doorgaat totdat er een (deels) leesbare output uit komt. De uitkomst daarvan kan je een hoop vertellen over het algoritme. Stel je voor dat er een header of zelfs meerdere headers zichtbaar worden. Misschien zie je op een grotere schaal wel een patroon verschijnen en kan je zo zien hoe groot alle blocks zijn. Met die gegevens alleen al kan je de tijd die het kost om een aanval uit te voeren drastisch verkleinen. Je hebt echt analytisch vermogen nodig en met grote sets durven werken om hier iets mee te kunnen.
• CPA -
  Indien je een kleine attack vector heb, kan je a lá rainbow table een procedure loslaten op het encrypt algoritme die net zo lang door gaat tot de ciphertext gelijk is aan de block die je hebt weten te vinden. Dan heb je dus de sleutel te pakken.

[Bodevinaat]

Als encryptie van bestanden een 'bijproduct' van een applicatie is wordt er vaak gekozen voor een eenvoudig algoritme en meestal symmetrisch. Dat betekent dat decryptie hetzelfde is als encryptie, m.a.w. 2 x encrypten van dezelfde string levert weer plaintext op. RC4 is een implementatie van dit principe. Je zou eens een plaintext 2x kunnen decrypten (want dat kan je wel) met dezelfde sleutel en kijken of je weer een leesbaar bestand hebt.

[ Voor 2% gewijzigd door Bodevinaat op 16-07-2015 10:53 . Reden: Typo ]

[Vaan Banaan]

Inderdaad beginnen met een bestand van 16 0x00 bytes of zo, dan een bestandje met de laatste 0x01 en een bestandje met de eerste byte 0x01 en kijken wat er uit komt.
Als het een simpele XOR is, dan lijken de berichten op elkaar, zo niet, zal er waarschijnlijk een stream cipher gebruikt zijn.
Verder kun je het decryptie programma eens in een notepad achtig ding openen en kijken wat er allemaal aan leesbare tekst langs komt.
Of eens zoeken naar stream ciphers strings (RC4, AES, enz)
Met een beetje freewheelen, krijg je misschien al een idee van de complexiteit
En afhankelijk van de taal waarin het pakketje geschreven is, kun je er altijd nog een decompiler op los laten.

[deadinspace]

Douweegbertje schreef op dinsdag 14 juli 2015 @ 17:00:
Het is geencrypt door 3e partij als zijnde hun file (storage) system. Hoe/wat/ etc is onbekend. Het programma om het te decrypten heb ik wel maar dat gaat enorm ruk (lees: traag). Daarom wilde ik graag kijken of ik een eigen implementatie kan maken.

Hoe traag is traag? Hangt dat sterk af van het formaat van het bestand?

Men wilt echter geen informatie geven dan "het is een eigen encryptie in ons programma", dus achter de manier van encrypten ga ik niet via hun achter komen.

Dan blijven cryptanalyse (nst6ldr gaf daar wat pointers voor) en reverse engineering (zoals al een paar keer gesuggereerd hier) over.

NMe schreef op dinsdag 14 juli 2015 @ 17:08:
Ehm...je realiseert je dat de traagheid van encryptie/decryptie juist bijdraagt aan hoe veilig die encryptie is? De kans is vrij groot dat het algoritme juist bewust zo traag is gemaakt en dat je het dus niet substantieel sneller gaat kunnen maken ongeacht hoeveel tijd je erin stopt. En stiekem moet je dat ook niet willen.

Dat is niet waar. Je bent in de war met password hashing, dat wel met opzet traag wordt gemaakt.

Encryptie moet juist zo snel mogelijk zijn, zodat het gebruik zo min mogelijk in de weg zit. Encryptie die niet gebruikt wordt omdat hij te traag is (en denk niet alleen aan PCs, maar bv ook aan smartcards waar elke bit telt) is nutteloos. Encryptie wordt daarom altijd ontworpen om zo snel mogelijk te zijn.

Het heeft ook echt bizar weinig zin om encryptie traag te maken; je kunt dan beter de key length een beetje vergroten. 10 extra bits aan "cryptographic strength" toevoegen (wat bij een goede symmetrische cipher neerkomt op 10 bits toevoegen aan de key) maakt brute-force een factor 1024 trager. Dat beschermt dus evenveel tegen aanvallers als de encryptie 1024 keer zo traag maken, waar ook legitieme gebruikers last van hebben.

Bodevinaat schreef op donderdag 16 juli 2015 @ 10:49:
Als encryptie van bestanden een 'bijproduct' van een applicatie is wordt er vaak gekozen voor een eenvoudig algoritme en meestal symmetrisch. Dat betekent dat decryptie hetzelfde is als encryptie, m.a.w. 2 x encrypten van dezelfde string levert weer plaintext op.

Dat is niet waar. Symmetrische encryptie betekent alleen dat de encryption key hetzelfde is als de decryption key (en eigenlijk niet eens dat, maar dat de twee keys direct van elkaar af te leiden zijn).

AES bijvoorbeeld verschilt in encryptie en decryptie, maar dat is toch echt een symmetrische cipher.

Vaan Banaan schreef op donderdag 16 juli 2015 @ 14:16:
Of eens zoeken naar stream ciphers strings (RC4, AES, enz)

AES is geen stream cipher, maar een block cipher.

[Douweegbertje]

Traag als in 1 seconden per bestand. In zekere zin zijn alle bestanden het zelfde dus veel kan er ik niet over zeggen noch kan ik iets testen of het aan de manier van encryptie ligt of de bestandsgrootte.

Ik ben op dit moment een beetje druk, hoop binnenkort wat getest te hebben!