Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 52 reacties

Het blijkt kinderlijk eenvoudig om de Britse veiligheidsdienst GCHQ te laten denken een moeilijke code gekraakt te hebben en er te solliciteren. De dienst toont een code op een site om cryptografie-experts te vinden, maar de site blijkt te omzeilen.

De GCHQ begon op 3 november de site Can you crack it? met daarop een code en de vraag of de bezoeker deze kon kraken. De oplossing is een woord dat op de site ingevoerd moet worden om verder te komen. Het project loopt tot 12 december en is bedoeld om mensen te vinden die deskundig zijn op het gebied van encryptie. De GCHQ verspreidde de url van de site onder andere via sociale media.

Het blijkt echter helemaal niet nodig de code te kraken om verder te komen op de site en je aan te melden als mogelijke kandidaat. Een Britse blogger ontdekte dat een eenvoudige site:command-zoekactie op de url bij Google voldoende is om de soyoudidit-site te benaderen die de bezoeker voorgeschoteld krijgt als hij de code heeft gekraakt. Overigens lijkt het authentieke wachtwoord nog niet op internet opgedoken te zijn.

Het is niet de eerste keer dat de Britse geheime dienst op een ongebruikelijke manier personeel werft. In 2009 toonde de dienst bepaalde content in spellen als Call of Duty en Assassin's Creed via het Xbox Live-netwerk en twee jaar eerder publiceerde de GCHQ posters in Tom Clancy's Rainbow Six: Vegas en Splinter Cell Double Agent. Zelfs in 1941 gebruikte de Britse afluisterdienst al kruiswoordraadsels in kranten om geschikte codebrekers te vinden.

GCHQ so you did it

Moderatie-faq Wijzig weergave

Reacties (52)

[spoiler]
De code is x86-code. Hoe je daar achter komt? Intutie, gokken, algehele structuur, een opvallende 0xdeadbeef als little-endian zien, etc. Die x86-code voert een bewerking uit op data, maar doet een paar checks. Een van die checks mislukt (bevat de data 0x42424242?), want er mist data. Als je dan verder zoekt vind je die data in het png-bestand als base64. Als je e.e.a. aan elkaar plakt zal die x86-code de data decoderen tot je het wachtwoord krijgt.
[/spoiler]

[Reactie gewijzigd door wintermute. op 3 december 2011 11:37]

Hier vind je overigens hoe ze het gevonden hebben, wel knap!

http://volatile-minds.blo...-nope-i-tried-though.html
"Overigens lijkt het authentieke wachtwoord nog niet op internet opgedoken te zijn."
Ondertussen is op Pastebin het wachtwoord te vinden. Overigens wel slecht dat ze die "youdidit" niet even uit google hebben gehaald.

http://pastebin.com/pHikN5bs

Pr0t3ct!on#cyber_security@12*12.2011+ ;)
Het lijkt me dat degene die dit nu heeft ontdekt misschien toch wel geschikt is voor de veiligheidsdienst.
Ik neem aan dat het hen ook voornamelijk om het eindresultaat gaat en dat dat ene woord dan wat minder belangrijk is.
Iedereen die na deze blog hier terecht komt zal wel minder interessant voor ze wezen!
Ik vermoed dat het kraken van de code helemaal niet het doel is geweest. Wat ze willen is dat er genoeg mensen (liefst binnen de ICT) deze vacature zien. De echte test of iemand al dan niet geschikt is komt later wel.

Et voila: dankzij sites als tweakers.net hebben ze dat doel nu gratis bereikt. Extreem goed staaltje viral marketing, en dat voor een overheid, hulde :Y)
ja helaas moet in uk wonen
Overigens lijkt het authentieke wachtwoord nog niet op internet opgedoken te zijn.
http://gathering.tweakers...message/37252827#37252827

[Reactie gewijzigd door afraca op 3 december 2011 11:21]

Error geen toegang :')

Moet je voor de huiskamer ook een code kraken ofzo :?
Password: toor

[Reactie gewijzigd door johncheese002 op 3 december 2011 11:13]

Als het password 'toor' zou zijn hebben ze ook een paar andere beveiligings issues. Het voldoet aan geen enkel criteria voor strong passwords.

Gelukkig is dat het niet na een korte test op de can you crack it site.

Het juiste password is: Pr0t3ct!on#cyber_security@12*12.2011+ Dat is wel redelijk strong qua lengte al zitten er wel woorden en data in.

[Reactie gewijzigd door bitflusher op 3 december 2011 12:34]

De puzzel kraken is niet moeilijk, gewoon even buiten de doos denken!
Haha, dat is wel heel knullig.
Yes, you are hired!

Laat de sufferds maar lekker puzzelen, wij hebben mensen nodig die gewoon om de veiligheidspoortjes heen lopen!

Met je hoofd tegen de betonnen muur aan beuken? Nee, dan liever door de achterdeur naar binnen.

Dit soort slimheid moet beloond worden.

[Reactie gewijzigd door E_E_F op 3 december 2011 11:21]

zeker maar niet echt dik dan toch..
CYBER SECURITY SPECIALIST


Ref CYBER/SEC/SPEC/11 PHASE 2
Region South West
Location Cheltenham
Salary 25,446 (GC10) 31,152 (GC9)
Discipline Cyber
Grade GC10/GC9

Closing date for applications is 12 December 2011
Misschien was dit het idee ook wel, mede omdat het "echte antwoord" nog niet online staat weet ik niet of er wel zo'n code is. Want als iemand zo'n code kraakt wil die persoon doorgaans er toch wel erkenning voor hebben en gaat dan eventueel de publiciteit opzoeken.

Alle niet geschikte mensen gaan zitten puzzelen op een stukje code dat nergens op slaat, en de mensen die ze WEL willen hebben zijn handig genoeg om het via zo'n route op te lossen.
het is z80 assembly.. have fun ermee

ex de,hl
inc b
xor a
jp nz,$A3BF
add a,c
call pe,256
nop
nop
ld sp,35017
inc c
inc c
cp 193
ld (hl),l
ld sp,hl49201
cp d
B_CALL ($ADBE)
sbc a,2
inc b
inc c
nop
ret nc
pop bc
jp z, $8A08
inc e
inc c
adc a,d
inc a
inc b
adc a,b
inc e
inc b
adc a,b
inc a
inc c
cp 193
ld (hl),l
ret pe
jp (hl)
ld e,h
nop
nop
nop
adc a,c
ex (sp),hl
add a,c
jp $0004
nop
nop
ld e,h
ld e,b
dec a
ld b,c
ld b,c
ld b,c
ld b,c
ld (hl),l
ld b,e
ld e,b
dec a
ld b,d
ld b,d
ld b,d
ld b,d
ld (hl),l
dec sp
ld e,d
adc a,c
pop de
adc a,c
and 137
rst 18h
add hl,hl
rst 08h
di
and h
adc a,c
sbc a,137
pop de
adc a,c
rst 18h
add hl,hl
rst 08h
ld sp,12736
in a,($31)
jp nc,$C0FE
ld (bc),a
inc e
ld b,138
inc d
ld b,138
inc (hl)
ld e,136
inc (hl)
ld b,136
inc d
ld e,0
jp p,$F630
adc a,d
inc e
ld d,138
rla
jr nc, $DA
adc a,b
rla
ld b,a
ld c,c
ld (hl),l
sbc a,49
in a,($89)
ret c
cp 192
call 36992
sub b
ret pe
sbc a,l
rst 38h
rst 38h
rst 38h
ld b,c
ld b,c
ld b,c
ld b,c
Bijna goed het is x86 assembly, maar de twee nop's aan het einde
moeten vervangen worden door andere opcodes.

Het gebruikte algoritme lijkt RC4 te zijn

objdump -D -b binary -mi386 (raw bytes here)

start:
0: eb 04 jmp 0x6

might_be_data1:
2: af scas %es:(%edi),%eax
3: c2 bf a3 ret $0xa3bf

init:
6: 81 ec 00 01 00 00 sub $0x100,%esp
c: 31 c9 xor %ecx,%ecx
search_for_zero_byte:
e: 88 0c 0c mov %cl,(%esp,%ecx,1)
11: fe c1 inc %cl
13: 75 f9 jne 0xe

15: 31 c0 xor %eax,%eax
17: ba ef be ad de mov $0xdeadbeef,%edx

checksum_loop:
1c: 02 04 0c add (%esp,%ecx,1),%al
1f: 00 d0 add %dl,%al
21: c1 ca 08 ror $0x8,%edx ; first time through, %edx = $0xdeadbe
24: 8a 1c 0c mov (%esp,%ecx,1),%bl
27: 8a 3c 04 mov (%esp,%eax,1),%bh
2a: 88 1c 04 mov %bl,(%esp,%eax,1) ; swap byte values
2d: 88 3c 0c mov %bh,(%esp,%ecx,1) ; swap byte values
30: fe c1 inc %cl ; run the loop until %cl wraps to 0
32: 75 e8 jne 0x1c

34: e9 5c 00 00 00 jmp 0x95

sub_39:
39: 89 e3 mov %esp,%ebx
3b: 81 c3 04 00 00 00 add $0x4,%ebx
41: 5c pop %esp
42: 58 pop %eax
43: 3d 41 41 41 41 cmp $0x41414141,%eax
48: 75 43 jne 0x8d
4a: 58 pop %eax
4b: 3d 42 42 42 42 cmp $0x42424242,%eax
50: 75 3b jne 0x8d
52: 5a pop %edx
53: 89 d1 mov %edx,%ecx
55: 89 e6 mov %esp,%esi
57: 89 df mov %ebx,%edi
59: 29 cf sub %ecx,%edi
5b: f3 a4 rep movsb %ds:(%esi),%es:(%edi)
5d: 89 de mov %ebx,%esi
5f: 89 d1 mov %edx,%ecx
61: 89 df mov %ebx,%edi
63: 29 cf sub %ecx,%edi
65: 31 c0 xor %eax,%eax
67: 31 db xor %ebx,%ebx
69: 31 d2 xor %edx,%edx
6b: fe c0 inc %al
6d: 02 1c 06 add (%esi,%eax,1),%bl
70: 8a 14 06 mov (%esi,%eax,1),%dl
73: 8a 34 1e mov (%esi,%ebx,1),%dh
76: 88 34 06 mov %dh,(%esi,%eax,1)
79: 88 14 1e mov %dl,(%esi,%ebx,1)
7c: 00 f2 add %dh,%dl
7e: 30 f6 xor %dh,%dh
80: 8a 1c 16 mov (%esi,%edx,1),%bl
83: 8a 17 mov (%edi),%dl
85: 30 da xor %bl,%dl
87: 88 17 mov %dl,(%edi)
89: 47 inc %edi
8a: 49 dec %ecx
8b: 75 de jne 0x6b
8d: 31 db xor %ebx,%ebx
8f: 89 d8 mov %ebx,%eax
91: fe c0 inc %al
93: cd 80 int $0x80
95: 90 nop
96: 90 nop
97: e8 9d ff ff ff call 0x39
9c: 41 inc %ecx
9d: 41 inc %ecx
9e: 41 inc %ecx
9f: 41 inc %ecx
Je kunt elk stukje binaire code wel als Z80-code weergeven, omdat alle waarden in gebruik zijn als instructie, maar dit is onzincode, b.v. meerdere keren dezelfde kopieerinstructie "ld b,c" achter elkaar.
B_CALL ($ADBE)
Fout. Fout, fout, fout, FOUT.

Hoewel ik het leuk vind dat je tijdens je middelbare school-tijd al zo met programmeren bezig bent dat je Z80 assembly probeert, lijkt het erop dat je een paar details nog niet helemaal begrepen hebt. Er bestaat namelijk helemaal geen "B_CALL" instructie (voor de rest van de lezers: waarschijnlijk "base call", al zou ik het "system call" genoemd hebben). De opcode (tweede regel, meteen na de marge in het midden) 0xEF heet normaal gesproken "rst 28h" en is in feite hetzelfde als "call 28h". Het enige verschil is dat deze opcode n byte lang is (er zijn acht rst opcodes: 0xC7 = rst 00h, 0xCF = rst 08h, ..., 0xFF = rst 38h).
Het oorspronkelijke idee is dat je dit kunt gebruiken als interrupt vectors (in "interrupt mode 0" wordt na het triggeren van een interrupt een byte van de databus gelezen en uitgevoerd als opcode; aangezien normale calls altijd een 16-bit adres nodig hebben als bestemming kun je die niet gebruiken, dat past niet). Juist omdat deze opcodes slechts n byte lang zijn en een (zeer bescheiden) variatie in bestemming hebben is dit mogelijk. Het ene stuk hardware kan dus bijvoorbeeld interrupten met een "rst 08h" terwijl een andere "rst 10h" kan gebruiken.
Door de trucendoos die TI heeft opengetrokken om, aanzienlijk, meer dan 64 kB aan geheugen in een 16-bit adresruimte te krijgen is het overgrote deel van het geheugen op een TI 84 niet rechtstreeks adresseerbaar. Onder andere het OS zelfs is normaal gesproken niet "gemapped". Als de processor een rst 28h tegenkomt gebeurt het volgende:
  • De Z80 voert de rst 28h instructie gewoon uit (een rst hoeft niet pers van de databus te komen na een interrupt, gewoon in de code voorkomen mag ook, een mogelijke toepassing zou exception handling kunnen zijn). Oftewel: push het adres van de volgende instructie op de stack en vervang de instruction pointer door 0x0028.
  • De routine die hier staat leest de twee bytes n de rst (met behulp van de stack pointer, die hiernaar wijst) en slaat deze op.
  • In normale Z80-code is de byte na een rst meteen de volgende instructie, in "TI Z80" volgen twee data bytes (normaal gesproken in het bereik 0x4000 - 0x7FFF) en daarna pas de volgende instructie. Daarom wordt het return address (bovenste waarde op de stack) met twee opgehoogd.
  • Er wordt een speciaal stuk geheugen adresseerbaar gemaakt (op 0x4000 - 0x7FFF) met daarin een tabel. De zojuist opgezochte waarde wordt gebruikt om daarin een waarde op te zoeken. Effectief komt dit neer op een 24-bit adres.
  • Dit adres wordt eerst adresseerbaar gemaakt, daarna wordt het gecalled (en wordt de daadwerkelijke functie uitgevoerd). Zodra de routine klaar is wordt teruggekeerd naar het laatste stukje van de rst 28h code.
  • De oorspronkelijke layout van de address space wordt hersteld, waarna geRETurned wordt naar het adres bovenop de stack; twee bytes n de 0xEF opcode.
Omdat dit mechanisme veelvuldig wordt gebruikt (en om die twee extra bytes netjes in de code te voegen) heeft TI het hele B_CALL gebeuren bedacht, wat gewoon een macro is die door de assembler wordt omgezet. Die twee extra bytes zorgen er wel voor dat je TI 84 code niet door een gewone Z80 disassembler moet halen; die weet niks van deze truc en zal die extra bytes ook proberen te vertalen naar opcodes. Doordat Z80 opcodes verschillende lengtes kunnen hebben zit het er dik in dat je daarna het begin van de volgende opcode op de verkeerde plaats verwacht en het helemaal in het honderd loopt.
Bijkomend voordeel is dat TI in elke update van zijn OS alle routines op een andere plaats in het geheugen onder kan brengen door simpelweg de tabel te updaten.

Overigens, als je even naar het begin van de code kijkt:
ex de,hl
inc b
xor a
jp nz,$A3BF
add a,c
call pe,256
Waarom zou je registers de en hl omwisselen als eerste instructie, er staat nog niets in.
Een xor a (effectief ld a,0 en het bijwerken van het f (flags) register) meteen gevolgd door een jp nz, xxxx slaat nergens op: waarom testen op nz (not zero) als de voorgaande instructie de zero flag altijd reset. Ook is dit stukje code op geen stukken na lang genoeg om adres 0xA3BF te bevatten.
Op zich is er niks mis met call pe, xxxx, maar de pe (parity even) conditie is extreem zeldzaam in alle Z80-code die ik ooit gezien heb. (Oh en 0x0100 valt ook buiten dit stukje code; het zijn maar 160 bytes.)
Dus die eerste paar regels zouden je al moeten vertellen dat het nagenoeg uitgesloten is dat het hier Z80-code betreft.


ps. Zie net dat hieronder een paar keer op het voorkomen van 0xDEADBEEF wordt gewezen. De laatste drie bytes daarvan (in LSB) zijn precies die B_CALL 0xBEAD (rst 28h \ 0xBEAD). Zit ik speciaal naar die 0xEF te zoeken, kijk ik er nog overheen. :?

[Reactie gewijzigd door robvanwijk op 3 december 2011 16:44]

Ik snap niet waarom er in dit artikel staat dat de echte code nog niet online gevonden is? Ik had gisteren aan de hand van een artikel hierover op fok de code binnen 2 minuten op google gevonden...
het antwoord staat nog niet online, de code zelf wel
Niet voor niets zoeken ze nog goede programmeurs ;)
wel knap trouwens dat google het indexeerd, gezien de robots.txt instructie http://www.canyoucrackit.co.uk/robots.txt
De vraag is of dit niet bewust is gedaan ;)
Ik denk dat ze die snel daar neer hebben gezet, nu ze zagen dat de "soyoudidit.asp" geindexeerd werd. De robots.txt zelf is voor het laatst gewijzigd in November 2006, waardoor ze 'm waarschijnlijk ergens vandaan gekopieerd hebben, omdat die site nieuwer is dan dat.
De site zal een dezer wel uit de indexes verdwijnen. Echter, de site wijzigt niet heel vaak, waardoor de bots niet vaak terugkomen. En google cached de robots.txt ook nog, waardoor die maar eens per 24 uur opnieuw wordt gedownload.
doet me heel sterk denken aan een film die laatst nog op tv was waarin een jonge jongen met autisme (wat ik zelf ook heb ~PDD nos). een elke dag dezelfde woordzoeker gaat maken en dan op een gegeven moment het nummer belt wat eruit komt. Hij word daarna gezocht door die mensen omdat het een code was van een of anderre terrorist.

OT:

grappig dat ze zoiets doen, maar wat is de "opzet" van de puzzel. een logaritme zoeken ofzo?
Je bedoeld Mercury Rising, en de code was van de NSA die het kind daarna uit de weg willen ruimen.

ik verwacht dat je niets te vrezen heb met het oplossen van de puzzel hier.
Met Bruce Willis als ik me goed herinner. Hele goeie film, goeie actie.
code kan je al op internet vinden gewoon ff in google intypen:http://www.canyoucrackit.co.uk/ keyword

als het goed is hebben 24 mensen hem echt gekraakt.
En dan? Dan ga je op sollicitatie gesprek en dan val je toch meteen door de mand. Je weet immers het code woord nog niet. Je krijgt met deze website alleen een link naar de vacature..
https://apply.gchq-career...ssl.asp?newms=jj&id=35874

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True