vervolg studie seca2

[Gast]

@ Kimble //

Ga vooral door met waar jullie mee bezig zijn ,daar heb ik alleen maar bewondering voor. mijn kennis gaat helaas niet zover en ook heb ik daar de tijd niet voor.

Het lijkt mij alleen behoorlijk frustrerend dat een newbe ff komt zeggen datie wat gezien heeft ( met alle respect voor de newbe ) waar jullie al heel lang mee bezig zijn.

 

 

m.vr.gr. SPJ

[Azazel]

Hallo satvrienden,

 

@Kimble om nog even terug te komen op je vraag betreffende nano 36-38, heb ik de indruk dat je toch de INS 36-38 bedoeld???

Kijk eens even hiernaar, er is nl. een bug ontdekt, de bug is duidelijk te zien.... :

 

*************************************************************

Proces van de INS 38/36. Eerste fout

Een log van een c1 40 verstuurd naar de blackcard, de INS respondeerd met een mooie 90 00!! (een luxe tot nu toe denk ik) vanwege nieuwschierigheid veranderd naar een c1 38,

 

C1 38 01 B1 5C 10 01 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

 

Zoals je ziet een mooie 9000, iets wat niet te verwachten was...

Als we gaan kijken naar de disassembler V4.1 van Homealone zien we dat de structuur van de INS 38 op de V6 is:

 

C1 38 xx yy 1A 16 (d1) 2A (d2 d3) 2B (d4 d5) 86 (8 bytes) 82 (signature)

 

De kaart zou moeten kijken of de nanos 16, 2A, 2B y 86 in vaste posities aanwezig zouden zijn, en als dit niet het geval zou zijn, dan zouden we een 9600 als respons moeten krijgen! Maar als dit het geval zou zijn op de v7, dan zou de structuur van de 40 indentiek moeten zijn, en dat lijkt niet logisch.

 

 

Dit zou de volgende mogelijkheden kunnen zijn:

-Dat de actuele 38 een proces van nanos heeft zoals die van de 3c of de 40, en dat er een 'foute' Ins die we hebben verstuurd, een 16, een 2a, een 2b en een 86 (best moeilijk)

-Dat de data van de 38 geen nanos bevatten, geordend per positie

 

Gebruikmakend van de 9000, bij het gebruiken van de INS 36 om de gevraagde data van de 38 te verkrijgen, zou men het volgende moeten ontvangen:

 

c1 36 21 00 09-> 86 xx xx xx xx xx xx xx xx 67 00

c1 36 21 80 16-> 86 yy yy yy yy yy yy yy yy ff ff ff ff ff ff ff ff ff ff ff ff 90 15 *

c1 36 21 80 15-> 13 yy yy yy yy yy yy yy yy yy yy 82 yy yy yy yy yy yy yy yy ff 90 00

 

Volgens het formaat van de ins 36, wat na de 86 komt, zou een gedeelte van de verstuurde ins 38 moeten zijn, maar omdat deze niet verstuurd is was het een 40, in dit geval moet het een gedeelte zijn van de 40 (decrypt) (wat lijkt op een gedeelte van de nano F0).

De respons 9015 geeft aan dat de nano D1 (origineel) fout was, en in dit geval zou de kaart een respons moeten geven met een byte minder dan er is opgevraagd.

Overigens de vorige versies kaarten deden allemaal hetzelfde.

Maar het belangrijkste is dat het proces van de ins 36 zoals jij ook al had gezien, ook gewijzigd is, omdat in het geval c1 36 21 80 15 zou men een superencryptie moeten verkrijgen, m.a.w. de nano 82 zou hier niet zichtbaar moeten zijn!

 

Deze logs zijn ook interessant om even naar te kijken, het zijn drie verschillende ins c1 40. Met deze c1 40, veranderd in een c1 38, na het toepassen van de 36 heb ik dit verkregen:

 

c1 36 21 00 09-> 86 00 00 00 00 00 00 00 00 67 00

c1 36 21 00 15-> 86 00 00 00 00 00 00 00 00 03 82 ff ff ff ff ff ff ff ff ff 90 35 *

c1 36 21 80 15-> 13 xx xx xx xx xx xx xx xx xx xx 82 xx xx xx xx xx xx xx xx ff 90 00

c1 36 21 00 1d-> 86 00 00 00 00 00 00 00 00 83 00 00 00 00 00 00 60 00 04 82 ff ff ff ff ff ff ff ff 90 35 *

c1 36 21 80 1d-> 1c xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 82 xx xx xx xx xx xx xx xx 90 00

c1 36 21 90 1d-> 1c xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 82 xx xx xx xx xx xx xx xx 90 00

c1 36 21 a0 1d-> 1c yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy 82 yy yy yy yy yy yy yy yy 90 00

c1 36 21 b0 1d-> 1c yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy 82 yy yy yy yy yy yy yy yy 90 00

c1 36 21 c0 1d-> 86 00 00 00 00 00 00 00 00 83 00 00 00 00 00 00 60 00 04 82 ff ff ff ff ff ff ff ff 90 34 *

c1 36 21 d0 1d-> 86 00 00 00 00 00 00 00 00 83 00 00 00 00 00 00 60 00 04 82 ff ff ff ff ff ff ff ff 90 34 *

c1 36 21 e0 1d-> 1c zz zz zz zz zz zz zz zz zz zz zz zz zz zz zz zz zz zz 82 zz zz zz zz zz zz zz zz 90 00

c1 36 21 f0 1d-> 1c zz zz zz zz zz zz zz zz zz zz zz zz zz zz zz zz zz zz 82 zz zz zz zz zz zz zz zz 90 00 90 00

 

Met andere woorden, deze ins 40 had een structuur met geldige data (petitie van de PBM).

Dit sluit de eerste mogelijkheid uit, betreffende het nieuwe proces van de 38, want het is niet logisch dat de ins 40 het volgende structuur heeft:

 

C1 38 xx yy 1A 16 (00) 2A (00 00) 2B (d4 d5) 86 (00 00 00 00 00 00 00 00) 82 (signature)

 

Ik denk dat de decrypted c1 40 een begin heeft zoals:

 

F0 00 00 .. 00 ......

 

Dus wat ik denk is dat als het eerste gedeelte van de ins 36 niet gewijzigd is, dan zie ik hier een mogelijkheid om een stukje van de ins 40 (8 bytes) te ontcijferen. Deze moegelijkheid moeten we met beide handen aannemen

 

Kimble, als je niet naar deze ins refereerd en je het werkelijk hebt over de nanos, dan weet ik echt niet welke nanos dit zijn. Heb ook hier en daar dit nagevraagd maar vooralsnog voor de meesten onbekend....

 

Saludos!

 

'Azazel miembro del equipo RAIDEN, la resistencia.'

[veda]

Voor iedereen die zich interesseert in de studie van seca 2, heb ik een vertaling gemaakt van een italiaanse posting van GohanSuperSayan (via een franse tussenvertaling !). Daarom ook mijn excuses indien de vertaling niet helemaal 100% is.

 

Deze analyse leert ons dat in functie van de statusbytes van de antwoorden enerzijds en van wat de kommando's gewijzigd hebben anderzijds men kan afleiden welke nanos de kommando's zouden moeten bevatten.

Men begint dus de structuur van de INS en het spel van de NANOS te begrijpen.

 

Men maakt hierbij gebruik van de 38/36 bug . Deze bug bestond ook al op de vroegere kaartversies maar was zodanig miskend dat zelfs de seca ingewijden hem vergeten zijn (des te beter voor ons)

 

 

+++++ BEGIN POSTING ++++++++++++++++

-SeKa2 door GohanSuperSayan-

 

Laten wij beginnen met de nieuwe EMM’s te analyseren.

 

De momenteel door iedereen aanvaarde nomenclatuur is :

 

CLASS INS P1 P2 LEN P3 P4 [P5] ...

 

Ik zal hiervan dan ook gebruik maken...

 

-------------------------------------------------------------------------------

 

C1 40 01 B0 61 10 01 [P5] ...

[9019] -> klaarblijkelijk de verandering van de PPUA

[97F2] -> 11110010 (klaarblijkelijk de verandering van de PBM)

[97FA] -> 11111010 (geen verandering, stabiel)

 

Is equivalent met de vroegere C1 40 01 80 54 ... van seca1

 

-------------------------------------------------------------------------------

 

C1 40 01 B1 5C 10 01 [P5] ...

[9730] -> 00110000 (verandering van de key 0D + datum verstrijken abonnement)

[9728] -> 00101000 (verandering van de key 0C + datum verstrijken abonnement)

[973C] -> 00111100 (geen verandering, stabiel)

 

Is equivalent met de vroegere C1 40 01 81 4E ... van seca1 (updaten van de keys)

 

-------------------------------------------------------------------------------

 

C1 40 01 B0 5C 10 01 [P5] ...

[9000] -> Wist de keys van 01 tot 0E en zet de datum op 01-jan-1991

 

Is equivalent met de vroegere C1 40 01 80 28 ... van seca1 (desactivatie van de kaart)

(C1 40 01 80 28 10 01 10 02 10 03 10 04 10 05 10 06 10 07 10 08 10 09 10 0A 10 0B 10 0D 10 0C 10 0E 21 02 21 82 + sign)

 

-------------------------------------------------------------------------------

 

C1 40 01 B0 5C 10 01 [P5] ...

[9000] -> ?

 

C1 38 01 B0 5C 10 01 [P5] ... [9000]

C1 36 21 10 15 [86] 00 00 00 00 00 00 00 00 [03] [82] FF FF FF FF FF FF FF FF FF [90 35]

 

Vermits dit naar alle waarschijnlijkheid de data zijn van de nano 86 de bytes van 10 tot 17 van de inhoud van de C1 38 hebben wij dus deze instructie bijna volledig 00 ... 00.

 

Weinig nano’s (één ?) en de rest opvulling om tot een minimale lengte te komen van 5C (onrechtstreeks bepaald door P3)

De instructie x blijft voorlopig nog duister (ik heb ze zelf niet gekregen, en ik weet daarom ook niet wat het resultaat is) Zij is zeer kort en geeft daarom steeds het antwoord 90 00.

-------------------------------------------------------------------------------

 

Wij hebben gezien dat op seca2 de activering van de kaart en het updaten van de keys op dezelfde manier gebeurt als op seca1, met dit verschil dat ze hierbij verborgen zijn via de versleuteling van de commando’s ?.

 

Laten wij beginnen met de instructie voor het updaten van de keys :

 

C1 40 01 B1 5C 10 01 [P5] ... -> Updaten keys

 

Het equivalent van seca1 was :

 

C1 40 01 81 4E

[F0] 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

[22] xx xx

[21] xx xx

[90] 5D xx xx xx xx xx xx xx xx

[90] 5C xx xx xx xx xx xx xx xx

[90] 5E xx xx xx xx xx xx xx xx

[82] xx xx xx xx xx xx xx xx

 

Op de 7.0 bestaat er een manier om te evalueren wat een bepaalde instructie doet en welke nano ze bevat, zonder er nochtans in te slagen de SE te decrypten, nl :

 

1) Te zien wat er op de kaart verandert

2) Te kijken naar de statusbyte van het antwoord bij het terugzenden van de instructie

 

Temeer geeft ons de 38/36 bug de ontsleuteling van een deel van de instructie, en in het bijzonder lijkt het erop dat het met grote waarschijnlijkheid om de bytes 10 tot 17 zou gaan (in vergelijking met de vroegere kaartversies).

 

C1 38 01 B1 5C 10 01 [P5] ... [9000]

C1 36 21 10 15 86 FB FF FF FF FF FF FF FF 03 82 FF FF FF FF FF FF FF FF FF [9035]

 

Dit is waarschijnlijk een deel van nano F0.

 

Temeer door de resultaten te bekijken van de instructie op de kaart zien wij :

 

1) Er is wel degelijk een verificatie van de PPUA -> dus er bestaat een NANO F0 (33 octets) welke bevestigd wordt door de bug 38/36. (het is wel degelijk 32 voor F0 + de nano op zichzelf.... goed we hebben alles begrepen)

2) De gegevens worden geverifieerd en opnieuw geschreven-> dus bestaan de NANO’s 22 et 21 (3+3 bytes = 6 bytes)

3) De sleutels OK 0C+0***0E kunnen geupdate worden-> er zijn dus 3 nanos 9x (10+10+10 bytes = 30 bytes)

4) De signature , Nano 82 (9 bytes)

 

Door de som te maken van alle bytes bekomen wij :

33+6+30+9=78 -> 4Eh - met uitsluiting van de 10 01 [P5] – ontbreken er 0Bh bytes, maar deze bytes worden enkel gebruikt om de instructie te vervolledigen tot de minimumlengte bereikt is toegelaten voor de 5C (zie hogerop).

 

Indien wij deze instructie meerder keren terugsturen bekomen wij :

 

C1 40 01 B1 5C 10 01 [P5] ... [97 3C]

 

Na analyse van de statusbyte bekomen wij :

 

3C -> 00111100

 

Mag ik U eraan herinneren dat de bits van rechts naar links worden gelezen. Dus de uitvoering van de eerste nano resulteert in de meest rechtse bit, terwijl de achtste nano resulteert in de meest linkse bit.

De eerste en tweede nano werden dus uitgevoerd, terwijl er van de derde tot de zesde nano niks werd uitgevoerd (geen update van de eeprom nodig)

 

Dit laat vermoeden dat de structuur van de instructie er als volgt uitziet :

 

C1 40 01 B1 5C 10 01 [P5]

(0) [F0] 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

(0) [22] xx xx

(1) [21] xx xx

(1) [90] 5D xx xx xx xx xx xx xx xx

(1) [90] 5C xx xx xx xx xx xx xx xx

(1) [90] 5E xx xx xx xx xx xx xx xx

(0...0?) [00] [00] [00] [00] [00] [00] [00] [00] [00] [00] [00]

(0?) [82] xx xx xx xx xx xx xx xx

 

-------------------------------------------------------------------------------

 

Laten wij nu overgaan tot de tweede instructie :

 

C1 40 01 B0 61 10 01 [P5] ... -> Activering van de kaart

 

Het equivalent van seca1 was :

 

C1 40 01 80 54

[17] xx

[10] 03

[10] 02

[80] xx xx xx xx xx xx xx xx

[21] xx xx

[90] 51 xx xx xx xx xx xx xx xx

[91] 51 xx xx xx xx xx xx xx xx

[00]

[00]

[90] 5D xx xx xx xx xx xx xx xx

[90] 5C xx xx xx xx xx xx xx xx

[90] 5E xx xx xx xx xx xx xx xx

[41] xx xx xx xx

[82] xx xx xx xx xx xx xx xx

 

De 38/36 bug levert ons ook in dit geval de ontsleuteling van een deel van de instructie.

 

C1 38 01 B0 61 10 01 [P5] ... [9000]

C1 36 21 10 15 86 00 00 00 00 30 86 90 51 03 82 FF FF FF FF FF FF FF FF FF 9035

 

Dit is duidelijk een deel van de Bitmap en van de nano van het wegschrijven van de primaire MK01.

Dit zet er ons toe aan te denken aan een structuur van het volgende type :

 

C1 40 01 B0 61 10 01 [P5]

?? ?? ?? ?? ?? ??

[80] xx xx xx xx xx xx xx xx

[90] 51 xx xx xx xx xx xx xx xx

?? ?? ?? ... ??

 

Temeer, zien wij door de analyse van het effect van de instructie op de kaart het volgende :

 

1) De MK03 is gewist -> dus bestaat er een Nano10 03 (2 bytes)

2) De abo einddatum wordt geschreven -> dus bestaat er een Nano 21 (3 bytes)

3) Er wordt een nieuwe Bitmap aangemaakt -> dus bestaat er een Nano 80 (9 bytes) (wordt door de bug 38/36 bevestigd)

4) De MK01p+s wordt herschreven-> er bestaan dus 2 nanos 9x (10+10 bytes = 20 bytes) (de bug 38/36 bevestigt dit)

5) De sleutels OK0***0C+0E worden herschreven -> er bestaan dus 3 nanos 9x (10+10+10 bytes = 30 bytes)

6) De PPUA is gewijzigd -> dus er bestaat een Nano 41 (5 bytes)

7)Het E1 record wordt aangemaakt -> dus bestaat er een Nano B0 (12 bytes).

Opmerking : dit record komt in de plaats van de MK03 (Record 000C), wat wil zeggen :

- Indien men eerst op de kaart de C1…61 ontvangt van de activatie van de C1..5C van de update, dan is deze nano zeker te positioneren na het wissen van de MK03, maar is echter absoluut niet positioneerbaar met betrekking tot de sleutels.

(Indien iemand zeker is dat hij deze ontvangen heeft VOOR de C1…61 gelieve mij dat dan te bevestigen)

8) De regiocode wordt herschreven met de waarde 00 -> dus bestat er een Nano 17 (2 bytes)

9)Signatuur , Nano 82 (9 bytes)

 

Dit resultert in de totale som van de bytes :

2+3+9+20+30+5+12+2+9 = 92 -> 5Ch, met uitsluiting van de 10 01 [P5] , er ontbreken 02h bytes die een Nano 10 02 moesten zijn. Dit gegeven zal later worden gemotiveerd...

 

Indien wij meerdere malen deze instructie terugsturen, dan bekomen wij :

 

C1 40 01 B0 61 10 01 [P5] ... [97FA]

 

Na analyse van de statusbyte bekomen wij :

 

FA -> 11111010

 

Men heeft dus de eerste en de derde nano uitgevoerd, terwijl de overige nano’s niet werden uitgevoerd (geen update van de eeprom nodig)

 

Redenering :

 

-De Nano 80 wordt geen tweede maal uitgevoerd, de Bitmap is reeds geschreven, zij moesten dus een bit 1 geven in de statusbytes.

-Wij weten van de Bug 38/36 dat er direct na de NANO 80, er een NANO 90 volgt, en wij weten ook dat deze geen tweede maal wordt uitgevoerd, wat zou willen zeggen dat wij (11) moeten hebben in de statusbyte.

 

Laten we zoeken naar een koppel 11 in de statusbyte :

 

FA -> 111(11)010

 

Het eerste koppel (altijd van rechts naar links) positioneert de NANO’s 80 en 90 op de vierde en vijfde plaats.

 

Indien het juist zou zijn dat de bug 38/36 ons de bytes 10..17 zou geven, dan zouden we slechts van de 80 een deel van byte 7 hebben (zie hogerop)

Maar vooral, hadden we 3 Nano’s in 6 bytes moeten krijgen.

 

Als bevestiging van de positie van de PBM en de regiocode, bekomen we als statusbyte :

 

 

 

 

Op de kaartversie 6.0 van seca1:

 

C1 40 01 80 54 ... [9019] -> PPUA

C1 40 01 80 54 ... [9771] -> 0111(0)001

C1 40 01 80 54 ... [9779] -> 0111(1)001

 

De bit die van 0 naar 1 gaat tussen de tweede en derde verzending komt overeen met de PBM

De regiocode komt overeen met de eerste NANO

 

Op de nieuwe kaartversie 7.0 van seca2 :

 

C1 40 01 B0 61 10 01 [P5] ... [9019] -> PPUA

C1 40 01 B0 61 10 01 [P5] ... [97F2] -> 1111(0)010

C1 40 01 B0 61 10 01 [P5] ... [97FA] -> 1111(1)010

 

Dus wordt de PBM bevestigd als vierde NANO. De tweede NANO zijnde de regiocode.

 

Verder :

 

C1 40 01 B0 61 10 01 [P5]

(0) [10] 02 (op indirecte wijze bekomen.. uitleg volgt hierna)

(1) [17] 00 (bijna zeker)

(0) [10] 03 (zeer grote kans)

(1) [80] xx xx xx xx xx xx xx xx (zeker)

(1) [90] 51 xx xx xx xx xx xx xx xx (zeker)

(1) [91] 51 xx xx xx xx xx xx xx xx (zeer grote kans)

(1) [b0] xx xx xx xx xx xx xx xx xx xx xx xx (grote kans)

(1) [21] xx xx (Deze en volgende NANO’s zijn zeker aanwezig, maar hun relatieve posities zijn hypothetisch)

(1?) [90] 5D xx xx xx xx xx xx xx xx

(1?) [90] 5C xx xx xx xx xx xx xx xx

(1?) [90] 5E xx xx xx xx xx xx xx xx

(1?) [41] xx xx xx xx

(0?) [82] xx xx xx xx xx xx xx xx

 

-------------------------------------------------------------------------------

Enkelen onder ons hebben vastgesteld dat op de instructie C1 36 (SE verplicht) de bug 38/36 bij enige EMM’s 9015 geeft in plaats van de klassieke 9035

 

Op de kaartversie V7.0 met de instructie C1 38 werd eveneens vastgesteld dat de controle op de aanwezigheid van pseudonano’s werd opgeheven

 

Dus het is zo dat er niet meer gevraagd wordt naar de aanwezigheid van de pseudonano’s 16 , 2A, 2B, 86 vooraleer de instructie te valideren en dus uit te voeren.

 

Vroeger zou het antwoord 9600 geweest zijn (tot aan de 6.2)

Alhoewel deze controle nu weggevallen is, behoudt de 7.0 dezelfde logika met betrekking tot de positie van de nano’s

Dus in werkelijkheid zoekt de nieuwe kaart naar dezelfde parameters en op dezelfde posities als de eerdere kaarten.

 

Wel, herinnert U zich de Bug die ontdekt werd op de INS 32 (door C0m4nch3) ?

Hierbij verfris ik even Uw geheugen...

 

De instructie C1 34 00 00 03 xx yy yy, ter evaluatie van de gevraagde minimum LEN bij de volgende C1 32, maakt gebruik van de toegang tot een tabel van Len, die voorkomt op alle kaarten van het type (Es.: 6.0) :

 

 

code:

 

L54D2: db 09 09 03 0C 0C 06 11 ; Lengte van de tabel voor de INS 32/36

 

Indien de len verstuurd in de C1 32 kleiner is dan de waarde van de tabel (+1), dan ontvangt men een 9015, terwijl indien deze groter is men een 90 00 bekomt. Voor de valide waardes xx (aanvaard of geldig) zou men altijd 90 00 krijgen, maar met een nano 03 in het geval van te kort en nano 04 in het geval van een onvoldoende len.

Door opeenvolgend C1 32/34 te sturen was het dus mogelijk om te begrijpen welke de bytes waren die in de tabel voorkwamen. De echte bug was - alhoewel deze geen enkele controle had op xx - dat het toch wel mogelijk was deze te spatiëren van 00 tot FF

Dit liet ons toe 7 bytes door te schuiven in de tabel en dus toegang te krijgen tot de 256 bytes van de ROM van de kaart. Door het sturen van deze C1 32 kon men dus alle bytes met een Len < 5F terugvinden (dit door het feit dat de maximum len van de instructies 5F was).

Indien U zich mijn programma GohanSekaTools herinnert dan weet U dat deze een functie had om dit fragment van de ROM te extraheren en dit bij alle kaarten.

Op de kaarten 6.2 en 7.0 werd deze bug gefixt en in het geval van een C1 34 met (xx!=consequente waardes) ontvangt men een 9600.

 

Maar wat heeft dit te maken met de C1 38 ?

 

De C1 38/36 deelt een groot deel van de codes met de C1 34/32 van dewelke zij dezelfde functie uitvoert met enkele toevoegingen.

 

Wel op de 7.0 werd deze Bug NIET VERBETERD.

 

Het enige wat men moet onthouden is dat de C1 36 voor kleinere Len’s van 014h dà 6700.

Dit is nodig omdat men plaats moet reserveren voor de nano 86 (9 bytes), de Nano 82 (9 bytes), de Nano 03/04 van "continu/einde" en een byte van Len.

 

Dus de regels blijven behouden van de INS door het toevoegen van 014h aan de Len.

 

Voorbeeld op 4.0 ST ......

 

C1 38 00 00 1A [16] 06 [2A] 00 01 [2B] 00 01 [86] 11 22 33 44 55 66 77 88 [82] 32 D1 85 79 70 F0 E5 D2 [90 00]

C1 36 20 00 09 [86] 11 22 33 44 55 66 77 88 [67 00]

C1 36 20 00 0A [86] 11 22 33 44 55 66 77 88 [67 00]

C1 36 20 00 0B [86] 11 22 33 44 55 66 77 88 FF [67 00]

C1 36 20 00 0C [86] 11 22 33 44 55 66 77 88 FF FF [67 00]

C1 36 20 00 0F [86] 11 22 33 44 55 66 77 88 FF FF FF FF FF [67 00]

C1 36 20 00 10 [86] 11 22 33 44 55 66 77 88 FF FF FF FF FF FF [67 00]

C1 36 20 00 11 [86] 11 22 33 44 55 66 77 88 FF FF FF FF FF FF FF [67 00]

C1 36 20 00 12 [86] 11 22 33 44 55 66 77 88 FF FF FF FF FF FF FF FF [67 00]

C1 36 20 00 13 [86] 11 22 33 44 55 66 77 88 FF FF FF FF FF FF FF FF FF [67 00]

C1 36 20 00 14 <13> [86] 11 22 33 44 55 66 77 88 [03] [82] 38 4F 4F 4B 49 31 46 74 [90 00]

C1 36 20 00 15 <13> [86] 11 22 33 44 55 66 77 88 [03] [82] 38 4F 4F 4B 49 31 46 74 FF [90 00]

C1 36 20 00 20 <13> [86] 11 22 33 44 55 66 77 88 [03] [82] 38 4F 4F 4B 49 31 46 74 FF FF FF FF FF FF FF FF FF FF FF FF [90 00]

C1 36 20 00 25 <24> [86] 11 22 33 44 55 66 77 88 [D2] 00 01 01 00 00 00 00 00 00 00 00 00 80 E0 00 00 [03] [82] 5C 18 A0 0C 94 0F 48 7C [90 00]

 

Dit

Dit wil zeggen dat bij iedere valide EMM welke verstuurd wordt via de C1 38, de tweede byte (deze die op de vroegere kaarten overeenkwam met de parameter van de pseudonano 16) is de index vande tabel. Door de LEN te wijzigen bekomen wij 90 00 en 90 15 en kunnen we dus de waarde bepalen van de geindexeerde byte.

 

 

 

Hierbij de volgende test op de instructie :

 

C1 40 01 B0 61 10 01 [P5] xx yy ...

 

De waarde (die na de nieuwe SE) zich bevindt op yy is de index.

Vanaf 90 00 en 90 15 beaalt men de waarde van T[yy]=03.

Via de tabel vindt men een waarde 03 als index 02.

 

code:

 

db 09 09 03 0C 0C 06 11 ...

00 01 02 03 04 05 06 ... Index

 

Wij zouden 03’s kunnen bekomen ook boven de 7-de byte, maar gezien de structuur van de instructie C1…61 die reeds hypothetisch is, met een grote kans op 03. Dus de tweede byte van de C1…61 is bijna zeker 02

 

De dichtst benaderende structuur zou moeten zijn :

 

C1 40 01 B0 61 10 01 [P5]

(0) [10] 02 <-- Waarde bekomen via de Bug

...

 

De bug werkt wel degelijk…Het probleem is het bepalen van de geheugenindex van de bytes die geextraheerd worden via meerdere EMM’s. De activerings-EMM heeft altijd dezelfde tweede byte (02) en zal ons dus altijd dezelfde waarde geven

Maar indien wij een update-EMM gebruiken, zullen wij een index bekomen welke afhankelijk is van de waarde van de eerste byte van de NANO F0…dit geeft ons ROM, maar hoe positioneert men deze ?

 

Ter vervollediging en voor hen die het nog niet wisten....

De bug 38/36 werkt ook op de oudere kaarten, maar alleen vanwege de controle op de nano’s, was hij nutteloos (men kon geen 38 zetten in plaats van een 40).

 

Voorbeeld op een 4.0 ST :

 

C1 38 01 00 1A [16] 01 [2A] 00 01 [2B] 00 01 [86] 01 02 03 04 05 06 07 08 [82] FC 48 FE F8 57 28 51 D4 [90 00]

C1 36 21 00 15 <13> [86] 01 02 03 04 05 06 07 08 [03] [82] E5 54 ED 65 CA 60 42 16 FF [90 00]

 

Zelfde instructie, maar verzonden met SuperEncryptie :

 

C1 38 01 80 1A F1 42 52 94 CF 73 44 9C 6A 19 09 78 F3 D5 08 44 85 51 77 E9 0A C2 7A 5E 51 D4 [90 00]

C1 36 21 00 15 <13> [86] 01 02 03 04 05 06 07 08 [03] [82] E5 54 ED 65 CA 60 42 16 FF [90 00]

 

GohanSuperSayan

New Brave

 

-------------------------------------------------------------------------------

 

De bal ligt nu in het kamp van diegene die werkelijk seca2 wil bestuderen ....misschien is het reeds gedaan...en zij die graag hun bevindingen willen uitwisselen.

Laten we zien of we er zullen in slagen deze posting te vervolledigen....etc.........

 

GohanSuperSayan

New Brave

 

+++++Einde posting++++++++++++++++

 

Groetjes, Dany

 

[Gast]

beste mensen, is het wel verstandig dit hier allemaal open en bloot neer te schrijven ?

 

ik bedoel maar, welicht zijn er ook mensen die hier mee kijken en die eigenlijk de boel aan het spioneren zijn om nog beter die seca 2 te maken..

 

groetjes.

[Gast]

jahoor.. dit is op een paar postings na allemaal al gepost op diverse spaanse en italiaanse boards. je hebt gelijk dat het misschien niet al te handig is om mensen te wijs te maken maar geloof me maar dat komt wel goed. wij zijn er ook nog :-)

groeten

[Gast]

Uiteindelijk gaat het toch om de hobby en niet direct om het kijken. We willen alleen maar kijken wat voor leuke dingen men heeft bedacht. Het is de uitdaging en daarbij hoort een zekere vorm van spanning. <img src="/ubbthreads/images/icons/grin.gif" alt="" />

[Azazel]

Hallo satvrienden,

 

@Veda, een en ander over de lijst van Gohan zijn reeds besproken, kijk vooral naar de INS 26, 38 en 40. Ook ben ik uitgebreid over de bug ingegaan, zoals je kunt zien is deze duidelijk in de lijst van Gohan. Zoals we allemaal ook kunnen zien zijn de ins hetzelfde als bij seca1, alleen de responsen op de ins......

Toch interessant dat je hem in zijn totaliteit post.

 

@Kimble, heb je naar de INS 40 gekeken, en eventueel getest, als men deze veranderd naar de 36? Moet echt even doen, komen zeer interessante tevoorschijn, dat ons goed kan helpen naar het vervolg van de studie.

 

Om verder te gaan met deze leuke toepassing t.o.v. de ins 40, kunnen we ook het volgende doen:

Om een einde te maken al aan de postings van key's voor seca2 etc., is hier een methode om zelf na te gaan of betreffende key geldig is! Zo zou je dus zelf alle 'vermoedelijke' key's zelf kunnen nagaan of deze geldig is.

 

 

Ten eerste moeten we er wel vanuit gaan dat de algoritme voor de bits 5 en 6 van de P2 onveranderd is gebleven, dus hetzelfde is als seca1. Ik ga daar wel vanuit gezien het feit dat ik daar geen grote veranderingen heb kunnen waarnemen. Zou het Algo wel veranderd zijn dan heeft het geen zin om de volgende stappen te ondernemen, maar leuke feit is dat je dus lekker kunt testen met key's en instructies, en mischien dat we een dezer dagen iets verassend uitkomt.

 

We gaan dus weer gebruikmaken van de bug 38-36, we kunnen 8 bytes van een INS 40 verstuurd naar onze blackcard decrypten, om vervolgens te met de algoritme en de key. In dit geval gaan we het klassieke algoritme gebruiken en de key's 0c, 0d, en 0e.

 

-We versturen om te beginnen een c1 40, veranderd naar een 38 (dit is belangrijk dat het een ins 40 betreft maar met verandering in C! 38) naar de kaart, deze zou een respons moeten geven van 9000.

 

Vervolgens c1 36 21 00 09

De kaart zou bv. de volgende respons kunnen geven:

 

86 00 00 00 00 30 86 90 51 67 00

 

De bytes 00 00 00 00 30 86 90 51 zijn een gedeelte van de decrypte c1 40

 

-Vervolgens herhalen we de c1 38...

 

-Daarna de c1 36 21 8c 14, en we verkrijgen:

 

13 C7 7A FF EC 23 E4 D0 88 FD 32 82 xx xx xx xx xx xx xx xx 90 00

 

waar 7A FF EC 23 E4 D0 88 FD de 8 vorige bytes zijn, encrypted met de key 0c.

 

-Vervolgens weer de c1 38...

 

-Nu sturen we c1 36 21 8d 14, en men verkrijgd:

 

13 AD 2B 41 07 25 66 FA 0D 54 D0 82 E4 20 78 4F BA 51 45 91 90 00

 

waar 2B 41 07 25 66 FA 0D 54 de 8 vorige bytes zijn, encrypted met de key 0d.

 

-Weer eens de c1 38...

 

-En nu sturen we c1 36 21 8e 14, :

 

13 45 44 BF B4 16 8D 07 A5 E9 2C 82 35 3D 44 22 F2 C6 CB 48 90 00

 

waar 44 BF B4 16 8D 07 A5 E9 de 8 vorige bytes zijn, encrypted met de key 0e.

 

 

Deze testen heb ik destijds gedaan met een geactualiseerde blackcard. Als men de eerste bytes encrypt met de 'vermoedelijke key' en een van deze groepen verschijnt, dan kun je stellen dat de key geldig is.

Voor alle duidelijkheid, alle keys hier gebruikt zijn geen geldige keys.

 

 

Saludos!

 

'Azazel miembro del equipo RAIDEN, la resistencia.'

 

 

[Hendrik007]

@Veda en de andere boys

 

waar hebben jullie dit toch allemaal geleerd? Want ik wil mijn ook in seca 2 gaan verdiepen. Is er een bepaalde site waar je dit kunt leren?

 

Alvast bedankt,

en ik vindt het knap werk! Petje af!

[Gast]

Ik zou ook wel eens willen weten waar je het kunt leren om dit soort dingen te snappen.

Of is het gewoon een kwestie van 'goed' in exacte vakken zijn.

Keep up the good work.

<img src="/ubbthreads/images/icons/smile.gif" alt="" /> <img src="/ubbthreads/images/icons/smile.gif" alt="" />

gr,

 

 

 

[Gast]

azazel

ook ik vind dat ge prachtig werk afleverd

proficiat en van mij mag je gerust 10 keer sterren krijgen

doe zo verder en je word zoals reeds gezegt moderator

succes

 

 

[rienk]

het is beter dat hij geen moderator wordt <img src="/ubbthreads/images/icons/confused.gif" alt="" />

 

hehe want dan heeft hij hier geen tijd meer voor <img src="/ubbthreads/images/icons/grin.gif" alt="" /> <img src="/ubbthreads/images/icons/grin.gif" alt="" />

suc6 er mee

[Azazel]

Hallo satvrienden,

 

jongens, zoals reeds vermeld zit ik behoorlijk vast met mijn methode betreffende de vergelijkingen in binaire waardes.

Na dagenlang zoeken en flink worstelen met allerlei methodes en berekeningen ben ik geen meter opgeschoten. kijk hier nogmaals naar (ook vermeld op mijn eerdere posting):

3C Nr. 1 3C Nr. 2 3C Nr. 3

54 = 01010100 1D = 011101 23 = 100011

CD = 11001101 76 = 01110110 03 = 11

61 = 01100001 47 = 01000111 66 = 01100110

31 = 110001 50 = 01010000 85 = 10000101

3F = 111111 0E = 1110 D8 = 11011000

F9 = 11111001 30 = 110000 67 = 01100111

E4 = 11100100 BD = 10111101 8C = 10001100

36 = 110110 A1 = 10100001 7F = 01111111

19 = 011001 25 = 100101 10 = 010000

32 = 110010 6A = 01101010 7F = 01111111

7B = 01111011 B5 = 10110101 EA = 11101010

7B = 01111011 01 = 1 5E = 01011110

 

Mijn theorie over de vermoedelijke nano's gaat hier niet op.

 

Ik kreeg onlangs een vraag om bv. de blackkaart te laten verlopen, en daarna via CSD weer te laten actualiseren en dan de ins te 'capturen'. Het is mischien vrij interessant om de complete instructie te posten van de actualisering van de kaart, zoals die is gedaan op 31-06-2002: (na dit dus toen te hebben gedaan).

 

C1 40 01 B0 61 10 01 EE 4C 7F B3 AC 4A F1 6B 4F F4

68 9D 7E 08 FE B0 AD 1D F9 B3 D9 31 4F B9 4A BB 57

16 6A DA 9D F4 54 05 55 25 69 40 84 D2 57 0A 7C F0

92 F3 27 2F 40 1C 33 2C D2 9B 41 44 35 F9 0C 23 6E

48 9A 3F 9B AC 0B 33 74 0F BD FB DB 95 1C 98 2E B3

49 BF F5 D9 A1 72 9E D2 40 34 2F 6A 02 B2 1A 34 06

 

Zal jullie op de hoogte blijven houden m.b.t. nieuws e.d. rondom onze studie naar het seca2 gebeuren.

 

Saludos!

 

'Azazel miembro del equipo RAIDEN, la resistencia.'

 

 

[Azazel]

Hallo Satvrienden,

 

Nog een leuke feitje is een meting van intensiteit van de v7 met het programma Protek:

 

Het lijkt erop dat de kaart geen status 'standby' heeft, vanaf het moment van verbinding. Het verbruik ligt tussen de 5,7mA of 5,8mA, en er verschijnt, zoals men kan zien, een kleine variatie na het opvragen van informatie en activering v/d kaart, een daling van enkele decimalen mA (punt 1640 v/d grafiek).

 

Saludos!

 

'Azazel miembro del equipo RAIDEN, la resistencia.'

[Azazel]

Hallo satvrienden,

 

Wat betreft de vergelijkingen met binaire waardes houd ik het voor gezien, zoals eerder vermeld ben ik nog niet veel verder gekomen.... Dus ik zet dit even opzij en ga met iets nieuws verder. Pak het mogelijk in een later stadium weer op....

 

Heb me meerdere malen afgevraagd: wat is nou eigenlijk het doel?, wat wil ik bereiken? Nou dat lijkt een simpele vraag, maar is het toch niet... Als men de juiste antwoord weet dan kan men specifiek verder gaan met het onderzoek..

Na lang nadenken wat ik als primaire taak, alles op alles moet zetten, ben ik toch tot de conclussie gekomen om wat in mijn ogen het gemakkelijkste is, toch maar als doel te stellen om een mogelijke 'bug' in de kaart zien te vinden. Ik weet niet of dit helemaal verstandig is en het alleen maar tijdverspilling is, maar men moet alles in de strijd gooien.

 

Dus, om een lang verhaal kort te maken, mijn primaire taak is de 'bug'.

 

Vanuit deze gedachtegang heb ik vele, vele uren besteed aan het enkel en alleen maar lezen van vele postings, niet alleen op deze forum, maar ook op vele andere spaanse en italiaanse forums..

Toch kwam ik weer terecht op deze forum (laat toch weer zien dat sat4all, één van de beste, mischien wel de beste forum is op het net), maar goed, wat mij dus opviel is een bericht die ik via pm mocht ontvangen van Melt_Down, waar overigens mijn dank. Ik citeer:

"Als je het programma niet kan uitlezen dacht ik dat je mischien een heel klein programmatje kon schrijven waarmee je het eerste gedeelte van de kaart kan overschrijven wat de rest wat nog niet overschreven is uit kan lezen dan heb je iig een gedeelte van de code (dit kan je volgens mij als je bijvoorbeeld geen read commando hebt, doen met jumps (een loopje met een test of de eerste byte kleiner/groter dan 128 (zeg kleiner) dan testen of het kleiner of groter dan 64 is (groter) dan weet je al dat het tussen de 64 en 128 ligt en zo door (ken wel lang duuren denk ik."

 

Ben hier uiteraard over gaan nadenken en ben nu in een fase waardoor ik denk iets te kunnen bereiken via deze methode....

In de eerste instantie weet ik dat het volgens de specificaties van SECA-MEDIAGUARD in zijn 'conditional acces' kaarten het dus niet mogelijk is om bep. veranderen, herschrijven, etc..

Maar na verder speurwerk, ben ik er achter gekomen dat alleen de ROM v/d kaart executabel is, en de eeprom/ram GEEN ruimte biedt voor dergelijke aanpassingen. Ook weet ik dat de ROM ontastbaar is........??

Mijn idee is om bv een 'worm' of iets dergeliks in de v7 kaart te programmeren en vervolgens te 'dumpen', maar dit lijkt technisch gezien niet mogelijk. Maar ja, ik denk maar weer zoals altijd... NIETS IS ONMOGELIJK.

Kijk, ze hebben de chip van elk kaart gewijzigd, en mischien dat ik daar iets mee kan doen.

Op moment is er niemand die dit heeft geprobeerd, maar iemand moet de eerste zijn.

Graag zou ik van de wat ervarene mensen hierover in discussie willen gaan en samen hieraan werken, gezien het feit dat ik dit alleen niet kan. Mensen met ideeen of met ervaring m.b.t. 'worms' e.d. zijn ook welkom.

Daarna zouden we ins naar de kaart kunnen sturen om te zien of we een bug kunnen vinden, iets in de trant van:

Een ins 'captueren' van bv. c1 40 xx xx xx xx ....

om vervolgens de eerste 2 paar bytes veranderen naar bv. 00 00 xx xx xx xx met exact hetzelde einde zoals de 'gecapturde' ins. en eindigen met FF FF xx xx xx.

 

Dit zou betekenen dat we 16 elevaties van 4 =65.563 ins en dan bij alle responsen zoeken naar iets 'raars', op zoek dus naar een bug.

 

 

Ik weet dat dit in de eerste instantie een onmogelijke taak lijkt en ontzettend veel tijd in beslag gaat nemen, maar ja, we kunnen ook niets doen en rustig afwachten....

Mocht het niet lukken, dan zijn we weer een beetje wijzer geworden en kunnen de 'negatieve' resultaten mischien toch 'indirekt' een goede bijdrage leveren naar de verdere vervolg van de studie seca2.

 

Deze methode is voor mij ook nog allemaal nieuw en moet hier op bep. onderwerpen nog diep in duiken en bestuderen, maar zoals reeds vermeld alle hulp is ZEER welkom! Mischien zijn er ook lezers met ervaring, die een andere mening hebben, en die me het tegendeel kunnen overtuigen van deze methode, dat scheelt weer een hele hoop tijd natuurlijk en kunnen we weer iets nieuws bedenken. Ik ben zeer benieuwd naar jullie reacties....

 

Ooh ja, bijna vergeten... de eeprom/ram heeft geen ruimte........

Ik ga hier ook op onderzoek uit, wat voor info bevat de eeprom? Waar dient het voor? Is het wel allemaal nodig? Kunnen we bep. informatie wissen op de v7?

Op pagina 2 van deze topic, het eerste bericht (van Kimble) staat de vermoedelijke informatie van de eeprom. Van hieruit dus testen waarvorr het dus dient en of het nodig is om de kaart te laten funktioneren. Van daaruit gegevens wissen en zo ruimte creeren op de ram.

 

Saludos!

 

'Azazel miembro del equipo RAIDEN, la resistencia.'

[Gast]

Mischien een dom idee hoor maar is het nou echt niet mogelijk een orginele kaart zodanig te loggen dat het alemaal zichtbaar wordt op een spectrum analizer ? en is hier niet meer mee te doen dan ?

we moeten denk ik een brute force zien te vinden om dit te realiseren.

de provider kan toch de kaart van nieuwe keys voorzien ....

dus waarom zouden wij niet de commando,s kunnen loggen voor het reproggen van de kaart met de gegevens om te kunnen kijken.dus de data stream van en naar de kaart.

zit mn eigen gek denken over de mogenlijkheden ...maar ben nog niet tot een goede oplossing gekomen.

aleen iets vreemds is me wel opgevallen ...mischien niet direct met dit te maken of wel mischien.

als ik zonder een geldige kaart naar een 16/9 kanaal ga dan schakeld het beeld van zelf op 16/9 ...dus er word bepaalde info wel doorgelaten door het kanaal lijkt me .

staat deze info los van de encryptie ?

we gaan weer lekker verder zoeken naar een oplossing <img src="/ubbthreads/images/icons/smile.gif" alt="" />