Kategóriák
Maga az iparos. Történetek a múltból és a jelenből.

A fénykardom.

Egy igazán elegáns küzdelem története. A kemény kockán a fénykard egyetlen mestervágással hatol át.

Egy 65C02 processzor és kódoló logika ami „feltörhetetlen” kerámia tokban várta, hogy összemérjem vele az erőmet.

Eredeti FunWorld kártya. Forrás: https://team-europe.blogspot.com/2017/03/

Ebben a posztban egy igazi intellektuális kihívást szeretnék ismertetni, utalnék arra, hogy sokan sokféleképpen állnak a problémákhoz. Vannak akik izomból és vannak akik ésszel csinálják.

Történt úgy 1996 körül, hogy egy kedves megrendelőm beállított a fenti képen szereplő játékkártyával, ha jól emlékszem Omega-Card pókerprogram volt benne, és azt a feladatot adta, hogy egy taiwani kártyában szeretné ugyanezt a programot futtatni.

Azt a bizonyos taiwani kártyát már jól ismertem, akkori munkahelyemen is volt szerencsém a bele írt „jugó – magic” programot javítgatni benne, de hogy mindenki ráismerjen itt látható a képe:

Szóval, annyi volt tudható első blikkre a kártyákról, hogy hasonlóak. Először is, a kártyában lévő statikus RAM tartalmát kellett biztonságba helyezni, mert bizony a próbálkozások során -ha a RAM elveszti a tartalmát („elfelejt”) akkor korántsem biztos, hogy újra lehet indítani a programot. Láttunk már telefonszámos, kódos megoldást is, így reflexből a RAM tartalom mentéssel kezdődik mindig a mutatvány.

Ez úgy történik, hogy egy akkut a RAM tetejére forraszt az ember a táp és a föld közé, majd a RAM CE lábát az akku táppal egy 3K3 ellenállással összeköti. Ezután már kivehető a foglalatából és egy EPROM égetővel szépen kinyerhető belőle a tartalom.

Ezután az EPROM-ok kiolvasása következett, de a program EPROM-ból semmilyen értelmes tartalom nem jött ki, masszív kódoló logika őrizte a titkot.

Az eredeti kártyából a kínaiba a kódolt processzort és az EPROM-okat, valamint a szín generáló PROM-ot és a rendszer GAL-t átrakva a próbáltam elindítani a programot, talán jó volt a megérzésem és van valami köze a kártyáknak egymáshoz.

Nagy örömömre a program beindult, de mivel a STAT-RAM tartalmát nem másoltam át, hibára futott. De ez akkor lényegtelen volt, ezzel a kísérlettel meggyőződtem arról, hogy a titok pusztán egy kerámia tokban rejtőzik. Láttam már korábbi próbálkozásokat, egy haverom kiköszörülte a tokot, de érdemben közelebb nem jutott a megoldáshoz. A borítóképhez kapcsolódó linken egy európai hacker csapat pontatlan bejegyzése látható akik ugyan ki bírták csiszolni a chipet, de tévednek. A leírásban Z80-ként valószínűsítik az eszköz processzorát, a valóságban azonban egy 65C02 processzor a megoldás.

A kezdeti örömöm és lelkesedésem néhány próbálkozás után kezdett megtorpanni: A memória végén található RESET, NMI, IRQ vektorok helyét a kódolt memóriában még lehetett azonosítani logikai analizátorral a RESET megjelenése utáni memória olvasásból, de aztán semmi. A processzor és a memória közé iktatott kódoló logika cím és adatfüggő módon elkódolta a program memória tartalmát.

Emlékeztetőül, egy 65C02 processzor memória modellje valahogy úgy néz ki, hogy:

  • 0xFFFE,0xFFFF – INT vektor
  • 0xFFFC,0xFFFD – NMI vektor
  • 0xFFFA,0xFFFB – RESET vektor
  • 0x0200 – 0xFFF9 – memory
  • 0x0100- 0x01FF – STACK RAM
  • 0x0000- 0x00ff – ZERO page, special indexing modes

A program GAL- jának méregetéséből kiderült még a következő memória felosztás:

  • 0x0000-0x07FF- STAT RAM
  • 0x0c00-0x0c0f- IO1
  • 0x0d00-0x0d0f- IO2
  • 0x0e00-0x0e0f- CGA ctrl
  • 0x0f00-0x0f0f- Sound ctrl
  • 0x4000-0x7fff- Extra ROM
  • 0x8000-0xffff- Program ROM

A memória modellből látható, hogy a perifériák és a RAM memóriák 0x1000 cím alatt találhatóak. Ez szöget ütött a fejembe, és megvizsgáltam a korábban kimentett SRAM tartalmat. Ebben a legnagyobb meglepetésemre értelmes BCD kódolt számokat (könyvelés adatai) és néhány olvasható szöveget vettem észre.

Ez azért különösen jelentős, mert rávilágít a védelmi kódolás hibájára: az alsó 0x1000 ig terjedő címtartományban nincs kódolás! (Hiszen, ha kétirányú lenne (R/W) a kódolás akkor a RAM területre írás is el lenne „obfuskálva”, és az IO chipek elérése sem lenne egyszerű, hiszen a kétirányú kódolás esetén a regiszterek helye és értéke a kódoló logika miatt változna. Így ez az architektúra nem lehet kétirányú, csak az EPROM területeket érinti, és azt is csak kiolvasáskor. A RAM a kétirányú használat miatt nem lehet kódolt.) Ennyi közbevetés után adódik a kérdés rögtön:

Hogyan lehetne ide kódot juttatni be, és hogyan lehetne rávenni a processzort, hogy azt végre is hajtsa? Hiszen a reset vektor a kódolt területen van!

Azért a RAM területre, mert ez a processzor von Neumann architektúrájú, vagyis a teljes address space-ben elhelyezhető a végrehajtható kód, és mint előbb bemutattam, a SRAM terület és ebben lévő veremtár nem védett a kódoló logika által.

Persze, rögtön bevillant a C64 korszakból az ISEPIC típusú „rögtöninduló”, ami egy olyan fájl volt tipikusan, ami a veremtárba töltődött, az elején kóddal, a végén 0x01 bájtok sorozatával. Ezek a bájtok egyformák, hogy a veremmutató páros vagy páratlan volta (a 16 bites cím alsó és felső bájtjának helye nem ismert a betöltődéskor), az SP regiszter valahová a végére mutat. A töltő rutin végén az RTS utasítás a felülírt veremből veszi elő a visszatérési címet, így elindítja a stack elején a programkódot.

Ekkor megterveztem a „fénykardom”: A statikus RAM lábkiosztásával az alaplaphoz kapcsolódó, de EPROM-ot is tartalmazó memória bővítés, ami egy kapcsoló átbillentésével a veremtárat és az utána következő egy lapot – átkapcsolja EPROM területre. Az átkapcsolást a PEEL végzi, az átkapcsoló függvény a sok bement miatt a 22V10 GAL-ban lett megírva.

Így juttat kódot a nem kódolt memóriarészbe és így el is tudja indítani. Észre kell venni, hogy ilyenkor nincs STACK memóriánk, így szubrutint hívni nem tudunk. (Lehet, csak nincs visszatérési cím.)

Innen már karikacsapásként ment a dolog, egy Royal-Card programból kiollózott IO chip inicializálással indított „rögtöninduló” kiportoló programmal a memória kiolvasható és a számláló kimeneteken keresztül kiadható a külvilágba, mert a processzor saját kódját tudja olvasni a logikáján keresztül.

A gyártott PCB hátsó oldala.

A megrendelés szoros határideje miatt még zöldítés sem készült a nyomtatott áramköri lemezre. Amint megvolt a nyák, gyorsan összeraktam, felélesztettem, majd megírtam a programot.

A kód elején található adat a veremtárat írja felül, és beindítja a 0x0202 címtől kezdődő kiportoló programot.

Nem bírtam kivárni azt, hogy számítógéppel printer portra kötve az érkező adatokat azonmód rögzítsem, hanem a kártyát összeraktam és remegő ujjakkal bekapcsoltam.

A játék beindult, minden rendben volt. A memória átkapcsoló vezetékére kötött kapcsolót átbillentettem, majd a számlálók vidám ciripelése tudatta, sikerült túljárjak a védelem eszén.

Körülbelül 7 óra elteltével a fénykardom programja kiszippantotta a tudást és azt a hozzá kapcsolódó számítógép rögzítette. A kapott tartalmat EPROMBA égettem, majd az eredeti kártyában lévő kódolt processzort egy originális 65C02 processzorra cserélve a beégetett nyitott eprom azonnal hibátlanul elindult.

Röviden ennyi a fénykardom története, egy igazi élmény volt a küzdelem!

Komment, észrevétel jöhet!

Szerző: Jáger Zoltán Tamás

53 éves okleveles vegyész és gépészmérnök vagyok. Vezettem autót, helikoptert, jártam északon és délen az út végéig elmentem. Nézem a világot, teszem amit kell. Újévi fogadalmam: többet, jobban!

Vélemény, hozzászólás?

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük