• kvp
    #62
    "Ez elmeletileg _titkos_ tehat ha tudsz valamit, akkor kerlek egy forumban _NEM_ kiadni az informaciot!!!"
    akkor már megint csak FUD-oltál ezzel is?

    Szeretnem felhivni a figyelmed arra, hogy aki tudhat barmifele informaciot az _NEM_ adhatja ki (valoszinuleg te sem), aki pedig nem tudja, az nem cafolhatja meg. Tehat ezt a temat tekintsuk veglegesen lezartnak.

    "semmi titok nincs, a shared source program sokéve elérhető"
    Csak a magyarok nem neztek at. Az egyetemek igen, de a tenyleges felhasznalo szervezetek sajnos nem. (az atfedeseket es megbizasokat a ket struktura kozott most hagyjuk)

    ""de a drm rendszer szamara irt drivereket hogy fogom debug-olni?"
    na jólvan, haladunk, az előbb még minden kernelszintű driverről beszéltél, most már csak a drm-et érintő driverekről. Ez egy picit már leszűkitette az érintettek körét. Ezek tipikusan nem otthoni barkács fejlesztők (és nem is kinai dzsunka hardvergyártók) nekik valóban szükségük lesz egy pár modositott file-ra. De ez a fejlesztők 99%-át nem érinti."

    Mivel minden kernel szinten futo driver erinti a drm-et, ezert barmilyen olyan fejlesztesrol beszelek amit a kernel szintre kell betolteni. Igy ket lehetoseg marad, vagy nem kernel szinten futo driver-t fejleszteni, ami csak a szabvanyos kulso buszos keszulekeknel lehetseges (amihez a busz meghajtot az ms irja, ilyen pl az usb), vagy ala kell iratni a driver-t a microsoft-al. (ez viszont bonyolult es draga, tovabba az ms nem engedi meg az open source-osoknak)

    Ilyen kozvetlen hardverhozzaferest es ezert kernel szintu driver-t igenylo fejlesztes pl. a sajat pci (vagy pci-e) kartya keszitese. Eleg sok kis ceg gyart specialis vezerlo celkartyakat. Ezek a hardverek csak kernel modbol, teljes hardver hozzaferes eseten erhetoek el. (ilyenek a halozati, a videokartyak es a hangkartyak is, de egy sima radios ora kartya is)

    A drm vedelmet a kernel vegzi, mint minden folyamat felett allo kod. A kernel csak akkor vedett, ha csak alirt driver van kernel modba betoltve. Innentol ha valakinek a printer portos mikrovezerlo egetoje igenyel egy kernel driver-t, akkor mar ez a driver is ki fogja kapcsolni a drm rendszert. Nem erinti a drm-et, de mivel kozvetlenul hozzanyulhat a hardverhez es ezert a kernelbe kell tolteni, igy vagy ala van irva, vagy rogton nincs drm es hd film lejatszas.

    A windows nt kernelek (nt3,nt4,nt5=w2k,nt5.1=wxp) nem tudnak harver hozzaferes szerint szeparalni az alacsony szintu driver-ek kozott, ezert minden kernelbe betoltott driver-nek kell a digitalis alairas, kulonben az elso nem biztonsagos driver felulirhatna a leirotablakat es minden user modu program irhatna a kernel teruletet. (van ilyen demo driver, winxp alatt is kitunoen mukodik, betoltes utan a rendszer stabilitasat es biztonsagat leviszi a win95 szintjere)

    A gond, hogy a vista meg mindig nem teljesen mikrokerneles. (a fo ok a kartya oldali bus master dma jelenlete es a pc i/o terenek kaotikussaga) Igy nem lehet _minden_ driver-t elszeparalni. Az eredmeny hogy a port irasokat vegzo driver-ek kenytelenek a kernellel egy biztosnagi szinten ulni. Igy viszont olyanok, mintha a kernel reszei lennenek. Az eredmeny, hogy a cpu nem tudja megkulonboztetni a driver kodot a kerneltol, ezert azonos jogon futnak. Tipikusan az osszes pci buszos kartya es az osszes alaplapi funkcio driver-e ilyen. (drm-et nem erinto driverek a kernelben: raid driver, radios ora driver-e, vezerlokartyak driverei, stb.) Ezeket hogy fogjak a kis cegek fejleszteni? Vagy alairatjak a microsoft-al, vagy ha ilyen hardver kerul a gepbe akkor nem lesz hd lejatszas. (vagy valahogy letiltjak a microsoftnal a bus master dma-t, hogy legyen mod rendes hardver/driver elkulonitesre, amire nem sok eselyt latok)

    "" A videokartyakon pedig kellene csinalni egy hd path-et, ami kikeruli a kartyakat, tehat toluk fuggetlen 'overlay' kent mukodik."
    beszéld meg a videókártya gyártókkal és a kiadókkal."

    Az ati ezt akarja, igy tudnanak linux kompatibilis hd player kartyakat is kiadni. Az ms valamiert ezt nem akarja...

    "csak éppen az a memóriarész nem elérhető más processek számára, lévén védett process, erről beszélünk két napja, tehát szoftveres megoldások kilőve. Aki pedig a memóriabuszra ráforraszt valamit amivel megsniffeli a forgalmat, az egyrészt megérdemli, másrészt annak nem kell pc-kkel bohóckodnia, az máshonnan is megszeri a kulcsot. De innentől ez azt is jelentené, hogy az otthoni user képtelen rippelni, ami elég súlyos csapás."

    Erre valok az ice alapu memory buffer-ek, ami semmi mast nem tesz, csak beul az alaplap es a memoria modul kozze, es naplozza a forgalmat. Ezutan vagy egy masik gep vagy ugyanaz a gep egy masik csatolon (mondjuk usb) keresztul kepes olvasni a rendszermemoriat is. Ilyen cuccot lehet kapni keszletben is. (kit-ben) Gyakorlatilag egy tulmeretes memoria modul, amin van meg egy mikrovezerlo is es amibol kilog egy usb (vagy tobbnyire jtag) csatlakozo. Megveszed, berakod, elinditod a lejatszast, majd egy 'celszoftver' kiadja a kulcsot. Hasonloval esett neki egy 'fejlesztocsapat' az ellopott xbox360-as devkiteknek es ekkor derult ki, hogy meg a rendszermemoria is aes128-al van titkositva. Szerencsere az x86-os vonal ezt meg nem tamogatja. (kiveve a via egy par celprocesszorat)

    A fud-rol meg csak annyit hogy vegigneztem az msdn-es anyagokat es ez lapjan allitom hogy ez igy az atlag felhasznalonak es a fejlesztoknek szivas lesz. A kalozoknak es a lopott szofterrel rohangaloknak viszont nem.