Kun je met een encrypted en decrypted key de mk vinden?

S

Satslope

Beetje maffe vraag maar hij heeft wel een achtergrond.

Ik heb 8 byte superencrypted data waarvan ik vermoedelijk weet wat de decrypted data is.

Is het dan mogelijk het algo zodanig aan te passen dat je met deze 2 gegevens de key vindt waarover het ge-en of gedecrypt is? (beide richtingen moet kunnen)

Nu even het "waarom"

Ik krijg op 0004 een keyupdate binnen over mk00, maar ik heb de mk00 niet.

De grap is, dat de superencryptie de zaak maskeert. Maar ik weet dat het decrypten gaan met blokken van 8 bytes.

Welnu, aangezien de eerste 8 bytes meestal zijn: 10 02 10 02 80 00 00 00 (evt. de laatste 3 nullen de verschillende PBM's proberen) heb ik het antwoord dus.

Nu de key. Mocht die te vinden zijn, dan kan ik em checken door de hele string erover te gooien, dan moet je alle nano's kunnen zien.

Ik heb van alles zitten proberen maar de progjes kunnen wel over een MK enc/dec/ maar niet de mk zelf.

Dan maar de ene over de andere proberen te gooien maar dat levert 4 antwoorden op die niet kloppen. Lijkt me ook logisch omdat de MK op een andere manier in het algo zit dan de enc. en dec. key.

Wie is er goed wijs met deze materie en kan me verder helpen (of uit de droom helpen).

?????

 
sorry voor de typfoutjes, het moet natuurlijk 10 02 10 03 zijn...

 
Tjee.. zijn jullie nog aan het nadenken?

Ik denk dat het moet kunnen, want je kunt ook een backdoor key schrijven en dat gaat door de kaart 8*00 over "een" MK (meestal 00 op seca) te laten crypten, en vervolgens wordt met dat antwoord een hoop ge-XOR'd. Ik heb het ooit handmatig geprobeerd en toen lukte me dat XOR'en niet goed. secamosc doet het wel.

Het leuke is, dat je opgeeft dat je een eigen key op bijv 06 wilt, en je ook de waarde daarvan kunt opgeven (8*00 bijv.)

Wat ie dan in feite dus doet is via de MK op seca jouw key weer encrypten en hoe zou die dat anders moeten kunnen als door de gegevens (plain 00 en een gecrypyte key) de Mk zelf boven water te halen.

Kan dit ook ZONDER kaart, of wordt er nog een truc toegepast waarbij absoluut de kaart nodig is?

 
Phew... Nee ik ben er al niet meer over aan het nadenken in elk geval.:)

Maar weten doe ik het ook niet, volgens mij moet hier onze Seca specialist Woutje eens over nadenken.

Of misschien CP.

 
Als je de encrypte en decrypte key heb en het algo dan kun je de mk naar mijn idee bruteforcen, maar dat gaat wel lang duren.

 
Hmzzz zelfde probleem als indertijd met Eurocrypt. Ik herinner me een deense site waar ik ook nog eens mee heb geholpen een bepaald "bereik" te bruteforcen. Tegenwoordig met de supersnelle pc's zou je een 8 byte key in een weekje of zo moeten kunnen vinden.. Helaas is de mijne nog uit de tijd van Ben Hur ;)

Of het moet zijn dat er een stommigheid in het systeem zit zodat je het sneller kunt. Het zijn maar fransen die het bedacht hebben en die auto's rijden perfect maar er zit weleens wat los ;)

Wat er gebeurt als je het redelijk snel kunt is dat alle 00 en 01 keys die ze nu aan het uppen zijn op straat liggen, en DAT lijkt me toch wel erg sterk.

 
zelfs met de 7 byte eurocrypt keys duurde het te lang.

alleen hebben ze op een gegeven moment een proggie gemaakt waarbij je zelf in kon geven bij welke key dat het begon en ook zaten er in het proggie heel veel key waar van alleen de maker de ppua wist

had je een key gevonden had kon je die opsturen naar de maker van het proggie en dan kreeg je de bijbehoorende ppua.

door nu met een hele grote groep allemaal van af een andere key te beginnen schijnen ze er wel een paar gevonden te hebben.

groeten blokker

 
Yep.. zoiets heb ik ook nog eens ooit gedaan ;-)

Maar hier is meer aan de hand.

Je weet dat er op het 9e byte van achter in de string 82 moet staan plus dat je een gedeelte van de sig kent (overblijvende bytes zijn ongecodeerd). De sig berekening gaat over de hele string, maar je hoeft dus alleen maar te bruteforcen op de 1e 8 bytes uit strings waarvan de ongecodeerde sig. bytes kloppen :)

Heeft iemand hier (vast wel) "het" algo en kan die me dat eens sturen? Ik wil weleens weten hoe het nou precies in elkaar zit. (puur voor het inzicht).

 
Ik zal jullie snel uit de droom helpen:

8 byte key brute forcen.

8 byte = 64 bits => 2e64 = 18446744073709551616 keys.

Stel je hebt een pentium 1GHz dwz dat een clock cyclus 1ns.

Stel dat je binnen 1 clock cyclus een key kunt berekenen (Is natuurlijk onzin zijn er honderden)

dan duurt dat 18446744073709551616 x 1ns = 18446744073.71 seconden.

1 dag = 60 x 60 x 24 = 86400 sec.

Dus 18446744073.71 gedeeld door 86400 = 213503 dagen.

1 Jaar = 365 dagen dus een 8 byte key kun je in 213503 gedeeld door 365 = 585 Jaar

brute forcen.

 
Tegen de tijd dat je de key gevonden hebt is c+ al op een andere key overgegaan en kun je opnieuw beginnen :)

Missschien iets voor het nageslacht? ;)

 
Hmm.. beetje lang, dat wel.

Maar er is nog iets meer: de signatuur berekening.

De hele string is superencrypted. De hele string? Nee.. ergens in Gallie hebben ze nog een paar overgebleven bytes niet gecodeerd. (vrij naar Asterix)

En je kunt zien of het klopt aan het 9e laatste byte.. Staat daar 82 dan heb je kans op de hoofdprijs.. lijkt me.. Er zijn misschien meerdere mogelijk die die 82 opleveren maar dan reduceer je de data wel.

De vraag is alleen, kun je het zo maken dat je een aantal bytes van de signatuur "vast" zet, dus de relatie tussen de mk en de sig, die is mij volledig onbekend.

Ik vind dat ze vrij veel prijs geven juist door die superencryptie.

En natuurlijk is het uitlezen van een kaart makkelijker maar daar gaat het niet om ;)

 
Even ter verduidelijking:

Je logt een string waar c1 40 01 80 54 voor staat (Ident0004)

0x54 = 84 bytes

dat betekent 10* 8 bytes encrypted + 4 plain.

Je hoeft dan maar 4 bytes te bruteforcen tot er voor die 4 bytes (na de omrekening van het laatste blok van :cool: 82 staat.

Daarna kun je de test uitvoeren op het eerste blok met de veronderstelde decrypted data (afschakel commando's en PBM)

Het punt is dat je dan de signatuur van 00 00 00 00 xx xx xx xx tot FF FF FF FF xx xx xx xx moet laten lopen door de mk te wijzigen, en dat is de omgekeerde wereld. Kan dat wel?

 
Hmm foutje de sig is natuurlijk altijd gecodeerd, de helft is dubbel gecodeerd.. ik weet het niet meer.. gelukkig is het bijna weekeind ;)

 
Ik zal eens kijken. Ik heb zo wel eens een MK01 ontfutseld omdat iemand zo dom was om een log gecrypt en decrypt te sturen met 4 bytes van de MK01 en de PPUA, maar dit is iets andere koek.

Ga het boek er nog eens bij pakken met aantekeningen en de de 52 logs die ik heb met een aantal bekende MK00's

Superencrypt slaat op de keys die dubbel gecrypt zijn

MTB

 
Tsja, het is juist die superencryptie die de info "weggeeft"

Je weet wat de eerste 8 bytes moeten zijn, en van de signatuur zijn 2 bytes "plain" (maar dat is in principe een sig die nog door de kaart moet worden gedecodeerd) en 6 bytes supernecrypted.

Bij de fransen zenden ze 0x54 lengte uit, dan heb je 4 bytes "over"

Ik denk dat schumiNL het bij het juiste eind heeft voor wat betreft bruteforcen, tenzij met die signatuur nog wat mogelijk is.

Mijn hersens zijn in elk geval eventjes uitgekraakt. ;)

 



Hosting Fun

Advertenties

Terug
Bovenaan Onderaan