De juli puls

[Zilverster]

@Rob Thonus,

 

Citaat:

Betekent dit dat de ci-modules waarbij de update niet werkt deze maand deze instructie niet goed verwerken ?

 

 

Kort antwoord, ja.

 

 

Citaat:

Dan is de volgende vraag, wordt de update volgende maand een normale die wel weer overal goed werkt, of blijft dit zo gaan.

 

In het laatste geval betekend dat dus dat bijv de Aston 1.05 niet meer zo bruikbaar is.

 

 

Moeilijk te bepalen, gezien ik + niet ben, maar als ik mijn Aston niet meer kan gebruiken is de kans heel groot dat + publiek wordt dit jaar en als ze het nog gekker maken, nemen we ze in de toekomst toch gewoon over en schenken jullie de zenders FTA <img src="/forums/images/graemlins/loldev.gif" alt="" /> <img src="/forums/images/graemlins/loldev.gif" alt="" /> , gr.

 

Zilverster.

[Gast]

@xyzzy,

 

Superleerzaam! Bedankt!

Heb misschien voor een mede zelfstudent wat literatuurverwijzingen of linkjes op het gebied van de verwerking van emm's/ecm's tot C1 commando's?

Naar mijn smaak zou dat in principe net als en50221, iso13818, etc. gestandaardiseerde publiekelijke informatie moeten zijn? Het gaat hier namelijk niet om het ontfutselen van de geheimen van seca, maar puur om een ontvanger of cam te programmeren om netjes met een officiële seca abonnementskaart te kunnen werken..

Als je me kunt helpen, bij voorbaat dank!

[Gast]

Dus is het toch zo dat de tabel 84 samen met de 82 gebruikt wordt ? Zitten die samen opdezelfde emm-pid.

Als ik een 84 instructie log en de aanpassing van de C1 40 71 ... doe dan kan ik dat gewoon met een phoenix naar mijn kaart sturen ?

[xyzzy]

@Zilverster

 

>Blijft de vraag waarom mijn Aston 1.05 cam er een C1 40 31 B1 65 van maakt i.p.v. C1 40 71 ..... , gr.

 

Weet niet waarom deze Cam dat zou doen, hoewel er sprake van is dat

van het high nibble van EMM[8] er slechts drie bits gebruikt zouden worden.

Misschien doet de CAM een extra (foute) shift.

 

Verder viel mij op dat de uniek updates (EMM's met een 0x82 als eerste byte)

over het algemeen 0x30 in EMM[8] hebben staan. Deze moeten dus als resultaat

een C1 40 31 .. geven.

 

@Hermanator

 

Info is (niet makkelijk) te vinden.

Ik denk dat alle info uit gedisassembleerde CAM's komt.

 

kijk eens naar

 

http://joshyfun.sytes.net/SECA_CAM_HowTo_1.03.pdf

SECA FAQ (b.v. de hele oude seca1 FAQ.)

de sources van PMcam

de sources van vdr-sc

 

Groetjes xyzzy

[Gast]

@xyzzy,

 

Wat een geweldige link die pdf! Dat is tenminste nog eens leerzaam!! Geweldig dat je ons helpt met dat soort info! Daar ga ik van de week echt eens lekker voor zitten.

 

Superbedankt! <img src="/forums/images/graemlins/biggthumpup.gif" alt="" /> <img src="/forums/images/graemlins/biggthumpup.gif" alt="" /> <img src="/forums/images/graemlins/biggthumpup.gif" alt="" />

[Zilverster]

@xyzzy,

 

 

Citaat:

Verder viel mij op dat de uniek updates (EMM's met een 0x82 als eerste byte)

over het algemeen 0x30 in EMM[8] hebben staan. Deze moeten dus als resultaat

een C1 40 31 .. geven.

 

 

Wat je hier schrijft klopt <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" />, gr.

 

Zilverster.

[Gast]

Dag,

 

Veel dank aan xyzzy die ons opmerkbaar maakte aan de faq van Joshyfun en natuurlijk nog meer dank aan de mens die dat schreef.

Dus heb ik begrepen dat de provider een emm-pid gebruikt om de kaarten per serialnum te updaten en een ander emm-pid om ze per ppua aan te passen.

Nu heb ik met het programma Si-Analyser van Micha de stream doorgenomen en dit geeft me hetvolgende voor de CAT :

}

}

Conditional Access Table [CAT] at PID 0x0001

{

CRC32 = 0x47FC29B5 (OK)

section_syntax_indicator = 1 (OK)

section_length = 0x001C

version_number = 0x04

current_next_indicator = 1 (is applicable)

section_number = 0x00

last_section_number = 0x00

descriptors

{

descriptor = 0x09 (CA_descriptor)

{

descriptor_length = 0x11

CA_system_ID = 0x0100 (SECA - Mediaguard)

CA_PID = 0x00C1

entire raw data (HEX and ASCII) :

03 E1 2F 00 6E E0 C9 00 9F E0 CC 00 0E .á/.nàÉ.ŸàÌ..

 

 

Volgens deze gegevens worden de normale emms op pid 0x00C1 verzonden,

en zouden en 3 andere specifieke pids zijn voor provider 00 6E ( E1 2F),

prov 00 9F (E0 C9) en voor prov 00 0E (E0 CC).

Nu heb ik al een tijdje gelogd op mijn provider 00 6E maar er komt niets door.

Ik log met een nokia via de scsi-poort dus mis ik weinig instructies en alle instellingen zijn goed.

Nu had onze vriend Metropar me een werkwijze aangegeven om met een solosammy te zien of er updates doorkwamen en die had ik inderdaad., ik zag regelmatig het ppua nummer veranderen., dus moet er iets aan de decoder doorgegeven worden en dat moet men toch ergens terugvinden.

Nu, kan er me iemand vertellen of ik op E1 2F moet loggen of dat dit met het een of ander getal zou moeten geand, gexord, of gevierkantswortels moeten getrokken worden, of zoiets anders

Het is de bedoeling om de instructie voor mijn ppua te loggen en nadien met de phoenix mijn kaart up te daten, zolang mijn abo natuurlijk geldig is.

 

Vriendelijke groeten...

[hd196]

@rodajo:

die E12F moet je anden met 1FFF, dan krijg je 012F

[Gast]

Dat is inderdaad de waarde die dvblog van Nirvana me aangeeft, maar daar ook nog niets.

Enfin, we zoeken verder.

[Gast]

@Rodajo,

 

Citaat:

Conditional Access Table [CAT] at PID 0x0001

{

CRC32 = 0x47FC29B5 (OK)

section_syntax_indicator = 1 (OK)

section_length = 0x001C

version_number = 0x04

current_next_indicator = 1 (is applicable)

section_number = 0x00

last_section_number = 0x00

descriptors

{

descriptor = 0x09 (CA_descriptor)

{

descriptor_length = 0x11

CA_system_ID = 0x0100 (SECA - Mediaguard)

CA_PID = 0x00C1

entire raw data (HEX and ASCII) :

03 E1 2F 00 6E E0 C9 00 9F E0 CC 00 0E .á/.nàÉ.ŸàÌ..

 

 

Volgens deze gegevens worden de normale emms op pid 0x00C1 verzonden,

en zouden en 3 andere specifieke pids zijn voor provider 00 6E ( E1 2F),

prov 00 9F (E0 C9) en voor prov 00 0E (E0 CC).

 

Dit wordt zo langzamerhand een bijzonder leerzaam draadje! <img src="/forums/images/graemlins/grin.gif" alt="" />

 

Volgens ISO13818-1 is dit de beschrijving van de CA-descriptor:

 

Table 2-52 -- Conditional access descriptor

Syntax No. of bits Mnemonic

CA_descriptor() {

descriptor_tag 8 uimsbf

descriptor_length 8 uimsbf

CA_system_ID 16 uimsbf

reserved 3 bslbf

CA_PID 13 uimsbf

for ( i=0; i<N; i++) {

private_data_byte 8 uimsbf

}

}

 

Het programma waarmee jij de CAID table logt doet een interpretatie van de reeks bytes van de CAID table en de CA-descriptors zoals die in de stream wordt verzonden.

 

Ik heb aan de hand van jouw gelogde data de oorspronkelijke reeks bytes samengesteld zoals ik denk dat die CA-descriptor eruit heeft gezien. Het eerste deel vóór de private databytes heb ik samengesteld volgens de ISO13818 beschrijving. Vervolgens heb ik de aangegeven "entire raw data" erachter geplakt, en het ongelooflijke "toeval" wil dat ik dan ook precies aan een lengte kom van 11 (hex), de lengte van de ca-descriptor die jouw programma aangeeft.

 

09110100E0C103E12F006EE0C9009FE0CC000E

 

09 = Descriptor Tag

11 = Descriptor Length = 17 decimaal

0100 = CA_System_id (Seca)

E0C1 = CA_Pid (and 1fff = 00C1)

 

De rest moeten dan dus de private databytes zijn. En dat klopt want achter het lengteveld (11) volgen inderdaad 17 bytes.

Dus 03E12F006EE0C9009FE0CC000E zijn de private databytes.

 

En dát vind ik dus nu zo leerzaam, want tot op dit moment had ik geen idee wat die private databytes betekenden. Daar wordt in IS13818 alleen maar over gezegd dat een provider dat naar eigen inzicht mag invullen. Uit jouw bericht begrijp ik nu dus dat daarin per provider nog een aparte EMM-Pid wordt gegeven. Weer een stukje van de puzzel gevonden. <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" />

 

Dit is een seca CA-ID descriptor die ik hier uit de Nederlandse streams uit een CAID table heb gelogd:

 

090D0100E0B602E0B7006AE0B80076

 

Dat betekent dat hierin de private databytes zijn:

02E0B7006AE0B80076

 

Als de veronderstelling klopt, dan zou dat betekenen dat er voor provider 006A EMM's worden verzonden op pid 00 B7 en voor provider 0076 op 00B8.

 

Ik denk dat de betekenis van het eerste byte dan ook direct duidelijk is. In jouw log is het eerste byte namelijk 03 en er zitten 3 provider emm-pids in, en in mijn log is het 02 en er zitten 2 provider emm-pids in. Zou toeval kunnen zijn maar dat is dan wel erg toevallig. Meer loggen zou hier uitsluitsel over kunnen geven.

 

Ik ga nu eens aan de slag met die private databytes en kijken wat er verzonden wordt op de pidnummers die hierin worden opgegeven. Wordt vervolgd! <img src="/forums/images/graemlins/grin.gif" alt="" />

 

We zijn weer lekker bezig!! <img src="/forums/images/graemlins/grin.gif" alt="" />

[IceKiller]

indd zeer intressant na examens is allemaal 'proberen' <img src="/forums/images/graemlins/wink.gif" alt="" />

[Gast]

Dag Hermantor en andere vrienden

 

Provider 006E is degene die hier in West-Centraal Afrika werkt.

Provider 009F zou de provider zijn voor Canal Satellite Réunion, maar kan er momenteel geen uitsluitsel over geven.

Ik vermoed dat ze dezelfde beeld en data stream gebruiken, komt ze natuurlijk goedkoper uit.

Provider 000E was de vroegere seca1 provider voor 006E.

 

Nu log ik al op pid 012F, wat me normaal emms voor de ppua zouden moeten geven, maar ik krijg er niets door. Wel krijg ik met de nokia easysammy in het dvkmenu 7 aanduiding van updates van de ppua's. Dus die moeten ergens van komen. Ok, ze komen uit de hemel, maar ik zou willen weten hoe ik ze verduiveld bij de lurven kan nemen.

 

Hebben jullie data op pid 00B7 en pid 00B8 ?

 

Dus samengevat zou ik zeggen waar komen de emms vandaan ?

Een gedeelte is algemeen bekend, en het andere ook mits nog enkele uitleg.

 

Groeten

[Gast]

Heb een beetje geexperimenteerd en heb op een gegeven ogenblik het volgende gevonden:

 

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Receive EMM : [82] ,2 ,6

0x82,0x00,0x6d,0x00,0x00,0x07,0xc7,0x10,

0xa3,0x00,0x6a,0x30,0xb0,0x10,0x01,0x02,

0xdd,0x40,0xc0,0x1b,0x2f,0x51,0xd2,0x6b,

0xd2,0x39,0x4d,0x2f,0x78,0x97,0x56,0x7b,

0x48,0xdf,0x6a,0x35,0x62,0x32,0x42,0x14,

0xdd,0x0a,0x99,0x9b,0xec,0xea,0x43,0x74,

0x98,0x79,0x2a,0xc5,0xdf,0xfa,0x80,0xd2,

0x2e,0xa9,0x74,0xd4,0x51,0xa7,0x51,0xe5,

0x62,0x83,0x24,0x6d,0xc6,0x76,0x44,0x1f,

0x8d,0x1b,0xac,0xcc,0xd5,0xd8,0x62,0xea,

0x92,0xc2,0x8e,0xcf,0x7d,0xf9,0x99,0x12,

0xb0,0x83,0x7c,0xcd,0x6b,0x27,0xcc,0x48,

0xa6,0xef,0x01,0xf9,0x14,0x78,0xf0,0xcc,

0x6a,0x48,0x59,0x99,0x3e,0x43,0x04,0x77,

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Receive EMM : [82] ,2 ,6

0x82,0x00,0x6b,0x00,0x00,0x09,0xf7,0xdf,

0x1b,0x00,0x6a,0x30,0xb3,0x10,0x01,0x35,

0x95,0x8b,0x19,0x2c,0xdf,0x8e,0x89,0x1e,

0x6e,0x53,0x60,0x5c,0x0e,0x7a,0x23,0xce,

0x41,0x2f,0x90,0x18,0xbc,0xfd,0x3a,0xff,

0xaa,0x3d,0xca,0x09,0xf8,0x9c,0x66,0xde,

0x97,0xd8,0x9f,0xc0,0x4a,0x0e,0x45,0x8a,

0x83,0xa8,0x2e,0x16,0x22,0x68,0xbc,0x35,

0xe9,0x35,0x7e,0xd1,0xea,0x8f,0xd2,0x6d,

0xd0,0xae,0x7b,0xc6,0x5a,0xee,0x68,0xc5,

0xfb,0x56,0x76,0x46,0xb8,0x66,0x8e,0xe1,

0x0b,0x43,0x8d,0xc4,0xd4,0xf0,0x15,0x3e,

0x6e,0x39,0x91,0x8d,0xdb,0x87,0x45,0xef,

0x3d,0x8b,0x14,0x22,0x9b,0x2d,

[color:"red"] 82 Status(9002), error(0) [/color]

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

Process ECM (4641494c) even(0) odd(0)

Seca SW(901d)

 

zo te zien krijg ik dus de foutmelding 9002. Kan iemand mij vertellen waardoor dit waarschijnlijk ontstaat? Heb namelijk nog niet precies door wat al die cijfers inhouden kan al wel een heel gedeelte maar nog niet alles. Alle uitleg cq. hulp is zeer welkom.

<img src="/forums/images/graemlins/kweetniet.gif" alt="" />

[Gast]

Is dat niet de inhoud van het allereerste berichtje in dit topic dan?

[Zilverster]

@xyzzy en @Hermanator,

 

 

Citaat:

http://joshyfun.sytes.net/SECA_CAM_HowTo_1.03.pdf

 

Ik heb mij nog even kunnen losrukken en dus even gekeken <img src="/forums/images/graemlins/shocked.gif" alt="" /> .

 

Geweldig stukje info, waarvan wij nog iets misten in de schakel, m.a.w. een geweldig stukje hulp <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" /> .

 

Via deze weg xyzzy, bedankt <img src="/forums/images/graemlins/biggthumpup.gif" alt="" /> , gr.

 

Zilverster.