Jump to content
Ménemszól.hu
  • 0

Modern hardware gyártók és a Linux - Dühöngő


wendelmar

Kérdés

válasz erre a kérdésre

Recommended Posts

No azért az mplab csak a pic mikroverzérlőket ismeri, de azokat sem fordítja vissza mindig eredményesen (mondjuk 90%-os hatékonyságú). A lexichiphez meg viszonylag gyors pic kell, vagy a lexichipet kell lelassítani, de akkor meg inkább egy logikai analizátor, de azzal sem egyszerű, bár ha jól emlékszem mindössze 128 programlépés / minta az algo. Ha megvan le lehet fordítani valami hétköznapi dsp-re, fpga-ra akármire. Sok-sok szabadidő kell hozzá az biztos.

FPGA a nyerő :)

Link to comment
Share on other sites

Pont az ilyen témákat szeretem :)

Egyébként beletörődtem már hogy nem fognak kimondottan linux hw-t gyártani (persze az alap vas-t ne vegyük bele : )

De mégis a Nordokhoz van opensource editor.(még mindig nem free software).

Midi-t is belevehetjük mert egy sztender. http://www.linuxstudiopro.com/#

Lehet csemegézni.

Viszont divat, nem divat ugyan a Native Instrument Maschine-t kezeli-e?(8potis változatát) Vagy ne adj isten az Akai Ableton kontrollert?

ui: most jut eszembe ilyen is van: http://forum.renoise.com/uploads/post-896-0-48080200-1324540952.png

Link to comment
Share on other sites

A kiolvasáshoz nem kell működnie az eszköznek, néhány cég bevállalja ma is, ha elküldöd neki a mikrovezértlőt, megfelelő összegért cserébe kiolvassák és megkapod a .hex fájlt.

Na jól elkanyarodtunk a témától, de legalább meg tudjuk beszélni... :)

Szóval egyrészt az ilyen chipek védett tartalma is ugyanolyan, ha nem erősebb jogi szabályokkal, szerzői, szabadalmi hatáskör alá tartozik, ami érthető, hisz egy cég szellemi tulajdona, amiből próbál megélni. Vagyis ennek akár a fenti úton való lenyúlása törvényes keretek közt biztos hogy nem megy, mert ipari kémkedés. Persze a "sufnyi józsi" vállalkozások biztos nekimennének ilyeneknek, de sem nekik, sem a Lexicon konkurenseinek nincs több százmilliós eszközparkjuk rá.

A zengetők meg olyan felépítésűek voltak pl. Lexiconéknál, hogy egy-egy alkatrész ilyen kivizsgálása semmire nem vezethetne, hisz összetett módon, modul rendszerűen üzemeltek.

Az egyszerűbb epromok kiolvasása persze ettől még működhet "mezeibb" körülmények között...

Link to comment
Share on other sites

Akkor meg működés közben kéne logikai analizátorral nézni hogy mit művel az áramkör, egy szinusszal mondjuk...(bemenőjelnek.)

Sokcsatornás, nagysebességű analizátor kell hozzá és rengeteg idő, mert amit kiolvasol még vissza is kell fejteni, az meg nem egyszerű.

Link to comment
Share on other sites

Anno a Lexicon nagyon a csúcson volt zengetők ügyében. Később a TC Electronic kezdett feléjük nőni, majd jött a Sony az impulzusválasz mintavételi technológiával. Addig azonban sokan próbálták utólérni a Lexicont és valahogy lemásolni az algoritmusait a Lexi chip ből. Én anno erre rákérdeztem az automatizálás tanáromnál ilyesmi hogyan lehetséges és ő mondta hogy ha védett egy eprom, akkor csak az ilyen "reszelgetős" megoldás müxik ami után mikroszkóp alatt olvassák ki az információt. Ebben csak az nekem máig a hihetetlen, hogy a dolgot mindenképp működés közben kell végezni. Ehhez pedig megnézném hogy raknak be egy komplett áramkört a szkenning mikroszkóp alá! :)

A kiolvasáshoz nem kell működnie az eszköznek, néhány cég bevállalja ma is, ha elküldöd neki a mikrovezértlőt, megfelelő összegért cserébe kiolvassák és megkapod a .hex fájlt.

Link to comment
Share on other sites

Igen erre gondoltam.

Anno a Lexicon nagyon a csúcson volt zengetők ügyében. Később a TC Electronic kezdett feléjük nőni, majd jött a Sony az impulzusválasz mintavételi technológiával. Addig azonban sokan próbálták utólérni a Lexicont és valahogy lemásolni az algoritmusait a Lexi chip ből. Én anno erre rákérdeztem az automatizálás tanáromnál ilyesmi hogyan lehetséges és ő mondta hogy ha védett egy eprom, akkor csak az ilyen "reszelgetős" megoldás müxik ami után mikroszkóp alatt olvassák ki az információt. Ebben csak az nekem máig a hihetetlen, hogy a dolgot mindenképp működés közben kell végezni. Ehhez pedig megnézném hogy raknak be egy komplett áramkört a szkenning mikroszkóp alá! :)

Link to comment
Share on other sites

Nevetni fogsz, de ezt a mai napig csinálják, lemaratják a chip tetejét, elektronmikroszkóppal ki tudák olvasni az egyébként védett firmwaret, vagy a logikai hálót cpld esetén. Piceknél pl. kikeresik a védelmi bitet, uv-lézerrel megvilágítják, az szépen "törlődik" (visszaáll alapállapotba) és olvasható is a firmware hagyományos módon. 

Pedig azt hittem az eljárás közben annyira sérülékeny az a nano, mikron mérettartományú lapka hogy ez eleve kizárja az ilyen behatásokat. (csináltam már SEM alá pár mintaelőkészítést laborban, innen a szkepticizmusom, de ezek szerint semmiben nem szabad előre kételkedni!) :)

Persze ki tudja a KGB mit fejlesztett ki annak idején. Az ipari kémkedés nagy politikai tényező volt a hidegháború idején. Jó tudni ilyesmiről is! :)

Amúgy ha valaki érti a technológia működését és felépítését, könnyen ki tud találni furmányos dolgokat ezek szerint, amivel "bemehet a zárt ajtón" is, á la nincs ellophatatlan titok, főleg a mai technikai korszakban, legfeljebb addigra elavul a kérdéses információ...

Link to comment
Share on other sites

Nekem annó azt mesélte egy ilyenekkel foglalkozó tanár az egyetemen, hogy valami nagyon spéci géppel "leköszörülik" a tokozás tetejét lehelet finoman majd SEM vagy hasonló mikroszkóp alatt nézik a dolgokat, óriási milliárdos apparátussal felvonulva... 

A technikai hátterét ismerve amúgy ez baromság, max az oroszok 50 éve csinálhattak ilyet amilyen ostobák voltak. :)

Nevetni fogsz, de ezt a mai napig csinálják, lemaratják a chip tetejét, elektronmikroszkóppal ki tudák olvasni az egyébként védett firmwaret, vagy a logikai hálót cpld esetén. Piceknél pl. kikeresik a védelmi bitet, uv-lézerrel megvilágítják, az szépen "törlődik" (visszaáll alapállapotba) és olvasható is a firmware hagyományos módon. 

Link to comment
Share on other sites

No azért az mplab csak a pic mikroverzérlőket ismeri, de azokat sem fordítja vissza mindig eredményesen (mondjuk 90%-os hatékonyságú). A lexichiphez meg viszonylag gyors pic kell, vagy a lexichipet kell lelassítani, de akkor meg inkább egy logikai analizátor, de azzal sem egyszerű, bár ha jól emlékszem mindössze 128 programlépés / minta az algo. Ha megvan le lehet fordítani valami hétköznapi dsp-re, fpga-ra akármire. Sok-sok szabadidő kell hozzá az biztos.

Nekem annó azt mesélte egy ilyenekkel foglalkozó tanár az egyetemen, hogy valami nagyon spéci géppel "leköszörülik" a tokozás tetejét lehelet finoman majd SEM vagy hasonló mikroszkóp alatt nézik a dolgokat, óriási milliárdos apparátussal felvonulva... 

A technikai hátterét ismerve amúgy ez baromság, max az oroszok 50 éve csinálhattak ilyet amilyen ostobák voltak. :)

Link to comment
Share on other sites

No azért az mplab csak a pic mikroverzérlőket ismeri, de azokat sem fordítja vissza mindig eredményesen (mondjuk 90%-os hatékonyságú). A lexichiphez meg viszonylag gyors pic kell, vagy a lexichipet kell lelassítani, de akkor meg inkább egy logikai analizátor, de azzal sem egyszerű, bár ha jól emlékszem mindössze 128 programlépés / minta az algo. Ha megvan le lehet fordítani valami hétköznapi dsp-re, fpga-ra akármire. Sok-sok szabadidő kell hozzá az biztos.

Link to comment
Share on other sites

Barom egyszerű visszafejteni egy programot. Bár ezt csak uC szinten tudom, hex fájlból az mp lab generál asmet. Lényegében az asm is már egy "gépi kód" mert ugyanazokat a "biteket" tologatod benne mint ha b3,e2 76 stb-t pötyögnél be...

Am ez a Lexiconos pices dolog mi is lenne ?

Link to comment
Share on other sites

Valami hasonlót sejtettem én is. Igen, pl. a 20 éves SONY tv-mhez is még járt szervízrajz is a jótállással... :)

Ilyen kódvisszafejtési legendát viszont régebben nem vettem komolyan, ezek szerint mégis igaz lehet. (persze ott állítólag más volt a cél, még anno a Lexicon effektek algoritmusát akarták "leszívni" chip szinten valami PIC-kel talán)

Link to comment
Share on other sites

Tulajdonképpen az adott eszköz és a gép közötti "kommunikációt" kell vagy visszafejteni, vagy megszerezni a gyártótól.

Tehát hogy pl. egy adott USB porton ha bejön egy olyan kódsorozat, hogy "F0-13-AB-37-E5" (marhaság, de mondjuk), akkor az azt jelenti, hogy mozdítsd az egérkurzort két pixellel balra.

Annak idején kellett írnom egy soros porti vonalkód nyomtatóhoz egy saját "eljárás gyűjteményt", hogy bármilyen tartalmú, méretű, kódolású címkét tudjak nyomtatni. Nekem "egyszerű" dolgom volt, mert a doksi megvolt, amiben részletesen leírták, hogy milyen utasítással mit lehet "elérni" a nyomtatón.

Ha ilyen doksi nincs (mert a gyártók féltékenyen őrzik), akkor bizony vissza kell fejteni az eszköz és a gép közötti kommunikációt.

Jellemző a mai világra, hogy mondjuk 15 évvek ezetőtt a HP nyomtatókhoz mellékelték azt a doksit, hogy milyen ú.n. ESC karakterekkel milyen beállítások érhetőek el. Ez ma már nincs...

A Creativ pl. közkinccsé tette az EMU10K család doksiját, ezért indulhatott el a kx-project (ha jól emlékszem a nevére).

Link to comment
Share on other sites

Csak úgy széljegyzetként, mert ez engem már régen érdekel, kizárólag mint laikus kíváncsiskodót, de egy driver megírás miből áll igazából? Már onnan kiindulva hogy régen linuxra még az egérnek is drivert kellett írnia aki értett hozzá. Gondolom én, ebben vmi port kezelés és egyéb ismeretlen dolgok voltak esetleg assemblyben? :D

Szerintem ui. ez még igen messze áll az általános info szakkörön megtanulható prog. alapok, (ciklus, tömb stb.) világától...

Link to comment
Share on other sites

A linuxon (és más unixokon is) létezik a jack lib, ami azért egyfajta standard. A kernelbe nyúlásokat úgy értem, hogy pl. a Red Hat is fejleszt / reszelget / javítgat a kernelen, meg pl. az Oracle is kicsit "moddolta" a Red Hat disztrót... A különböző verziójú libekben meg azért elég "szép" (na jó, csúnya) dolgokat tudnak elkövetni, hogy egyik verzióról a másikra valami "obsolote / deprcated" legyen... (legalább is régebben futottam bele ilyen dolgokba... aztán fordíthattam újra be egy drivert az új libekkel, új kernel forrással...)

Link to comment
Share on other sites

Valóban jó kérdés hogy mire jó az a rengeteg distro. Mások meg ezeket tekintik a linux előnyének, hogy mindenki személyre szabhatja (mondjuk úgy tudom a kernelbe azért Torwalds sem enged belefirkálni másnak).

Én nagyon gondolkodok egy Mintet kipróbálni mostanság mellék vágányként, hátha bejön. Kezd elegem lenni ui. a windows örökös babusgatásával és nyafogásaival. Persze tudom a linux még kutyább és hardcore programozó szemléletet erőltet a userekre, de ahogy környezetemben látom, 1-2 év alatt elég szép szintre el lehet benne jutni ahol már kényelmesebb a hátradőlés, mint windowson. Na majd meglátjuk, egyenlőre bizakodó vagyok! :)

Másrészt szerintem ezek a hardver gyártók ismerik hogy a win/Mac platformon kívül a linux nagyon picike szegmens zenei téren, nem hiába mint unix alapokon főként szerverekre szánt dolog volt kezdetekben. Azt meg már csak hatványozza negatívan, hogy fél évente változnak a dolgok, felszorozva a kismillió változattal ami létezik linuxból. Még ha jól tudom olyan egyetlen egységes dolog sincs mint az ASIO PC-n, abban is mindenféle változatok sarjadnak linux alatt. Így valóban nehéz és értelmetlen is a gyártóknak vele foglalkozni szerintem.

Link to comment
Share on other sites

Elöljáróban annyit: 15 évig ('95 óta) (napi szinten!) linuxoztam, azon (is) fejlesztettem, és valahol tökéletesen megértem a sirámokat... DE!!

Egyrészről van igazság abban, hogy esetleg az ember szidja a HW gyártókat, hogy miért nem képesek a Linuxhoz megfelelő dirver-eket "gyártani". (Pláne úgy, hogy a legtöbb - vagy nagyon sok - hardware-hez a Linux közösség lelkes és hozzáértő tagjai feljesztenek driver-eket, már ha egyáltalán sikerül a gyártókból kicsikarni a minimálisan elégséges információt... de ez egy teljesen más történet.)

Viszont - egy kicsit az ördög ügyvédjeként - hadd védjem meg őket: a közkézen forgó linux disztribúciók eleve mindenféle kernel verziókkal, lib verziókkal kerülnek forgalomba, és elég gyorsan követik egymást a kernel és lib frissítések.

Másrészt az egyes disztribúciók elkészítői többé kevésbé belenyúlnak a kernelbe is és a libekbe is, hogy egy kicsit jobbá, mássá, "tisztábbá-szárazabbá" tegyék a disztrót.

Harmadrészt többféle csomag-telepítési "workflow"-t használnak.

Namármost a windowson is (ahol azért nem ennyire sűrű a frissítési ciklus, ráadásul "egy kézben van" a fejlesztés) és az OSX-en is (ahol dettó) néha-néha belefutnak a gyártók olyanba, hogy egy frissítés után egyszercsak hipp-hopp nem működik (ez az egyszerűbb eset talán) vagy rosszul (kiszámíthatatlanul) működik a "cucc".

A fentieket végiggondolva, lehet, hogy érthető, ha a "komoly", egyébként windows és OSX paltformról normálisan megélő gyártók nem vállalják fel a "homokzsák" szerepét... Hogy aztán mindenki azért "ekézze" őket, mert az éppen aktuális linux kombón nem megy a vas...

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...