Azazel Geplaatst: 31 maart 2003 Geplaatst: 31 maart 2003 Hallo satvrienden, Met veel plezier is hier dan de lang verwachtte seca2 FAQ: (Vanwege het vertaalwerk zal deze in gedeeltes geplaatst worden). [color:"blue"]Seca2 FAQ [/color] [color:"blue"]Nader kennis met de ECM/EMM [/color] [color:"blue"]By Supergip vertaling door Azazel [/color] Als eerste zou ik aan willen geven dat voor het begrijpen van deze FAQ, allereerst kennis van zaken moet hebben betreffende het seca systeem met behulp van Seca FAQ. Alles wat hier vermeld wordt is uitsluitend bedoeld voor het onderzoek en studie van seca2. [color:"blue"]Nieuw in het seca2 systeem [/color] Aan de hand van een log van een ECM is het mogelijk om het eerste karakter- eigenschap van het nieuwe systeem te realiseren: C1 3C 01 BE 5C [color:"red"] 10 01 [/color] CD 99 F1 E7 88 F1 E9 00 50 F9 09 5B 02 43 DD 03 35 39 1B C2 41 97 AF B3 8A A7 F7 9A FA 78 12 C9 BA 23 16 42 99 0E 9A F3 31 72 22 BC B8 C6 62 45 37 F9 7F 68 15 7C BB 7C A7 F2 3D F8 27 82 52 49 54 56 98 0C AB 94 26 95 74 A7 12 B6 83 4D 23 46 03 F1 E1 A5 66 31 05 96 46 48 [90 00] Bij wijziging van alle bytes, behalve de rode, tussen twee verschillende ECM's, is enig nanocommando onbekend en is er geen spoor van de 'signature' te bekennen: de reden hiervoor is het simpele feit dat de data encrypted is. Men weet nu dat er bij seca2, twee paren van ecryptie aanwezig zijn: de [color:"purple"]SUPERENCRYPTIE [/color] (werkt met blokken van bytes) en de [color:"purple"] SECUNDAIRE SUPERENCRYPTIE [/color] [color:"purple"] (SSE of Envelope)[/color], die handelt de data die zijn geintegreerd. Deze processen van encryptie zijn verplicht voor de data van de ins. 3C/38/40. Het gebruikte algoritme voor de SSE is vooralsnog onbekend, al verdenkt men dat er gebruik wordt gemaakt van een decrypt type RSA. De superencryptie zou anders dan de SSE moeten lijken op die van SECA. Superencryptie (SECA) Als men de instructie in zijn geheel neemt (incl. de signature) en deze is te delen in blokken van 8 bytes, bij elk blok kan men de algoritme van encryptie met de key aangegeven door P2 toe passen. Als de bytes die overblijven een nummer minder dan 8 zijn, dan kan de blok niet compleet gemaakt worden en blijft het gecodeerd. [color:"blue"] De structuur van de ins 38/3C/40 [/color] De klassieke formulering van SECA is compleet gehandhaafd met respect naar ISO 7816. [color:"purple"] C1 38/3C/40 P1S P2 LEN + pakket van data [/color] [color:"blue"]p1 [/color] Bit 0...3 :Aanduiding van de provider naar waar de commando verstuurd wordt. Bit 4 :Gebruiken van primary key of primary + secundary key. Bit 5,6 :Geeft begin aan van flashbuffer voor de berekening van de 'signature' Bit 7 :niet in gebruik. [color:"blue"]P2 [/color] Bit 0...3 :Aanduiding van de gebruikte key voor decrypten van de SuperEncryptie. Bit 4 :Betekennis onbekend (moet zijn = 1) Bit 5,6 :Selecteerd de map voor desencryptie en een eventuele user ALGO (niet actief bij de v7). Bit 7 :Aanwijzer van de SuperEncryptie (moet zijn = 1) [color:"blue"]LEN [/color] Is de lengte van de 'pakketten van de data' Voorbeeld: C1 40 01 B1S 5C [color:"red"]10 01 [/color] 12 08 F5S 56 DE F0 11 12 DOS D8 40 3B 34 7A EB A5 B7 30 41 50 5F 02 6D B2S 03 ABS 29 2B 29 7A 05 4F AFS 83 18 75 1F 33 49 67 29 0CS C0 22 C7S 44 E3 BA 45 6D 1B 3A F3S 56 07 A9S 89 5D B4S 5E 8A D1 1F 40 F4S 50 D1S 57 D0S 96 88 5B EBS 93 2A 10 CE E8 4D 36 1F 80 A7S 65 A6S 9C 3E 03 78 49 Zoals eerder vermeld, zullen de twee bytes aangegeven in rood, voor alle lengtes van de INS zich hetzelfde handhaven. Ze vertegenwoordigen enige parameters voor de SSE en 'gedragen' zich verschillend met respect op alle andere data. Ze geven ons de definitie aan van parameters P3 en P4. Binnen deze data bevind zich een parameter van zeer grote extensie die niet zichtbaar is, vanwege het feit dat deze encrypted is. Zijn funktie zal ik nader uitleggen, maar als eerste is het genoeg om zijn extensie, zijn positie (de laatste byte van de data) en de naam (P5) te weten. Dit wetende kunnen we een nieuwe uitvoering van de structuur van de INS aangeven: [color:"purple"]C1 38/3C/40 P1 P2 LEN P3 P4 + Data Pakket (P5) [/color] Volgende deel: het proces van executie van de INS. Saludos! 'Azazel miembro del equipo RAIDEN, la resitencia.' [color:"red"] LLORAMOS JUNTOS, GANAREMOS JUNTOS! [/color]
Azazel Geplaatst: 1 april 2003 Auteur Geplaatst: 1 april 2003 [color:"blue"] Proces van executie van de ins. [/color] In grote lijnen heeft het deze logische 'gebeurtennis' (en tijdelijk): [color:"brown"]1 - De normale controles van protocol ISO7816 CLA/INS/LEN [/color] (mogelijke status error 6D00, 6E00, 6700) [color:"brown"]2 - Controle van P1, aanwezigheid van de provider [/color] (status 9004 als niet aanwezig) [color:"brown"] 3 - Controle van bit 4 van P2 [/color] (moet zijn = 1, status 9024 in tegengesteld geval) [color:"brown"] 4 - Controle van bit 0 van P4 [/color] (moet zijn = 1, status 9024 in tegengesteld geval) [color:"brown"] 5 - Controle van P3 [/color] De gereserveerde handeling van P3 is gelijk aan die van een nanocommando, maar: - Moet op zijn minst waarde 10 hebben (status 9024 voor inferieure waardes) - Is volledig onbekend, samen met data geasocieerd naar P3, voor het volgende proces: -> Decrypt SSE ( ) -> DECRYPT SE -> Parsing en executie ("PARSING", letterlijk vertaald w.d.z. "Analyse van de periode", in onze context betekend het "examinatie van een nanocommando en zijn parameters") - Behoord tot de data voor berekening van de 'signature' Om te weten hoeveel data geasocieerd is aan P3, nemen we de klassieke lijst van de LEN van de nanocommando: High Nibble / Nano Lenght --------------------------- 0... C / 0... 12 [color:"brown"] ( belangrijk : 0 is geen acceptabele waarde voor P3) [/color] D / 16 byte Y / 24 byte F / 32 byte Observatie: P4 is de eerste byte van de data voor P3. Als laatste voor deze controle kan men status 6700 (error LEN) verkrijgen, omdat nadat de data van de P3, moeten op zijn minst de 5A bytes (90 in decimalen) verschijnen. De reden hiervoor zal verderop toegelicht worden. [color:"brown"] 6 - Controle van de bits 1,2 van P4 [/color] (moeten zijn = 0, status 9036 in tegengesteld geval) P4 is indicator voor de-SSE, maar de exacte funktie is nog onbekend. [color:"brown"] 7 - Decrypt SSE [/color] (de-SSE of de-envelope) Gezien het feit dat de algoritme onbekend is, kunnen we aanschouwen dat men gebruik maakt van verschillende keys voor elk provider (maar hetzelfde voor alle kaarten) en deze opereerd altijd en alleen bij de laatste 5A byte van de data. De consequenties zijn: - Een ECM/EMM geadresseerd naar een provider is niet toepasbaar bij een verschillende provider. - de data van P3 (neemt geen deel aan de-SSE) moeten vervolgd worden door tenminste 5A bytes (dit is de verklaring voor de status 6700 gedurende volgorde van P3) - Mogelijke bytes bij de data van P3 en de laatste 5A byte nemen geen deel aan de SSE/envelope (belangrijk). Voorbeeld: [color:"blue"] (Note: De getoonde commando is fictief, correspondeerd aan geen enkele log van data) [/color] C1 40 01 B1S 6A [color:"red"]43 51 6E b1 92 [/color] 0F 87 17 D3 5C 87 47 34 5E 39 79 [color:"blue"]12 08 F5 56 DE F0 11 12 D0 D8 40 3B 34 7A EB A5 B7 30 41 50 5F 02 6D B2 03 AB 29 2B 29 7A 05 4F AF 83 18 75 1F 33 49 67 29 0C C0 22 C7 44 E3 BA 45 6D 1B 3A F3 56 07 A9 89 5D B4 5E 8A D1 1F 40 F4 50 D1 57 D0 96 88 5B EB 93 2A 10 E8 4D 36 1F 80 A7 65 A6 9C 3E 03 78 49 [/color] Bij deze commandode bytes in het rood aangegeven hebben betrekking op P3 en de relatieve data (High Nibble van P3 =4, dus 4 data bytes). De bytes in het geel aangegeven hebben betrekking op 5A bytes onder SSE. De rest zijn bytes buiten de SSE (zichtbare bytes of SuperEncrypted). [color:"blue"]Wat vinden we onder een SSE decrypt? [/color] Een groot verschil kunnen we onmidelijk zie ten opzichte van Seca: De sigature is extern naar de SuperEcryptie en heeft geen vaste positie. We gaan terug naar het commando aangegeven bij het voorbeeld met de veronderstelling van een mogelijke de-SSE: C1 40 01 B1S 6A [color:"red"] 43 51 6E B1S 92 [/color] [color:"green"] 0F 87 17 D3 5C 87 47 34 5E 39 79 D7 C6 1A C9 4F E8 40 6C 67 E3 AB 84 4C 29 3F DD A3 F0 E6 37 86 6D 8A 23 CB 88 55 9D 47 78 B6 71 54 9F [/color] 82 D8 85 1C 3E 05 34 36 27 00 00 00 00 00 00 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:"blue"] P5 [/color] <- ----------------(NU ZICHTBARE P5) Deze parameter heeft als funktie het aangeven van de positie van nano 82, dit betekend dat de kaart niet op zoek gaat naar de signature, waarbij de gehele commando nagaat bij het zoeken naar de nano. Maar het gaat op "veilige modus" naar de positie aangegeven door [color:"blue"] P5 [/color]. (positie nano 82): - De signature en lengte van de 8 bytes, het is niet aannemelijk dat de nano 82 bij de laaste 8 posities van de commando aanwezig is. - De data voor de berekening van de signature moeten o zijn minst 8 zijn, en bij andere beeindigigen van nano 82 moeten deze gepaard gaan met op zijn minst 8 bytes. [color:"brown"] 8 - Cotrole van de waarde aangenomen door P5 [/color] De berekening die de kaart aangaat voor de bepaling va de postitie van nano 82 is de volgende (berekening a.d.v. 8 bits) [color:"red"]POSITIE 82 = LEN - (P5 +8) [/color] De waardes van P5 tussen 128 en 255 zijn niet geldig (verkrijgt status 9037). Als P5 = 0 dan verkrijgt men status 9038. Als P5 de waardes in de rang 1/127 aanneemt verkrijgt men status 9037. [color:"brown"] 9 - Controle van bit 7 van P2 [/color] (moet zijn = 1, status 9035 en tegengesteld geval) Dit is de bit die de SuperEncryptie aangeeft. [color:"brown"] 10 - Zoeken naar de key voor de berekening van de signature [/color] Voor de berekening van de signature is de key aangegeven door P2 noodzakelijk; De tweede van de INS geeft aan dat niet alle keys bruikbaar zijn. INS 40 : Alleen 'richtingaanwijzende' Key (Key Index in rang 0... in tegengesteld geval verkrijgt men status 9013 INS 3C : Alleen Operationele Key (Key Index in rang C...F) in tegengesteld geval krijgt men status 904A INS 38 : Enige verbonden data bij bruikbare key. Hier aangekomen begint het zoeken naar de key in EEPROM, als deze niet aanwezig is krijgt men status 901D, als men geen primary key vind, of status 901F, als men geen secundary key vind. Eenmaal de key teruggevonden, gaat men de checksum verifieren, als dit proces faalt dan krijgt men status 9028. [color:"blue"] ATTENTIE!! [/color] [color:"blue"] De status 9028 verktijgt men niet alleen bij het falen van de checksum!!! Het kan ook tijdens het proces die betrekking heeft op de-SSE verschijnen , maar de reden waarom dit gebeurd is op het moment onbekend. Voor onderscheiding van beide gevallen is het noodzakelijk om een analyse te doen van de 'respons-tijd'. 9028 pre-SSE : rond de 73000 cyclussen 9028 Key-Checksum : over de 190000 cyclussen [/color] [color:"brown"] 11 - Verificatie van nano 82 en berekening signature [/color] De kaart neemt de waarde van het berekende onder punt 8 en verifieerd of de nano 82 daadwerkelijk op aangegeven positie bevind. Als men deze niet vind krijgt men status 9002. Als nano 82 aanwezig is, dan gaat het met de berekening van de signature verder. De bytes die afhankelijk zijn van de waarde van de signature verstaan we allen en alleen de data die betrekking hebben op nano 82 totdat de inbegrepen P3 gelokaliseerd is. C1 40 01 B1S 6A [color:"blue"] 43 51 6E B1 92 0F 87 17 D3S 5C 87 47 34 5E 39 79 D7 C6 1A C9 4F E8 40 6C 67 E3 AB 84 4C 29 3F DD A3 F0 E6 37 86 6D 8A 23 CB 88 55 9D 47 78 B6 71 54 9F [/color] 82 [color:"red"] D8 85 1C 3E 05 34 36 27 [/color] 00 00 00 00 00 00 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 Bij dit voorbeeld alle bytes aangegeven in het blauw nemen deel aan de berekening van de signature. De key voor berekening van de signature, wordt door de Nibble onder P2 aangeduid, ondertussen de bits 5,6 de tabellen voor gebruik aangeven. Bit 6 / Bit 5 / ------------------------------------------ 0 / 0 / Tabel ROM (zelfde als Seca) 0 / 1 / Tabel EEPROM (A) 1 / 0 / 'Alternatieve' Algoritme 1 / 1 / Tabel EEPROM ( Als (Bit 6, Bit 5) = (1,0) dan is benodigd om de de decrypt middels een 'alternatieve' algoritme te executeren, memoriserend in de EEPROM van de kaart. Bij de v7 is zo'n algoritme niet aanwezig: een mogelijke INS verstuurd met (Bit6, Bit5) = (1,0) zou men status 9034 moeten krijgen. De analyse van Bit 6,5 wordt onmiddelijk gedaan voordat men begint met bevestiging van de aanwezigheid van nano 82. Het momet is aangekomen voor de berekening van de signature: het is interessant om de lengte van de commando in de gaten te houden, dat deze geen invloed heeft op betrokken tijd m.b.t. de berekening. Dit zou aan kunnen geven dat het gerealiseerd wordt middels de hardware (de crypto-processor). Als de berekende signature verschillend is van de aanwezige bij de commando dan is de status die men verkrijgt 9002 (ook wel 9002_B of 9002 type 2 genoemd). 9002_A en 9002_B verschillen tijdens respons-tijd: time(9002_> de time(9002_A) [color:"brown"] 12 - Decrypt SuperEncryption [/color] (Decrypt SE) De decrypt SE gebeurd a.d.h. van 'achtsten', acturerend de bytes die tussen de P3 en de nano 82 zitten. C1 40 01 B1S 6A 43 51 6E B1 92 [color:"red"] 0F 87 17 D3 5C 87 47 34 [/color] [color:"green"] 5E 39 79 D7 C6 1A C9 4F [/color] [color:"orange"] E8 40 6C 67 E3 AB 84 4C [/color] [color:"yellow"] 29 3F DD A3 F0 E6 37 86 [/color] [color:"purple"] 6D 8A 23 CBS 88 55 9D 47 [/color] [color:"pink"] 78 B6 71 54 9F [/color] 82 D8 85 1C 3E 05 34 36 27 00 00 00 00 00 00 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 1- Decrypt SE actueerd verschillend voor de INS 3C, zoals bij Seca ook het geval was. 2- Anders dan bij Seca, waarbij de incomplete 'achtsten' zichtbaar verschijnen, hier gebruikt men een proces van psuedo-cryptie van de 8 bytes met betrekkng op nano 82, om als doel geen enkele data zichtbaar te maken. [color:"brown"] 13 - Pre-parsing van de 'body' van de INS en executie van de commando [/color] Na de SuperEncryptie moeten we een INS type zoals bij seca, met een 'kanonieke' nanocommando, maar nu heeft het niet dezelfde executie. Een voorbeeld: C1 40 01 B1S 5C 10 01 [F0] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF [22] 1A 3F [21] 1A 7F [90] 5D B9 5D 66 CA DE DF FF 00 45 [90] 5C 55 A8 EE 6F 9F 67 AA 92 [90] 5E EF AB 5A 97 FA BC 6F 91 [82] C9 2D C3S 6C C4 77 74 8B...... ETC. ETC. De analyse van de nanocommand gebeurd van links naar rechts.... 1 + 1 byte [color:"green"] 10 01 [/color] - P3 en P4, niet beschouwd bij executie van de commando, het verspringd. 1 + 32 byte nano [color:"green"] F0 [/color] plus 32 data bytes (Customer Word Pointer bitmap) 1 + 2 byte nano [color:"green"]22 [/color] - Controle data abonnement 1 + 2 byte nano [color:"green"] 21 [/color] - Formulering data abonnement. 1 + 1 + 8 byte nano [color:"green"] 90 [/color] - Beschrijving van primary key (Index [color:"green"] 5D [/color] ) 1 + 1 + 8 byte nano [color:"green"] 90 [/color] - Beschrijving van primary key (Index [color:"green"] 5C [/color] ) 1 + 1 + 8 byte nano [color:"green"] 90 [/color] - Schrijven van primary key (Index [color:"green"] 5E [/color] ) Hier aangekomen bereikt men de nano 82, en verloopt en eindigt correct. Ervan uit gaande van dit commando: C1 40 01 B1S 5C 10 01 [F0] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF [22] 1A 3F [21] 1A 7F [90] 5D 89 5D 66 CA DE DF FF 00 45 [90] 5C 55 A8 EE 6F 9F 67 AA 92 [41] 5E EF AB 5A [90] 5E BC 6F 91 [82] C9 2D C3 6C C4 77 74 8B... etc. etc. 1 + 1 byte [color:"green"] 10 01 [/color] - P3 en P4, niet beschouwd bij executie van de commando, (overslaan) 1 + 32 byte nano [color:"green"] F0 [/color] plus 32 data bytes (Customer Word Pointer bitmap) 1 + 2 byte nano [color:"green"] 22 [/color] - Controle over data abonnement 1 + 2 byte nano [color:"green"] 21 [/color] - Formulering data abonnement 1 + 1 + 8 byte nano [color:"green"] 90 [/color] - Beschrijving van primary key (Index [color:"green"] 5D [/color] ) 1 + 1 + 8 byte nano [color:"green"] 90 [/color] - Beschrijving van priamry key (Index [color:"green"] 5C [/color] ) 1 + 4 byte nano [color:"green"] 41 [/color] - Beschrijving van PPUA Hier komt men bij nano 90, dit benodigd 9 data bytes, voorbijgaand aan nano 82. Dit is een voorbeeld van een 'foute' (slechte) parsing. In ieder geval zou men status 9600 krijgen (= pre-parsing). Volgende deel: status 9600 bij versch. INS. Saludos! 'Azazel miembro del equipo RAIDEN, la resistencia.' [color:"red"] LLORAMOS JUNTOS, GANAREMOS JUNTOS! [/color]
Azazel Geplaatst: 8 april 2003 Auteur Geplaatst: 8 april 2003 [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.' [color:"red"] LLORAMOS JUNTOS, GANAREMOS JUNTOS! [/color]
Aanbevolen berichten