Waarom zijn er überhaupt loaderfiles???

[Duwgati]

Ik zou ook graag nog eens wat bijleren <BR>Wie kan me eens uitleggen waarom er eigenlijk loaderfiles nodig zijn.<BR>Ik weet waarvoor ze gebruikt worden en wanneer je ze nodig hebt (ja ja, zover was ik al ).<BR>Wat mij alleen bezig houdt is het volgende:<BR>Als ik een kaart AU maak, dan wordt de eeprom in mijn kaart regelmatig geupdate. Hoe krijgt die CAM dat voor elkaar als er geen loaderfile in de PIC geladen is?<BR>Er moet dus een mogelijkheid zijn om naar die kaart te schrijven zonder een speciale loaderfile. Of zie ik iets over het hoofd?<BR>Bye<BR>Duwgati

[Gast]

als je een 'update' ontvangt dan zegt de file<P>in de pic toch(na nano40/3c/3e enzovrrtt) bv: ok_0cbv)_geupdate<P>en schrijft de pic de nieuwe keyz(encrypted) weg<P>dus eigenlijk doet de cam niets meer als met de pic<P>praten, en als er dan geschreven/gelezen moet worden<P>dan doet een soort van (block) loader/schrijvertje<P>die info op of van de eeprom brengt, maar<P>het is dus de pic die belangrijk is, kijk<P>maar naar mkf, dat je de keyz kan zien is<P>toch gebaseerd op de nano bug, die zit<P>toch grotendeels(niet helemaal) op de pic<P>en toont jouw de geheimen van de eeprom<P>er is dus geen echt 'contact' tussen cam en<P>eeprom, in mijn opvatting kan je daarom<P>dus zonder loader(lege pic) bij bv een GW<P>niets doen<P>beetje warrig en er zullen nog wel wat reply's op<P>volgen, maar dit ff als voorzetje..<P><BR>scccss<p>[ 21-09-2001: Message edited by: radxnl ]

[Duwgati]

Dat de PIC-file net zo belangrijk is als de eeprom-file weet ik ook.<BR>Maar de uiteindelijke PIC-file is in staat om de eeprom te updaten. De CAM kan dit niet rechtstreeks omdat er op een GW domweg geen direkte verbinding naar de Eeprom is. Het moet dus via de PIC-file gedaan worden. Dat is trouwens ook conform de manier waarop de data-stromen in het hele proces geregeld zijn. Die definitie c.q. algoritme ligt vast.<P>Als we daar dan ook vanuit gaan betekent dat dus ook dat er in de uiteindelijke PIC-file al een voorziening is voor "through PIC programming". <BR>En ik neem aan dat dat inderdaad alleen maar een primitieve uitvoering is (block-loader zoals jij hem noemt) die niet op kaartnivo, maar alleen op providernivo kan schrijven. <BR>Alleen zou ik het graag zeker weten.<BR>Bye<BR>Duwgati

[Gast]

ik heb nog ff ter info de datasheets naar je<P>door gestuurt op je meel... <P>mzzll

[Duwgati]

Heb ze gevonden, hartstikke bedankt, daar ga ik nog wat mee doen.<BR>Bye<BR>Duwgati

[Dr. Humax]

@Duwgati <BR>" Wie kan me eens uitleggen waarom er eigenlijk loaderfiles nodig zijn. "<P>Kan het fout hebben maar dacht dat een loaderfile als enige doel had te zorgen dat je de Eeprom naar de kaart kan schrijven en daarna overschrijft met de afsluitende pic.hex. Als je met secanix de Eeprom leest en dan handmatig update, dan schrijf je toch ook naar de kaart zonder loader.

[Duwgati]

@Dr. Humax,<BR>Klopt helemaal. En juist omdat de CAM (of secanix) ook naar de kaart kunnen schrijven zonder gebruik van een loader, vroeg ik me dus af of de loaderfile techniek wel de enige manier is om een eeprom te kunnen beschrijven.<BR>Er zijn echter meerdere manieren om die eeprom te beschrijven. En om de eeprom in zijn geheel te kunnen overschrijven heb je dus wel een loaderfile nodig. Om stukjes te kunnen updaten heb je dat niet nodig. Dat werkt dus op providernivo. Via Instruction Bytes om precies te zijn. <BR>Bye<BR>Duwgati

[-= [ Appien ] =-]

Ja maar als je een "verkeerde" pic file hebt, kun je met Secanix niet (rechtstreeks) proggen!!!<P>Niet alle Pic files "ondersteuen" dit!!

[Duwgati]

Weer wat geleerd, bedankt Appien <BR>Bye<BR>Duwgati

[prutsie]

Het is heel simpel eigenlijk,, toch ?<P>Omdat de eeprom niet rechtstreeks (fisiek) aan de contacten van de smartcard is doorverbonden heb je een loader nodig.<P>de loaderfile is een soort van doorgeefluik, het binnenkomende byte wordt door de pic processor op de eeprom op een van te voren megestuurd adres weggeschreven. het hele geheugen van de eeprom is zo te benaderen, en te beschrijven.<BR>het emulatieprogramma (van bv seca) wat je hierna in het geheugen van de pic processor schrijft kan alleen maar via het algo. de adressen benaderen waar de keys staan weggeschreven. het hele adersbereik van de eeprom is dus niet benaderbaar, maar alleen de adressen waar de programmeur van de software de keys wil wegschrijven.<P>Er is natuurlijk weer een uizondering, en dat was de piccard 1 en II software. met deze software was het wel mogelijk de hele eeprom te adresseren, en dus te programmeren.<P>Er is genoeg info over deze materie en het gebruikte I2C protocol voor de communicatie tussen pic en eeprom op internet te vinden, evenals kant en klare voorbeelden. kijk eens op de homepage van microchip de producent van de pic processorfamilie. hier zijn ook gratis ende voorniets assemblers, debuggers en andere leuke onontbeerlijke programmeertools op te halen.<P>Peter.

[Duwgati]

Dan had ik het dus inderdaad goed begrepen. Bedankt voor de bevestiging Prutsie.<BR>En je bevestigt meteen mijn theorie dat het mogelijk moet zijn om de loaderfile te kombineren met de picfile, zodat je daarna de eeprom kunt herprogrammeren zonder de pic opnieuw te hoeven schrijven.<BR>Daar zal dan een andere PIC op de kaart voor nodig zijn, maar het zou moeten kunnen. Toch?<BR>Ik kan me dus voorstellen dat het mogelijk zou kunnen zijn om bijv. met een aangepaste PIC file een Piccard 1 te "misbruiken" als een Goldwafer kaart. Waarbij de PIC wordt geprogrammeerd met een file die zowel als loader alsook als PIC file fungeert. Een gemodificeerde GW-PIC file dus. Of draaf ik nou door?<BR>Bye<BR>Duwgati<p>[ 24-09-2001: Message edited by: Duwgati ]

[prutsie]

Het kan gewoon met 1 pic, en 1 eeprom.<BR>Je kan de loaderfile natuurlijk combineren met de emulator. De files van mastercrd werkten zo bijvoorbeeld. je programmeerde de pic met de emulator/loaderfile, en vervolgens jaagde je er een crd file overheen die de eeprom programmeerde.<BR>Er is natuurlijk 1 maar, het is in deze natuurlijk voor de betaaltvprovider relatief simpel deze kaartjes op zwart te zetten.<BR>stuur een instructie mee die bv. een bitje in de hash tabel verkeerd set, en weg beeld !<BR>Peter.