Azazel
-
Items
296 -
Registratiedatum
-
Laatst bezocht
Inhoudstype
Profielen
Forums
Store
Berichten die geplaatst zijn door Azazel
-
-
Hallo satvrienden,
We hebben nu een aantal algoritmes behandeld, naar mijn mening de belangrijkste en vooral de basis van alle andere versleutelings systemen die er zijn of nog ontwikkeld zullen worden.
Nu is natuurlijk de vraag:
Welk systeem wordt gebruikt door Seca2?
Om dit te kunnen onderzoeken moeten we rekening houden met vele factoren en dan nog is het moeilijk om hier achter te komen gezien het feit dat vele algoritmen varianten zijn van..... en dus veel op elkaar lijken.
In een topic van mij op 19-09-2002 had ik al het een en ander daarover geschreven:
Citaat:Het algo van seca2 lijkt verdacht veel op die van seca1, vanuit gegaan wordt dat het hetzelfde is (lijkend op DES), maar de tabellen zijn verschillend.Vooral vanuit Italie wordt er gezegd dat seca2 gebruik maakt van een algoritme type RSA. Dit is iets waar we natuurlijk al die tijd rekenng mee hebben gehouden en een beetje al vanuit zijn gegaan...
De vraag is natuurlijk hoe onderzoeken we dat???
Dat doen we door middel van Criptanalysis .
Criptanalysis wordt gebruikt voor het ontdekken van encryptie methodes en decoderen van gecodeerde berichten. Het wordt ook gebruikt voor vergelijking van versleutelde data (data-veiligheid).
Enkele encryptie methodes zijn wat meer vatbaarder of gevoeliger voor 'cryptanalysys' aanvallen dan anderen. Daarom wordt er bij het ontwikkelen van nieuwe systemen of verfijning van bestaande systemen hiervoor al rekening gehouden.
Het bestuderen van cryptanalysis is ontzettend moeilijk mede doordat er eigenlijk geen standaard manuals of dergelijke van bestaat en je moet een behoorlijke wiskundige achtergrond hebben om hiermee aan de slag te gaan.
Voor de echt geinterreseerden is er een manual (in het engels) van Bruce Sneier over de zelfstudie van Cryptanalysis.
[color:"red"] Deze documenten kun je op de site van duwgati downloaden. Ga naar het Download Archief -> Seca-divers -> Seca2 en download de file CryptAnalysis.zip [/color]
Saludos!
-
Hallo satvrienden,
PGP (Pretty Good Privacy) is natuurlijk ook een van de systemen die wordt gebruikt voor versleuteling van diverse toepassingen.
De maker van PGP (Phil Zimmerman) heeft op basis van het RSA algoritme een beter en veiliger systeem willen ontwikkelen. Hieruit kunnen we concluderen dat PGP geen RSA is.
Wel maakt PGP gebruik van RSA; PGP kiest een willekeurig 128 bits sleutel, codeert het bericht daarmee en codeert vervolgens die sleutel met RSA.
Ook maakt PGP gebruik van IDEA (International Data Encryption Algorithm) algoritme. IDEA is een iets uitgebreidere versie van DES.
PGP genereert bij encryptie een unieke IDEA sleutel waarmee het bericht versleuteld wordt. Deze IDEA sleutel wordt daarna weer met RSA versleuteld.
Dit is een uiteraard een zeer korte uitleg betreffende de PGP versleuteling, voor meer info kun je bovenstaande link, aangegeven door Deman uitgebreidere informatie lezen.
Met dank aan Deman.
Saludos!
-
Hallo satvrienden,
We gaan verder met de symetrische systemen.
Symmetrische encryptie is encryptie waarbij 1 sleutel zowel gebruikt word bij het encrypteren als het decypteren. Dus de ontvanger en de zender hebben beiden dezelfde sleutel nodig. Persoon A stuurt dus iets met sleutel Z naar persoon B. Als persoon B sleutel Z heeft, dan kan hij aan de gegevens, anders niet. Als iemand het bericht kan onderscheppen, kan hij er niets mee doen, omdat hij sleutel Z niet heeft.
Er zijn vele verschillende symetrische systemen, o.a. Blokversleuteling, DES, 3DES, IDEA, CAST, Blowfish, Stream Cipher, RC4.
Veelgebruikte zijn o.a. DES en Blowfish.
RC4 is het systeem waarvan men vermoed dat seca2 gebruik maakt. Ik zal later dit systeem uitgebreid behandelen en de diverse tests en proeven die er inmiddels zijn gedaan om dit te kunnen bevestigen.
We beginnen eerst met de DES.
DES
DES is een vrij oude systeem en het is op basis van blokversleuteling, en is in de eerste instantie ontworpen voor de versleuteling en ontsleuteling van blokken van 64 bits.
De sleutel is ook 64 bits lang, maar er worden maar 56 bits werkelijk gebruikt. Voor de te onderscheiden bewerkingen worden meestal verschillende sleutels gebruikt die afgeleid zijn uit de hoofdsleutel. De source-code die ten aan de basis liggen aan de verschillende stappen bij DES, zijn geheim. De werking is alleen vrijgegeven in de vorm van weinig overzichtelijke tabellen.
Vanwege de korte sleutellengte van 56 bits zou DES makkelijk te kraken zijn, en inderdaad is dat gebeurd.
3DES
3DES, ook wel TripleDES genoemd, maakt gebruik van het originele DES algoritme. Maar in plaats van een 56 bits sleutel, worden twee of drie sleutels van elk 56 bits gebruikt. Bij DES-EEE3 worden de data drie keer versleuteld met drie verschillende sleutels (Encrypt-Encrypt-Encrypt). DES-EDE3 gebruikt ook drie verschillende sleutels, maar nu worden de data versleuteld met de eerste sleutel, ontsleuteld met de tweede (waar dan natuurlijk een enorme brei uit komt) en weer versleuteld met de derde (Encrypt-Decrypt-Encrypt). DES-EEE2 en DES-EDE2 doen hetzelfde als de hiervoorstaande, maar dan zijn de sleutels voor de eerste en derde operatie hetzelfde en worden dus twee sleutels gebruikt. In 3DES gaan we ervan uit dat er geen andere mogelijkheid is om DES te breken dan via brute force en dan is de sterkte dus afhankelijk van de sleutellengte. De formule EDE2 heeft als effect dat de uiteindelijke data versleuteld zijn met een sleutel van ongeveer 112 effectieve bits.
Als de key van 128 bits gevormd is door twee dezelfde keys van 64 bits (C1=C2), dan zal het systeem zich gedragen als een 'eenvoudige' DES.
Na een uitgebreide proces naar de zoektocht van de compabiliteit met DES, die overigens 3 jaar heeft geduurd, gebruikt 3DES 3 verschillende keys, waarmee dit systeem veel robuuster is, (men kan keys bemachtigen met lengtes van 192 bits (effectief 168 bits).
Bron -> ]http://www.htmlweb.net/seguridad/cripto/cripto_7.html
Blowfish
Dit systeem is op basis van een simpel systeem maar vrij bruikbaar; Het verdeeld een byte in drie blokken van bits op een zodanig wijze dat deze blokken zich weer verdelen in drie andere bytes.
De laatste drie bytes zijn de bytes van een blok die de data bevat waarbij men deze data kan modificeren of terugzetten zonder dat de informatie die deze data bevat 'beschadigd of aangetast' wordt.
Hieronder een voorbeeld:
We hebben een beeld van 100x100 pixels en 24 bits kleur. Dit betekend dat de map samengesteld is uit 10000 pixels die dus 30000 bytes bevat.
Elk van deze bytes correspondeerd met de drie hoofdkleuren; rood, groen en blauw.
1 pixel -> 3 bytes
1 byte van rood (0-255)
1 byte van groen (0-255)
1 byte van blauw (0-255)
totaal =24 bits informatie per pixel
De aplicatie zou als volgt moeten zijn: nemende een byte van de informatie die
we willen 'verbergen', verdelen we in 3 blokken, twee van 3 bits en een van 2 bits (totaal 8 bits). Vervolgens worden deze groepen samengevoegd bij elk van de bytes die de pixel maakt.
Als eindresultaat van deze 'operatie' zouden we een foto verkrijgen van 24 bits
maar dan een 67% van het origineel. We kunnen met ons blote oog het verschil tussen de origineel niet waarnemen.
Verder zijn natuurlijk meerdere toepassingen mogelijk via dit systeem.
Volgende gedeelte de RC4 systeem.
Saludos!
-
Hallo satvrienden,
Een van de vele projecten waarmee men nu bezig is, is natuurlijk de zoektocht naar het algoritme, die nu gebruikt wordt voor seca2.
Er zijn in het verleden diverse serieuze pogingen gedaan om succes te boeken m.b.t. de algoritme, maar allemaal tevergeefs.
Opnieuw wordt er een serieuze poging gedaan naar de zoektocht van de algoritme, en het lijkt erop dat er positieve vorderingen gemaakt zijn.
(Later meer hierover).
Om de zoektocht te beginnen is het natuurlijk van belang om te weten wat de algoritme eigenlijk is en wat hij doet...
De meesten van ons zullen dit waarschijnlijk al weten, maar toch wil ik hier een beknopte uitleg geven:
Natuurlijk is deze informatie op vele site's te lezen, maar het is toch handig als we met de basis beginnen en het hier op het forum geplaatst wordt.
(dat scheelt weer wat zoekwerk...) <img src="/ubbthreads/images/graemlins/wink.gif" alt="" /> <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />
-------------------------------------------------------------------------------
Symmetrische en asymmetrische systemen
- Bij symmetrische systemen wordt slechts een sleutel gebruikt.
- Bij asymmetrische systemen een sleutelpaar.
Asymmetrische systeem
Bij asymmetrische systemen wordt door beide partijen een sleutel afgesproken waarmee het bericht zowel versleuteld als ontsleuteld kan worden. Een van de nadelen van dit systeem is dat je dan eerst een veilig kanaal moet vinden om die sleutel af te spreken, en dat zou moeilijkheden kunnen opleveren.
Op zich heeft dit systeem twee funkties:
- Het versleutelen van de data
- Verificatie van de indentiteit van de 'zender'.
Dit systeem is op basis van de 'trapdoor funkties'. Elke deelnemer heeft dan twee sleutels: de openbare sleutel en de geheime sleutel (of privé sleutel).
De geheime sleutel mag dus niet bekend worden, maar de openbare sleutel kan verspreid worden naar iedereen die de eigenaar van de openbare sleutel een bericht wil sturen. Iemand die met een openbare sleutel een bericht codeert, kan niet met dezelfde openbare sleutel het bericht decoderen, dus het is geen ramp als de openbare sleutel bij iemand terechtkomt die er minder goede bedoelingen mee zou hebben.
Een ander nadeel van de asymmetrische cryptografie is dat het decoderen wel 100 tot 1000 keer langer duurt dan symmetrische cryptografie.
Daarom wordt asymmetrische cryptografie vaak alleen gebruikt om een symmetrische sleutel door te geven.
Voorbeeld: A en B willen veilig kunnen communiceren, maar asymmetrische cryptografie duurt hen te lang. Daarom willen ze symmetrische cryptografie nemen, maar het risico is te groot dat bij het uitwisselen van de geheime symmetrische sleutel iemand die sleutel te zien krijgt, en zo dus alle berichten die verstuurd worden kan decoderen. Daarom nemen A en B eerst allebei een asymmetrische geheime en openbare sleutel. De openbare sleutels maken ze aan elkaar bekend, en wisselen met het asymmetrische systeem de symmetrische geheime sleutel uit. In het vervolg gebruiken ze alleen nog maar het symmetrische systeem om hun berichten te (de)coderen. Een bericht dat asymmetrisch wordt gecodeerd, wordt precies hetzelfde gecodeerd als een symmetrisch bericht, alleen zijn de sleutels verschillend. Dus: eerst het bericht omzetten in een reeks cijfers, daarna in blokjes opdelen, daarna coderen met de openbare sleutel van de ontvanger en versturen. De ontvanger decodeert hem met zijn geheime sleutel, voegt de blokjes bij elkaar en zet de cijferreeks om in letters.
Twee belangrijke assymetrische systemen zijn o.a. de RSA en ECC.
RSA
Met dit systeem kan men een geheime sleutel over een 'onveilig' kanaal sturen zonder dat er van te voren via een veilig kanaal andere geheimen afgesproken moeten worden. Met die afgesproken sleutel kun je vervolgens data versleutelen.
De uitwisseling van vertrouwelijke gegevens is wel kwetsbaar. Daarom werd in 1992 het Station-to-Station (STS) protocol ontwikkeld dat digitale handtekeningen en public-keycertificaten toevoegt aan het D/H algoritme.
RSA is een public-key cryptosysteem dat zowel versleuteling als digitale handtekeningen en is gebaseerd op het wiskundige gegeven dat het makkelijk is om twee grote priemgetallen met elkaar te vermenigvuldigen, maar dat het uitermate moeilijk is om uit het product de twee priemgetallen weer te onttrekken, dus:
- n=a*b
Vervolgens wordt een getal 'e' bepaald zodanig dat:
3 < e < (a-1)(b-1)
en de grootste deler van 'e' en (a-1)(b-1) is 1, ofwel 'e' is relatief priem tov (a-1)(b-1).
Mbv dit getal e wordt getal d berekend zodanig dat:
d*e=1 mod (a-1)(b-1)
'd' is dus de inverse van 'e'. De openbare sleutel bestaat nu uit het getallenpaar (e,n). De grootheden a, b en d zijn geheim. Het maken van de versleutelde code gaat als volgt. De originele boodschap wordt opgedeeld in blokken B en:
Code=B^e mod n
De werking van het systeem berust op het feit dat 'e' weliswaar gemakkelijk uit 'd' berekend kan worden, maar niet andersom. Het is bijna ondoenlijk om 'd' op basis van alleen de openbare sleutel (e,n) te berekenen. Voor de berekening van 'd' moeten ook 'a' en 'b' bekend zijn.
(Bron -> ]http://www.argo.es/~jcea/artic/hispasec93.htm)
ECC
Bij ECC ofterwijl Elliptic Curve Cryptosystem, worden de sleutelparen gegenereerd door de priemgetallen-truc. Dit heeft weinig extra voordelen ten opzichte van RSA. Maar ECC heeft een ander mogelijkheid, nl. dat het gebruik maakt van discrete logaritmen in combinatie met een elliptische curve. Voordeel hiervan is dat de sleutellengte korter kan zijn dan bij normale asymmetrische systemen, terwijl de sleutel toch even sterk is.
Om een goede keuze te kunnen maken voor de sleutellengte in functie van het gewenste veiligheidsniveau, zijn gegevens nodig over de kost om een bepaalde sleutellengte te kraken. Die kost kan geschat worden, maar enkel op een nauwkeurige manier als het ontwerp van het kraaksysteem vrij ver wordt doorgevoerd. Daarbij is het geweten dat voor ECC's het gebruik van speciaal ontworpen hardwarecomponenten aangewezen is, dit in tegenstelling tot RSA.
Volgende deel Symetrische systemen.
Saludos!
- n=a*b
-
Hallo satvrienden,
@Littlesat,
Je vraag is zeker niet stom..... Maar met alle respect is het voor de meesten mischien toch een beetje te technisch en blijft het na mijn uitleg nog te technisch en worden velen er niet veel wijzer van. <img src="/ubbthreads/images/graemlins/confused.gif" alt="" /> <img src="/ubbthreads/images/graemlins/confused.gif" alt="" />
Maar ik zal mijn best doen..... <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" /> <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />
Om bij het begin te beginnen, is deze ontdekking / studie, begin maart gedaan door de in de satwereld zeer gerespecteerde 89mark89.
Door zijn studie, die publiekelijk werd midden mei, zijn er veel italiaanse, spaanse en franse teams gaan samenwerken en experimenteren.
Ook wij hebben deelgenomen aan deze experimenten, maar helaas hebben wij er niets positiefs uit kunnen halen en snel genoeg de samenwerking een beetje verbroken. Onze meningen zijn hierover verdeeld.
En met alle respect voor 89mark89 hebben wij zijn studie een beetje links laten liggen..... (moet nog blijken of het wel verstandig is geweest).
De team die door deze methode positieve en verre vorderingen (zoals zij zeggen) heeft verkregen is het spaanse GT Team. Helaas laten ze vooralsnog niet veel los; je kunt er een en ander over lezen in het forum TopDigital .
Als eerste moet men de term 'ppv spot' begrijpen; deze bytes te lokaliseren, verscheidene manieren waardes varieren, etc.....
Om het wat beter te begrijpen citeer ik een stukje tekst van de zeer beroemde rom6 van homealone:
- ;-------------------------------------------------------------------------------
; Ins 38 : data request and PPV event recording request
; C1 38 xx yy 1A 16 (d1) 2A (d2 d3) 2B (d4 d5) 86 (8 bytes) 82 (signature)
; Superencryption may be active
; on exit : d1=ext[126] d2=ext[128] d3=ext[129] d4=ext[12a] d5=ext[12b]
; 82-89h=(8 bytes for security)
; d1 d2 d3 as in ins 34 d4-d5 : PPV event spot
;-------------------------------------------------------------------------------
;-------------------------------------------------------------------------------
; Ins 36 : output requested data and PPV event recording
; P1 : bits 7,6,5 must be 0,0,1 - provider must be the same of ins 38
; P2 : key for signature and for superencryption (if bit 7 is set)
; data from ins 38 : d1=ext[126] d2=ext[128] d3=ext[129] d4=ext[12a] d5=ext[12b]
; 82-89h = a1..a8
; d1 d2 d3 example
; 0 0 0 Provider package bitmap C1 36 xx yy 1D && 83 data 04 $$
; 1 0 0 Provider PPV credits C1 36 xx yy 1D && 84 data 04 $$
; 3 x x Provider PPV event record C1 36 xx yy 20 && B1 data 04 $$
; 4 0 x Seca record C1 36 20 yy 20 && B2 data 04 $$
; 6 x x Given record (number) C1 36 xx yy 25 && D2 data 03 $$
; where:
; && = 86 a1..a8 if no probs or FF a1..a8 if key problems
; $$ = 82 (signature) if no probs or nothing if key problems
;------------------------------------------------------------------------------
Na het einde van RMOSC heeft men geprobeerd andere methodes te vinden, betreffende mosc van de v7 kaarten.
De methode Twin Keys wordt dan ook de QDMOSC (Quasi Deterministic Mosc)genoemd.
Om het ff heel simpel te zeggen is het doel van de QDMOSC om met de ppv-spot te 'spelen'.
Gebruikmakend van de methode 'gecontroleerde schrift met de 'lange 7x (>4 blokken) het schrijven van twee indentieke keys, een ter controle en een operationeel. Het volstaat met het 'spelen' van de user spot van de events en het verkrijgen van een paar 90 xKg in een geval en een 90 xKo in ander geval, vervolgd door dezelfde 8 bytes a0...a7.
Nu hebben we twee keys met dezelfde waarde, maar die we niet kennen.
Het enige wat we weten is dus dat de a0...a7 overeenstemd met de masking+cryptie van de gecreeerde key.
Gebruikmakend van eerder vermelde methode in deze topic (zelfstudie) creeren we een C1 40, in werking tredend met de key Kg, die een nano 90 K' b0...b7 moet bevatten waardoor we de key K' kunnen creeren.
Vervolgens creeren we een 3c met key Ko=Kg, met een nano 04 en een nano D1
b0...b7 x0...x7. Nadat we de 3c verstuurd hebben, zal de respons die de 3a (eerste DW) ons terug geeft een waarde verkrijgen van de key K' in vrij (decrypted).
Zoals 89mark89 zelf zegt kan men bij het creeren van een K'=0F, controleren of de block cipher waar men nu gebruik van maakt dezelfde is als die van SECA1 en of deze dezelfde tabellen gebruikt.
Ik persoonlijk heb hier mijn bedenkingen over....
Mijn theorie is dat je namelijk een record Bx en de user spot 09-0A moet modificeren. En de user spot modificeren...... is volgens mij nog niet mogelijk.
Al denkt Controlbyte daar wel anders over:
- ; PPV EVENT RECORD
; 00 type (0=unused/1=normal use/2=special use)
; 01-02 event id
; 03 diffusion number
; 04 number of visions
; 05-06 event cost
; 07-08 date
; 09-0A user spot
; 0B Bx (x=provider)
- code:-----------------------------------------------------------------
C1 38 P1 P2 Len 16 (d1) 2A (d2 d3) 2B (d4 d5) 86 (8 bytes)....
------------------------------------------------------------------------------
Hij zegt dat je de user spot kunt modificeren middels een 'call' van het paar 38/36, met de d1=3, na het verzoek van de 36 retourneerd de records met de Event Id -> d2 d3 verandering van user spot d4 d5???
------------------------------------------------------------------------
Al met al krijgen ze met deze methode meer inzicht in het SE proces van seca2.
Helaas kan ik er niet dieper op ingaan daar ik de vervolg-studies van eerder genoemde collega's en teams 'nog' niet weet....
Op dit punt ben ik een beetje de weg kwijt, maar wilde jullie toch informeren over de mogelijkheden van de Twin Keys.
Ik wil zeer zeker niet negatief zijn over 89mark89 studie, die ik ontzettend respecteer vanwege al zijn werk en 'ontdekkingen' en ons deze steeds weer mee laat genieten, maar nogmaals onze meningen verschillen:
Volgens mijn vizie zijn er nog teveel vraagtekens en moeilijkheden die eerst opgelost zullen moeten worden om te kunnen vorderen in dit proces.
Kijk maar wanneer men een 'dergelijk' nano met 'welk' parameters creerd, in werkelijkheid deze op een zeer indirekte manier gebeurd.
En wat te denken van de creatie van de preview registers Ax met verandering van de counter of de creatie van registers ppv met 'korte' ins 5x, controlerend dat de 'lage' nibble van de tweede byte niet een 0 of 1 is waardoor de mk0 of de mk1 verloren kunnen gaan!
En wat ik eerder al zei verandering van de registers Bx van de user spot.
Als enige positieve wat ik (vooralsnog) aan deze studie heb overgehouden, en laten we hopen dat ik me vergis, is het feit dat we de werking van het 'blinde' mechanisme van de DWi in de 3c hebben leren kennen.
Al met al hoop ik dat deze uitleg wat beter begrepen wordt en ik zal zonder enige twijfel de studie van GT Team volgen en deze hier posten.
Saludos!
Bij deze wil ik ook nog even mijn zeer gewaardeerde vriend en met grote respect Toxic[Q] bedanken voor al het goede werk dat hij hier verricht, en dat wij elke keer weer dankbaar gebruik mogen maken van dit geweldige board! En natuurlijk niet te vergeten al de moderators die, en laten we dat niet vergeten, ook veel tijd en energie in het board steken en zeer zeker ook mijn respect krijgen!!
Thanks again!!
En voor allen, sorry voor mijn offtopic'je..... <img src="/ubbthreads/images/graemlins/wink.gif" alt="" /> <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />
Saludos!
- ;-------------------------------------------------------------------------------
-
Hallo satvrienden,
Zoals in vorige topic reeds vermeld gaan we nu verder met het fenomeen 'Twin Keys'.
Deze studie is gedaan door 89mark89 vertaald door Azazel .
- Seca 1
Nanocommando 90
C1 40 P1 P2 LEN 90 ki K1 K2 K3 K4 K5 K6 K7 K8 82 S1 S2 S3 S4 S5 S6 S7 S8
Commando voor tussenvoeging van een MK of OK, voor de in P1 aangegeven provider, zijnde ki = Key Index, K1...K8 = de key die ingevoegd wordt, maar let op: de key wordt niet vrij aangegeven maar wordt gecodeerd met de key aangegeven in P2.
We gaan een C1 40 'construeren' waarbij de inhoud de data is van een lange respons type 0x79:
-86 xx xx xx xx xx xx xx yy
-D2 00 21 00 43 7C FF 89 00 00 FF FF 00 00 B3 00 00
-D2 00 22 5E FF FF FF FF FF FF FF FF 69 00 83 00 00
-D2 00 23 B1 00 B3 D9 FF 00 00 12 4F 33 67 E3 00 00
-D2 00 24 00 81 DD FF 77 00 00 FF FF 00 00 B3 00 00
-D2 00 25 00 4E 08 FF 0C 00 00 FF FF 00 00 B3 00 00
-D2 00 26 04 FF FF FF FF FF FF FF FF 04 00 83 00 00 03
We modificeren de ppv-spot van het register Bx aanwezig in de 0021 waarbij deze de waarde aanneemt van de “90 ki” en de bytes van de nano86 specificeerd waardoor de parsing daalt aan de “90” (het is hierbij ook van belang dat de waarde “xx” gemodificeerd moet worden op dusdanig manier dat we de inhoud encrypted verkrijgen met een 'hoge' nibble (P3) = 7 en 'lage' nibble (P4) = 1 og betergezegd 9).
Van de andere kant heb ik de ppv-spot van de register Bx gewijzigd, aanwezig bij de 0024. Dit vanwege de parsing:
-86 xx xx xx xx xx xx xx(C0)
-D2 00 21 00 43 7C FF 89 00 00 FF FF(90)KI B3 00 00
-D2 00 22 5E FF(FF)FF FF FF FF FF FF 69 00 83 00 00
-D2 00 23 B1 00 B3 D9 FF 00 00 12 4F 33 67 E3 00 00
-D2 00 24 00(81)DD FF 77 00 00 FF FF 1F(37)B3 00 00
(D2)00 25 00 4E 08 FF 0C 00 00 FF FF 00 00 B3 00 00
(D2)00 26 04 FF FF FF FF FF FF FF FF 04 00 83 00 00(03)
Tussen haakjes zijn de 'nanocommandos' aangegeven die zullen worden 'geparst'.
De laatste nanocommando (03) aan het einde van de totale inhoud, neemt
onzichtbare waardes aan.
Al met al is het een parsing zonder risico's (wordt beschermd door Nano 10).
Verandering van de configuratie van de register kunnen we een risicovolle parsing + of - verkrijgen.
Ik heb drie ppv-spot voorbereid om in de register 0021 toe te voegen:
-a- 90 22
-b- 90 1D
-c- 90 0F
Het is dus duidelijk mijn bedoeling om drie keys..... te schrijven, waarbij
enige commando de form aanneemt van....
C1 40 23 9x D3 7y y1 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 82 s0 s1 s2 s3 s4 s5 s6 s7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 14
Ik leg de nadruk op parameter “P2” (selectie van key en hash tabel), omdat
deze een belangrijke rol speelt.
We beginnen met de eerste ppv-spot
-86 xx xx xx xx xx xx xx(C0)
-D2 00 21 00 43 7C FF 89 00 00 FF FF(90)22 B3 00 00
-D2 00 22 5E FF(FF)FF FF FF FF FF FF 69 00 83 00 00
-D2 00 23 B1 00 B3 D9 FF 00 00 12 4F 33 67 E3 00 00
-D2 00 24 00(81)DD FF 77 00 00 FF FF 1F(37)B3 00 00
(D2)00 25 00 4E 08 FF 0C 00 00 FF FF 00 00 B3 00 00
(D2)00 26 04 FF FF FF FF FF FF FF FF 04 00 83 00 00(03)
De geconstrueerde C1 40 gesplits door deze data, zal een key creeren met
index 22 van onbekende waarde. Ervanuitgaande dat de kaart een MK01 bevat en deze gebruiken om de commando te versturen (in mijn geval stel ik P2 aan waarde 91 bij).
We nemen nu de tweede ppv-spot....
-86 xx xx xx xx xx xx xx(C0)
-D2 00 21 00 43 7C FF 89 00 00 FF FF(90)1D B3 00 00
-D2 00 22 5E FF(FF)FF FF FF FF FF FF 69 00 83 00 00
-D2 00 23 B1 00 B3 D9 FF 00 00 12 4F 33 67 E3 00 00
-D2 00 24 00(81)DD FF 77 00 00 FF FF 1F(37)B3 00 00
(D2)00 25 00 4E 08 FF 0C 00 00 FF FF 00 00 B3 00 00
(D2)00 26 04 FF FF FF FF FF FF FF FF 04 00 83 00 00(03)
De geconstrueerde C1 40 gesplits daaor deze data, zal nu een operationele key creeren met index 1D.
Als men voor deze tweede commando dezelfde parameter 'P2' gebruikt als bij de
eerste (P2=91) dan heeft men een key gecreeerd met dezelfde waarde als de key die voorheen werd gecreeerd (ondanks een andere index).
Dit kan men verifieren door een C1 38 te versturen en voor de succesvolle C1 36 een andere key te gebruiken: je zult dan zien dat deze dezelfde 'crypty' en 'firm' bevat.
We noemen deze twee keys: [color:"red"] TWIN KEYS [/color]
We gaan naar de derde ppv-spot....
-86 xx xx xx xx xx xx xx(C0)
-D2 00 21 00 43 7C FF 89 00 00 FF FF(90)0F B3 00 00
-D2 00 22 5E FF(FF)FF FF FF FF FF FF 69 00 83 00 00
-D2 00 23 B1 00 B3 D9 FF 00 00 12 4F 33 67 E3 00 00
-D2 00 24 00(81)DD FF 77 00 00 FF FF 1F(37)B3 00 00
(D2)00 25 00 4E 08 FF 0C 00 00 FF FF 00 00 B3 00 00
(D2)00 26 04 FF FF FF FF FF FF FF FF 04 00 83 00 00(03)
De geconstrueerde C1 40 gesplits door deze data, zal nu een key creeren met index 0F.
De constructie van deze commando zal GEEN gebruik maken van key 01, zoals wel in
eerder genoemde gevallen.
Maar wel in mijn geval een MK02, dus: 'P2' = 92.
Nu gaan we op zoek naar een ppv-spot (voor register 0021) volgens wijze: 'XX D1'.
Voorbeeld:
- 68 D1
Mijn bedoeling is om een C1 3C te construeren en deze te 'parsen' totdat D1....
-86 xx xx xx xx xx xx xx yy
-D2 00 21 00 43 7C FF 89 00 00 FF FF 68(D1)B3 00 00
-D2 00 22 5E FF FF FF FF FF FF FF FF 69(00|83)00 00
-D2 00 23 B1 00 B3(D9)FF 00 00 12 4F 33 67 E3 00 00
-D2 00 24 00 81 DD(FF)77 00 00 FF FF 1F 37 B3 00 00
-D2 00 25 00 4E 08 FF 0C 00 00 FF FF 00 00 B3 00 00
-D2 00 26 04 FF(FF)FF FF FF FF FF FF 04 00 83 00 00 03
De laatste (FF) in register 0026, is geen echte FF.
Voor de constructie van deze INS moet ik dezelfde bijstellingen gebruiken zoals
ik gebruik heb bij de test van de CW/DW.... Ik moet het 'parsen' tot D1 maar...
HET IS HELAAS NIET GENOEG!!!
We missen Nano 04
Het nieuwe hierbij is dat bij de C1 3C tenminste 8 bytes 'vrij' (decrypted) zijn, en in dit geval hier in vet aangegeven :
C1 3C 23 9x D3 7y y1 xx xx xx xx xx xx a0 a1 a2 a3 a4 a5 a6 a7 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 82 s0 s1 s2 s3 s4 s5 s6 s7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7B
Al met al is de commando als volgt:
-86 xx xx xx xx xx xx xx a0
-a1 a2 a3 a4 a5 a6 a7 89 00 00 FF FF 68(D1)B3 00 00
-D2 00 22 5E FF FF FF FF FF FF FF FF 69(00|83)00 00
-D2 00 23 B1 00 B3(D9)FF 00 00 12 4F 33 67 E3 00 00
-D2 00 24 00 81 DD(FF)77 00 00 FF FF 1F 37 B3 00 00
-D2 00 25 00 4E 08 FF 0C 00 00 FF FF 00 00 B3 00 00
-D2 00 26 04 FF(FF)FF FF FF FF FF FF 04 00 83 00 00 03
Ik heb nu een INS 3C geconstrueerd waarbij de achtste a0...a7 = 04 CF A0 55 40 D3 ED 32 die dus een nano 04 is gevolgd door een Nano Cx (de rest van de bytes doen er niet toe; mogen verscheidenen zijn).
-86 xx xx xx xx xx xx xx(04)
(CF)A0 55 40 D3 ED 32 89 00 00 FF FF 68(D1)B3 00 00
-D2 00 22 5E FF FF FF FF FF FF FF FF 69(00|83)00 00
-D2 00 23 B1 00 B3(D9)FF 00 00 12 4F 33 67 E3 00 00
-D2 00 24 00 81 DD(FF)77 00 00 FF FF 1F 37 B3 00 00
-D2 00 25 00 4E 08 FF 0C 00 00 FF FF 00 00 B3 00 00
-D2 00 26 04 FF(FF)FF FF FF FF FF FF 04 00 83 00 00 03
De commando maakt gebruik van 'P2' de waarde 9D, gebruikmakend van operationele TWIN key 0D...
C1 3C 23 9D D3 73 71 EC 46 5D F3 D0 1D 04 CF A0 55 40 D3 ED 32 0E 87 02 41 B4 D9 17 64 35 47 F4 A3 79 00 85 80 52 38 52 FF 4D 6B 90 10 CC A4 88 5E 3D 0B ED E4 68 9B 3E 37 40 44 11 25 17 85 6D C8 62 0F 65 4C AB A6 73 88 12 98 CB E9 AB 3A 4C 46 FA 04 A5 30 78 8E FD AB 82 CA 0E 3C 0C 92 A3 A2 B2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7B
Vervolgens verstuur ik de C1 3A en verkrijg twee DW....
Wat is de eerste DW ????
Control Byte geeft hiervoor een goede definitie:
quote:
--------------------------------------------------------------------------------
Wat is de eerste DW ????
--------------------------------------------------------------------------------
De unmask van (B3 00 00 D2 00 22 5E FF ) decrypted met de key 1D = 91 :
Key 0F vrij (encrypted).
Saludos!
- Seca 1
-
@Ome Merde,
<img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" /> <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />
-
Klopt, pagina is verwijderd???
Probeer deze maar:
http://www.microsoft.com/technet/treeview/?url=/technet/security/bulletin/MS03-026.asp
Saludos!
-
Hallo satvrienden,
Het gaat hierom de W32/blaster worm.
Momenteel is op het internet een uitbraak aan de gang onder de naam W32/Blast of ook onder de naam W32/Lovesan.A
Zie het Microsoft Bulletin voor meer informatie:
http://www.microsoft.com/technet/tr...in/MS03-026.asp
Je kunt daar ook de patch downloaden en het probleem verhelpen.
Op deze pagina is ook nog een extra tool ontwikkeld om de worm te verwijderen:
http://securityresponse.symantec.co...moval.tool.html
http://securityresponse.symantec.co...er/FixBlast.exe
Saludos!
-
Bij deze ook gefeleciteerd!!
Saludos!
-
@Impuls,
Je kunt dit alleen testen als je ins hebt van activering / deactivering:
C1 40 01 B1 5C 10 01..
C1 40 11 B1 5C 10 01..
C1 40 01 B0 5C 10 01..
C1 40 01 B0 61 10 01..
C1 40 01 B0 63 10 01..
Voor het vervolg van de bug, verwijs ik je graag naar topic zelfstudie.
Voorb.:
- ................ zien bij de optie Log Gegevens zijn belangrijk voor het verdere proces van de studie. We bekijken de laatste regel van deze lijst en daar kun zal het volgende te zien zijn:
N.: XX Aantal ins 'captured'
CLA: C1
INS: 40
P1: 01
P2: B1 / B0
LEN: 5C / 61
DATA: 10 01 XX….
Deze gegevens geven ons aan dat het ons gelukt is om ins. van actualisatie / activering / deactivering van onze v7 kaart te verkrijgen.
Vervolgens drukken we in het menu 'Log Gegevens' op de optie exporteerd log naar bestand,(ikoontje met de krat met export erop), en vullen de gegevens in die door de prog worden aangegeven.
In de map waar je de file (capture.hex) had bewaard, is een bestand bijgeschreven type tekst (extensie .TXT) met dezelfde naam als die van de files.
We hebben nu de ins die we nodig hebben om te starten met de studie naar de RESET BUG en het proces van de 38/36 van onze kaarten.............
Saludos,
'Azazel miembro del equipo RAIDEN, la resistencia.'
- ................ zien bij de optie Log Gegevens zijn belangrijk voor het verdere proces van de studie. We bekijken de laatste regel van deze lijst en daar kun zal het volgende te zien zijn:
-
Hallo satvrienden,
Ik sluit me volledig aan bij prutsie....
Het is raadzaam om zo veel mogelijk te loggen en deze te bewaren, dat kan in de toekomst zeker goed van pas komen.
Wat belangrijk is om te weten is of de bug 38/36 aanwezig is op de v7.3.
Omdat de versie van de kaart [color:"red"] v7.3 [/color] is, kan het zijn dat de pseudonano 1x voor de nano F0 is geplaatst, dit om de mogelijkheid van de bug38/36 uit te sluiten.
Dit is destijds ook met de franse kaarten (v7.1) gedaan.
Vooralsnog is het zeer verstandig zo veel mogelijk INS 40 (van activering) te loggen die verstuurd worden naar je kaart, voor het geval dat er 'betere tijden' aanbreken. <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" /> <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />
Deze zullen zeer zeker nuttig zijn, alsook de maandelijkse actualisaties.
Het is altijd raadzaam om een goed arsenaal aan INS in bezit te hebben!!
Saludos!
'Azazel miembro del equipo RAIDEN, la resistencia.'
-
Beste Avalon... Mijn oprechte deelneming voor het verlies van je moeder.
Woorden schieten te kort... maar toch wil ik je dit even zeggen:
Een been ben ik verloren,
een been hangt er aan.
Ik moet het nu gaan zoeken,
anders kan ik niet meer gaan.
Er kwamen vele benen.
Een paste er, god zij dank.
Die mocht ik gelukkig lenen.
Nu loop ik alleen nog mank.
Het werd me steeds aangeboden,
als ik niet meer goed kon staan.
Maar na een periode,
zal alles beter gaan.
Ik wil het been nog voorstellen.
Echte vriendschap is de naam.
Die kunnen we altijd bellen.
Als we weer wat wankel staan.
Weet dat we er altijd voor je zullen zijn ......
-
Grrrrrrrrrrr...... <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" /> <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />
Proficiat allen!!!
Zeer zeker een goed partij van Verkerk.
Saludos!
'Azazel miembro del equipo RAIDEN, la resistencia.'
-
FASE 9
------------------------------------------------------------------------
Andere types INS.
Gezien de 'contra-offensieven' die CSD heeft gedaan, z ben ik genoodzaakt om de studie via een andere weg te bewandelen i.p.v. de weg die ik in de eerste instantie in gedachte had.
Tot nu toe hebben we gezien hoe we responsen type 13 XX en 1C xx middels het programma Studio 3.02c kunnen.
We beginnen met de 'korte' responsen, type 13 xx.
Eerdere EMM (C1 40 01 B1 5C 10 01) veranderen naar C1 38 21 01 B1 5C 10 01.
Extractie met LEN = 14
> C1 36 P1 P2 14
< C1 36 P1 P2 14 (36) 13 XX ......9000
> C1 36 P1 P2 14
< C1 36 P1 P2 14 (36) 86 XX ......9015/35
Zoals je reeds gemerkt hebt, is in de meeste gevallen, geen enkele goede waarde voor P3 en P4 aanwezig die de creatie van een nieuwe ins 38 toe stemt en daardoor de studie gewoonweg te kunnen vervolgen.
Vandaar dat we gaan proberen om andere middelen te gebruiken om verschillende
responsen te kunnen verkrijgen en de reeds verkregen en het zoeken onder de nieuwe responsen, diegene die goede P3 en P4 bevatten.
Men kan proberen om direct de getransformeerde EMM te extracten
(C1 38 01 B1 5C 10 01) responsen type 1C XX, varierend van waarde van de
Len bij onze ins 36.
Met andere woorden, als we eerst C1 36 P1 P2 14 verstuurden, moeten we nu C1 36 P1 P2 1D versturen.
Om vervolgens te observeren dat de respons die we terug krijgen van de kaart type 1C xx ...... is.
Samenvattend:
Eerst:
> C1 36 P1 P2 14
< C1 36 P1 P2 14 (36) 13 XX ... 9000
Nu
> C1 36 P1 P2 1D
< C1 36 P1 P2 1D (36) 1C XX ... 9000
Al spelend met de waardes van P1 (21,31), P2
(B0,1,C,D,E,90,1,C,D,E,F0,1,C,D,E) en met LEN = 1D, zouden we andere rangs van responsen type 1C xx kunnen verkrijgen, welke een goede waarde van P3 en P4 kunnen krijgen voor de creatie van een 'lange' ins 38 en deze omzetten naar deze 'korte' responsen.
Dit gegeven zal niet aanwezig zijn bij ieder van de EMM's die we reeds hadden gevangen (captured). Om dit te laten gebeuren moeten we het volgende doen:
C1 38 P1 P2 LEN 16 d1 2A d2 d3 2B d4 d5 86 d7 d8 d9 da db dc dd de 82 s1 s2 s3 s4 s5 s6 s7 s8
We bekijken even naar de byte d1.
De funktie die deze data d1 aangeeft, is gevormd door het volgende tabel:
Als d1 = 00
Retourneerd de pakket BITMAP van de provider
Als d1 = 01
Retourneerd men een register van PPV Credit van de provider
Als d1 = 03
Retourneerd men een register van PPV van de provider
Als d1 = 04
Retourneerd men een register type Ex
Als d1 = 06
Retourneerd men een register
Alleen als de data d1 een waarde verkrijgt van een van deze bytes
(00,01,03,04 of 06), zal de respons van de ins. 36 varieren.
Wanneer de data d1 een van deze bytes aangeeft, dan is het voldoende om een aanpassing te doen op de LEN van de ins 36, waardoor we 'langere' responsen kunnen verkrijgen en verschillend als de 13 xx.
We gaan er even vanuit dat het type van verkregen responsen wanneer data d1 'vraagt' naar een van deze waardes eerder vermeld, van 2 types zijn, en afhangende van het aangegeven bij P2:
Als P2 = 00
Respons 'zichtbaar' ( >> status 9035)
Als P2 = 90 >> bit 7 = 1 - tegengesteld verkrijgt men 90 35 nu dat deze de bit is die de DE aangeeft (encrypted).
Zie hier een tabel om een kleine referentie te hebben:
(met de status 9035 houden voor even geen rekening omdat we deze niet kunnen gebruiken om nieuwe ins te maken)
Als waarde data d1 = 00 >>> Status 9000 = Respons type 1C XX
Als waarde data d1 = 01 >>> Status 9000 = Respons type 1C XX
Als waarde data d1 = 03 >>> Status 9000 = Respons type 1F XX
Als waarde data d1 = 04 >>> Status 9000 = Respons type 1F XX
Als waarde data d1 = 06 >>> Status 9000 = Respons type 24 XX
Als aanvulling op dit geheel kunnen we wel kijken naar de 'zichtbare' responsen verkregen door de ins 36 in het venster van de nano 86. De waarde die P2 hierbij moet hebben zal 00 moeten zijn (om respons te krijgen 'niet encrypted'.
Venster van nano 86 bij de 'lange ins' gecreeerd door responsen type 1C xx.
C1 38 P1 P2 76 [color:"green"] P3 P4 [/color] aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [color:"red"] 82 s1 s2 s3 s4 s5 s6 s7 s8 [/color] [color:"blue"] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/color] P5
Om dit te verkrijgen:
C1 36 21 00 20 (36) 86 vv vv vv vv vv vv vv vv
- [color:"green"] Tabel P3 [/color]
[color:"red"] Nibble hoog P3 >>>>>>>> [/color] Verspringende bytes (Saltabytes) (10 + nibble hoog P3)
1x >>>>>>>> 11
2x >>>>>>>> 12
3x >>>>>>>> 13
4x >>>>>>>> 14
5x >>>>>>>> 15
6x >>>>>>>> 16
7x >>>>>>>> 17
8x >>>>>>>> 18
9x >>>>>>>> 19
Ax >>>>>>>> 20
Bx >>>>>>>> 21
Cx >>>>>>>> 22
Dx >>>>>>>> 26
Het proces van de saltabytes begint bij P3, m.a.w.:
Als P3 = 1x = 11(10+1) saltabytes
C1 38 P1 P2 76 [color:"green"] 1x P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 s1 s2 s3 s4 s5 s6 s7 s8 [/color] [color:"blue"] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/color] P5
In het venster van de nano 86 zouden we krijgen:
C1 36 21 00 20 (36) 86 [color:"green"] jj kk ll mm nn oo pp qq [/color]
Als P3 = 2x = 12(10+2) saltabytes
C1 38 P1 P2 76 [color:"green"] 2x P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 s1 s2 s3 s4 s5 s6 s7 s8 [/color] [color:"blue"] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/color] P5
In het venster van de nano 86 krijgen we:
C1 36 21 00 20 (36) 86 [color:"green"] kk ll mm nn oo pp qq [/color] [color:"red"] 82 [/color]
Als P3 = 3x = 13(10+3) saltabytes
C1 38 P1 P2 76 [color:"green"] 3x P4 aa bb cc dd ee ff gg hh ii jj kk [/color] ll mm nn oo pp qq [color:"red"] 82 s1 s2 s3 s4 s5 s6 s7 s8 [/color] [color:"blue"] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/color] P5
In het venster van nano 86 krijgen we:
C1 36 21 00 20 (36) 86 [color:"green"] ll mm nn oo pp qq [/color] [color:"red"] 82 [/color] s1
Als P3 = 4x = 14(10+4) saltabytes
C1 38 P1 P2 76 [color:"green"] 4x P4 aa bb cc dd ee ff gg hh ii jj kk ll [/color] mm nn oo pp qq [color:"red"] 82 s1 s2 s3 s4 s5 s6 s7 s8 [/color] [color:"blue"] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/color] P5
In het venster van nano 86 krijgen we:
C1 36 21 00 20 (36) 86 [color:"green"] mm nn oo pp qq [/color] [color:"red"] 82 s1 s2 [/color]
Als P3 = 5x,6x,7x…..etc
[color:"red"] In het venster van nano 86 zullen we gedeeltes van de zichtbare bytes, dus 'niet encrypted' zien van de INS 38.
Zoals we reeds weten, zowel de nano 82 als de bytes van de 'firm' verschijnen zichtbaar, waardoor deze geen proces ondergaan can de-crypt en zullen dus getoond worden zoals deze verschijnen bij de ins 38. [/color]
Functies van de parameters Px en de ins 36
P1 = -- >> dezelfde waarde van de INS 38
P2 = 00 >> Geen superencryptie aanwezig. Respuesta zichtbaar
P3 = xx >> Herschreven in bovenstaand tabel (alleen hoge nibble)
P4 = yy >> Vervolgens
P5 = zz >> Zie studie LEN
FUNKTIE VAN DE LEN
De waarde die LEN vraagt, hangt af van het wel of niet gebruik maken van de bytes Zx.
Bij de korte INS zal de LEN zonder byte Zx zijn: 6D (13+5A)
Bij de lange INS type 1C zal de LEN zonder bytes Zx zijn: 76 (1C+5A)
Als we de LEN groter maken, moeten we bytes Zx zoals hieronder aangegeven toevoegen:
- LEN ___ Bytes Zx
6D/76 ///////// 0
6E/77 ///////// 1
6F/78 ///////// 2
70/79 ///////// 3
71/7A ///////// 4
72/7B ///////// 5
73/7C ///////// 6
74/7D ///////// 7
75/7E ///////// 8
…
De maximale waarde die de hoge nibble van P3 kan vragen is Dx (26 saltabytes :
Als P3 = Dx = 26 saltabytes
C1 38 P1 P2 76 [color:"green"] Dx P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 [/color] s1 s2 s3 s4 s5 s6 s7 s8 [color:"blue"] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/color] P5
In het venster van nano 86 krijgen we:
C1 36 21 00 20 (36) 86 [color:"red"] s7 s8 [/color] [color:"blue"] 00 00 00 00 00 00 [/color]
Varieren we nu de LEN, deze vergroten door 1 bij 1 daarbij kijkend hoe de bytes van de SSE verplaatsen om daarbij toegang te bieden voor de bytes Zx die we toegevoegd hebben:
Zonder Zx:
C1 38 P1 P2 76 [color:"green"] Dx P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 [/color] s1 s2 s3 s4 s5 s6 s7 s8 [color:"blue"] 00 ... 00 [/color] P5
C1 36 21 00 20 (36) 86 [color:"red"] s7 s8 [/color] [color:"blue"] 00 00 00 00 00 00 [/color] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Met 1 byte Zx:
C1 38 P1 P2 77 [color:"green"] Dx P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 [/color] s1 s2 s3 s4 s5 s6 s7 s8 Z0 [color:"blue"] 00 ... 00 [/color] P5
C1 36 21 00 20 (36) 86 [color:"red"] s7 s8 Z0 [/color] [color:"blue"] 00 00 00 00 00 [/color]FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Met 2 bytes Zx:
C1 38 P1 P2 77 [color:"green"] Dx P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 [/color] s1 s2 s3 s4 s5 s6 s7 s8 Z0 Z1 [color:"blue"] 00 ... 00 [/color] P5
C1 36 21 00 20 (36) 86 [color:"red"] s7 s8 Z0 Z1 [/color] [color:"blue"] 00 00 00 00 [/color]FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Met 3 bytes Zx:
C1 38 P1 P2 77 [color:"green"] Dx P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 [/color] s1 s2 s3 s4 s5 s6 s7 s8 Z0 Z1 Z2 [color:"blue"] 00 ... 00 [/color] P5
C1 36 21 00 20 (36) 86 [color:"red"] s7 s8 Z0 Z1 Z2 [/color] [color:"blue"] 00 00 00 [/color]FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Met 4 bytes Zx:
C1 38 P1 P2 77 [color:"green"] Dx P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 [/color] s1 s2 s3 s4 s5 s6 s7 s8 Z0 Z1 Z2 Z3 [color:"blue"] 00 ... 00 [/color] P5
C1 36 21 00 20 (36) 86 [color:"red"] s7 s8 Z0 Z1 Z2 Z3 [/color] [color:"blue"] 00 00 [/color]FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Met 5 bytes Zx:
C1 38 P1 P2 77 [color:"green"] Dx P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 [/color] s1 s2 s3 s4 s5 s6 s7 s8 Z0 Z1 Z2 Z3 Z4 [color:"blue"] 00 ... 00 [/color] P5
C1 36 21 00 20 (36) 86 [color:"red"] s7 s8 Z0 Z1 Z2 Z3 Z4 [/color] [color:"blue"] 00 [/color]FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Met 6 bytes Zx:
C1 38 P1 P2 77 [color:"green"] Dx P4 aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq [/color] [color:"red"] 82 [/color] s1 s2 s3 s4 s5 s6 s7 s8 Z0 Z1 Z2 Z3 Z4 Z5 [color:"blue"] 00 ... 00 [/color] P5
C1 36 21 00 20 (36) 86 [color:"red"] s7 s8 Z0 Z1 Z2 Z3 Z4 Z5 [/color] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
De bytes Zx zijn ontvangen bij de respons van de INS 36 niet encrypted zoals deze bij de INS 38 verschijnen.
Hier gebeurd overigens niet hetzelfde als de bytes die ontvangen zijn bij de gedeelte van de SSE (00 00 00 00 00... ).
Hierbij ontvangen we bytes van de buffer van bewerking, verderop in de studie zal het proces van de SSE nader besproken en uitgelegd worden zo ook wat voorbeelden van de bytes van de buffer van bewerking.
Venster van de nano 86 en de LANGE INS gecreeerd door responsen type 1F xx en 24 xx
Analiseren we deze structuur voor de 1F :
C1 38 P1 P2 76 [color:"green"] P3 P4 [/color] aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq rr ss tt [color:"red"] 82 s1 s2 s3 s4 s5 s6 s7 s8 [/color] [color:"blue"] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/color] P5
Om dit te verkrijgen:
C1 36 21 00 20 (36) 86 vv vv vv vv vv vv vv vv
En als hetzelfde als de vorigen (1C), herhalen we het proces voor deze.
Hetzelfde zal gebeuren zoals bij de INS type 24.
In dit geval zal de basis structuur zijn:
C1 38 P1 P2 76 [color:"green"] P3 P4 [/color] aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq rr ss tt uu vv ww xx yy zz [color:"red"] 82 s1 s2 s3 s4 s5 s6 s7 s8 [/color] [color:"blue"] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/color] P5
---------------------------------------------------------------------
Tot op de dag van vandaag zijn krijgen we in ieder geval op de spaanse v7 kaarten geen responsen type 90 00.
Helaas ben ik (nog steeds) niet in het bezit van een Nederlandse kaart dus kan deze type ins zelf niet toepassen op de Nederlandse versie v7 kaarten. Mischien is het interresant om dit gedeelte van de studie toe te passen op de kaarten, gewoon om te kijken wat de responsen zijn.
Dit kan van zeer belang zijn op het vervolg van de studie.
Hiermee is dit tevens een afsluiting van de zelfstudie seca2 volgens de 'oude' methodes.
Voor de volgende fase zal ik het vervolg van de studie en het fenomeen van de 'twin-keys' uitgebreid gaan behandelen.
Met de methode twin-keys gaan er werkelijk deuren voor ons open die nieuwe perspectieven bieden.
Er zijn momenteel diverse studies gaande door o.a. collega's 89Mark89, Salicilato en Parisino.
Saludos!
Azazel miembro del equipo RAIDEN, la resistencia.'
- [color:"green"] Tabel P3 [/color]
-
Hallo satvrienden,
Er zijn verschillende onduidelijkheden en vele vragen wat betreft de c1 40's.
Het is inderdaad zo dat de c1 40 encrypted zijn, maar er is een methode om deze duidelijk te maken....
Het onderzoek richt zich nu naar die c1 40's.
We kunnen wel zeggen dat de welbekende RMosc niet meer opgaat voor seca2.
We zijn momenteel bezig met nieuwe technieken en andere methodes.
Een van die methode is de QDMOSC (quasi-deterministic mosc).
Dit onderzoek richt zich vooral op naar de zogenaamde methode van de 'twin-keys'. En concreet gezegd kunnen we een c1 40 construeren, bevestigd door de key Kg.
Er gaan nog volop onderzoeken naar dit fenomeen, en ik zal er later nog meer nieuws over posten zodat iedereen er mee kan onderzoeken en dat het jullie een beetje meer verder weg kan helpen met de studie.....
Saludos!
'Azazel miembro del equipo RAIDEN, la resistencia.'
-
Hallo satvrienden,
Zoals Duwgati al zegt, er zijn dus nog geen interessante vorderingen .
Voor nu... blijven studeren....
Saludos!
'Azazel miemro del equipo RAIDEN, la resitencia.'
-
[color:"blue"]Status 9600 en de INS 40.[/color]
De pre-parsing voor de INS 40 werkt volgens modus zoals eerder beschreven,
de kaart examineert alle nano's voordat men nano 82 bereikt.
Let er wel op dat een gevonden Nanocommand niet perse nodig is dat deze
een betekennis heeft, simpelweg de kaart zal deze overslaan en examineert
de volgende nano, die funktioneert volgens de theoretische lengte van de
onbekende nano.
[color:"blue"]Status 9600 en de INS 3C - DE BUG. [/color]
Met de INS 3C en een 'foute' parsing genereerd men niet altijd status 9600.
Er zijn diverse gedrags verschillen opgemerkt bij het varieren van enige
'body' van de Ins. Vergelijkingen van status 9A00, en ook de pre-parsing
(die verkrijgt men wanneer data van de C1 3C nano 24, 81, 90, 91, F6, F7
bevatten), maar het interessante heeft men wanneer de parsing de vastlegging
van de signature 'uitlokt': In plaats van 9600, krijgt men een bug hetzelfde
als die present is bij de vorige versies van de kaaten: DE BUG.
[color:"blue"] Zie: BUG in Seca . [/color]
Bij de nieuwe kaarten werkt de BUG verschillend, we zien dat bij het eerste
register de primaire MK00 gekopieerd komt van de provider die de C1 3C
aangeeft - De 2e Bug -
Het zou interessant kunnen zijn de bug te proberen bij een provider zonder
MK00, om te kijken wat er dan gebeurd.
[color:"blue"]Status 9600 en de INS 38 - De bug 36/38 [/color]
Hier treffen we een 'macroscopische' bug aan die onmiddelijk is verbeterd
bij de v7 kaarten. De routine van controle bij de oude C1 38 verdwijnt en
in de plaats daarvan hetzelfde routine van de pre-parsing die gebruikt wordt
bij de INS 40.
Hierbij is het belangrijk om te weten hoe de pre-parsing van de C1 38
werkte bij Seca 1.
Neem hierbij voorbeeld van secafaq:
[color:"blue"]Instructies 36 en 38 - Lezen van Record en Signature.[/color]
Deze paar van ins. realiseerd het lezen van de aanwezige Records....
Bovendien staat het toe om enige byte van de eventuele aanwezige Record Bx
te veranderen. Eerst moeten de 38 gerealiseerd zijn (versturen van data)
vervolgens de 36 (aplicatie van data).
[color:"blue"] C1 38 P1 P2 1A 16 xx 2A mm mm 2B nn nn 86 K0 K1 K2 K3 K4 K5 K6 K7 82 Signature [/color]
De waardes [color:"green"] 16, 2A, 2B, 86 [/color] zijn geen echte nanocommands, het is nodig dat
deze op goede posities staan. De status error is hier 96 00 .
P1 en P2 hebben dezelfde betekennis al van de INS 40, PK of PK+SK, deze
kunnen gebruikt worden en zijn bruikbaar voor de SUPERENCRYPTIE.
De waardes 'xx' geven de type register van de DUMP aan, ondertussen geven
de bytes 'mm mm' een offset aan.
[color:"green"]00 vv vv [/color] Provider Package Bitmap Record
[color:"green"]01 vv vv [/color] Provider PPV Credit record [color:"green"]vv vv [/color] = enige waarde
[color:"green"]03 xx xx [/color] Provider PPV record [color:"green"] xx xx [/color] = bevat EventID van de PPV
[color:"green"]04 00 yy [/color] Record Ex [color:"green"] yy[/color] = specificeerd de Record Ex om te zoeken
[color:"green"]06 zz zz [/color] Record [color:"green"] zz zz[/color] = Record nr. om de 'lectuur' te beginnen
In het geval dat 'xx' gelijk is aan [color:"green"] 03 [/color], bovendien tonen van de PPV Record,
zal de ins de PPV-Event Spot veranderen, die de 10e en 11e byte is (beginnend
vanaf links) van de gebruikte Record die twee waardes bijvoegd gevolgd aan 2B.
Daarna de waarde 86 gevolgd door 8 bytes.
De werkelijke DUMP wordt gerealiseerd met de Ins 36
[color:"red"] C1 36 P1 P2 LEN [/color]
P1 moet hetzelfde als P1 van de vorige ins zijn met de zesde bit in
plaats van een.
P2 geeft, zoals altijd, de key aan.
Len moet meer zijn als 13 (in hexadecimaal).
Nu is het niet meer noodzakelijk de aanwezigheid van waardes 16, 2A, 2C, 86,
vanaf de BUG 36/38.
C1 40 01 B1 5C
10 01 7E 3C 29 03 1B AC 43 31 82 A1 7E AE C4 26
96 F2 3E 0A C3 9E 76 3E C6 20 86 79 2E 4A 8D D9
18 14 95 3B 2E B6 54 D2 89 5F 76 0B 23 3B 63 4D
BF 00 EA 81 E5 24 BB 93 CA D4 D0 6F F8 38 5F 9C
5B EF AB 11 33 9B 17 8A EC CC 1D 6B 90 5D CD 2F
50 2C 90 A7 BE 29 68 37 7C 56 6F 33 [90 00]
-
Bij de voobeeld van de C1 40 is de status byte [color:"blue"] 90 00 [/color], in werkelijkheid
bestaan er zoals C1 40 met verschillende statussen en hetzelfde bruikbaar
voor de Bug. De meest frequente statussen zijn:
[color:"blue"]
- 97 xy
- 90 19
- 93 01
- 90 09
[/color]
De 40 veranderen in 38....
C1 38 01 B1 5C
10 01 7E 3C 29 03 1B AC 43 31 82 A1 7E AE C4 26
96 F2 3E 0A C3 9E 76 3E C6 20 86 79 2E 4A 8D D9
18 14 95 3B 2E B6 54 D2 89 5F 76 0B 23 3B 63 4D
BF 00 EA 81 E5 24 BB 93 CA D4 D0 6F F8 38 5F 9C
5B EF AB 11 33 9B 17 8A EC CC 1D 6B 90 5D CD 2F
50 2C 90 A7 BE 29 68 37 7C 56 6F 33 [color:"red"] [90 00] [/color]
Attentie: Als men probeert hetzelfde te doen met een INS 36 verkrijgt men\
niet hetzelfde resultaat:
C1 36 01 BD 5C
10 01 E6 12 CC 77 60 AE 96 FF F4 4D 58 03 99 F1
3F EF F3 A4 44 E6 1B 16 18 21 EB 40 D4 65 BC F5
66 60 6D 7D 54 29 28 06 52 95 29 D6 07 E0 11 23
1C 8E 89 29 89 2A 43 4E 11 98 2A 63 35 DB 56 F4
4B 03 82 B2 66 29 69 80 69 50 68 FC EC 0 2E 3B
F2 A7 BC 04 CA A8 15 D9 60 7D 28 47 [90 00]
C1 38 01 BD 5C
10 01 E6 12 CC 77 60 AE 96 FF F4 4D 58 03 99 F1
3F EF F3 A4 44 E6 1B 16 18 21 EB 40 D4 65 BC F5
66 60 6D 7D 54 29 28 06 52 95 29 D6 07 E0 11 23
1C 8E 89 29 89 2A 43 4E 11 98 2A 63 35 DB 56 F4
4B 03 82 B2 66 29 69 80 69 50 68 FC EC 0B 2E 3B
F2 A7 BC 04 CA A8 15 D9 60 7D 28 47 [color:"red"] [90 02] [/color] <------ of [color:"red"] [90 34] [/color]
Conclussie:
Vanaf de byte van encryptie, geeft de de-SSE van de INS 3C een verschillend
reslultaat dan die van de INS 40/38.
De gebruikte key of het begin van de algoritme zouden verschillend kunnen
zijn, of verschillend betreffende de P5 die zich zonder twijfel in de
goede positie bevind.
[color:"blue"] We gaan terug naar de C1 38 met status 90 00 ..... dit resultaat staat ons toe om een succesvolle C1 36 te versturen. [/color]
[color:"red"] C1 36 P1 P2 LEN [/color]
Laten we de verbindingen en graden gerelateerd aan deze ins. nader
onderzoeken en analyseren.
[color:"purple"] P1 [/color]moet hetzelfde zijn als 2y of 3y waarbij de 'y' hetzelfde hoort te
zijn als de Nibble van de P1 van de C1 38 voorafgaand verstuurd.
[color:"purple"] P2 [/color]geeft de key en de Hahs tabellen aan die gebruikt worden voor de
encryptie van de responsen (hetzelfde betekennis als C1 38/3C/40).
[color:"purple"] LEN [/color]moet groter zijn dan 13 (in hexadecimaal), van de andere kant
moet de staus 6700 zijn.
De respons die men verkrijgt is hangt af van de 'body' van de INS 38
die men verstuurd heeft, zoals bij volgende voorbeeld:
C1 38 P1 P2 LEN
P3 + data van P3 + 16 d1 2A d2 d3 2B d4 d5
86 K0 K1 K2 K3 K4 K5 K6 K7 82 s0 s1 s2 s3 s4 s5
s6 s7 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 P5
De kaart controleerd hierbij niet op de aanwezigheid van de "nano",
maar verwijderd de data direct "d1", "d3 2", d5 4", "K0... K7".
Beginnend te tellen bij de byte vanaf degene die onmiddelijk de data
van de P3 opvolgt, zullen de data worden verwijderd volgens volgende criterium:
- De tweede voor d1
- De vierde en vijfde voor d3 d2
- De zevende en achtste voor d5 d4
- Van de tiende t/m de zeventiende voor K0... K7.
Voorbeeld:
C1 40 01 B0 61
10 01 92 BD 1F C2 E6 A6 C0 8B 1E F7 02 1E 7D F0
07 F2 31 2B 31 46 9E E9 1F 28 65 0D 12 68 F6 F1
25 B2 91 66 63 C0 EA 48 7D E3 1F EB E0 99 92 37
26 86 DB 0E C6 92 13 CD 61 E7 4C 70 45 27 2F A6
D9 B2 74 0C DF 7C E4 07 5D 62 B1 DD B0 13 F5 8C
9E 2A F2 28 12 55 1E 8D 76 43 19 31 01 6E B1 92
11
Veranderen naar C1 38...
c1 38 01 b0 61
10 01 92 BD 1F C2 E6 A6 C0 8B 1E F7 02 1E 7D F0
07 F2 31 2B 31 46 9E E9 1F 28 65 0D 12 68 F6 F1
25 B2 91 66 63 C0 EA 48 7D E3 1F EB E0 99 92 37
26 86 DB 0E C6 92 13 CD 61 E7 4C 70 45 27 2F A6
D9 B2 74 0C DF 7C E4 07 5D 62 B1 DD B0 13 F5 8C
9E 2A F2 28 12 55 1E 8D 76 43 19 31 01 6E B1 92
11 [90 00]
De data worden pas verwijderd nadat deze duidelijk (decrypt) zijn.
Ervan uitgaande dat de decrypt het volgende is:
10 01 10 [color:"red"]02[/color] 17 [color:"red"]00 10 [/color] 03 [color:"red"]80 00 [/color] 80 00 00 [color:"red"]00 00 00
22 00 80 90 51[/color] DE E2 04 D1 AF B3 FB B6 91 51 A1 37 9E
4B D0 49 4C 51 21 1A 7F 90 5C 75 13 DE 05 65 03
C4 57 B0 66 75 63 6B 20 26 20 73 75 63 6B 90 5D
9D 33 0E A2 6C 2D 3C 05 90 5E 06 73 8A B7 5D 9A
4C 5C 41 09 C3 22 21 82 D3 E8 54 CA 78 CD D2 61
P5
.... Men begrijpt nu wat de verwijderde data is (aangegeven in rood) en gebruikt voor de volgende C1 36.
Volgende deel: Verschillede responsen met D1.
'Azazel miembro del equipo RAIDEN, la resistencia.'
-
-
@FredjeV,
Kijk dat vind ik nu geweldig om te lezen....
Eens kijken of er meerderen mee bezig zijn.....(zoals je zelf al vraagt)..
Saludos!
'Azazel miembro del equipo RAIDEN, la resistencia.'
-
@FredjeV,
Het is je dus gelukt!! Wil je hier zeggen hoe je dat hebt gedaan??
Dat eventueel voor mensen met dezelfde probleem.
Ps. Toeval bestaat toch niet.... <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" /> <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />
Saludos!
'Azazel miembro del equipo RAIDEN, la resistencia.'
-
@Cosenza,
Je hebt je zoals gezegd je PPUA. Nu is het van belang om een ins 40 die geldig is voor je PPUA te 'zoeken'.
Deze kun je aan de hand van de topic 'Zelfstudie seca2' doen. Daar staat stap voor stap hoe je ins. via een pic2 kunt loggen.
Helaas kan ik dat niet voor je doen (gezien de tijd die je daarvoor kwijt bent) en zul je het zelf moeten doen.
Mocht het niet lukken, dan kun je het volgende proberen; een verkorte versie maar is niet altijd even succesvol:
Mijn tip is toch de zelfstudie te volgen.
Benodigd materiaal:
Hardware: Programmer T-20 / T-21 (phoenix). Piccard2
Software: Ic-prog, MatrixStudio en software mosc om je kaart uit te lezen (MKF, Secarl, Camelmosc, etc. etc.)
1. - De eerste stap is dus om je PPUA en je UA te weten. Dit kan dus met de software boven aangegeven. Kopieer de PPUA van de provider en de serie nummer (op de spaanse v7 staat deze achterop, de laatste 9 cijfers), maar anders zou je die ook via de mosc software lezen. (persoonlijk vind ik camelmosc goed). (C1 0E 00 00 08)
Disconnect en naar de pic2.
2- Open Matrixstudio en neem een file .hex (ik gebruik hiervoor funsecom)
Deze open je bij knop 'Program 16f876' en zal daarna meteen vragen om providers te actualiseren. Je klikt 'ja' en vervolgens op 'Providers'.
Je gaat naar betreffende (opererende) provider en vult je PPUA en UA in.
Klik opnieuw bij 'Program 16f876' en vervolgens op 'Copy providers from providers folder' en bewaar deze file.
Je hebt nu de file klaar om te schrijven met IC-prog en je Phoenix.
3 - Eenmaal de .hex file beschreven op je pic2 open je Matrixstudio weer
en klik je (met de kaart in je programmer) op 'Config'. En configureer je settings (comport, Phoenix etc.)
Meteen daarna klik je op 'Debug Mode', en vervolgens op 'Open-Close Port' en bij het rechter venster dubbel klikken op 'activate command capture', gevolgd door 'write culluh config'. Klik op 'Reset' en daarna 'Read Providers'.
Nu ga je links in het venster naar 'Log in card'. Er verschijnen verschillende venstertjes: CLA, INS, P1, P2 en LEN.
Je wil dus een ins. van actualisering 'capturen' (C1 40 01 B1 5C), bij CLA in het venster Mask vul je FF C1 in, en bij de INS in Mask FF 40, bij P1 Mask FF 01, bij P2 Mask FF B1 en bij LEN Mask FF 5C.
Vervolgens 'Send Mask to PicCard2', 'Debug Mode', 'Reset' en als laatste 'Open-Close Port'. Dan gaat de kaart in je deco en gaat naar een kanaal betreffende de provider. (In jou geval een Italiaanse Tele+ zender).
Na ongeveer een uur heb voldoende traffic ontvangen.
4 - De kaart gaat in je Phoenix en open Matrixstudio.
'Debug Mode' -> 'Open-Close Port' -> 'Read Providers' en daarna 'Log in Card'.
Klik op 'Read Log From PicCard2' vervolgd door 'Analysis captured Log'.
Je krijgt vervolgens een lijst met verschillende data.
Wat ons interesseerd is wat er staat bij 'Ins captured' en bij 'Datas'.
Je selecteerd deze, -> copy and paste volgens 'aangegeven manier' zodat je een Ins met LEN 5C hebt, (0x5Ch, 97 bytes).
Je krijgt dan iets zoals: (deze data is fictief)
C1 40 01 B1 5C 10 01 0A 67 CF ED 33 34 2C BC 1C 13 54 AF 5C 38 6E 7C 2C BA 80 54 BE A5 7A 4F 64 8C 13 E1 2D 03 32 FF 59 D2 17 2D FF 13 5F 16 81 F0 98 C8 41 3C FD F5 40 F6 41 38 82 02 3A 60 84 F0 83 94 78 EE E7 19 18 9B 1F 71 F7 1E 91 43 2D A7 4A 4E F0 4A 58 CF 02 88 E3 2A B9 47 F7 21 AE E5
Je bewaard deze als .txt en je kunt gaan 'spelen'!!!
Het kan natuurlijker ook makkelijker, via de diverse lijsten die zich op het net bevinden, kun je een ins 40 vinden die geldig is voor je PPUA (tenmisnte als je een van de gelukkige bent).
Maar deze lijsten vinden we helemaal niet leuk.. het is leuker om zelf op onderzoek te gaan... Toch??
Ps. Let op de criteria die aangegeven is bij topic zelfstudie.
(volgende stap is je PBM aanpassen met o.a. SM2).
Succes!!
Saludos!
'Azazel miembro del equipo RAIDEN, la resistencia.'
-
@hallo satvrienden,
Dit is ook leuk om te zien, radiografische vergelijkingen van de
spaanse V3, V6 en V7 kaarten.
V3
V6
V7
Saludos!
'Azazel miembro del equipo RAIDEN, la resistencia.'
-
Sorry satvrienden,
Maar ik kon het niet laten........
Jippiieeeeeee 250 alweer!!! (en dit op 1 april)...... <img src="/ubbthreads/images/graemlins/smirk.gif" alt="" /> <img src="/ubbthreads/images/graemlins/smirk.gif" alt="" />
(vergeleken met anderen is dit een schijntje natuurlijk)...
Ps. Iedereen is uitgenodigd om Paella bij mij te komen eten!!
(vino en cerveza zelf meenenemen por favor.) <img src="/ubbthreads/images/graemlins/grin.gif" alt="" /> <img src="/ubbthreads/images/graemlins/grin.gif" alt="" />
Saludos!
'Azazel meimbro del equipo RAIDEN, la resistencia.'
-
@Unetwork,
Wat is de status van de kaart en abonnement?...
Belangrijk om te weten is of je PPUA tussentijds is veranderd.
( je hebt dus een INS 40 gevonden voor jou PPUA, is de PPUA nog hetzelfde)..
Saludos!
'Azazel miembro del equipo RAIDEN, la resistencia.'
De zoektocht naar het algoritme
in CI, CI+, (soft)cams en smartcards
Geplaatst:
Hallo satvrienden,
We vervolgen onze zoektocht naar het algoritme, en zoals op enkele Italiaanse forums wordt beweerd maakt seca2 gebruik van RC4 Algoritme.
Dit was voor ons een reden om dat eens uit te gaan zoeken.
Dus dat betekend dat het weer afgelopen is met de schaarse vrije tijd en flink aan de slag!
De eerste vraag die meteen komt opduiken is natuurlijk:
Wat is RC4?
Tsja, wat RC4 is, dat weten we eigenlijk wel, maar hiermee wordt eigenlijk bedoeld: hoe gaat RC4 te werk?
[color:"red"]
- RC4 is een van de snelste ciphers (codering) wereldwijd gebruikt voor het serieuze werk.
- Variabele key lengte van 40 tot 256 bit key.
- De lengte van de te coderen tekst is even lang als de gecodeerde tekst. [/color]
RC4 gebruikt twee arrays van bytes (van 8 bits). The "status" array is 256 bytes en bevat een permutatie van de nummers 0 t/m 255. The "sleutel" array kan elke lengte tot 256 bytes hebben. RC4 gebruikt ook twee indexvariabelen, i en j, die op nul beginnen. Alle variabelen zijn 8 bits en alle optellingen worden gedaan modulo 256.
RC4 heeft twee fases: het initialiseren van de sleutel en de eigenlijke versleuteling. De initialisatie wordt maar 'e'en keer per bericht gedaan en begint met het zetten van de hele status array zodat het eerste element de waarde nul heeft, het tweede de waarde 'e'en, het derde de waarde twee, enzovoort.
De status array wordt dan 256 keer door een mengoperatie gehaald door middel van een lus die i door de waarde nul tot 255 laat stappen. Elke mengoperatie bestaat uit twee stappen:
Tel bij de variabele j the waarde van het i'de element van de status array en het n'de element van de sleutel, waarbij n gelijk is aan i modulo the lengte van de sleutel.
Verwissel het i'de en het j'de element van de status array.
Nadat de lus klaar is, worden i en j weer op nul gezet.
Tijdens de versleutelingsoperatie worden de volgende stappen voor elke byte van het bericht doorlopen:
De variabele i wordt met 1 verhoogd. De waarde van het i'de element van de status array wordt bij j opgeteld. Het i'de en j'de element van de status array worden verwisseld en tevens bij elkaar opgeteld om een nieuwe waarde n te vormen.
Het n'de element van de status array wordt dan via een bit-voor-bit exclusive-or met het byte van het bericht gecombineerd
om de uitvoerbyte te vormen.
Deze stappen gelden zowel voor encryptie als voor decryptie.
In CipherSaber bestaat de RC4 sleutel array uit het password dat de gebruiker invoert gevolgd door een 10 byte lange initialisatievector (IV).
Wanneer je een bestand versleutelt, genereer je een nieuwe IV met random waardes en schrijf je deze tien bytes weg in het uitvoerbestand alvorens de versleutelde bytes van het bericht te schrijven.
Wanneer je een bestand ontsleutelt, lees je de eerste tien bytes van het invoerbestand en gebruikt deze als IV.
Als we vervolgens naar de code kijken kun je zien dat deze niet moeilijk is in te brengen / toe te passen:
Dim Keyx(255) As Integer
Dim S(255) As Integer
Dim K(255) As Integer
Dim NumeroBits As Integer
NummerBits = 256 'Nº bits van 40 tot 256
For i = 0 To Len(Text3.Text) - 1 'Text3.Text is de symetrische key
Keyx(i) = Asc(Mid(Text3.Text, i + 1, 1))
Next
For i = 0 To NummerBits - 1
S(i) = i
K(i) = Keyx(i Mod Len(Text3.Text)) 'Lengte van de symetrische key.
Next
j = 0
For i = 0 To NummerBits - 1
j = (j + S(i) + K(i)) Mod NummerBits '<-- een van de RC4 algoritmes
medium = S(j) '
S(j) = S(i) '
S(i) = medium '
Next
n = 1
i = 0
j = 0
Do
i = (i + 1) Mod NummerBits
j = (j + S(i)) Mod NummerBits
medium = S(j)
S(j) = S(i)
S(i) = medium
t = (S(i) + S(j)) Mod NummerBits
keystreamByte = S(t) 'we erkrijgen de key waarme we de XOR bij de plain tekst kunnen toepassen.
Plaintekst = Asc(Mid(Text1.Text, n, 1)) 'Text1.Text is de plaintekst en gaat over op ascii.
n = n + 1
codering = plaintekst Xor keystreamByte 'Men codeert byte voor byte
Text2.Text = Text2.Text & Chr 'Text2. Text is de gecodeerde plaintekst
Loop Until n > Len(Text1.Text).
[color:"black"] Controlbyte [/color] zegt: De v7 heeft een cryptoprocessor bijgevoegd die het eventueel mogelijk zou kunnen maken om SHA1 en enkele miliseconden uit te voeren. Bovendien time analysis van het proces van 'firm' laat zien dat de berekening van de digest wordt gerealiseerd in blokken van 64 bytes!! Met de toevoeging van enige extra bytes bij het bericht, waarschijnlijk UA, PPUA of SA, naarmate deze correspondeerd.
RC4 zou perfect in het totale plaatje kunnen passen.
PS. Deman, de interne software van de ontvangers krijgen regelmatig een update, waardoor het onderwerp wat jij aanhaalt helaas niet opgaat hier.
Via die weg zal het ontzettend moeilijk zijn om vooruitgang te boeken.
Saludos!