Ga naar inhoud


[Cam Algemeen] CAM/card programmeren for dummies


Gast

Aanbevolen berichten

Ik denk dat dat inderdaad zou moeten kunnen.

 

In de gelogde communicatie kan een byte iedere waarde aannemen van 0x00 tm 0xff. Als je zou loggen door de ontvangen string rechtstreeks door te schrijven naar de log, zou de kaart volgens mij niet kunnen bepalen of 0x11 (x-on) en 0x13 (x-off) bedoeld zijn voor het starten/stoppen van de communicatie, of dat ze een inhoudelijk onderdeel van een logmessage zijn?

 

Maar ik laat Eva in printable ascii hexcodes loggen. Als er dus een byte 0x11 voorkomt in de communicatie, vertaal ik dat naar de smartcard interface in twee bytes: 0x31 en 0x31, dus volgens de ascii tabel "11". Ik heb dit gedaan zodat je de logs gewoon met bv. notepad kunt bekijken. In principe komen in mijn log dus 0x11 en 0x13 nooit voor. De enige "nonprintables" zijn cr/lf (0x0d/0x0a).

 

Het zou denk ik ook de mogelijkheid van loggen met de season niet in de weg zitten. Als je naar de kaart logt, dan kunnen er x-on/x-off characters terug komen van de kaart, en zal verzending moeten hervatten of pauzeren. De season zal dit echter nooit doen, omdat het hier niet nodig is.

 

Het enige is dat er dan ten behoeve van de cardlogger wel wat aanpassingen moeten worden gemaakt. Nu schrijft Eva in een stuk door naar de smartcard interface. Op deze plaats zou dan na ieder verzonden byte moeten worden gelezen van de kaart of er geen x-off wordt verzonden. Daarna zal de kaart moeten blijven lezen tot de x-on wordt ontvangen. En wat zou je in de cam doen? Zou het geen timing problemen geven als je het programma gewoon laat wachten op de x-on bij de verzending van die ene logmessage, of zou dit wel het geval zijn en zou je de te loggen message moeten bufferen en periodiek kijken of je naar de card kunt verzenden...

 

Aan de ene kant vind ik het een beetje zonde van de moeite omdat het met een season perfect loopt. Aan de andere kant stel je mensen zonder season ook in staat om te loggen. Mmm... wat vind jij, Milo?

Link naar reactie
Delen op andere sites


Volgens mij kan ik hem zelfs in hardware laten handshaken. De CAM en kaart delen namelijk een IO lijntje. Als ik die lijn gewoon op "0" zet (actief maak), dan kan de kaart in principe niet meer zenden (en wordt hij geblokkeerd).

 

Deze "0" wordt wel als startbit gezien trouwens, dus echt praktisch is dat niet.

 

Een XON/XOFF schema kan ook, maar dan blijf je in de bufferproblemen zitten (want dan moet de CAM gaan bufferen en verplaats je het probleem alleen maar - ook die buffer loopt op den duur vol)

 

In de kaart kan ik ongeveer 500 bytes bufferen, da's toch vrij riant. Hoeveel log je _gemiddeld_ vanuit EVA?

 

Overigens wordt in de kaart/CAM communicatie wel degelijk parity gebruikt (even, dus aantal "1"en is even). Als de parity niet goed is, dan zet de kaart de IO even op "0" om de CAM te laten weten dat er een fout was. De CAM moet de byte dan opnieuw sturen. Dit mechanisme zou je ook als flowcontrol kunnen gebruiken, door net zolang te klagen dat de parity niet goed is tot de buffer weer leeg is.

Link naar reactie
Delen op andere sites

Milo,

 

Ik moet nu weg en zal vandaag niet zo gek veel meer kunnen doen. Er zijn verschillende logopties in Eva die afzonderlijk aan en uit kunnen worden gezet. Ik zal (hopelijk) morgen een paar files maken die gedurende bijvoorbeeld 5 minuten loggen. Dan kan ik eens kijken wat er gemiddeld in een log wordt gepompt.

 

Ik vraag me af wat er gebeurt als je de handshaking hardwarematig gaat doen. Ligt een beetje aan hoe Sidsa de smartcard routines heeft gemaakt denk ik. Blijft ie bijvoorbeeld wachten of krijg je in Eva een foutmelding van die routine terug.. Moeten we misschien maar eens mee testen.

Link naar reactie
Delen op andere sites

@Hermanator,

 

Wat, 5 minuten loggen, als ik zie wat er in 1 minuut al binnen komt, mag ik nu alwel een nieuwe hardeschijf er bij kopen, of je moet de herhalingen er uit filteren <img src="/ubbthreads/images/graemlins/grin.gif" alt="" /> , gr.

 

Zilverster.

You are "The last in line" - Ronnie James Dio R.I.P.

Link naar reactie
Delen op andere sites

Deze versie:

 

Gebruikt een 256-byte FIFO buffer in zijn RAM, en leegt deze zo snel mogelijk naar de EEPROM. Het binnenlepelen van bytes uit de CAM heeft voorrang, schrijven naar de EEPROM doet hij zodra de EEPROM weer klaar is om geprogrammeerd te worden en er geen data binnenkomt.

 

Als er te snel teveel data binnenkomt, wordt het een zooitje. Zodra de buffer "over loopt" ben je de hele buffer namelijk kwijt.

 

De rest werkt als voorheen.

878562-Logger.zip

Link naar reactie
Delen op andere sites

Milo,

 

Eerst even over de aantallen bytes die worden gelogd. Als Eva zowel ecm's als emm's logt, dan stuurt ze zo'n 36000 bytes per minuut naar de kaart. Alleen ecm's zijn het een dikke 1000 bytes per minuut. Zoals uitgelegd, wordt ieder ontvangen byte vertaald naar een ascii hexadecimale presentatie en wordt iedere regel afgesloten met cr/lf. Dit om de log met een gewone editor als notepad te kunnen bekijken. Als Eva dit niet zou doen, dan zouden de aantallen dus halveren. Je zou dan wel met een hexeditor de log moeten bekijken, wat de overzichtelijkheid niet ten goede zou komen.

 

Ik heb met je nieuwe versie gespeeld het ziet er nu goed uit. Inderdaad vind ik een deel van de log terug in de interne eeprom. Ik stuur je de logfile toe zodat je het resultaat kunt bekijken.

Link naar reactie
Delen op andere sites

  • 1 maand later...
Code:

static unsigned long scardSOpen(const unsigned int i_numCard, scardOptions_t* io_options,const unsigned int i_cklFreq){
unsigned long retval = 0L ;
int appo,i;
int delayVal;
int (*callDelay)(const unsigned int i_delay);
unsigned volatile char *scardG_base_byte;
scardG_base = (unsigned int*)scardInterfaceBase;
scardG_base_byte = (unsigned char*)scardInterfaceBase;

getRealScardState(); // per la revolution
if (scardG_cardData.scardIN){
//10670
scardSDataReset(0);
appo=0xC0;
scardG_base[0x5]=appo;
scardG_base[0x1]=io_options->baudRate | 0x50;
scardG_base[0x3]=0x2;
scardG_base[0x4]=i_cklFreq;
appo= appo | 0x1;
scardG_base[0x5]=appo;
appo = appo & (~0x1);
scardG_base[0x5]=appo;
delayVal=0x14;

callDelay = (int (*)() ) scardG_cardData.defDelAddr;
callDelay(delayVal);
if (picInterruptPending (scardG_intr[1]) != OK){
delayVal= scardG_base[0x0]; //lettura fasulla
}
//1070C
if (scardG_cardData.scardIN){
picInterruptEnable (scardG_intr[1]);
appo = appo & (~0x40);
appo = appo | 0x20;
scardG_base[0x5]=appo;
delayVal=0x64;
callDelay(delayVal);
//1074C
if (scardG_cardData.scardIN){
if(scardG_cardData.bytesToRead == scardG_cardData.dataOffset){
appo = appo & (~0x20);
scardG_base[0x5]=appo;
delayVal=0x64;
callDelay(delayVal);
}
if (scardG_cardData.scardIN){
// 10784
if(scardG_cardData.bytesToRead == scardG_cardData.dataOffset){
appo = appo | 0x20;
scardG_base[0x5]=appo;
delayVal=0x64;
callDelay(delayVal);
}
if (scardG_cardData.scardIN){
// 107BC
if(scardG_cardData.bytesToRead == scardG_cardData.dataOffset){
appo = appo & (~0x20);
scardG_base[0x5]=appo;
delayVal=0x64;
callDelay(delayVal);
}
if (scardG_cardData.scardIN){
// 107F4
delayVal=scardG_base[0x5];
if(scardG_cardData.bytesToRead != scardG_cardData.dataOffset){
scardG_cardData.scardON=1;
if (io_options->ATRLength >= scardG_cardData.bytesToRead){
io_options->ATRLength = scardG_cardData.bytesToRead;
} else {
// 10840
io_options->ATRLength = 0 ;
retval = ERROR_SCARD_BASE + 1 ;
}
// 10848
if (io_options->ATRLength > 0)
{
for (i=0;i<io_options->ATRLength;i++){
io_options->ATR[i] = (unsigned char) scardG_cardData.dataBuffer[i];
// WRONG !!!! io_options->ATR[i] = (unsigned char) scardG_base_byte[i];
}
}
} else {
// 10878
io_options->ATRLength=0;
retval = SCARD_ERROR_UNDERFLOW;
}
// 10888
scardG_cardData.bytesToRead=scardG_cardData.dataOffset;
}
// 10890
if (!scardG_cardData.scardIN){
retval = SCARD_ERROR_UNDERFLOW;
}
}
}
}
}
} else {
retval = SCARD_ERROR_UNDERFLOW;
}
return retval;
}
Link naar reactie
Delen op andere sites

Dr.Galaxis,

 

Dat was mr. Bug dus inderdaad!!!

 

De gehele routine "scardSOpen" vervangen gaat bij mij niet, want in ADS 1.2 compileert ie niet. Maar de atr moet inderdaad worden uitgelezen uit "scardG_cardData.dataBuffer" in plaats van uit "scardG_base_byte". Je ziet dat in scardByteRead() ook wordt gelezen uit scardG_cardData.dataBuffer. Ik heb alleen in "scardSOpen()" de variabele veranderd en hoppa: atr wordt gelezen! Goed gevonden!!!

 

Ik denk dat dit toch tijdens de reverse engineering door de Italiaanse vriendjes fout is gegaan. Of zou het al fout zijn geweest in de originele Sidsa library? Heeft iemand wel eens in een emulatie van een Matrix (welke dan ook) een ATR in het menu kunnen opvragen?

 

In ieder geval echt prima werk en hiermee zijn we weer een stuk verder!

 

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

Link naar reactie
Delen op andere sites

In the italian forum where was no error in one source but in a second one.

I had to change the source in a few points, specially in pointer to functions to compile. The source I emailed to you compiles in my APM without errors.

If you pot the errors i can evetually help you.

 

cu DrGalaxis

Link naar reactie
Delen op andere sites

OK, vooralsnog werkt het deel met de atr nu. Als ik binnenkort aan de slag ga met de c1 commando's zal ik erachter komen of de rest ook werkt. Ik meld me graag voor wat hulp als het niet lukt. Thanx!! <img src="/forums/images/graemlins/biggthumpup.gif" alt="" />

Link naar reactie
Delen op andere sites

  • 4 weken later...
  • 1 maand later...

Hey Hermanator,

 

Ik heb deze thread aandachtig gelezen, en vraag me af of je al een nieuwe revisie van je documentatie afhebt. (Wellicht wil je eerst je hele broncode enzo afmaken, maar ikzelf ben nu vooral geinteresseerd in de uitleg over smartcards etc. die je in een later stadium zou toevoegen.)

 

Maar verder, ik heb een Dreambox, en gebruik daarom softcams, maar ik heb wel een oude (paarse) funcard liggen, die een kennis me aanraadde (die bij mij overigens geen invloed had op de decodering, ook vroeger niet). Ik begrijp dat de bezitters die het moeten stellen met een CAM + onofficiele smartcard nu geen basispakket NL TV meer kunnen zien? Of hoe zit het anders? MiLo suggereerde immers ergens in deze thread dat hij met zijn oude apparatuur (MR etc., wat dat ook moge betekenen) in de huidige situatie eigenlijk weinig uit kan richten, dus jullie moeten nu toch aan de officiele Canal+-kaart? Ik snap eigenlijk niet wat het doel is van een (onofficiele) smartcard, de bekende CAMs konden zelfstandig toch al de gangbare encrypties decoderen als ik me niet vergis?

 

Is MiLo en de rest trouwens al wat opgeschoten? Of hebben jullie tot op heden even een lange pauze genomen i.v.m. de zomervakantie? <img src="/forums/images/graemlins/wink.gif" alt="" />

Link naar reactie
Delen op andere sites

Maak een account aan of log in om te reageren

Je moet een lid zijn om een reactie te kunnen achterlaten

Account aanmaken

Registreer voor een nieuwe account in onze community. Het is erg gemakkelijk!

Registreer een nieuwe account

Inloggen

Heb je reeds een account? Log hier in.

Nu inloggen
  • Wie is er online   0 leden

    • Er zijn geen geregistreerde gebruikers deze pagina aan het bekijken
×
×
  • Nieuwe aanmaken...