4250 replies to this topic

[Erik Slagter]

Haha ROFL, daar ben ik ook al eens ingestonken. En ja, toen heb ik met de hand ALLE tags eruit mogen halen...

Ik zal even de versie uit m'n mailbox hier pasten, die is wel goed:

int  seca_version  =  reader -> availkeys [ 0 ][ 1 ];  //misusing availkeys to store seca_version  
if  ( seca_version  ==  3 )  ecm_type = 0; // assume ecm request always same as cardtype in reader 
if (seca_version == 2) ecm_type = 1; 
 
if ( er -> ecm [5..8] == 0x00075C00 )  ecm_type  =  0 ; // mediaguard 3 request 
 if ( er -> ecm [5..8] == 0x0000FC10 )  ecm_type  =  1 ; // seca2 request 

Ben trouwens wel benieuwd wat de compiler hiervan gaat vinden:

if ( er -> ecm [5..8] =

[theparasol]

Nouja, ik weet het echt niet. Iemand die wel zijn C++ op orde heeft leest vast wel wat de bedoeling is en past zonodig de code aan

Typo ontdekt

En waardes aangepast, nu is het leesbaarder!

static int32_t seca_do_ecm(struct s_reader * reader, const ECM_REQUEST *er, struct s_ecm_answer *ea)
int ecm_type;
int seca_version = reader->availkeys[0][1]; //misusing availkeys to store seca_version
if (seca_version == 3) ecm_type = 3; // assume ecm type same as card in reader
if (seca_version == 2) ecm_type = 2; // assume ecm type same as card in reader
if(er->ecm[5678] == 0x0000FC10) ecm_type = 3; // this is a mediaguard 3 ecm request
if(er->ecm[5678] == 0x00075C00) ecm_type = 2; // this is a seca2 ecm request
if ((ecm_type == 2 && seca_version == 3) || (ecm_type == 3 && seca_version == 2)) return ERROR;

Edited by theparasol, 24 February 2012 - 21:39.

[Erik Slagter]

if(er->ecm[5678] == 0x0000FC10) ecm_type = 0; // this is a mediaguard 3 ecm request
if(er->ecm[5678] == 0x00075C00) ecm_type = 0; // this is a seca2 ecm request

Ik ben bang dat je de laatste tijd teveel in python-achtige talen gewerkt hebt LOL

Je gaat hier 5678 bytes vanaf de er->ecm pointer opvragen -> segfault (of crash).

C heeft hier geen pasklare oplossing voor. Wat altijd werkt is de bytes 1 voor 1 in een in stoppen en doorschuiven. Soms wordt in programma's daarvoor een macro of functie gedefinieerd, maar bij een "vreemd" programma weet je dat niet zo 1,2,3 natuurlijk. Mocht je nou in de verleiding komen om dit te doen:

int tmp = *(uint32_t *)(er->ecm+5);
if(tmp == ...)

Dat is zoooooo fout! Endianness, alignment, allemaal kansen op segfaults en bus errors, niet doen dus!

Gewoon maar uitschrijven dus: int tmp = (er->ecm[5] << 24) | (er->ecm[6] << 16) | (er->ecm[7] << 8) | er->ecm[8];
Dat werkt altijd. Als je heel zeker wilt zijn, gebruik je uint32_t, maar niet alle arch's en compilers snappen dat.

[Erik Slagter]

Volgens mij moeten we daar samen zo wel uitkomen...

[theparasol]

Kunnen we niet gewoon een double word variable aanmaken en vervolgens pointen naar er->ecm[5] ??

int temp {Double Word}

temp = er->ecm[5]

if temp = 0xblablabla then

[Erik Slagter]

Het aantal bits wat je kwijt kunt in een variabele wordt al geimpliceerd door het type, daar hoef je niet nog eens "{Double Word}" achter te gaan zetten. Een int is heel tricky omdat die afhankelijk van de arch verschillende "lengtes" kan hebben, 32 of 64 bits (of nog anders eventueel). Daarom heb je tegenwoordig ook int-types met expliciete "size", zoals de uint32_t, dat is een int van 32 bits waar alle 32 bits gebruikt worden voor de waarde, geen "sign" bit.

Maar zelfs dan ben je er nog niet. De code die jij hebt staan, leest de vijfde entry in het array er->ecm (er is een pointer naar de array ecm, die in C ook vaak vertegenwoordigd wordt als pointer). Ik ga er even van uit dat ecm een array van "chars" is (signed bytes, of unsigned, als je er "unsigned" voor zet of "uchar8_t" gebruikt). De vijfde entry in het array is dan gewoon het vijfde byte, niets meer en niets minder. En wordt dan opgerekt naar de int (blijft dus gewoon hetzelfde getal). Dat is niet wat je wilt. In C heeft links van het = teken nooit invloed op rechts ervan.

Je zult het dus helaas echt op mijn manier moeten doen. Een int van size "4 bytes" dus vullen door er afzonderlijk vier bytes in te stoppen. Die andere gore truuk die ik liet zien komt in de buurt van wat jij in gedachten had. Je houdt de compiler dan voor de gek door te zeggen dat het "even" geen pointer naar een array van bytes is, maar een pointer naar een array van ints en daar neem je dan 1 waarde van, die dan vier bytes is (of acht, of whatever de arch) maar NIET DOEN DUS! Grote kans dat het niet eens werkt hier.

Edited by Erik Slagter, 24 February 2012 - 21:55.

[theparasol]

Dat moet toch beslist eenvoudiger kunnen
Vroeger in assembly las ik gewoon die waardes in cx en dx register door naar data segment te verwijzen.

Zo'n pointer verwijst ook naar een stukje data in geheugen, moet mogelijk zijn daar een variabele naar te laten verwijzen die exact het aantal bytes opslorpt waarvoor het gedefinieerd is. Daana compare en voila!

Maar goed: Milo / PieterG: wat is hier nu de beste manier? { leuke test om eens te kijken of ze dit topic al niet in de ignore hebben staan }

[pieterg]

altijd network byte order veronderstellen voor data die van buiten komt:
uint32_t tmp = ntohl(*((uint32_t *)(er->ecm + 5)));

Oh, en ik zag al ergens een rightshift zonder mask voorbij komen, dat moet je dus nooit doen, met een right shift schuif je de data voorbij het eventuele sign bit mee naar binnen.

Edited by pieterg, 24 February 2012 - 22:12.

[Erik Slagter]

Dat moet toch beslist eenvoudiger kunnen
Vroeger in assembly las ik gewoon die waardes in cx en dx register door naar data segment te verwijzen.

Zo'n pointer verwijst ook naar een stukje data in geheugen, moet mogelijk zijn daar een variabele naar te laten verwijzen die exact het aantal bytes opslorpt waarvoor het gedefinieerd is. Daana compare en voila!

Dat is precies wat deze regel doet: int tmp = *(uint32_t *)(er->ecm+5);

Waar je alleen de mist in gaat, is dat je aannames doet die voor een x86 processor gelden, maar niet voor allerlei andere processoren. Zo kunnen veel soorten processoren bijvoorbeeld 4-byte-ints alleen lezen vanaf adressen % 4 (dus 0,4,8,12, etc.). Als je dan ergens midden een byte array een 4-byte-int gaat lezen, dan krijgt je programma heel hard op z'n vingers -> exit programma. Ook de volgorde van de bytes binnen zo'n 4-bytes-int is geheid anders binnen jouw processor dan je verwacht, met name de x86 processor doet het precies verkeerd om. Gewoon niet doen dus.

[Erik Slagter]

altijd network byte order veronderstellen voor data die van buiten komt:
uint32_t tmp = ntohl(*((uint32_t *)(er->ecm + 5)));

Mee eens, maar in dit geval is de byte order vast en bekend. En eigenlijk moet je het imho dus zowiezo niet op deze manier doen. Ik zie al bus errors van de mipsel vanwege alignment violations...

Oh, en ik zag al ergens een rightshift zonder mask voorbij komen, dat moet je dus nooit doen, met een right shift schuif je de data voorbij het eventuele sign bit mee naar binnen.

oscam code... tsja...

Overigens even voor mijn goede begrip, je bedoelt de sign bit die meegeschoven wordt? De (vaak) rare implementaties van shift op de cpu zouden geen invloed mogen hebben op de operator in C...

Edited by Erik Slagter, 24 February 2012 - 22:21.

[pieterg]

altijd network byte order veronderstellen voor data die van buiten komt:
uint32_t tmp = ntohl(*((uint32_t *)(er->ecm + 5)));

Mee eens, maar in dit geval is de byte order vast en bekend. En eigenlijk moet je het imho dus zowiezo niet op deze manier doen. Ik zie al bus errors van de mipsel vanwege alignment violations...

mipsel vindt dat niet zo erg. Arm vaak wel.
Maar inderdaad, omdat je niet weet waar de boundary zit, bij nader inzien niet zo handig.

Overigens even voor mijn goede begrip, je bedoelt de sign bit die meegeschoven wordt? De (vaak) rare implementaties van shift op de cpu zouden geen invloed mogen hebben op de operator in C...

in C(++/#) is een right shift op een signed variabele doorgaans een 'arithmetic' shift, oftewel je sign bit wordt links steeds weer aangevuld.
(een right shift op een unsigned variabele is wel gewoon een logical shift)

[theparasol]

Maken we de detectie met wat minder bytes:

seca2 byte 8 altijd FC
mediaguard3 byte 8 altijd 5C

Scheelt aardig wat code

static int32_t seca_do_ecm(struct s_reader * reader, const ECM_REQUEST *er, struct s_ecm_answer *ea)
int ecm_type;
int seca_version = reader->availkeys[0][1]; //misusing availkeys to store seca_version
if (seca_version == 3) ecm_type = 3; // assume ecm type same as card in reader
if (seca_version == 2) ecm_type = 2; // assume ecm type same as card in reader
if(er->ecm[7] == 0x5C) ecm_type = 3; // this is a mediaguard 3 ecm request
if(er->ecm[7] == 0xFC) ecm_type = 2; // this is a seca2 ecm request
if ((ecm_type == 2 && seca_version == 3) || (ecm_type == 3 && seca_version == 2)) return ERROR;

Edited by theparasol, 24 February 2012 - 22:41.

[theparasol]

Nieuwe input van oscam timeline... Erik, je zat in de goede richting te denken met wat gebeurt er volgende maand / nieuwe key:

static int32_t seca_do_ecm(struct s_reader * reader, const ECM_REQUEST *er, struct s_ecm_answer *ea)
int ecm_type;
int seca_version = reader->availkeys[0][1]; misusing availkeys to store seca_version
if (seca_version == 3) ecm_type = 3; assume ecm type same as card in reader
if (seca_version == 2) ecm_type = 2; assume ecm type same as card in reader
if(er->ecm[8] == 0x00) ecm_type = 3; this is a mediaguard 3 ecm request
if(er->ecm[8] == 0x10 && er->ECM[9] == 0x01) ecm_type = 2; this is a seca2 ecm request
if ((ecm_type == 2 && seca_version == 3) :: (ecm_type == 3 && seca_version == 2)) return ERROR;

Edited by theparasol, 24 February 2012 - 22:51.

[aardbei]

wat zijn die code-postings een leuk stuk om te lezen zeg, sowieso heren, thnx voor de uitleg da's erg leuk!!!

[theparasol]

Erik, tijd om de code aan te passen van oscam.dvbapi. Ik kom er niet uit door mijn matige C++ code beheersing: http://streamboard.g...001/ticket/2359
Er zit daar een knoepert van een bug in: ik heb request 1 pid tegelijk staan en zoals je terecht aangeeft: hij pakt er 2 omdat bij CDS er meer pids met gelijke caid:provid zijn
Ik zie nu dat hij altijd de seca3 ecm aanvraagt en daarnaast ook direct de seca2 ecm.
Die laatse vangt hij nu wel correct af maar ondertussen returned hij een error en dus gaat er alsnog een CW 00000000000 naar de tuner en gaat je beeld alsnog op zwart

[theparasol]

Nog ff doorgegaan

DVBAPI REQUESTMODE moet op 1 staan, 0 werkt dus niet!

OSCAM.DVBAPI mag nu eventueel ook leeg zijn

In de bijlage een oscam-mipsel met mijn patches op basis van svn 6450

reader-seca.c (line 220)

 
static int32_t seca_do_ecm(struct s_reader * reader, const ECM_REQUEST *er, struct s_ecm_answer *ea)
{
 if (er->ecm[3] == 0x00 && er->ecm[4] == 0x6a) { //provid 006A = CDNL uses seca2/seca3 simulcrypt on same caid
  int ecm_type = 0;
  int seca_version = reader->availkeys[0][1]; //misusing availkeys to store seca_version
  if (seca_version == 3) { //assume ecm type same as card in reader
   ecm_type = 3; 
  }
  if (seca_version == 2) { //assume ecm type same as card in reader
   ecm_type = 2;
  }
  if (er->ecm[8] == 0x00) { //this is a mediaguard 3 ecm request
   ecm_type = 3;
  }
  if (er->ecm[8] == 0x10) { // first seca2 request byte found
   if (er->ecm[9] == 0x01) {//second seca2 ecmrequest byte found
	ecm_type = 2;
   }
  }
  if (ecm_type != seca_version){ //only accept ecmrequest for right card!
   snprintf( ea->msglog, MSGLOGSIZE, "invalid ecm for cardtype!" );
   return ERROR;
  }
 }

module-dvbapi.c line 602

 
void dvbapi_start_descrambling(int32_t demux_id) {
 int32_t j,k;
 int32_t streamcount=0;
 demux[demux_id].pidindex = demux[demux_id].curindex;
 for (j=0; j<demux[demux_id].ECMpidcount; j++) {
  if (demux[demux_id].curindex == j) {
	
   if (demux[demux_id].curindex != j) {
	if (demux[demux_id].ECMpids[j].status < 0 || !demux[demux_id].ECMpids[demux[demux_id].curindex].streams)
	 continue;
	 
	dvbapi_start_filter(demux_id, j, demux[demux_id].ECMpids[j].ECM_PID, 0x80, 0xF0, 3000, TYPE_ECM, 0);
   }
   if (!demux[demux_id].ECMpids[j].index)
	demux[demux_id].ECMpids[j].index=dvbapi_get_descindex();
   demux[demux_id].ECMpids[j].checked=1;
   demux[demux_id].ECMpids[j].irdeto_curchid=demux[demux_id].ECMpids[demux[demux_id].curindex].irdeto_curchid;
   for (k=0;k<demux[demux_id].STREAMpidcount;k++) {
	if (!demux[demux_id].ECMpids[j].streams || (demux[demux_id].ECMpids[j].streams & (1 << k))) {
	 dvbapi_set_pid(demux_id, k, demux[demux_id].ECMpids[j].index-1);
	}
   }
   streamcount++;
  }
 }
 cs_log("Start descrambling PID #%d (CAID: %04X) %d", demux[demux_id].curindex, demux[demux_id].ECMpids[demux[demux_id].curindex].CAID, streamcount);
 if (cfg.dvbapi_au>0)
  dvbapi_start_filter(demux_id, demux[demux_id].pidindex, 0x001, 0x01, 0xFF, 0, TYPE_EMM, 0); //CAT
}
 

Zo nu ga ik pitten

Attached Files

•  oscam-custom.zip   371.95KB   11 downloads

[theparasol]

En loadbalancer disabled...

[Erik Slagter]

mipsel vindt dat niet zo erg. Arm vaak wel.

Op school hadden we sparc, toch wel een beetje een mede-voorouder van de mips, en die was héél erg moeilijk daarmee.

Ik heb zelf ooit een 68000 gehad, idem, word van oneven adres lezen -> bus error trap. Ik weet niet hoe het de moderne processors is, maar de 68000 had niet eens aan a0 adres lijn (jaja wel een odd/even enable...)

Anyway vandaar bij mij een gezonde weerzin tegen unaligned access...

in C(++/#) is een right shift op een signed variabele doorgaans een 'arithmetic' shift, oftewel je sign bit wordt links steeds weer aangevuld.
(een right shift op een unsigned variabele is wel gewoon een logical shift)

Zegt de standaard daar niks over dan? Ik heb maar even rondgezocht en inderdaad "implementation specific". Lekker. Het is maar goed dat ik bijna altijd unsigned ints gebruik. Andere dingen doet (ANSI-)C dan weer wel een heel harde uitspraak over, bijvoorbeeld dat een null pointer altijd de integer waarde 0 heeft, ook al is de null pointer op een bepaalde arch != 0. Nou ja goed om te weten dus...

Edited by Erik Slagter, 25 February 2012 - 09:41.

[Erik Slagter]

Erik, tijd om de code aan te passen van oscam.dvbapi. Ik kom er niet uit door mijn matige C++ code beheersing: http://streamboard.g...001/ticket/2359
Er zit daar een knoepert van een bug in: ik heb request 1 pid tegelijk staan en zoals je terecht aangeeft: hij pakt er 2 omdat bij CDS er meer pids met gelijke caid:provid zijn
Ik zie nu dat hij altijd de seca3 ecm aanvraagt en daarnaast ook direct de seca2 ecm.
Die laatse vangt hij nu wel correct af maar ondertussen returned hij een error en dus gaat er alsnog een CW 00000000000 naar de tuner en gaat je beeld alsnog op zwart

Dit lijkt heel erg op het probleem wat ik eerder vond? Ben benieuwd... Had je mijn patch al geprobeerd?

[Erik Slagter]

parasol, kun je even een diffje maken, is wel zo makkelijk lezen en ook makkelijker om te passen bij andere oscam-revisions.

Even jouw versie en die van oscam naast elkaar zetten dan diff -u doen.

Als je een "live" svn repo hebt waarin je de wijziging hebt gemaakt, is het nog makkelijker, dan doe je svn diff en dan krijg je alle wijzigingen die je zelf hebt aangebracht, op dezelfde manier.