Vervolg onderzoek

Azazel · 4 december 2002

Hallo satvrienden,

Hier het vervolg van het onderzoek, zodat we nu serieus met het onderwerp verder kunnen gaan, en op verzoek van Duwgati.

Ik zal eerst een korte samenvatting en de belangrijkste punten hier posten, van het topic analise log.

Petitie nummer van providers v/d kaart, bewijst dat seca aanwezig is op

de kaart, status van pin en waardes v/d registers m080.

0004 ... C1 16 00 00 08

00 00 00 0F 00 10 DB DB

90 00

0F = Nummer van providers. 0F(hexadecimaal) = 15(decimaal) = 1111(binair).

Analisatie van de binaire waarde: 1111 >>>> 4 providers aanwezig. SECA + 0064 + 0066 + 0067

00 = Status pin. 00 = Niet aanwezig

10 = Status van de bits 4 y 5 in de registers m080. 10(hexadecimaal) = 16(decimaal) = 10000(binair)

Analiseren van binaire waarde: 10000 >>>> waarde 4.bit = 1 , waarde 5.bit = 0

DB = Indicatie van algoritme tabel A

DB = Indicatie van algoritme tabel B

Petitie indentificatie van seca en providers. P1 geeft de aangevraagde provider aan.

0005 ... C1 12 00 00 18

00 00 53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00

90 00

00 00 = SECA ID

53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 = Tekst ASCII = SECA

00 00 00 00 = PPUA

00 00 = Datum einde abonement = 00.00.1990

0006 ... C1 12 01 00 18

00 64 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 20 20 20 XX XX XX XX 19 9F

90 00

00 64 = CANALSATÉLITE ID

43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 20 20 20 = Tekst ASCII = CANALSATÉLITE

XX XX XX XX = PPUA

19 9F = Datum einde abonement = 31.12.2002

0007 ... C1 12 02 00 18

00 66 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 32 20 20 XX XX XX XX 19 9F

90 00

00 66 = CANALSATÉLITE2 ID

43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 32 20 20 = Tekst ASCII = CANALSATÉLITE2

XX XX XX XX = PPUA

19 9F = Datum einde abonement = 31.12.2002

0008 ... C1 12 03 00 18

00 67 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 33 20 20 XX XX XX XX 19 9F

90 00

00 67 = CANALSATÉLITE3 ID

43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 33 20 20 = Tekst ASCII = CANALSATÉLITE3

XX XX XX XX = PPUA

19 9F = Datum einde abonement = 31.12.2002

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

****

Petitie register PBM. Hier, de C1 32, geeft de provider waar men de

informatie op aanvraagt (P1)

0009 ... C1 34 00 00 03

00 00 00

90 00

0010 ... C1 32 00 00 20 >>> P1 = 00 = SECA

04 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

90 00

04 = Nano 4 met de lengte 0 = Geen data meet te verkrijgen. Geen PBM voor

deze provider

0011 ... C1 34 00 00 03

00 00 00

90 00

0012 ... C1 32 01 00 20 >>> P1 = 01 = CANALSATÉLITE

83 00 00 00 00 00 00 30 86 04 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

90 00

83 = Nano 3 met lengte 8 = 8 bytes met data

00 00 00 00 00 00 30 86 = PBM CANALSATÉLITE

04 = Nano 4 met data 0 = Geen data meer aanwezig

0013 ... C1 34 00 00 03

00 00 00

90 00

0014 ... C1 32 02 00 20

83 00 00 00 00 00 00 00 00 04 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

90 00

83 = Nano 3 met lengte 8 = 8 bytes met data

00 00 00 00 00 00 00 00 = PBM CANALSATÉLITE2

04 = Nano 4 met lengte 0 = Geen data meer aanwezig

0015 ... C1 34 00 00 03

00 00 00

90 00

0016 ... C1 32 03 00 20

83 00 00 00 00 00 00 00 00 04 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

90 00

83 = Nano 3 met lengte 8 = 8 bytes met data

00 00 00 00 00 00 00 00 = PBM CANALSATÉLITE3

04 = Nano 4 met lengte 0 = Geen data meer aanwezig

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

Maestro Home Alone zei ons bij de rom6:

; Ins 16 : output providers bitmap, pin prot status, flags and table

indicators

; C1 16 00 00 08 answer: 00 00 xx xx aa bb cc dd

; xx xx : providers bitmap

; aa : pin protection status (0=inactive 1=active)

; bb : flags

; bit 0 - addressable bit 01 (20.1)

; bit 1 - addressable bit 06 (20.6)

; bit 2 - addressable bit 07 (20.7)

; bit 3 - addressable bit 03 (20.3)

; bit 4 - addressable bit 05 (20.5)

; bit 5 - addressable bit 02 (20.2)

; bit 6 - addressable bit 00 (20.0)

; bit 7 - addressable bit 08 (21.0)

; cc : algo table a indicator

; dd : algo table b indicator

;-------------------------------------------------------------------------------

; Ins 48 : set flags 20.2 and 20.5

; C1 48 00 00 01 (data byte, bit 5 and 4)

;-------------------------------------------------------------------------------

Naar aanleiding van beide INS kunnen we een beetje 'spelen' met de 48, we

veranderen in de ram de flag en met de 16 vragen we de register op, maar

opnieuw krijgen we dezelfde meededeling, dat er in de realiteit niets

veranderd op de kaart.

Ook wil ik vermelden dat volgens de INS 30 we kunnen 'spelen' met de status

van de pin en zijn verandering, maar dat zal ik een andere keer doen.

De waardes van de flag kunnen zijn: 00, 10, 20 y 30

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

Middels de INS 48 is het dus mogelijk om de indicatiegever van de tabellen

algoritme te veranderen, maar het effect gebeurd in het RAM geheugen van de kaart, daarom denk ik dat nadat er een reset is geweest de kaart terug gaat naar originele staat...???

Hoe zie jij dit? Zou je dit mischien ook kunnen testen om te kijken wat de resultaten zijn?

Wat je nog verder in de gaten moet houden, volgens de theorie van Home Alone

is:"20.5 5 ppv management (clear=all event transactions allowed) set by ins 48".

20.2 2 eeprom update indication (if set then indicate eeprom update in ins 40)

; set by ins 48

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

Wat betreft de bug op de nieuwe kaarten, zijn er wel degelijk vooruitgang geboekt, kijk even naar het volgende berichtje:

by jack70

Status 9600 en nieuwe Bug !!!

In de INS 3C en 40, bij de v6.2 betekende, dat de voorbereiding van de nano had gefaald.

quote:

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

9600 -->ins 0C P2=1 nano 23-90 absentins, ins 38 nano incorrect, ins 3C nano

82 nano problems, ins 3C nano 2C-15 null event

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

We zullen ditzelfde toepassen op de v7.0.

1) We gebruiken een cimando van de volgende type:

C1 40 0y Dz 6D 10 01 33 44 55 66 77 88 99 00 ss 11 22 33 44

55 66 77 88 C1 C2 C3 C4. .. C90

We varieren nu de bytes Ci (1<=<=90) met als doel om een

9034 te verkrijgen met ss=82 en de 9037 met ss!= 82.

2) Vervolgens nemen we een serie van geldige EMMs en gebruiken dan de

bug 38/36 met als doel om het volgende te verkrijgen:

C1 36 2y P2 14 - > 13 h1 h2 h3 h4 h5 h6 h7 h8 h9 h10 82

j1 j2 j3 j4 j5 j6 j7 j8 9000

Dus h1>=10h en h2=x9h of x1h (waarbij x een nummer is tussen de

0 en F) .

Het kan ook zijn dat h1<=Dfh (nodige conditie, alleen maar bedoeld voor de

gebruikte comando (zie 1), vergroten van de LEN van de comando, zoals volgens

deze condities moet horen.

Voor elke EMMs kunnen we proberen: P2=90h 91h B0h B1h F0h F1h

3) We versturen de comando verkregen onder punt 1, maar met bijvoeging

van de Bytes verkregen onder punt 2.

C1 40 2y P2 6D h1 h2 h3 h4 h5 h6 h7 h8 h9 h10 82 j1 j2 j3

j4 j5 j6 j7 j8 c1 c2. .. c90 - >

Azazel · 4 december 2002

De nieuwe INS voor seca2 C1 3C y C1 40) moeten op zijn minst een minimale

lengte hebben van 92 bytes (10 01+90) alhoewel ze ook groter kunnen zijn.

Superencryptie is hierbij verplicht en bovendien zijn de laatste 90 bytes

verbonden aan een onbekende cryptografische die volgens mijn weten ookwel

SSE noemt (Secondary SuperEncrypt) alhoewel men vermoed dat het ook een

encrypt kan zijn tipe RSA/720 bits.

Wat ik denk is middels deze instructie, het eerste wat de kaart doet is

het negeren van de SSE en de instructie op superencrypted laten staan en het

voorzien van een 'firm', wat er dan zoiets zou moeten uitzien:

C1 3C P1 P2 LEN P3 P4 xx xx xx xx xx .... xx xx 82 s1 s2 ... s7 s8 yy yy yy yy ... yy yy P5

xx xx ... xx -> data superencryptie

82 s1...s8 -> nano 82 en firm

yy yy ...yy -> padding

Die 9600 bij jou is niet te verklaren door mij.. Nano's zouden correct moeten zijn??

De kaart leest de waarde van de P5 die de 'nodige' lengte aangeeft en

'knipt' de instructie na de s8 (laatste byte bij de 'firm').

Vervolgens zou het de 'firm' na moeten gaan met de data P3 P4 xx xx ...xx

tot de nano 82 en als deze correct is, dan gaat men over tot het decrypten

van deze data wat de Parameter P2 aangeeft.

Als LEN=5C (92 bytes) we niet de mogelijkheid hebben om te weten te komen

wat de laatste positie is van nano 82, maar als we een INS construeren

met een grotere lengte dan kunnen we enige byte in de laatste 90 varieren,

in de vorm zodat de P5 de kaart laat 'zoeken' naar de nano 82 buiten de

SSE om.

Met de data van superencryptie en de gesitueerde 'firms' buiten de SSE, zou

het mogelijk moeten zijn om een soort 'bypass' te doen op de Secondary

SuperEncrypt.

Mischien is dit weer een vergezochte item van mij, maar het zou moeten kunnen werken...

Wat Jack70 bedoeld is denk ik, om enige data superencrypted met goede 'firms'

te 'breken' (zoals je kunt zien bij de INS 36) om deze vervolgens te versturen

in de vorm van een 38 of een 40, in een vorm zodat de kaart dit accepteerd.

Natuurlijk hebben we op het moment helemaal geen controle op de efecten

volgens dit proces, want we weten niet exact wat we versturen.

Azazel · 4 december 2002

Ik vroeg me dus af wat er zou gebeuren als je een INS 3C met LEN 5C (typische) naar de blackcard verstuurd?

Heb de proef op de som genomen, en het volgende is eruitgerold:

C1 3C 01 BE 5C 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 -> 90 02

En ik ga ff door met testen.... wat gebeurd er als we hetzelfde INS versturen, maar nu naar een niet bestaand key? (bv Key OF)

C1 3C 01 BF 5C 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 -> 90 02

En dit is het vreemde...!! Als key OF niet zou bestaan zouden we toch een ander respons moeten krijgen?? Iets in de geest van 90 1D???

Nu ga ik het aantal bytes van de INS verhogen tot bv. 90h bytes:

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 -> 90 02

Nu opnieuw met een kleine aanpassing:

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 1D

Kijk!! Nu krijgen we een andere respons, verlaring hiervoor zou kunnen zijn dat de nano82 is gevonden op de verwachte positie, en is het dus logisch om de 90 1D te krijgen --> geen key aanwezig om de 'firm' na te gaan.

Nu komt het!!

Met seca2 weten we inmiddels dat het proces van de 'firm' wordt toegepast bij de superencrypted Ins, en niet bij de 'vrije' Ins zoals dit bij seca1 het geval was, dus:

1 - De gezochte byte als het resultaat van de de-SSE zou moeten zijn 0x82.

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 1D

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 xx 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 02

C1 3C 01 BF 90 10 01

82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 xx 82

82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82

82 82 82 82 82 82 82 82 82 82 82 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 02

2 - De postitie staat vast, met uitzondering aan het einde.

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 1D

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 02

Zoals we kunnen zien, de funktie van het resultaat van de de-SSE van de laatste 90 bytes, de kaart gaat dan op zoek naar de nano82 bij de

bepaalde positie.

Als men die daar gevonden heeft, dan gaat het proces 'nagaan van de firm'

door; Als men een andere waarde vind dan geeft hij een 90 02, en als men bij het zoeken (aangegeven door de waarde resulterend van P5, gezien de vorige res.) verder gaat dan de aangegeven data 'velden' of buiten de toegelaten 'velden' dan krijgt men een 90 37 / 90 38.

Azazel · 4 december 2002

Hallo satvrienden,

Dit stukje tekst en onderzoek van Kimble is ZEER GOED GEVONDEN!

Het is een zeer vreemde zaak die we nu moeten uitzoeken en petje af voor Kimble. Ik heb het een en ander besproken en uiteraard getest. Ook heb ik mijn nieuwe 'satcollega's' van CANALTOPDIGITAL, gevraagd om hier eens naar te kijken, en we hebben dit, uiteraard, onder naam van Kimble, gepost op dat forum.

SSE RSA/720 bits.

C1 3C P1 P2 LEN P3 P4 xx xx xx xx xx .... xx xx 82 s1 s2 ... s7 s8 yy yy yy yy ... yy yy P5

xx xx ... xx -> date

82 s1...s8 -> nano 82

yy yy ...yy -> padding

LEN=5C (92 bytes) nano 82.

Ins 3C met LEN 5C

C1 3C 01 BE 5C 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 -> 90 02

Niet bestaande key (bv key 0F)

C1 3C 01 BF 5C 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 -> 90 02

90h bytes:

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 -> 90 02

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 1D

SSE 0x82 wijzigen.

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 1D

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 xx 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 02

C1 3C 01 BF 90 10 01

82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 xx 82

82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82

82 82 82 82 82 82 82 82 82 82 82 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 02

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 1D

C1 3C 01 BF 90 10 01

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 C6 -> 90 02

Als ik het tot zover heb kunnen simuleren is er sprake van een bug, kijk eens naar de 6C.

DE RSA is wel duidelijk geworden, de techniek die gebruikt is laat duidelijk zien dat we met een SSE RSA/720 bits hebben te maken.

Denk niet dat ik hiermee ver vandaan zit.

Als je om de instructie door de SSE (Secondery Super Encryption) heen gaat (Bypass), dan kan je dit hoofdstuk in principe overslaan en doorgaan met hoofdstuk3.

Onthoud het volgende.

1) De kaart reset bij bepaalde nano's

2) Er zitten 2 tabellen in

3) Er zijn instructies die je misleiden, en dit zou er best een kunnen zijn, of het is een verschrikkelijke bug.

Azazel · 4 december 2002

@Kimble,

Bekijk dit stukje tekst even, naar aanleiding van jou studie en onderzoek.

Bron CANALTOPDIGITAL.

Jcotu.

Ins > c1 3c 01 bf 90

Data > 10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f6

Status < 90 37

Nu nemen we en plaatsen we nano82 op de postitie zoals die door jou (kimble) wordt aangegeven.

Ins > c1 3c 01 bf 90

Data > 10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f6

Status < 90 37

Nu nemen we en veranderen laatste byte F6 voor C6:

Ins > c1 3c 01 bf 90

Data > 10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c6

Status < 90 1d

Kimble, een vraag aan jou... zou je de hele analise die je hebt gedaan en waardoor je die C6 hebt verkregen kunnen verklaren. Mischien dat de hele analise in het vervolg van de studie niet interessant is maar we moeten toch alles nagaan, vind je niet?

Verder zou er hier een logische verklaring of theorie op kunnen zijn:

C6=11000110

82=10000010

Het verschil tussen beide binaire waardes van 82 en C6 is dat bit 6 en bit 2 geactiveerd worden.

De waarde van F6 zou logischerwijs 11110110 moeten zijn.

Van 10000010 = 82 gaan we over naar 11000110 = C6, om dit te laten werken zou er een bit geactiveerd moeten worden zoals voorgaande analise, daarom die F6.

Ik denk dat we hiermee een goede weg inslaan en zeker wat kunnen bereiken.

Wat denk je er zelf van?

Saludos!

'Azazel miembro del equipo RAIDEN, la resistencia.'

4 december 2002

@ AZAZEL

Er zijn maar 2 verklaringen voor als je zwart/wit denkt.

a) Er is sprake van een bug.

Er wordt een bit geactiveerd.

Met betrekking tot de bit die wordt geactiveerd ben ik aan het kijken of deze bit een normale procedure is danwel er een bit is geactiveerd die in een later stadium (tevens?)wordt gebruikt om de tabel (adressering) te wijzigen.

Om dit aan te kunnen tonen is een studie noodzakelijk naar de onbekende data.

De klus waaraan ik begonnen ben is om de gehele status (alle data in de prom) van de kaart te bekijken na iedere instructie.

Pas dan kan ik met zekerheid zeggen wat die bit (allemaal) veroorzaakt.

4 december 2002

ga zo door mannen

veel succes

een fan

Azazel · 4 december 2002

Ok Kimble,

Ik ga met je mee... dus als ik je goed begrijp wil je na iedere instructie de status controleren.. Laat me weten of ik iets kan doen..

Bekijk ook even deze twee instructies: C1B0 & C1B4.

Zover bij mij bekend zijn deze geheel nieuwe instructies, heb je deze ooit eerder gezien. De werking van deze zijn nog niet bekend.

Ik spring hiermee wel van het ene naar het andere, maar mischien dat een en ander verband met elkaar zouden kunnen hebben.

Ps. Ik zal zelf ff op zoek gaan naar informatie omtrent deze nieuwe instructies, mischien dat er iemand is die weet wat ze doen..

Saludos!

'Azazel miembro del equipo RAIDEN, la resistencia.'

DIGIWIEW · 5 december 2002

volhouden jongens groeten digiwiew

Azazel · 5 december 2002

Hallo satvrienden,

@Kimble,

Ik ben wat aan het spelen geweest met wat ins. en het bekijken betreffende de bits die geactiveerd worden.

Om de studie te vervolgen heb ik even het listje van HA er bij gehaald op basis van de rom6:

; Ins 16 : output providers bitmap, pin prot status, flags and table indicators

; C1 16 00 00 08 answer: 00 00 xx xx aa bb cc dd

; xx xx : providers bitmap

; aa : pin protection status (0=inactive 1=active)

; bb : flags

; bit 0 - addressable bit 01 (20.1)

; bit 1 - addressable bit 06 (20.6)

; bit 2 - addressable bit 07 (20.7)

; bit 3 - addressable bit 03 (20.3)

; bit 4 - addressable bit 05 (20.5)

; bit 5 - addressable bit 02 (20.2)

; bit 6 - addressable bit 00 (20.0)

; bit 7 - addressable bit 08 (21.0)

; cc : algo table a indicator

; dd : algo table b indicator

;---------------------------------------------------------------------------

; Ins 48 : set flags 20.2 and 20.5

; C1 48 00 00 01 (data byte, bit 5 and 4)

;---------------------------------------------------------------------------

Hiermee kunnen we wat testen en wat spelen. Belangrijk om te weten is dat met de ins. 30 we wat kunnen spelen met de status van de pin en de varandering.

Heb ergens gelezen dat de waardes van de flags 00, 10, 20 en 30 zouden kunnen zijn.

Middels de ins.48 kunnen we de bits 4 en 5 activeren, en met de 16 kunnen we het terug lezen.

Ik zit nu nog in discussie met wat andere 'collegas' betreffende deze studie, en we gaan de waardes van de P2 en P3 hierin betrekken.

In een volgende fase zal ik de complete studie, die overigens nog niet klaar is, van de waardes P2 en P3, hierop posten en discusieren.

Overigens na wat rondneuzen en vele uren klatsen, heb ik inmiddels wat informatie bijeen gekregen omtrent de onbekende ins.

Ik zal alle informatie in een nieuwe topic starten.

Saludos!

'Azazel miembro del equipo RAIDEN, la resistencia.'

Azazel · 7 december 2002

Hallo satvrienden,

wat vinden jullie hiervan? Kimble, wat denk jij?

Ins > c1 3c 01 bf 90

Data > 10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f6

Status < 90 37

We nemen en zetten de nano 82 op de postite zoals Kimbel aangeeft:

Ins > c1 3c 01 bf 90

Data > 10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f6

Status < 90 37

Wijzigen van de laatste byte F6 voor C6:

Ins > c1 3c 01 bf 90

Data > 10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c6

Status < 90 1d

Na discussies met div. mensen, is het zo dat een vreemde zaak is? Missen we iets hier??

Kimble, alleen maar even zeggen dat het geweldig is wat je hebt gedaan, en kijk even hiernaar en zou het erg waarderen als je je mening hierover geeft, zodat ik... ja je weet wel, wat we over pm besproken hebben.

Saludos!

'Azazel miembro del equipo RAIDEN, la resitencia.'

7 december 2002

Prima,

Ben nog wat aan het vogelen met de checksum op het serienummer, naar aanleiding van die bit.

Om terug te komen op de analyse van de data van de gehele kaart zie je dat nano82 toch wel degelijk iets veranderd.

Er wordt een bit gezet, en een watchdog (waar die routine zit is nog onbekend) benaderd hem.

Ins > c1 3c 01 bf 90

Data > 10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f6

Status < 90 37

Na deze instructie is met de checksum van het serienummer iets vreemd gebeurt.

De verwachting was dat bij een inmiddels berekende lijst van mogelijke serienummers de checksum wederom niet klopte maar ik krijg nu WEL de lang verwachtte 9000.

7 december 2002

Ha die Kimble ! Doet me deugt om je nog steeds te zien rondwippen hier ! . <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />

Wat jij met Azazel allemaal overlegt is voor mij compleet chinees (!) maar daardoor heb ik er wel vertrouwen in <img src="/ubbthreads/images/graemlins/grin.gif" alt="" />....

Keep on going with the good work !

En jullie uiteraard een fijn weekend.

7 december 2002

Ik ben weer een stap verder. Zoals ik al aangaf wilde ik de status van de kaart zien na iedere instructie.

Omdat ik nano82 toch even niet met rust kon laten, heb ik de Jack-theorie dat de "traffic" 1,989 groter is dan bij de "oude kaart" helemaal in acht genomen.

Op een crypt/decrypt is de cyclus groot 43699, wat nu in een verhouding staat van 2,02 : 1,09

Getest op 300.000 ECM's met LEN 5C.

Ik moet dit even uitwerken op papier, want het vreemde is dat als ik met tabeltoewijzing ga spelen ook de OK en foutmeldingen varieerend veranderen. Dit is op de "oude" kaart niet het geval.

Maar het lijstje met de meldingen kan ik nu aardig in de hand houden 9000 9002 9024 9036 9037 9038.

Na een eerste cyclus staat de kaart in 9000, dan gebeurt er iets vreemds (de cyclus begint niet opnieuw) en de error verschijnt.

Die bit die is gezet heeft wel degelijk invloed. Het verhaal met die 9000 op de checksum van het serienummer is inmiddels met deze insteek weer van de baan.

Maar er gebeurt meer, nano82 is het laatste struikelblok voordat de signature wordt gechecked, als DE bit waar we het hebben goed staat dan komt de laatste stap en anders komt er een 9002 foutmelding. Klopt de signature dan gaat hij op 9000 en er is beeld, zo niet dan gaat hij ook op 9002.

Azazel · 8 december 2002

@Kimble,

dat zou de enige logische verklaring kunnen zijn...

Nu er achter zien te komen hoe men de nieuwe ciclus kan starten??

Wat je ook kan doen en voor mij nu onverklaarbaar is, is het feit dat je met P2 ook leuk kunt spelen en vreemde resultaten ontvang..

We kunnen verschillende status bytes verkrijgen, afhankelijk wat de waarde P2 is.

Een vb.

Ins: C1 3C 01 [color:"red"] BO DA [/color] 90

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

Data ins. = 3C

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

10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6

ACK kaart ontvangen-->90 4A

Ook hier zien we de positie van nano82, en de invloed die heeft op het respons.

C1 3C 01 [color:"red"] DC, DD, DE [/color] 90

10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6

ACK kaart ontvangen-->90 34

Dit vind ik erg vreemd....

Het volgende heb ik geprobeerd:

Hier kunnen we zien dat de status bytes en de waarde van P2, onderling niet kloppen van elkaar en om een logische 'lijst' te verkrijgen hier, heel erg moeilijk is (maar niet onmogelijk?)

C1 3C 01 [color:"red"] Ax, Cx, Ex, 2x, 4x, 6x [/color] 90

10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6

ACK kaart ontvangen-->90 24 <<< ins not allowed in atr level 3

Naar mijn mening is dit omdat bit 4 en P2 niet actief zijn. -> daarom status 90 24 (not allowed)

Als ik er snel overheen kijk denk ik dat er geen enkele 'oneven' byte, in de superieure nibble P2 aanwezig is.

We proberen het gewoon:

C1 3C 01 [color:"red"] 1x. 3x, 5x, 7x, 9x [/color] 90

10 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6

ACK kaart ontvangen-->90 35

Het vreemde hieraan is, is dat we duidelijk kunnen zien dat we status 90 35 kunnen verkrijgen door alleen maar bit 4 bij nibble van P2 te activeren.

Zoals je al zei Kimble, er zijn nog genoeg dingen die we diep onder de loep moeten nemen, de kaart reageert zeer verschillend. En om de reeds verkregen status te krijgen die je hier opnoemt, is het dus noodzakelijk een diepgaand studie te doen, op de waarde P2 en P3. Ook nano82 speelt hier een belangrijke rol in.

Maar ja, dat is mijn mening......

Ps. Je laatste PM, geeft ons dus zeker aan dat we toch voorzichtig te werk moeten blijven.......!!

Saludos!

'Azazel miembro del eqipo RAIDEN, la resistencia.'

Inloggen

Vervolg onderzoek

Aanbevolen berichten

Azazel

Beste reacties in dit onderwerp

Populaire dagen

Beste reacties in dit onderwerp

Populaire dagen

Azazel

Azazel

Azazel

Azazel

Gast

Gast

Azazel

DIGIWIEW

Azazel

Azazel

Gast

Gast

Gast

Azazel

Maak een account aan of log in om te reageren

Account aanmaken

Inloggen

Wie is er online 0 leden

Overig

Activiteit