vertrouwelijk informatie? Weten we wel zeker dat dat de AIVD is en geen phishing site? ;-)

Hmm iemand heeft het zip-bestand vanochtend om 9:57 reeds gescand.

Ja. In plaatjes H.jpg D.jpg en J.jpg ziet iets heel anders :)...

Best een pittige challenge :)

ohhh, allemaal plaatjes waar copyright op zit. hoe illegaal!

hmm, volgens mij hebben we te maken met Steganografie

hmm, volgens mij hebben we te maken met Steganografie

Is dit zo'n test van wie antwoord valt af ?

AIVD en delen van informatie; lol.

Plaatjes H,D en J jpg omzetten naar zip en dan het password vinden :))

Ik heb ze facebook te pakken XD alleen loop beetje vast :(

Wat is het wachtwoord van die PDFjes?

Ik ben een noob. Ik loop al vast op het tevoorschijn halen van de .exe :'(

Iemand al het wachtwoord van de ZIP files?

Is het de bedoeling de zips te kraken of is het wachtwoord te raden? Het raden lukt mij niet.

ja maar als we de antwoorden hier geven dan wordt het wel heel makkelijk he.... creatief zijn en het lukt je ook

uhmm.. weetje wel zeker dat dit niet een Overheids truc is? Aangezien malware ook in plaatjes verstop kan worden 0_0
en de bekentenis dat ze malwares gaan gebruiken of al aan het gebruiken zijn... LOL?

Beetje jammer dat 'aivd.nl' niet met DNSSEC is gesigned nog..

fcrackzip in linux levert niks op in ieder geval.

En ik zou voor de AIVD willen werken? Net zoals ik ook al zo graag voor de KLPD zou willen werken?

Het zijn en blijven overheidsdiensten.

doe ik, alleen krijg ik dan een leuke foutmelding met windhoos. Of moet dit gebeure onder linoeks misschien ?

In file k staat als je deze in kladblok opent n.zip.encPK dat ook de naam is van een bepaalde trojan....

Nou schiet mij voorlopig maar lek...

Ik dacht dat de passwords voor de 'verborgen' bestanden wellicht in de telex waren te vinden, ben nog
bezig om dat door te nemen, echter op dit moment nog noppes.

Mijn notities en voor diegene die het misschien van waarde achtten, de tekst in tekst vorm van de telex
met de character hoeveelheden van de uitgeblankte stukken.

Helaas moet ik gaan werken, anders was ik hier wel een paar uurtjes langer achter gaan zitten ;)



NOTES
======
D.jpg has file content: b.pdf (protected)
H.jpg has file content: h.pdf (protected)
J.jpg has file content: crypt.exe (protected)
K.jpg has file content: n.zip.enc (not protected)

F.jpg comments (from exiftool) ;
??~.?.?.@.J.@.|.?.?.|.?.|.V.|.?...?.?.?.?...?.<. .?. .<.?.?0?...d.d...?.?0:#?.J.?.:#V%........V%?.?.?.?0?.?.?0:>?-:>HZHZ0?

H.jpg comments (from exiftool) ;
cp: 2004 ThinkFilm. All rights reserved...nn: http://pro.imdb.com/name/nm1503383/ (RED)..nn: http://pro.imdb.com/name/nm1503403/ (brown)

File J.jpg contains more ICC data.

Okee hij was leuk, maar moeilijk viel wel mee.

Have fun allemaal

Ik heb de eerste al gevonden j.jpg omzetten naar j.zip vervolgens openen, wachtwoord is Joshua, en nu uitvogelen wat crypt.exe doet :)

x Liveonline

nope, jij zal zeker niet bij de AIVD komen, als je een beetje ervaring met Linux had wist je dat je programma's die je normaal in windows draait ook in Linux kan draaien, en je kan de "challange" gewoon uitvoeren.


Hahaha, jij bent grappig en zo geloofwaardig.


Voor de mensen die zo desperate zijn. Het eerste bestandje waar ik mee aan de gang ben gegaan is: J.jpg, omzetten naar J.zip (wachtwoord is tenminste 6 karakters lang)

De rest zoeken jullie zelf maar uit :) na verloop van tijd zal ik meer posten.

Probeer het eens met Winrar

Hahaha wat heb je allemaal al geprobeerd dan?

PS: zal je ook nooit lukken ;)

Zullen hun zelf wel gedaan hebben, of iemand was ons heeeel snel voor

De namen van de films en e.e.a. uit de EXIF-info (althans, de paar dingen die me geschikt leken).

In K.jpg bevind zich ook een bestand 'n.zip.enc'
Dit archief is niet beveiligd, maar geen idee wat ik nu met dit bestandje aan moet.
Nog mensen bezig?

Denk dat n.zip.enc gecodeerd is met de 'crypt.exe' toepassing in archief J.
Frustrerend, weet niks meer om te proberen. Ik denk dat de wachtwoorden voor de archieven te achterhalen zijn ergens, en dat ze niet te raden zijn.
Ik ben helaas niet kundig genoeg, heb wel veel interesse.
Hou ons/mij alsjeblieft op de hoogte van je vooruitgang.
Matthijs

Het bestand n.zip.enc was vandaag om 4u 's ochtends al gescand op virustotal. Apart!

Afbeelding K.jpg is toch een scene uit Star Wars ?

Probeer wat keywords van die films te gebruiken voor de crypt.exe op de n.zip.enc, maar voorlopig nog geen resultaat.

okee, voor de mensen die met de n.zip.enc vast zitten. Wat weet je van de "plaintext" van een zipfile? Dat de eerste 4 tekens bekend zijn. Daarnaast kan je met een debugger vinden dat de 4 bytes in de ENC file gewoon een headers zijn maar de volgende bytes je iets vertellen over de sleutel. Hiermee moet het ook jullie lukken om de eerste 4 tekens van het wachtwoord van de enc file te vinden.

succes.

Dat is Luke Skywalker op Tatooine..

Ik heb inmiddels zowat alle Star Wars keywords die ik maar kan vinden erop los gelaten, maar geen resultaat.

misschien toch maar een scriptje maken en de starwars wikis erop loslaten..

Usage crypt -[d/e] [file_in] [file_out] [password]

Gekregen door compatibiliteit te verzetten en snel te zijn met de prt sc

Uh, als je naar start gaat zoekt naar CMD en dan enter, en en vanuit daar start (command: start crypt.exe) krijg je dat bericht permanent. :\
Snel te zijn met print screen hoeft helemaal niet. Maargoed gefeliciteerd.

Ik was bezig om met de -e switch wat bestanden te coderen met de crypt.exe om te kijken of ik overeenkomsten kon vinden met de n.zip.enc.

Ben nog aan het kijken.. maar ik geef mijnzelf weinig hoop.. Ik ben hier overduidelijk niet wijs genoeg voor ;)


Is er iemand wat verder gekomen met de andere bestanden ?

Heb een stegdetect op de jpegs gedaan ;

Dan een stegbreak (met -t op) op de diverse jpegs laten lopen, met wachtwoord lijsten gemaakt van de woorden uit de telex / exif data en voor de goede orde ook maar de rockyou woordenlijst.

Helaas geen resultaat, hoewel het toch lijkt dat er iets is :(

Als ik in archief H het wachtwoord "Himora" gebruik krijg ik alleen nog een CRC error maar niet meer een duidelijke wachtwoord verkeerd melding. Misschien zit ik in de buurt of is het bestand beschadigd?
Matthijs

Gefeliciteerd de rootkit is succesvol geïnstalleerd! ;)

Ik sta op het punt af te haken. Vroeger had ik nog programma's als SoftICE en IDA, aan Ollydbg kan ik zo snel niet wennen.

Ik weet niet of de AIVD meeleest, maar wel hulde voor deze challenge. De cyber-challenge van de politie heb ik juist als anti-reclame ervaren.

Ze zijn wel dol op PI zeg, deze malware-makers. Of op 0xbb40e64e of hoe je het ook wilt noemen...

Lol, is dit van de aivd? Dit is eerder een dom puzzeltje.

Joh doe mee, of blijf aub stil..

hm, de versleutelde bestandjes van crypt.exe beginnen idd met 3-4 constante tekens die afhankelijk zijn van (Alleen?) de sleutel. Ik dacht, laat ik dan even een lijstje gaan maken met alle karakters en hun tegenhangers, maar het lukt me nog niet om er een werkend scriptje voor te schrijven :/

Nog geen vooruitgang, iemand anders nog geluk of ingevingen?
Matthijs

De jpeg header comments van F.jpg bevat x86 code (geen flauw idee wat 't doet) maar omgezt is het :

"\x80\x97\x7e\x04\xcc\x01\x00\x00\xcc\x01\x00\x00\x40\x02\x00"
"\x4a\x01\x00\x00\x40\x02\x00\x00\x7c\x05\x00\x00\xea\x01\x00"
"\xea\x01\x00\x00\x7c\x05\x00\x00\x80\x0d\x00\x00\x7c\x05\x00"
"\x56\x04\x00\x00\x7c\x05\x00\x00\x80\x0d\x00\x00\x16\x11\x00"
"\xb4\x09\x00\x00\xa6\x08\x00\x00\xa6\x08\x00\x00\xb4\x09\x00"
"\x16\x11\x00\x00\xe4\x18\x00\x00\x3c\x0c\x00\x00\x20\x0a\x00"
"\xb4\x09\x00\x00\x20\x0a\x00\x00\x3c\x0c\x00\x00\xe4\x18\x00"
"\xba\x30\x00\x00\xee\x11\x00\x00\x14\x0d\x00\x00\x64\x0b\x00"
"\x64\x0b\x00\x00\x14\x0d\x00\x00\xee\x11\x00\x00\xba\x30\x00"
"\x3a\x23\x00\x00\xfc\x12\x00\x00\x8e\x0e\x00\x00\x4a\x0d\x00"
"\x8e\x0e\x00\x00\xfc\x12\x00\x00\x3a\x23\x00\x00\x56\x25\x00"
"\x18\x15\x00\x00\x16\x11\x00\x00\x16\x11\x00\x00\x18\x15\x00"
"\x56\x25\x00\x00\x8e\x29\x00\x00\xe4\x18\x00\x00\xba\x15\x00"
"\xe4\x18\x00\x00\x8e\x29\x00\x00\xba\x30\x00\x00\xa4\x1f\x00"
"\xa4\x1f\x00\x00\xba\x30\x00\x00\x3a\x3e\x00\x00\xfc\x2d\x00"
"\x3a\x3e\x00\x00\x48\x5a\x00\x00\x48\x5a\x00\x00\x30\xb1\x00";

b.jpg is byte identiek aan de afbeelding op http://dailygrindhouse.com/thewire/hellboy-3-news/

Hoe kwam je op Himora? Lijkt erop dat het ww van een zip de beginletter van de file moet hebben: J.zip Joshua H.zip Himora, nu nog voor D.zip, Disney is het iig niet ;-)

Het plaatje b.jpg is byte identiek aan de afbeelding op http://dailygrindhouse.com/thewire/hellboy-3-news/

Door met crypt -e inputfile outputfile password te spelen kan je kijken wat een wijziging van het wachtwoord oplevert in de output. Zoals eerder gezegd zou je de eerste 4 tekens van het wachtwoord (byte 5-8) in de output moeten kunnen afleiden. Daarmee dus het ww van n.zip.enc kunnen achterhalen.

Sequentieel proberen van AAAA, AAAB, AAAC totdat 4e teken klopt, dan 3e etc, lukte niet.

En wat denk je van de volgende info uit afbeelding C ? (gewoon JPG openen in kladblok)

Œcp: 2004 ThinkFilm. All rights reserved.
nn: http://pro.imdb.com/name/nm1503383/ (RED)
nn: http://pro.imdb.com/name/nm1503403/ (brown)

Om iedereen die moeite met de wachtwoorden heeft even een hint te geven. ( en dit wachtwoord is toch al in de comments gegeven ).

Het wachtwoord van J.zip is dus Joshua. Maar hoe kom je hier aan? Als je naar de afbeelding kijkt dan zie je daar een afbeelding van de supercomputer uit de film wargames. Iedere hacker kent deze film wel. En iedere nerd kent de truc met het lipje van het colablikje en de telefooncel uit zijn hoofd. ( maar hoe die mooie jongedame er ook alweer uitzag???? sorry vergeten te kijken naar dat stuk van de film ). Deze computer heette WOPR of zoals zijn maker hem genoemd heeft "Joshua". Daar is je wachtwoord

Andere wachtwoorden uit deze challenge hebben ook iets te maken met de films waar ze of andere plaatjes naar verwijzen.

De .enc file is inderdaad encrypted met crypt. Zoals ik al eerder meldde, een plaintext attack op de eerste 4 bytes geeft misschien een idee over wat het wachtwoord kan zijn ;-)

Succes verder

Ik krijg die .exe al niet bij het omzetten van J.jpg naar J.zip. Die baan bij de AIVD mogen ze houden.

Een leuke challenge. Ik heb weinig tijd, dus ik ben er af en toe nog steeds mee bezig. Het bovenstaande heb ik ook ontdekt. Met het commando strings zijn de (zip) bestandsnamen te vinden. Kan natuurlijk ook met grep. Het commando fcrackzip werkt pas als de eerste bytes van het plaatje worden verwijderd. Hiervoor natuurlijk dd gebruikt (dd bs=1 skip=35076 if=H.zip of=Houtput.zip). Via een woorden lijst is het genoemde wachtwoord van J.zip te achterhalen. De andere ben ik nog mee bezig. Het genoemde wachtwoord voor H.zip werkt inderdaad niet (misschien klopt de checksum van het ww dan wel).

De exe kan ik in Linux niet zomaar draaien. Wel te zien, dat deze met Visual C++ is gemaakt. Het lijkt te werken met Wine.

So far so good.

Zoals bekend staat achter afbeelding D (met Wall-E) een PDF-je "b.pdf" verstopt.
Als je deze afbeelding opent met een Hex-editor, staan er in de eerste 3 regels de woorden "Ducky" en "Adobe"
Kan toeval zijn, maar het kan ook een sleutel zijn...

Overzicht herkomst afbeeldingen:
Plaatje A The Big Lebowski (1998) - IMDb www.imdb.com/title/tt0118715/

Plaatje B is uit hellboy identiek aan http://dailygrindhouse.com/thewire/hellboy-3-news/

Plaatje C Primer (film) - en.wikipedia.org/wiki/Primer_(film)

Plaatje D WALL·E (2008) - IMDb www.imdb.com/title/tt0910970/

Plaatje E Pi (film) - en.wikipedia.org/wiki/Pi_(film)

Plaatje F Mr. Magorium's Wonder Emporium (2007) - IMDb www.imdb.com/title/tt0457419/

Plaatje G Office Space (1999) - IMDb www.imdb.com/title/tt0151804/

Plaatje H Princess Leia en.wikipedia.org/wiki/Princess_Leia Password Himora ??

Plaatje I Sneakers movie

Plaatje J WOPR en.wikipedia.org/wiki/WOPR Password van j = Joshua

Plaatje K Two suns star wars Tatooine en.wikipedia.org/wiki/TatooineNumber of suns

Ik ben er nu voor de fun een 26gb wordlist erdoor aan het jagen. Ik denk wel dat de zip niet protected is ofzo. Weet ik niet zeker

Hey Yobi,

Mij is het niet gelukt om de zip bestanden als zodanig te laten herkennen via de door jou gebruikte manier.

Hoe ben je op de hoveelheid bytes 35076 gekomen ?

Ben wel benieuwd daar ik eigenlijk ook een kraker erop los wil laten.

EDIT
-----
OK, had ffekes moeten zoeken ;)

Heb gewoon de JPG info in een Hex editor eruit gehaald (zoeken op 'FF D9' voor einde JPG) en dan heb je je zip.. doh..

Hoi Tape,
de bestanden worden door winrar gewoon herkend, maar dan merk je dat een password cracker ze niet als .zip bestand herkend. Wat ik gedaan heb is ze in een hex editor geopend en vervolgens even op PK gezocht. Deze PK zijn de eerste twee bytes van de zip file en daarna heb ik ze met een klein php filetje uit elkaar gehaald. Maar de wachtwoorden zijn dusdanig lang dat het niet te doen is om ze te brute forcen. Ik ben nu al een uur of 8 bezig om de enc file langs een dictionary attack te leggen, maar tot op heden nog geen resultaat.

Omtrent de enc file en het crypt programma wil ik mijn bevindingen wel delen :

De hash van het wachtwoord staat in de enc file zelf en is : 0x6A6BA51C

de methode waarmee het wachtwoord wordt gehashed is mij helaas onbekend ( ik heb de assembly en zelfs pseudocode, maar geen idee welke functie dat in het echt is ). De en-/decryptie wordt gedaan in blokken van 4 bytes, dus lijkt het erop dat een hash van het een of ander de decryptie regelt. Ik heb de binairy van crypt aangepast dat hij onafhankelijk of het wachtwoord goed is toch begint te decrypten. Door daarna net zo lang door te gaan blijkt dat het eerste teken wordt gedecrypt door het derde teken in het password. Met een php script heb ik hem door alle letters heen laten zoeken totdat er een P als eerste letter stond ( even uitgaande dat het een plain zip file is ). Dit heb ik met de andere 3 bytes van de zip header ook gedaan en daaruit blijkt dat de eerste 3 bytes PK(0x03) zijn als het wachtwoord begint met iml. alleen het 4e teken in de decryptie wijzigd niet meer met het 4e teken in het password maar met de lengte van het wachtwoord. Ik heb het wachtwoord hierna verlengt maar tot op heden niet tot PK(0x03)(0x04) gekomen. Wel blijkt dat het wachtwoord intern in crypt maximaal 16 tekens heeft en daarna roundrobin het begin overschrijft.

Let overigens op dat crypt functies heeft om de debugger te trappen en zelfs als je die omzeilt met de debugger aan een ander resultaat uit spuugt dan zonder debugger. Dat maakt het patchen ervan lastiger omdat je het resultaat niet in je debugger kan testen.

Wordt vervolgd, Overigens jammer dat dit topic waarschijnlijk morgen van de site af is.

@tape doe eens # unzip h.zip en check de output.

Hey allemaal,

Ik heb nog even geprobeerd, Himora is niet het wachtwoord van plaatje H,
Misschien lijkt het op de echte sleutel.

(Heb optie aangezet om foute CRC's te negeren, toen kreeg ik wel weer de melding dat het ww verkeerd was.)

Matthijs

File is decrypted;

Alleen ik krijg chineese rommel eruit?!?

De huishoudens Fu Jia ? ? de Han ? Mu Po HM SHABU?? ? parel ????? rivier in ? ? ? ? op Gall? De ? ?? Het? Mao ? de druppels ?? de ? ??? ? ? Ling ? ? ma ? Lan ? ? uitstekende ? ? ? ? bewoners ? ? ? ? beoordeling ? Yuan ? ? ? Oh ? ? Qin Yi ??? ? ? ? valse beschuldiging ? ? ?? ??? ? Chen ? ? H ? bittere anker ? ? ??? ? VS ? FORALL ? Yin ?? dare ? ? ? ? geoogst soorten van larvale vis het?? ¤ ? ? Ling spion Youyang ? ? ? Xi Wu ? Geng ? ? ? Bei ? ? beheer ? Yan ? ? ? ? ? ? ? Ballet ? ? ? ? Ù ? ? Hai ? ? ? ? ? Yin ? ? ? ? ? ? ? ? ??? echappement ? Hang Shang ? ? Een ? ? ? Uu ?? ? japonica Mi ? ? ? Weixinan mijnbouw ? hout stukjes ? ?? ? ? ?? za ? ? Nai ? ? de gunstige ? ?? ? Sui ? Moju ? ? ? ? Zhu ? eat Chao?? het zand ? ?? ? Mihong?? ronde van Tao wind?? gesloten ? ? van Xue ? ? ? ? ? enz. Bi ? ? ?? Hou ? ? ??? Nang ? taboe ?? ???? ? Lu ? ? ? stationair ??? ? Se?? ? ? Bei ? ? patroon ? ??? Cup ? ? verlegen Fei ? ? spiffing ? veeg ? ? ? ? ? ? ? ? Re ? ? Ga ? weefgetouw?? ? ? ? ? ondertekend ? Qianzhi ? ? ? ? ? ? ? moeten inzonderheid ? ? ? ? ? ? reel bel ? ? Xu ? ? inertie Xiang Lou ?? Liu Jian dochter Jue ?? ? ? ? het adres ? ? ? ? ?? ??? de ? ? ? ? ? Shen ? ? ??? o ? verloren smoorspoel, 5 ? ? ? de Boeddha ? T ? Mu corruptie dom ? ? Xu ? ? Fu ? ? ?? pot ? mand voor het uitpersen van ?? van Koelen ? rooster ? ? belang Nao ? Yue rijst dumplings ? De kers ? ? ? -?? ?? ? ? ? Lai ? ? ? Xin ? ? ? ? Wu ? ? ? Jie ooievaar Wu ? ? Que ? voet met zes tenen gevangen ? Yin? ? ??? ? Fung Ling Ren ? roller ? ? ? begraven ? ? ? mos ? ? ? ? ? schade ? Yu ? Ju ? ? ??? ? ? ? ? Leng ?? ? Yue ? Hui ? Op ? ?? ? ? haarspeld Zhou Ge ? ü ? ? o ? ? Jiao?? Zhi Qin ??? ?

ik heb nu een eigen bruteforcer geschreven voor de n.zip.enc. Hij gaat net zolang door totdat hij 4 hex decimalen overeen komen. Hopelijk gaat het lukken :D

ff accountje aangemaakt.

Maar what the hell dude wat moet ik met al die text? Tis van een film of email ofzo i guess?

http://maps.google.nl/maps?q=131.3+132.1+115.8+123.6+131.6

Mja ik ga morgen wel verder..

Ik heb een wachtwoord waarmee het n.zip.enc bestand volgens crypt.exe succesvol wordt gedecrypt, de bytes 3-7 komen overeen met de gebruikte sleutel... Het resultaat bestand is echter alles behalve een geldig zip bestand (geen zip headers te bekennen), file noemt het "data" en er is geen zinnig byte uit te halen..

Ik heb een wachtwoord waarmee het n.zip.enc bestand volgens crypt.exe succesvol wordt gedecrypt, de bytes 3-7 komen overeen met de gebruikte sleutel... Het resultaat bestand is echter alles behalve een geldig zip bestand (geen zip headers te bekennen), file noemt het "data" en er is geen zinnig byte uit te halen..

Dat is een adres;

6th Ave E
Manilla, Filipijnen

Maarruh.. hoe kom je daaraan ?

Komt uit het decrypted n.zip.enc bestand. Ik dacht doe eens google maps op die coordinates. En het bleek te werken.

Dus jou is het wel gelukt om de juist ww te pakken voor de n.zip.enc ? Congrats.. ik struikel er nog over..

De hoeveelheid bytes wordt weergegeven door unzip in Linux.

Ben nu ook bezig met n.zip.enc. Ik heb twee wachtwoorden, waarmee het bestand wordt gedecrypt. Er komt echter nog geen zip formaat uit. Het moet toch beginnen met: 50 4B 03 04 14 00 00 00 08 00? Mijn vermoeden is, dat het wachtwoord meer dan 6 karakters is.

Het is nog even rekenen (xor of iets dergelijks).

Ik heb crypte.exe het passwoord ingevoerd en er staat. decryption succeeded. Maar alsnog kan ik de n.zip niet openen :( Heb een hele bruteforcer in c geschreven -.-'

Ik heb algoritme verbeterd. nu zal hij alle wachtwoorden opslaan die hij kan vinden. hopelijk zal het wachtwoord daar tussen staan. Nu is het wachten....

Ik heb voor de jpg's zonder zichtbare 'hidden content' de (verwachtte) originelen gezocht (gebaseerd op grootte en afmeting) en deze met HxD Hex Editor met elkaar vergeleken.
Resultaat is dat de bestanden identiek zijn, wellicht dat ik wat dit betreft iets over het hoofd heb gezien, maar lijkt dat de bestanden dus hints moeten geven of gewoon zijn meegegeven als camouflage.

Ik heb trouwens ook een stegdetect gedaan op de verwachtte originelen met -s 2 om een vergelijk te hebben,
en krijg eveneens melding van mogelijk jphide inhoud.
Ik ga er nu dus vannuit dat die er in de challenge bestanden geen jphide info is, gezien de info dat ze identiek zouden zijn aan de originelen..

argh.. what a mind fuck..


Krijgen we nog een hint van onze anonymous vriend ?

http://pastebin.com/YavRfy9e

crypt.exe openen in CMD en voer het volgende commando uit: "crypt -e n.zip.enc [hier een naam in vullen] Joshua"

Hier komt een file uit, ik weet alleen nog niet wat ik hiermee kan... heb er al een .zip / .jpg / .txt van gemaakt alleen dit leverde geen resultaat! Iemand een idee?

Lupo bedankt voor het bruteforce programma. Helaas compileert deze niet gelijk onder Linux. Ik ga ook eens een script proberen. Met het wachtwoord 12345678 dan hebben 3 en 7 invloed op de waarde, die op 1C uit moet komen. De waarde 2 en hebben daarna invloed op de waarde A5. De waarde 1 en 5 hebben daarna invloed op de waarde 6B. De waarde 4 en 8 hebben vervolgens invloed op de waarde 6A.

Cs7l en 777M17 werken in ieder geval niet (het bestand wordt wel uitgepakt maar niet goed).

@ Yobi
Verander system("pause") bijv. in system("sleep 5") en de aanroep van Crypt.exe in

WINEDEBUG=-all wine /path/naar/crypt.exe -e

en hij compileert prima. Ga er wel even vanuit dat je wine gebruikt om de executable te draaien.

Bedankt voor alle info op de n.zip.enc heren,


Ik zit voorlopig echter muurvast .. inderdaad jammer dat deze topic van de voorpagina verdwijnt, maar ik houd hem gewoon open voor de F5 !

Voorlopig ff geen tijd meer, dus ik zal maar afwachten wat de meer begaafde mensen kunnen vinden !

Over n.zip.enc: Het gecrypte bestand is 24 bytes groter dan het orgineel. Zowel vanaf byte 5 als vana byte 25 gekeken wat de waarden worden als deze met de verwachte output worden ge-xored. Ik kom geen sequence tegen.

Dus ook maar eens brute kracht gebruiken (hmm zal wel even duren met deze oude celeron).

Bytes 1-4 bevatten ENC/, een header, bytes 5 t/m 24 waarschijnlijk een hash van het wachtwoord, die wordt berekend per vier bytes van wachtwoord. Dit wordt vervolgens gebruikt als 'check' om te zien of het wachtwoord correct is voordat de decryptie start met (zodat dit niet gebeurd met een foute key). Het lijkt erop dat de check alleen de eerste vier bytes controleert en niet de rest van het wachtwoord, zodat de mensen hierboven er wel in slagen om een wachtwoord van vier characters te vinden, dat toch niet resulteert in een correct gedecodeerde zipfile. Daarnaast heb je natuurlijk met een hash altijd te maken met collisions, en meerdere keys kunnen coderen tot dezelfde hash.

Mijn vermoeden is dat het encrypte bestand als volgt is opgebouwd:

byte 0-3: magic number (ENC/)
byte 4-7: paswoord
byte 8-23: random nummer
byte 24-...: data

Om verwarring te voorkomen. De byte 4-7 wordt gebruikt voor de wachtwoord als hash. Als iemand wil decompilen zal het programma eerst het wachtwoord een hash van maken en zal dan controlleren dat het overeen komt wat in het bestand staat. Als dat zo is zal hij daarna pas de data decompileren. Het probleem tot nu toe is dat verschillende wachtwoorden zelfde hash zouden kunnen hebben.

Tot nu toe weet ik nog niet waar de byte 8-23 voor gebruikt wordt.

Volg me via: http://www.livestream.com/lupo_

Ik denk dat byte 8-23 een random generated 128-bit key vormen welke, al dan niet, in combinatie met het paswoord als key paar dient. Je kunt dit zien door herhaaldelijk dezelfde data te encrypten met een statisch paswoord. De bits 0-7 blijven identiek. [8,...] veranderen bij elke run. De laatste bits zijn de data bits (dit kun je afleiden aan het feit dat voor elke byte extra data een byte extra in de output voorkomt, bij een zelfde paswoord). Aangezien de data bits veranderlijk zijn bij dezelfde data en hetzelfde paswoord lijkt het aannemelijk dat de random 128-bits hier van invloed op zijn.

Overigens is er nog niets waaruit je kan afleiden dat de 128 bits byte 8-23 zijn. Het is even aannemelijk dat deze als laatste aan de output toegevoegd worden! Het is dus evengoed mogelijk dat de data bytes 8-(n-16) zijn.

Voor degene die zich afvragen hoe de strings ("encryption succeeded", "decryption succeeded", etc.) zijn versleuteld in crypt.exe:

Hiervoor wordt b * 3 mod 128 voor gebruikt, waarbij b de ordinale waarde van de byte is.

- J.

Voor de degene die zich afvragen hoe de strings in crypt.exe ontsleuteld moeten worden:

Dit is b * 3 mod 128, waarbij b de ordinale waarde van de byte is.

http://nativeborncitizen.wordpress.com/2009/04/29/ducky-hunting/ :

"Reality is that the headers of JPEG files created by Adobe Photoshop contain three tags, JFIF, Adobe and Ducky meaning that the file was created by an Adobe program called Ducky"

"Ducky" noch "Adobe"betekent helaas niets voor deze challenge :(

Een hint aan Lupo deze keer. bytes 8 t/m 11 zijn de seeds waarmee de decryptie routine een 16 byte blok aanmaakt om de rest van de data mee te decrypten. De encryptie is overigens niet meer dan een normale XOR uitgevoerd in blokken van 16 bytes. Maar welke 16 bytes en wat hebben bytes 8 t/m 11 daarmee te maken.. Overigens is het 4e byte van de versleuteling afhankelijk van de lengte van het wachtwoord ( deze lengte wordt als eerste byte aan een groep van 16 bytes toegevoegd zodat bij big-endian hij als 4e byte uitkomt ). Ik ben wel heel benieuwd hoe jij aan die 7 op de 3e plek bent gekomen. Is dat omdat alle tot nu toe gevonden wachtwoorden een 7 op die plaats hadden?

Overigens hoor ik nog weinig mensen over de data in F.jpg?? Dit blok van 256 bytes is hier al eens gepubliceerd maar maar weinig mensen schenken er aandacht aan. Als je even naar het blok kijkt dan moeten een aantal dingen gaan opvallen.

- Het eerste integer is groter dan de overigen.
- De overige data is overduidelijk iets 32-bits.
- Het is big-endian
- Als het een tekst is.. welke character-set is het dan? ( hint: Word is hier je grote vriend )
- Als het geen tekst is, is het dan misschien x86 assembler.. maar zouden dan al die nullen niet wel heel veel nul-pointers opleveren?
- Als het assembler is, hoe debug je eigenlijk een JPG?? ( onder windows XP natuurlijk gewoon met good-old DEBUG.EXE )

- Als het nou eens iets versleutelds is wat zou het dan kunnen zijn. Als we de eerste integer even buiten beschouwing laten dan zijn het allemaal relatief kleine getallen. Wat wel opvalt als je zo onder elkaar zet is dat ze steeds groter worden. Dit betekend dus dat het niet zomaar een optelling is, maar dat de positie van het getal mogelijk te maken heeft met de grote van de versleuteling. Iets wat deze stelling weer ontkracht is echter dat er meerdere keren gelijke getallen achter elkaar zichtbaar zijn. Dit zou in de vorm van letter-distributie misschien inhouden dat de versleuteling toch liniear is. Ook kan het zijn dat de versleuteling wel plaats afhankelijk is, maar de ontsleuteling niet ( zoals bij een modulo functie het geval is ).

Ik wens u allen weer veel puzzel plezier.. May the force be with you :-)

Eerste stap was de data bekijken als je iets encrypte, daaruit maakte ik een conclusie dat byte 4 t/m 8 niet veranderde van elkaar als de data veranderde. Hier heb ik een bruteforcer voor gemaakt om te controleren of de bytes van n.zip.enc overeen kwamen. Uiteindelijk zijn er optimalisaties gemaakt namate ik per wachtwoord de 4 bytes zag veranderen. Na 2 dagen bruteforcen zijn er in 7 wachtwoorden die gebruteforced zijn op de 3e plek een 7 te staan. Kan dat toeval zijn?

Wat je merkt is dat hier toen nog helemaal geen broncode is doorgekeken in de crypt.exe.

Hoi Lupo,
hou bij het toevoegen van de ASM code even rekening met de antidebug trucks die in crypt.exe verwerkt zitten. Alleen met een kernel debugger kun je ze omzeilen, met een usermode ( ring3 ) debugger wordt het heel lastig.

Hou rekening met :
- GetTickCount metingen op verschillende plaatsen.
- CloseHandle invalid handle
- Loslopende Int3 die door de debuggers zelf worden ondervangen ipv het programma.

Hierdoor wordt de executie volgorde van het programma gewijzigd en kom je niet tot de uiteindelijke hash terwijl wel een "bruikbaar" wachtwoord is ingevuld.

Als je die 7 telkens op dezelfde plek hebt. ( plaats 3 ) dan betekend dat dat het eerste teken telkens hetzelfde is, maar is dat dan ook de verwachte P uit de PK header?

Begrijpelijk. Wil de core eruit halen door zelf te lezen wat relevant is. Ik heb de asm code van encrypt functie al. Dus het heeft nog tijd nodig.

Wat bedoel je met "de verwachte P uit de PK header"?

Wat bedoel je met "de verwachte P uit de PK header"?[/quote]Ik heb eens gekeken,.. nee de decrypted outputs beginnen allemaal met een "ï". De HEX is EF. Was me niet eens opgevallen

foutje:$

De decrypted n.zip.enc met mijn wachtwoorden hebben allemaal zelfde data na elke 4 bytes
Hier onder eerste regel decrypte data van verschillende wachtwoorden:
Output "Cs7T" : EF 8A BA 38 DA 93 91 1B-39 25 52 C9 39 63 99 37-00 81 B8 C5 CA 4C A3 EE-12 77 BD 5E 2E ...
Output "8s7x8" : EF 8A 21 D0 DA 93 68 DB-39 25 37 EC 39 63 EA 4F-00 81 AE 5F CA 4C CA AE-12 77 A8 E8 2E ...
Output "777M17" : EF CE A4 A2 DA 27 30 0C-39 1D 54 3C 39 A1 B2 7B-00 19 F3 BA CA EA 76 9F-12 85 CE 2C 2E ...

Wat je ziet dat hij de eerste byte overeen komt met meerdere outputs. Dit gebeurd elke 4 bytes... De hele bestand door

Wat dus waarschijnlijk goed is: EF .. .. .. DA .. .. .. 39 .. .. .. 39 .. .. .. 00 .. .. .. CA .. .. .. 12 .. .. .. 2E ...

Dit was me nog niet eens opgevallen,.. bedankt

foutje

Hoi Lupo,
nu maar even met een accountje, dat scheelt de moderator een hoop werk. De werking is zo dat zolang het wachtwoord onder de 16 tekens blijft het derde teken van je wachtwoord overeenkomt met het 1e,5e,9e enz. teken uit de decrypted file. het tweede teken van je wachtwoord komt overeen met 2e,6e,10e enz teken van het decrypted bestand. het eerste teken van je wachtwoord komt overeen met 3e,7e,11e, enz. Alleen de reeks 4,8,12 enz is afhankelijk van de lengte van het wachtwoord.

Dit komt omdat intern in crypt als eerste in een reeks van byte[] de lengte van het wachtwoord wordt geplaatst. Daarna pas komt het wachtwoord afhankelijke deel. De byte[] is 16 bytes lang en wordt geïnitieerd met een getal gelijk aan ( 0xFF + ( het LSB van de timertick, maar is deze kleiner dan 256, dan wordt er 00 gebruikt <- onderdeel van de GetTickCount anti-debug beveiliging ). Maar goed dat terzijde. Omdat de byte array daarna in een integer (big-endian) wordt geladen komt de lengte van het wachtwoord dus uit op de vierde plek en is de rest in omgekeerde volgorde van belang.

Dus wat je je nu moet gaan afvragen is wat bytes 5 en verder van je wachtwoord voor invloed op de output hebben.

Het wachtwoord "Cs7l" geeft overigens ook een valide hash.

Ik heb de verandering tussen decryptie van data en wachtwoord positie kunnen bepalen. Pass->X betekend wat er veranderd. Daar achter komt XX te staan wat er in de data veranderd.

Pass Data
XNNN NN NN XX XX NN NN XX XX NN NN XX XX NN NN XX XX
NXNN NN XX XX XX NN XX XX XX NN XX XX XX NN XX XX XX
NNXN XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
NNNX NN NN NN NN NN NN NN XX NN NN NN XX NN NN NN XX

X= Changes
N=Not change

Conclusie: Als je dus eerst het 3e letter van wachtwoord bruteforced moet er een P in de decrypted data komen te staan op de eerste regel. Dit kunnen we voor zorgen als we van uit gaan dat de hash die in n.zip.enc niet klopt.

Vanavond ga ik hier mee verder

Even reageren op Anoniem hierboven en Lupo. Wat jij gedaan hebt Anoniem klopt inderdaad. Om het onderzoek naar de bruteforce iets makkelijker te maken kan je op positie 0xCAD de 74 patchen naar een EB. Vanaf dat moment zal het programma met foute hashes toch de decryptie starten en kan je de output gebruiken voor verder onderzoek.

Als je het wachtwoord begint met iml dan zullen de eerste tekens PK(0x03) zijn, maar het verkrijgen van de (0x04) die daarna volgt is lastiger.

Lees je mee op de live stream, Hellbender? Dat hadden we net gedaan.

Wat ik me nou afvraag: ik heb de challenge opgelost. Ja, dat kostte moeite, ik zal niet stoerder doen dan ik ben. Ik beschouw mezelf niet eens als moderne kraker. Als ik de reacties hier lees, lijk ik de eerste te zijn: er staan hierboven echt enorme onzin-reacties, zoals over de chinese tekst en de mysterieuze coördinaten. Totale nonsens. Maar de Anoniem van vandaag, 10:04, die begrijpt er wel iets van. En van Hellbender2 vraag ik me af: jij "coacht" Lupo min of meer, maar heb je zelf nou al wel de oplossing? Zo ja, dan heb je die via een andere weg bereikt dan ik, of probeer je Lupo om de tuin te leiden.

Anyway, omdat er al zoveel claims gemaakt zijn: voor degenen die hem al opgelost hebben en mijn claim willen verifiëren: 81xxxxxx61. Voor degenen die hem nog niet opgelost hebben en mijn claim willen controleren: encrypt een zipje met encrypt.exe, upload hem ergens, plaats hier de link en ik vertel je de inhoud van de zip (zolang de zip zelf maar niet gezipcrypt is). Je wachtwoord mag zo lang en gek zijn als je zelf wilt. Zelfs `23' tekens, en nee, ik ga n.zip.enc niet voor je doen ;)

Ik ga hier verder geen vage hints geven of wat dan ook, t.z.t. geef ik mijn volledige aanpak. Ik denk as. weekend, of het weekend erop, zodat iedereen een redelijke termijn gehad heeft er aan te werken en zonder dat het antwoord simpelweg op internet staat. Wel zo leuk voor iedereen, lijkt me. Goed?

Gefeliciteerd. Hoop je snel te volgen ;) Respect ^_^

Dat was ik, hoop hem snel op te lossen

Deze moet worden gedecodeerd (optie -d). De optie -e betekent encoderen.

Congrats !

Ben reuze benieuwd, is voor mij allemaal teveel geweest, maar zal blij zijn waar te nemen hoe je te werk bent gegaan..

Hoi Hans,
gefeliciteerd. Mag ik vermoeden dat jij een directe aanval op de functie die de file decrypt hebt gedaan? Dan ben je er ook achter gekomen dat de 16 bytes na de hash van het wachtwoord de seed van het decryptieblok zijn ( de 16 bytes waarmee de file gexored wordt ). Met wat rekenwerk kan je in ieder geval de eerste 4 bytes van het blok uitrekenen waarna je de routine zou kunnen laten loopen om dat ene passende blok te laten uitrekenen.

Omtrent het coachen van Lupo. De aanpak van hem was goed alleen keek hij niet naar de resultaten. Door naar het resultaat te kijken komt hij tot een directer, maar niet makkelijker oplossingspad.

Ik heb overigens inmiddels ook een methode gevonden om met een ring3 debugger de anti-debug maatregelen te omzeilen. Dit maakt het een stuk makkelijker om de code te analyseren.

Overigens vraag ik me af wat jij met de laatste twee random bytes gedaan hebt.. heb je die gewoon gebrute-forced tot je een correcte zip file had?

Wow... Ondanks dat ik alles wel begrijp wat ik hier lees, heb ik nog een hoop te leren merk ik al :) ergens interessante websites hiervoor?

Hellbender, welke "twee laatste random bytes" bedoel je precies?

Whacko, mijn reverse-engineer-kennis is de afgelopen 10 jaar lang niet bijgewerkt. Maar dat was afdoende, kennelijk. Uit mijn tijd herinner ik me fravi+ http://en.wikipedia.org/wiki/Fravia en +ORC als bronnen van informatie. Woodmann http://www.woodmann.com/ site kan ik aanraden, bestaat ook al vele jaren. En als je programma's wil uitpluizen is het handig om te weten hoe ze gemaakt worden, dus programmeren in iets als C++ en weten hoe de bijbehorende machinecode van constructies in C++ er uitzien is handig. De gereedschappen van toen zijn nog grotendeels hetzelfde: een disassembler (IDA) en een debugger (toen SoftICE/WinICE, nu gebruikte ik OllyDbg, niet een vooruitgang). En nu heb je ook nog eens uiterst handige hulpmiddelen zoals Hex Rays.

Hoi Hans,

Ik ben fulltime programmeur, C/C++, heb zelfs ervaring met x86 assembly. Heb in het verleden wel eens met SoftICe gewerkt, maar dat was voornamelijk voor het maken van trainers voor games, met enige vorm van code injection. Vandaar dat ik jullie technieken wel snap, maar er zelf opkomen is wat lastiger. Voornamelijk encryptie is een van mijn zwakkere punten. Ik ben de laatste jaren meer bezig met webapplicaties en dergelijke, dus ben meer up to date met XSS en webaanvallen dan op applicatie niveau. Ik ga de sites die je gaf eens bekijken, misschien dat ik mijn kennis weer kan bijspijkeren :)

Hoi Hans,
Wat ik vermoed dat je gedaan hebt is alles wat het wachtwoord checked overgeslagen en meteen door gegaan bent naar de routine die het bestand decrypt. Je hebt dan de functie die vooraf aan het XOR-en een blok met te Xor-en getallen opbouwd. Dit blok wordt gestart met de 16 bytes na de hash in de enc file. Omdat de eerste 14 bytes van de PK header bekend zijn kan je 14 van de 16 bytes van de uitkomst van het eerste blok vaststellen. Alleen hoe je van de 16 bytes na de hash naar het XOR blok komt... Eerst alles vermenigvuldigen met de grote integers en daarna shiften. Alleen bij het shiften wordt gebruik gemaakt van 12 bytes uit het blok welke met het wachtwoord zijn aangemaakt. Deze 12 bytes moet je "goed" zetten om het juiste blok mee te maken. Hierna worden geen externe variabelen meer gebruikt dus kan de routine gewoon doorlopen worden en zou het bestand correct gedecrypt worden.

Omdat je 14 bytes uit de PK header weet kan je 14 bytes van de eerste uitkomst van het XOR blok bepalen maar je hebt er 16 als blok dus je mist 2 bytes. Dat was mijn vraag of je de random 2 bytes die overblijven gegokt hebt.

Ha Hellbender, ik begrijp je nu. De eerste 14 bytes van de PK header zijn niet per se bekend; kijk maar eens naar de zipjes uit de challenge, daar wisselt e.e.a. ook nog afhankelijk van de compressiemethode en eventuele zip-crypto. Kun je dus niet op rekenen. Maar die 12 bytes onbekende bytes die een functie zijn van het wachtwoord, die gok je niet zomaar! 2^96 mogelijkheden is best veel. Wat hierboven al wel voorkwam is de "iml" waar het wachtwoord mee begint. Die andere byte is de 0x3c + wachtwoordlengte. Je kunt dus de lengte van het wachtwoord uitrekenen (of eigenlijk, de minimale lengte want de opgeslagen lengte is mod 256), en daaruit conclusies trekken wat haalbaar is en wat niet.

HansVanDenAcker,

Gefeliciteerd, grote prestatie!

Ik ben zeer benieuwd hoe je om bent gegaan met de tools en zie naar je uitleg uit! Tot die tijd ga ik proberen (net als Lupo) het een en ander er van te bakken met de genoemde websites, tools en de files :)

Josine.

Bedankt ! :D ik weet nu hoeveel tekens je moet gebruiken :D Nu het laatste deel kraken:P

Hoi Hans,
sorry even drukke dagen op kantoor dus geen tijd gehad om te reageren. De lengte van het wachtwoord is inderdaad bekend. Wat wel opvallend is is dat als je 0x3c + letter3 + letter18 = 0xA5 hebt, ik daar niet direct iets uit de letter ascii reeks bij kan verzinnen :-) misschien is het wachtwoord in eerste instantie wel fake.

Maar goed, wat je al zei over 2^96 wordt onmogelijk om te hacken klopt, behalve als je met dank aan de block-functie die er de hash van maakt dit terug kunt brengen naar 4x 2^24 dan is het wel haalbaar. Gelukkig zorgt de bit-shift in deze functie er voor dat je een aantal bytes uit de 16 byte array tegelijk kunt bekijken, zodat je met 4 zoektochten tot de juiste hashes komt. Ik zal eens uitrekenen hoeveel collisions er bestaan en of je dan niet nog toeval moet hebben om hem goed te hebben.

Hoe gaat het Lupo? na het vinden van de wachtwoord lengte al iets wijzer geworden?

0xa5-0x3c = 105 decimaal. Bijvoorbeeld '0'+'9' = 105... de andere twee bekende getallen van "iml" zijn ook uit te drukken in sommen van ascii-cijfers...

Jup, heb nu een reeks gevonden van mogelijkheden. wat op neer komt,.. 192 * 192 * 192 mogelijkheden.
Dus dat ga ik nu bruteforcen

Ik heb een foutje gemaakt. Heb wat over het hoofd gezien. Ik ga hier later mee verder. Ik zal niet opgeven! Ooit zal het me lukken ;)

Waar zit je fout? misschien dat we nog een hint voor je hebben.

nou, die 8 t/m 24 bytes had ik niet rekening mee gehouden dat het voor encryptie gebruikt werd. Dus daar ga ik nu mee verder. Me bruteforce kwam uit dat verschillende wachtwoorden het zelfde resultaat gaven. En dus conclusie dat die 16 bytes niet goed zijn. Tot nu toe geen advies nodig. Het is ook eerste keer en leer daarom van me fouten. Het heeft dus tijd nodig.

Zaterdagavond, tijd voor nerdige dingen: een kort waardeloos verhaal---voor wie het interesseert. http://pastebin.com/rRbQDp5w

Ik ben het trouwens vergeten te vragen, maar hadden de grote integers uit functie #16 nog een bepaalde betekenis?

Hoi Hans,
de grote integers in functie #16 hebben als doel om een overflow te creeren en daarmee informatie kwijt te raken. Hierdoor kunnen de originele waarden niet vanuit de functie en zijn uitkomst terug gerekend worden. Tenminste niet 100%, want er zijn meerdere antwoorden die tot dezelfde uitkomst geleid zouden kunnen hebben.

Heb jij de functies uit crypt.exe overgewerkt in een eigen programme of heb jij net als ik de bruteforcer in assembly in crypt.exe gepatched?

Ik heb overigens wat minder patch werk gedaan dan jij. Ik heb de tickcount gefacked door de sub eax,tickcount te wijzigen in mov eax,0x1FF.
De Int3 heb ik gepatched met een nop en de jump die erachter stond gewijzigd om naar het begin van de exception handler te springen. De closeWindow was al geregeld door de IDAStealth plugin :-) maar die zou je gewoon kunnen noppen. De rest ben ik niet tegen aan gelopen.

De naam is Ans, niet Hans. Maar ik snap de verwarring. Dat van die overflow was me duidelijk, maar ik vroeg me af of de getallen willekeurig waren, of dat het nog bepaalde spannende waardes waren.

Ik heb de relevante C code uit hex-rays gekopieerd, herschreven totdat ik het begreep (de bitschuif-expressie was nogal obscuur gemaakt) en in een eigen programma gezet. Op dat moment wist ik nog niet wat ik er mee ging doen, en het leek me handig om makkelijk te kunnen printfen e.d.

Goede analyse van Ans en Hellbender2. Zelf heb ik weinig ervaring met IDA ik ga straks in de kerstvakantie er nog eens naar kijken. Reverse-engineren is denk ik de snelste methode. Na twee dagen bruteforcen ben ik ermee gestopt. Een bestand met allemaal nullen heb ik vercijferd en de tweede keer vercijferen met hetzelfde ww geeft inderdaad een ander resultaat.

Heeft iemand de D.zip en H.zip reeds gekraakt? Het zal wel want de prijzen zijn al vergeven zie ik.

Niemand van de prijswinnaars heeft die zips gekraakt. Tijdens de prijsuitreiking vertelde de maker wel wat de wachtwoorden zijn. Ik weet niet meer welke zip in welke zat, maar het wachtwoord van de zip in het Starwarsplaatje kan je alleen redelijkerwijs bedenken als je n.zip.enc hebt kunnen ontsleutelen, het wachtwoord van het plaatje in WALL-E staat helemaal los van de rest, maar zelfs met de uitleg van de maker kon ik nog niet achterhalen wat het wachtwoord precies zou moeten zijn.

Finish him! 55555255275323448753141 BAM!

De laatste opdracht moest je een code vinden op een plek. Maar ik kan niks vinden. Kan iemand miss bevestigen dat die code daar nog is?:$

Die code op die fysieke plek is weg.

Erg jammer ben er naar toe gegaan. Kon niks vinden XD
Dankje dat je op gereageerd hebt. Kan ik ook weer rustig slapen :P