- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- iPhone topik
- Samsung Galaxy S24 - nos, Exynos
- Redmi Note 9 Pro [joyeuse]
- Samsung Galaxy Watch7 - kötelező kör
- One mobilszolgáltatások
- Sony WF-C710N - átlátok rajta
- Milyen okostelefont vegyek?
- Android szakmai topik
- Android alkalmazások - szoftver kibeszélő topik
Új hozzászólás Aktív témák
-
#91
nyaralasptt
csendes tag
mikk2000
#90
nyaralasptt
csendes tag
Látom a matek nem az erosseged...
1.
''...És ez a két bit még olyan messze van a 128 bittől...''
Leirom megegyszer, hogy megertsd: Tok mindegy, hogy honnan jon ossze a 2^128 lehetoseg. Mindegy, hogy 1 2^128 bit hosszu /most mindegy, hogy ilyen hosszu fajl nincs/ fajlban modositasz mindig csak 1 bitet, vagy lenyegesen rovidebb fajlban 2-t, 3-t...128-at /n!/((k!)*(n-k)!) legyen 2^128 ugye/. Ugyhogy az elso bekezdesed egy baromsag, mivel a fajl hosszanak az eg egyadta vilagon semmi koze az egeszhez.
2.
''Magadat cáfolod meg,...''
Nezz utanna mi a kulonbseg a konstruktiv es az egzisztencia tetelek kozott.
3. ''Tetszoleges fajlra igaz, fuggetlenul annak hosszatol, amennyiben legalabb 128 bit, hogy bitjei kozul tetszolegesen kivalasztott legfeljebb 128 darab modositasaval, az eredeti es a modositott fajl hash-e megegyezik, amennyiben a hash fuggveny invertalhato erre a halmazra.
Ez egy állítás, ami egyáltalán nincs alátámasztva, és képletnek se látom. Ez lenne az emlegetett matematikai bizonyítás ?''
Abszolut primitiv formaba redukalva a bizonyitas:
FIGYELEM!!! EGZISZTENCI ALLITAS!!! NEM KONSTRUKTIV!!!
-Van 128 bited, amibol tetszoleges bit ill. bitsorozat megvaltoztatasanak hatasara a kimenet /hash/ valami random szam lesz.
-Annak valoszinusege, hogy ket 128 bites rnd. szam pont egyenlo: 2^128:1.
-128 biten pontosan 2^128 bemenetet lehet eloallitani
-Annak valoszinusege, hogy a 2^128 db bemenet kozott letezik olyan, amelynek hash-e megegyezik az elore megadott ertekkel /file hash/: 1-{2^128-1/(2^128)}^(2^128) ~lim(n->vegtelen)1-{(n-1)/n}^n = 0.63578 = 63.5781%!!!
/Es itt nem is hasznaltam fel semmit az invertalhatosagbol, pusztan csak a crypto hash definiciot./
Szerinted, ebben a bizonyitasban hol a hiba?
Amivel ne farassz: 1. 63.57% != 100% -> Ekkor nyilvan nem erted a bizonyitas lenyeget, es valoszinuleg soha semmilyen diszkret matematika/valoszinusegszamitas tetelt nem lattal.
Ha megis ezzel tamadnal: A 100%-ot tetszolegesen lehet kozeliteni plussz bitek hozzaadasaval.
2. De a plussz bitek miatt mar nem 128 bit kell...
Ez esetben feltetelezhetoen a fuggvenyanalizis is kimaradt az eletedbol...
segitseg 1. /valoszinuseg fuggese a plusz bitek szamatol/: P = 1-e^x, ahol P az egyezes valoszinusege, x a plusz bitek szama
segitseg 2. : + 4 db bit /azaz osszesen 132 db/ P = 0.999999887 = 99.9999887%
A gyakorlati jelentosegen, jovoben kitalalando toresen, biztos osszeveszhetunk, de semmi ertelme, ezert inkabb a konkret allitas/bizonyitas-rol vitatkozzunk, ha lehet, illetve az abbol levonhato /nem tul messzemeno/ kovetkeztetesekrol.
[Szerkesztve] -
#90
mikk2000
őstag
nyaralasptt
#89
mikk2000
őstag
válasz
nyaralasptt
#89
üzenetére
Namost, ha neked a matematikai bizonyitas, nem bizonyitas, akkor ne is olvass tovabb...
Hát, jelen esetben engem konkrétan az érdekelt, hogy a gyakorlatban mennyire jelent a veszélyt a felhasználóra az md5 esetleges törése. Egy esetleges jó hosszú képlet még nem bizonyíték, de még ha el is fogadom hogy működik, akkor sem ad választ a valós használhatóságra, nem véletlenül emlegettem szerverparknyi (vagy jóval nagyobb) számítógép-kapacitást, hiszen a kérdéses módosító bitek megtalálása rendkívül nagy számítógép-kapacitást igényelhetnek, hiszen minden egyes bit módosítása miatt újra kell számolni a hash-t az egész fájlra. Egészen pontosan ahány bitből áll a fájl, annyiszor. Szerintem 1 bit módosítása még nem fog célra vezetni, a 128 bit körüli érték (most példakén fogadjuk el a 128 bit-et, szerintem ennél jóval több kell) nagyságrendekkel nagyobb, hiszen már 2 bitnél(!) a kombinációs lehetőségek miatt a (fájl hossz bitben*fájl hossz bitben) alkalommal kell hash-t számolni, ami az adott 2mbyte-os fájlnál
281 474 976 710 656 (!)
hash generálás. És ez a két bit még olyan messze van a 128 bittől és ügye a bitek emelkedésével hatványozódva növekszik a számítási szükségesség...és ügye a kisebb bitszámú kombinációkat is mind végig kell számolni, tehát először 1 bittel végig a fájlon aztán 1+1 bittel, aztán 1+1+1 bittel. Khhmmm.
Röviden, ha a szükséges ál-hash érték megtalálása mondjuk 10 a 917-en évig tartana, akkor ez ügye nem reális veszély a felhasználókra nézve, hiszen ennyi idő alatt sok milliószor omlik porrá a naprendszerünk és jön létre újra más lényekkel...
Tetszoleges fajlra igaz, fuggetlenul annak hosszatol, amennyiben legalabb 128 bit, hogy bitjei kozul tetszolegesen kivalasztott legfeljebb 128 darab modositasaval, az eredeti es a modositott fajl hash-e megegyezik, amennyiben a hash fuggveny invertalhato erre a halmazra.
Ez egy állítás, ami egyáltalán nincs alátámasztva, és képletnek se látom. Ez lenne az emlegetett matematikai bizonyítás ?
Ráadásul ha a 128 bit különbüző byte-okban található, akkor máris 128 byte módosításnál járunk. Az utolsó bekezdés amúgy is hatástalanítja ezt az állítást, hiszen azzal kezdi hogy amennyiben.
A 128 bit onnan jon, hogy megneztem az md-5 hash meretet.
Ez igaz, de nem is volt nehéz kiszámolni. Biztosan könnyebb, mint egy 2mbyte-os fájlhoz egyező md5-öt.
Persze lehet, hogy a te sejtesed az igaz es telleg nagy volumenu modositasra lesz szukseg (...)
Magadat cáfolod meg, fentebb még azt állítottad, idézem újra : Tetszoleges fajlra igaz, fuggetlenul annak hosszatol, amennyiben legalabb 128 bit, hogy bitjei kozul tetszolegesen kivalasztott legfeljebb 128 darab modositasaval, az eredeti es a modositott fajl hash-e megegyezik, amennyiben a hash fuggveny invertalhato erre a halmazra.
Khm.
Mivel a usernek fogalma nincs rola, hogy pl. a telepites alatt milyen kepnek kell a hatter elott lennie ezert a hacker nyugottan megteheti, hogy egy masik, jobban tomoritheto /mondjuk egyenletes kek, fraktalmintas stb./ kepre csereli le az eredetit, vagy egyszeruen nem rak semmit az ures hatter ele. Ezzel maris megsporolt egy csomo helyet.
Ez igaz akkor, ha először telepíti, de ha többedjére, akkor kiszúrhatja.
Viszont ez a fajta trükközés csak akkor kellene, ha a fájl hossza ellenőrzött információ lenne, holott md5-nl nem az, ez akkor lett volna ellenőrzött ha a javaslatomra az md5-be bekerülne a fájl hossza...tehát ha azt állítottad hogy az általam szükségesnek vélt vádelem bővítés fájl-hossz eltárolásal szükségtelen, akkor ne agyalj azon hogyan lehetne az eredeti fájl méretet megőrizni.
franc se akar meg most is matematikai tetelekkel szorakozni, gyakorlati jelentosege amugy sincs sok.
Ha én állítanék valamit, ami többekben megütközést kelt, és nem tudnám bizonyítani, akkor a pofámon égne a bőr és eszembe se jutna vigyorogni, pl zöld gumilabdaként ugráló vigyorgó fejecskével. -
#89
nyaralasptt
csendes tag
mikk2000
#88
nyaralasptt
csendes tag
Namost, ha neked a matematikai bizonyitas, nem bizonyitas, akkor ne is olvass tovabb...
Megprobalom akkor meg egyertelmubben leirni, hogy mit allitok:
Tetszoleges fajlra igaz, fuggetlenul annak hosszatol, amennyiben legalabb 128 bit, hogy bitjei kozul tetszolegesen kivalasztott legfeljebb 128 darab modositasaval, az eredeti es a modositott fajl hash-e megegyezik, amennyiben a hash fuggveny invertalhato erre a halmazra.
A 128 bit onnan jon, hogy megneztem az md-5 hash meretet.
Az invertalhatosagi feltetel elhagyasa eseten az egesz allitas csak varhatoertekben lesz igaz, de nem akartam ezzel tovabb bonyolitani a cuccot.
Namost a fenti allitas existencia allitas, azaz NEM FOGLALKOZIK AZZAL, HOGY HOGYAN KELL MEGADNI EZT A MODOSITAST. A modositas megtalalasa nyilvan nehez feladat, kulonben mar milliomos lennek
, de soha nem is allitottam, hogy konnyu, amire ra akartam vilagitani az a kovetkezo: Alap valoszinusegszamitasbol kovetkezik, hogy letezik ilyen 128 bit /sot tetszoleges 128 bit ilyen/. Namost a gyakorlati tores egyaltalan nem biztos, hogy igenyli, hogy ennel tobb nagysagrendel tobbet kene modositani, bar ez nyilvan csak talalgatas, mivel egy nemletezo tores bitmodositas igenyerol van szo.
Persze lehet, hogy a te sejtesed az igaz es telleg nagy volumenu modositasra lesz szukseg, az elso ilyen modszerek megjelenesekor /ha lesznek ilyenek egyeltalan/, de ezt nem tamasztja ala semmi.
Kep: 2Mpx tulzas volt tolem.
Vegyuk az altalad irt 35k-t. Mivel a usernek fogalma nincs rola, hogy pl. a telepites alatt milyen kepnek kell a hatter elott lennie ezert a hacker nyugottan megteheti, hogy egy masik, jobban tomoritheto /mondjuk egyenletes kek, fraktalmintas stb./ kepre csereli le az eredetit, vagy egyszeruen nem rak semmit az ures hatter ele. Ezzel maris megsporolt egy csomo helyet. Persze azt is megteheti, hogy amennyiben tobb kep jelenik meg egymas utan /windows, jatekok/, akkor egyet mondjuk kivesz a listabol es a tobbit annyival hosszabb ideig mutatja.
Persze szerintem nem erdemes ezen vitatkoznunk...Orulok, hogy elvegeztem az egyetemet
, franc se akar meg most is matematikai tetelekkel szorakozni, gyakorlati jelentosege amugy sincs sok. -
#88
mikk2000
őstag
nyaralasptt
#87
mikk2000
őstag
válasz
nyaralasptt
#87
üzenetére
Olyan választ kaptam amire számítottam. Okoskodást, válaszmegkerülést.
Csak egy példa : ''Kep/zene: Ha te ket 1-2 Mpx kep kozot eszreveszel 24 byte kulonbseget''
Megadtam a lehetőséget hogy bizonyítsd hogy 24 byte módosítással/bővítéssel ugyanazt az md5 hash-t lehet generálni. Te nem hogy nem bizonyítottad, de még azt mondtad hogy akár 1 bit módosítással is el lehet ezt érni. Ez nem bizonyítás, bizonyítatlan dologgal pedig nem lehet példálózni. Mert ha valójában mondjuk 200kbyte kell azonos hash-al való felbővítéshez, maga az installer jpg kép pedig 35kbyte, akkor igencsak észrevehető...
Zavard el a tanulóidat haza, fürtözd össze az egyetem összes gépét, irj célprogramot a feladatra ami fürtözhető, akár boinc-el is nekem mindegy, de amíg nem tudod egy példán bizonyítani hogy igen csekély számú módosítás elegendő az md5 töréséhez egy 2 MB körüli fájlon, addíg engem nem győzöl meg. -
#87
nyaralasptt
csendes tag
mikk2000
#86
nyaralasptt
csendes tag
''Ezek szerint ha én küldök neked egy 2 megás install fájlt, akkor te tudsz küldeni nekem egy 2 mega+24 byte hosszú fájlt, azaz az eredeti fájl 24 byte-al felbővített változatát, és mindkét md5 hash ugyanaz lesz rá. Mikor felel ez meg ezt megejteni?''
Nem pont ezt akartam mondani, de valoszinuleg nem fogalmaztam eleg vilagosan, ezert most ujra megprobalom: van egy fajlod x hosszal, van egy hash fgv.-ed ami minden fajlhoz hozzarendel egy fix pl. 192 bit hosszu hash-t. Namost egy olyan masik fajlt keresunk, aminek a lenyomata epp megegyezik egy adott fajleval. Mint irtam a hash ugy mukodik, hogy egy bit valtas a bemeneten a kimeneti ertekben megjosolhatatlan valtozast idez elo, amit ugy is fel lehte fogni, mint egy rohadt nagy random lekepzest /marmint a lekepzest mintha ugy keszitettek volna, hogy sorbamentek az osszes lehetseges bemeneten, aztan egy 2^192 oldalu kockaval dobtak volna es ami kijott az lett a kimenet, majd a kijott vegtelen tablazatot lefixaltak volna/. Tehat annak a valoszinusege, hogy 2 fajl hash-e megegyezik eppen annyi, mint hogy ket veletlen 192 bit hosszu szam pont egyenlo, vagyis varhatoan 2^192 db veletlen bemenet kell ahhoz, hogy a szukseges egybeeses bekovetkezzen.
Namost kozbe rajottem arra, hogy korabban hulyeseget irtam, mert valtoztatashoz lehet, hogy 1 bit is eleg, a bemeneti fajlon /bar nem tul valoszinu, mert akkor kb. 2^192++ meretu fajl kene, hogy meglegyen a kello szamu bemenet/, de valoszinu 30-40 bit biztosan eleg.
A primitiv kimeriteses kereses /hash utkozesre/ kb. ugy mukodik, hogy egy fajlban nehany bitet valtoztatnak meg, majd nezik, hogy a kimenet veletlenul nem-e esik egybe az elvart ertekkel. Nekunk az egyetemen a digitalis alairas kapcsan tanitottak a cuccot, es ott olyan peldat mondtak, hogy irsz egy tok masik szerzodest, mint amit a masik fel mar alairt, majd addig addig modositgatod /extra space, karakterformazas, space helyett tab es forditva, ami a lenyegen nem valtoztat es automatizalhato/, amig a ket szerzodes hash-e egybeesik, es mar van is egy olyan doksid, amit latszolag a masik irt ala. Persze ez a modszer gyakorlatban nem kivitelezheto, de azt illusztralja, hogy nehany bit modositas is eleg lehet.
Kep/zene: Ha te ket 1-2 Mpx kep kozot eszreveszel 24 byte kulonbseget, akkor valoszinuleg az x-men tagja vagy /ugy, hogy az eredetit meg nem is lattad, vagyis honnan tudod, hogy az installerbe ott kepnek kene lenni, vagy hangnak kene szolni, meg mi van a kepen stb./.
Egyebkent pl. a hibajavito kod kijavit egy csomo hibat, tehat ha nem egy egy helyre koncentraltan modositassz, akkor a mukodes nem is valtozik, mivel a javito kodolas egyszeru hibakent kijavitja azokat, de a ket fajl nem lesz bitre egyforma.
Abban frankon igazad van, hogy tobb algo hasznalata javithatja a biztonsagot pl.: MD5 es SHA1 hash is. A hossz se gyengit, de ertelmet nem latom ,mivel szerintem semmit nem erosit /erdemben/ a biztonsagon. Egyebkent igenis hash fv. mert ellenorzesre akarod hasznalni es amugy is rendelkezik a hash tulajdonsagokkal /nem kriptografiai ertelemben/. -
#86
mikk2000
őstag
nyaralasptt
#85
mikk2000
őstag
válasz
nyaralasptt
#85
üzenetére
Kicsit vártam hogy a topic eredeti témáját ne offoljam szét, de hát nem nagyon iparkodik a nép.
Üdv!
Kb 192 bit biztosan eleg / kb. 24 Byte/, de lehet, hogy kevesebb is, ha van alcsoport.
Ezek szerint ha én küldök neked egy 2 megás install fájlt, akkor te tudsz küldeni nekem egy 2 mega+24 byte hosszú fájlt, azaz az eredeti fájl 24 byte-al felbővített változatát, és mindkét md5 hash ugyanaz lesz rá. Mikor felel ez meg ezt megejteni?
Redundans adatbol meg kb k***a sok van: kepek pixelei, klf. fontok, hangok stb., plussz egy csomo cucc ami nem kell konkretan a telepiteshez csak kesobb hasznalja a pgm.
De itt is az a gond, hogy ez észlelhető, ha egy kép egy része helyett hülyeség van, akkor vagy elszáll a képmegtekintő program rész, vagy látunk oda nem illő dolgot, betűnél szintúgy, bár annál szerintem tuti elszállás következik be, hangoknál meg minimum hallani.
A vírusok egyik jellemzőjét hajlamosak vagytok átlépni, nevezetesen hogy a lehető legnagyobb titokban kell működnie, egészen addig, amig ő úgy gondolja hogy neki titokban kell maradnia.
latszik, hogy meg nem foglalkoztal komolyan ilyesmivel, ugyanis a hossz fuggveny is egy hash fuggveny
A hossz az csak hossz, függvénynek nevezni kissé túlzás, egy fájlt nevén és tartalmán kívül a hossza jellemzi, ami keletkezésekor kötelezően meg kell hogy legyen adva, egyébként használhatatlan. Egy kötelezően megadott érték, ami létszükséglet a fájl használatához, azt kissé okoskodás hash-nak nevezni, hash maximum akkor, ha ellenőrzésre szánjuk. Szóval ne csináljunk fából vaskarikát.
Egyébként értem én , hogy arra célzol, hogy a hossz önmagában mint hash-szerűen értelmezett ellenőrző szám kevés használhatósággal bír, de én nem is önmagában mondtam, hanem kombinálva az md5-el, erősítve azt. Ha tagadod is hogy erősíti, azt nem tagadhatod hogy nem gyengíti.
Namost egy normalis hash fuggveny ezt mindet tudja
A topik olvasása közben ami a figyelmemet felkeltette egy megjegyzés volt, ami az md5-re vonatkozott, hogy törhető. Tehát kifejezetten ez érdekelt, az md5. Ha a nagyobb biztonság a cél, akkor úgyis több hash kombinációját alkalmazom, azt csak az összekapcsolási algoritmus visszafejtésével lehetne törni.
#############
Szerintem meg az lesz, hogy mindenki be lesz kábelezve kifejezetten nagy sebességű összeköttetéssel, te meg ledobod magad a kanapéra, bekapcsolod a tv-t, kiválasztod a menüből mit nézel, milyen minőségben kéred, megkérdi a tv hogy most megnézel 30 perc reklámot előtte, vagy fizetsz 100ft-ot. Döntésedtől függően élezheted a műsort az óriási képernyőn.
#############
[Szerkesztve] -
#85
nyaralasptt
csendes tag
mikk2000
#82
nyaralasptt
csendes tag
''További okoskodás helyett, szerinted, ha van mondjuk egy 2 megás install fájl, akkor h ány byte-ot kell benne módosítani minimum (vagy felbővíteni) ahhoz, hogy biztosan az eredeti fájl hash-át kapjuk?''
Kb 192 bit biztosan eleg / kb. 24 Byte/, de lehet, hogy kevesebb is, ha van alcsoport.
Redundans adatbol meg kb k***a sok van: kepek pixelei, klf. fontok, hangok stb., plussz egy csomo cucc ami nem kell konkretan a telepiteshez csak kesobb hasznalja a pgm.
Egyebkent amit mondassz az nem tunik hulyesegnek, de latszik, hogy meg nem foglalkoztal komolyan ilyesmivel, ugyanis a hossz fuggveny is egy hash fuggveny, vagyis egy valamifele lenyomat a filerol /raadasul egy iranyu, azaz a hosszbol nem lehet visszafejteni a fajlt/, de siman lehet ket fajlt talalni, aminek azonos a hossza, raadasul az erteke nem fugg a bitek konkret erteketol.
Namost egy normalis hash fuggveny ezt mindet tudja /meg meg egyeb dolgokat is pl. ha 1 bitet modositasz a fajlban a kimenet butjeinek atlag fele valtozik/, es eddig az MD5 es az SHA1 is eleg eroskent volt szamontartva, tehat a hossz fv.-nel valoszinuleg nemikepp erosebbek, ugyhogy ez a kiterjesztes engem nem gyozott meg.
#############
Lehet, hogy egy par ev mulva bevezetnek valamilyen atalanydijas ftp szolgaltatast, ahonnan havi fix osszegert azt szedsz le amit akarsz, aztan a szerzoket a letoltesek szama alapjan fogjak honoralni. Persze az is elkepzelheto, hogy nemsokara mar csak ugy nezhetsz filmet, ha ott all melletted egy rendor.
############
Valaki emlitette a faktorizacios cuccot /RSA/, ami rohadtul erdekelne /kiveve, ha q szamitason alapszik, mert az nem ujsag/, ezert egy linket megkoszonnek. -
A file-ba túrásnak nem kell feltétlenül elszállást eredményeznie. A default Windows-os installer csomagokban pl. alapértelmezésben benne van ugyanis az ''adminisztratív install'' felülete és esetleges custom kódja. Ha ezeket a területeket használja fel az ember, sok minden bepakolható az eredeti file-méret megtartásával, hogy közben az eredeti telepítő rutinjai is mind lefussanak.
-
mikk2000
őstag
Tuti hogy sokat kell még tanulnom
Viszont ha engem érdekel egy adott rész-terület, akkor nyilván csak azzal foglakozom, a többivel meg nem. Engem az md5 fájlok szempontjából ragadott meg.
Látom beláttad, hogy fájlhossz megváltozás nélkül ha belenyúl az installerbe a vírus abból elszállás lesz nagy valószínűséggel, viszont itt van akkor egy lényeges különbség, nevezetesen hogy a felhasználó észleli hogy valami nincs rendben.
Olyan meg nincs, hogy az MD5-be belevenni a fájl hosszát, mert az MD5 egy magasabb szintű, absztrakt dolog, egy algoritmus, aki nem tud olyan fogalmakról, hogy fájl
Ezzel egyáltalán nem értek egyet, ugyanis te azt mondod hogy a hajót is kerék hajtsa meg a vizen, csak azért, mert a kerék egy magas szintű dolog, nem szabad módosítani, ebből követezően a hajócsavar az egy tilos dolog Én azt gondolom, hogy emelt szintű védelmet adna, ha a fájlokhoz rendelt (!) md5 számítások szabványilag felbővítve tartalmaznák a védendő adat hosszát, pontosan azért, hogy sima felbővítéssel ne lehessen elérni ugyanazt a hash értéket.
Másfelől ez kissé halódó topic arról szól, hogy feltörtek egy viszonylag új filmtitkosítási eljárást (röviden és pontatlanul fogalmazva), azért említem, mert ''újat'' találtak ki, tehát ''új'' dolgokat szabad és kell is kitalálni.
Amúgy a manipuláció nem feltétlenül jár hossz változással is!!! Mindig vannak módosítható adatok is.
Életszerűségi szempontból továbbra is, egy fájlnak van hossza. És azért van neki egy bizonyos hossza, hogy azokat az információkat amiket tárolnia kell el tudja tárolni. Fölöslegesen senkinek sem érdeke egy fájlt fölös infókkal telenyomkodni, de ha felépítéséből adódóan mégicsak vannak benne ilyen részek, az csak a fájl kis hányadának megfelelő mennyiség, márpedig ebből a kevés byte-ból aligha lehet addig kavarni hogy az általad említett 10 az akárhanyadikon módosítást elérjük az azonos hash-hez. Marad tehát a felbővítés, amit viszont az én hosszrögzítéses javalatom kizárna.
További okoskodás helyett, szerinted, ha van mondjuk egy 2 megás install fájl, akkor hány byte-ot kell benne módosítani minimum (vagy felbővíteni) ahhoz, hogy biztosan az eredeti fájl hash-át kapjuk? -
tocsa
senior tag
Sokat kell még tanulnod. Nem jó szemüvegen keresztül nézed a dolgot, vedd fel a hacker szemüveget. Egy adathalmazban te módosítod a cél információt, majd ezek után mindig lesz majd olyan számodra nem lényeges információ, amivel továbbra is manipulálhatsz, úgy hogy pl ne törjed meg az alkalmazás futását (ne szálljon el azonnal). Az már elég ahhoz, hogy pl a te rootkited települjön, utána már elszállhat a telepítő.
Olyan meg nincs, hogy az MD5-be belevenni a fájl hosszát, mert az MD5 egy magasabb szintű, absztrakt dolog, egy algoritmus, aki nem tud olyan fogalmakról, hogy fájl. Te arra gondolsz, hogy a hash vagy MAC számítás során alkalmazott protokoll/algoritmus-ba kerüljön bele az adat hossz is? Ez már konkrét alkalmazást érint, és persze nem lenne rá szükség, hogyha az MD5 tökéletes lenne, amit a rendszer tervezésekor sokszor alapul vettek. Amúgy a manipuláció nem feltétlenül jár hossz változással is!!! Mindig vannak módosítható adatok is.
Elnézést kérek az elütési hibáimért (az összes korábbiért). Nincs időm átnézni.
[Szerkesztve] -
tocsa
senior tag
Ez jó kérdés. Nyilvánvalóan megpróbálják elérni, hogy virtualizáció esetén se tudjál belekukkantani a Vista Portected Environment részébe. Ehhez kaphatnak támogatást hardware oldalról is, pl Intel és AMD is természetesen a TCPA tagja.
A Ross Anderson TCPA FAQ-ban megfogalmazott triviális módzserük erre ugye az lenne, hogyha TCPA DRM nélküli módba boot-olod be a géped (azért annyira nem pofátlanok, hogy en is választhass), akkor csak nem TCPA/DRM-es alkalmazést futtathatsz. Ez azt is jelenti, hogy Windows-t sem, mert sz TCPA-s lesz. És ezt megpróbálják hardware oldalról megtámogatni, hogy a Linux nehogy kikerülhesse. A Linuxnak meg lehetőségük van megakadályozni, hogy ne lehessen TCPA-s: pl orbitálisan nagy opreációs rendszer certificate ár megszabásával. Ezt az MS zsebből kipengeti, a Linux miből?
Amúgy alapvetően azt mondom én is: különféle kerülőutakon mindig lesz megoldás a ''törésre''. Szándékosan idézőjelben a törés. Fölöslegesen feccölnek dollár trilliárdokat ezekbe a technológiákba a már említettt kapzsi egyének a kiadók élén. Előbb-utóbb be kell látniuk, hogy más megoldás után kell nézniük.
[Szerkesztve] -
mikk2000
őstag
Hm kösz a részletes választ, mondjuk nem igazán életszerű a dolog, tegyük fel van egy install fájlom 10 mega, hozzá egy md5 hash. Jön a víruska, átírja kicsit, de ahhoz hogy a hash eggyezzen nem írhat át létező adatot hiszen az installer fejreállna, max a végéhez tud hozzácsapni annyi és olyan byte-ot, hogy az md5 hash eggyezzen, azaz megváltozik a fájl hossza. Én mondjuk már régen agyalok azon hogy jó lenne az md5-öt kibővíteni úgy, hogy tartalamzza a fájl hosszát is. Addig is tökéletes megoldás a védendő fájlról kétféle elven működő hash generátorral hash-t készíteni...
-
tocsa
senior tag
Az MD5 és az SHA-1 hash függvényekben úgynevezett collision weakness-t találtak, md5-ben 2004-ben, SHA-1-ben 2005-ben. Ez tulajdonképpen annyit jelent, hogy ha adott egy információ és arról a lenyomata (hash-e), akkor el tudsz végezni az információn módosítást úgy, hogy végül a módosított információ hash-e is az eredeti hash legyen. Ugye ha nem lenne a gyengeség, akkor statisztikailag az ütközésnek esélye majdnem 0 lenne (SHA-1-nél 2^-160, md5/nél 2^-128). Viszont a gyengeségek pont a hash függvények egyik fontos tulajdonságát gyengítik.
Mivel az eredeti hírek már régen voltak, ezért rákerestem a google-ben ''md5 weakness-re'', ez pl egy FAQ mindkettőről egyszerre:
[link]
A FAQ persze arről szól, hogy enm dőlt össze a világ. És ez így is van. De pl az SHA-1-nél a 2^159 szükséges brute force számítást sikerült 2^69-re csökkenteni. Ami a 160 bit bithosszúság kevesebbb, mint a fele!!!! Még mindig nem ''feasible'' a támadás, de 2^69 azért az már baromira nem hangzik olyan jól, mint a 2^160.
Amúgy annak ellenére, hogy nem ''feasible'', tudományos és hacker konferenciákon már konkrétan prezentáltak olyan támadásokat, ahol a fennt említett infó módosítást végeztek úgy, hogy adott hash-t találtak hozzá. Ehhhe.
Semmi sem törhetetlen emberek. Az RSA sem pl. Prímfelbontásban (az RSA ugye ennek a nehézségén nyugszik) szintén kb 1-2 éve szinte megsemmisítőnek nevezhető eredmény született. Keress rá.
[Szerkesztve] -
Ez mondjuk kicsit nehezen fog menni.
Legális anyagról nem tudsz biztonsági másolatot csinálni, az elején mindig végig kell nézni a fenyegetőző üzenetet. A te pénzedért.
Illegális cuccról tudsz gyerek+kakaó elleni másolatot csinálni, és nem is fenyegetőznek, mert a ripper kihagyja azt a sávot. -
tocsa
senior tag
Mi lesz ekkor illetve ezután?
Bár említettéktek, hogy magát az AES-t nem tudják feltörni. Itt jelezném, hogy pár éve már akorábban miztonságosnak hitt md5 checksum gyengült meg, aztán az SHA-1. Az AES sem 100%, hogy betonerős.
Igazatok van, a hackerek nyilván nem ezirányba mennek. Mindig a megkerülés lesz az egyszerűbb megoldás. Az egész AACS rendszert emberek tervezték, ezáltal meglehet majd találni a gyenge pontjait, mert szinte biztosan vannak. De ugyanez igaz az a TPM/TCPA rendszerre is. Ugyanúgy a rendszer operncer támogatás oldali részét szintén humanoidok írják, ezáltal annak is lesznek gyenge pontjai. Sőt, a hardveres részeének: a cshipen futó firmware szoftverben is lesznek hibák. Ki lehet majd iktatni vagy kijátszani, és mégis rá lehet majd keresni a kikódolt kulcsokra, de azért nehezebben, mint most.
Mindig fel lehet törni a rendszert.
Az ellenállás a MPAA/RIAA részéről teljesen felesleges. Már most is látszik. Széllel szemben nem lehet. Csak baromi drágává teszik majd a rendszereket, amivel az átlag usernek ártanak. De ezért ne hibáztassuk a hackereket, nem ők tehetnek erről, nem ők az okai annak, ha a DRM technolóhgiák miatt, a PVP-UAB miatt drágább lesz egy gép (Gondoljunk bele, hogy pl a videó memória buszt AES titkosítani akarják majd valamikor a jövőben... mekkora telejsítmény kell ahhoz???? nem normálisak, de annyira foggal körömmel kapaszkodnak a kapzsik, hogy bele fogják előbb-utóbb 10 éven belül ezt is nyomni a gépekbe; hacsak nem bukik el mondjuk 5 év múlva az egész hóbelebanc, mert a userek megelégelik a kötöttségeket, bonyolultságot és körülményeskedést, és valami nyíltabb platform felé fordulnak). Hanem a kapzsi kiadók. -
dark100
aktív tag
En is olvastam meg regen a cikket es meggyozo. Egyszeruen tul sok szereplo van a rendszerben. A kiadok, hogy gazadasagosan tudjanak filemeket eladni, ra vannak szorulva, hogy tomegcikkek legyenek, ahol mindenki rendelkezik a lejatszoval (kulccsal) TV-vel, stb (mindegyik masik gyarto termeke). A hires-neves HDMI-nel pl valami 40 ismert HDMI kulcs segitsegevel barmely HDMI eszkoz feltorheto (cikket most nem tudok linkelni sajna). Ez azt is jelenti, hogy a jelenlegi HDTV-k nagyjabol ugyanazt a kulcsot hasznaljak, mert nem eri meg mar az elejen elszorni a 40 lehetoseget. Ha viszont most kizarjak ezt a kulcsot, akkor mindenki mehet uj HDTV-t venni. Nagy lesz a boldogsag
A titkositas egyszeruen csak ugy mukodik, ha keves szereplo vesz benne reszt. -
tocsa
senior tag
Szóval amire ki akarok jukadni. Mi lesz az általam leírtak után?
Képbe kerül a Trusted Computing-nak nevezett valami, a TPM/TCPA/NGSCB betűszavak által határolt rendszer. Ami nem megvédi a gépedet a különböző irányból fenyegető támadásoktól (rosszindulatú weboldalak, SPAM-ek, trójaiaik, vírusok, keyloggerek, rootkitek, ...), hanem egy célja lesz: a számítógépeden kialakítani egy olyan részt, amit ők irányítanak, csak ők érhetnek el. Ezáltal korlátozni azt, amit a gépeddel csinálhatsz. Ez a krolátozás kezdetben persze csak a most ''Permium Content''-ként emlegetett dolgokat fogja érinteni, ami jelenleg a HD-DVD és a Blue-Ray.
Talán 1-2 éven belül már a VIstá-ra is fel fog települni egy olyan kiegészítés, ami már valóban alkalmazni fogja a TPM-re épülő DRM technológiákat. Először csak a PVP-OPM lesz, majd PVP-UAB, ugyanez audio vonalon is, PAP. Ez nem kitaláció, kemény tények:
''Output Content Protection and Windows Vista WinHEC 2005 Version - April 27, 2005''
[link]
Amúgy erre figyelmeztet Peter Gutmann is (ja Bruce Schenier, Ross Anderson mellett szerintem még ő is kandidáns lehet arra, hogy az egdberg felhasználónév mögött álljon a doom9 fórumban):
''A Cost Analysis of Windows Vista Content Protection''
[link]
Én tudom, hogy a Peter Gutmann féle írás paranoidnak tűnhet, de higgyétek el nem annyira az, mint amennyire hinnénk. Erre bizonyíték a linkelt WinHEC anyag, ami magától a Microsoft-tól származik. A Microsoft progrmozók persze érzik, hogy ez elég durva dolog lesz minden szempontból, dehát ők azt csinálják, amit amanagement kitlál. Márpedig az MS managementre óriási nyomást heyleznek a kiadók (MPAA, RIAA), meg persze magának a Microsoftnak is érdekében állhat egy kalózkodást csökkentő technológia bevezetése, ezért enged a nyomásnak. Bár látják, hogy nagyon problémás, többek között ezért is nem lett benne a Vistá-ban, és szerintem a VIsta csúszásának egyik meg nem említett fő oka ezen technológiák bevezetésének a kudarca a túl korai probálkozás miatt. Hiszen pl látjuk hogy ez együttműködést igényel minden hardware gyártótól, stb. Amúgy a TCPA-nak mostmár szinte minden gyártó a tagja.
Visszatérva újra az eredeti gondolatmenetre. Mit fog jelenteni még konkrétabban a TPM alapú DRM technológia megjelenése? Le van írva. A számítógéped/oprendszered azon részét, ami irányít és hozzáférhetetlen, azt ún ''Protected Environment''-nek nevezik. El fogják intézni, hogy a kulcsok kikódolt állapotban csak ezen a területen létezzenek futás közben. Ezután már nem lehet majd csak úgy a memóriában keresgélve rábukkanni a kulcsokra, mint ahogy a WinDVD-nél tapasztalhatják. A Protected ENvironment hardveres alapon (TPM segítségével) az oprencer támogatásával meggátolja az ottani szimatolást. A PVP-OPM és UAB technológiák is a buszok szimatolása ellen is mennek, szintén TPM hardveres támogatással. Ugye láttuk, hogy bizonyos infókat az USB buszról szimatoltak le.
Ezzel lényegesen nehezebb lesz a hackerek dolga. Ezt 1-2 évre teszem, hogy megjelenhet.
(Felvetődhet a krédés, hogy mi van, ha Linux alatt játszod le, ott nem lesz Protected Environment. A válasz nyilvánvaló. A nyílt forráskódú közösséget nem tudják eléggé szabályozni, ezért egyetlen út a TCPA/NGSCB/TPM rendszer segítségével való kigolyózás marad. Ezt Ross Anderson le is festi a TCPA FAQ-ban. Persze ez előtt már jóval csapásokat mérnek a open source világra, ugyanis a HFS miatt a nyílt forráskódú meghajtók kerülnek veszélybe, pedig már nyersére állna a közösség mostani állapotban.)
Amúgy elnézést mindenkitől, utálok jósolgatni, de ez kikívánkozik belőle. -
dabadab
titán
válasz
t72killer
#67
üzenetére
''Az viszont jogi nehézségekbe ütközik, lévén sok országban jogszerű a biztonsági másolatok készítése''
Lattad mar az USA es az EU vonatkozo szabalyait?... Konkretan Mo-n mar par eve torveny tiltja, hogy a sajat, penzen megvett DVD-idrol masolatot keszitsel, ha azok masolasvedettek (= CSS van rajtuk (valaki (talan PPeter?) emlitette, hogy ezt mostanaban hajlamosak lesporolni, gondolom mindenki rajott, hogy felesleges penzkidobas)). -
Az viszont jogi nehézségekbe ütközik, lévén sok országban jogszerű a biztonsági másolatok készítése - lévén sehova sincs leírva, h a filmet a lemez élettartamáig béreltem. - másik megoldás, hha a lemez meghalt akkor az adathordozó jogdíjak és adók nélküli árán kell pótolniuk... (legalábbis civilizált helyen így működne a backup kiváltása)
Ld. szoftvereket sok gyártótól 1xerűen le lehet tölteni, amiért fizetsz az a kulcs - ami nem karcolódik, nem törik össze, stb. (pl winXP-t is lehet venni online asszem)
[Szerkesztve] -
-
-
tocsa
senior tag
Rive hozzászólására reagálva folytatnám. Tehát előző postomban láthattuk, hogy a DRM eleve feltörhető. Ott van a kulcs valahol a rendszerben.
Mit tudnak tenni a tisztelt kiadók (azon kívül, hogy esetleg alkalmazkodnának a piachoz)? Végletekig ellehetetlenítik az információk megkeresését. Végletekig elbonyolítják a rendszert. Persze a macska-egér játék így is megmarad. A mindig akadnak majd ügyes felhasználók.
(OFF, ez már jogi: Direkt nem írtam hackert. Mert ha valaki megvesz egy HD-DVD vagy Blue-Ray filmet, akkor jogosan várhatná el, hogy a tetemes összegért cserébe csinálhasson róla egy biztonsági másolatot (arra az esetre pl, ha a kisgyereke megkólázná vagy meglekvározna az eredetit), vagy pl Linuxon is le tudja azt játszani. Ha eléri ezt a rendszer elemzésével, akkor mindössze használja a lemezt, amiért már fizetett. Azt csinál vele, amit akar, az ővé az a darab lemez.)
Mik lesznek az első lépések? Megpróbálnak kulcsokat visszavonni, lejátszó szoftverektől és drive-októl. Mondjuk a Processing Key-nél ez nem megy. Viszont változtatják majd az MKB-t (Media Key Block), valóban véletlenné teszik a Title Key-eket. De ezután is lesz törés. Akkor a Blue-Ray-nél még kijátzsható ütőkártya az eddig nem használt DRM layer, minden bizonnyal ezt is be kell vetniük, de a userek előbb-utóbb erre is válaszolnak.
A doom9 fórumban az ''evdberg'' nevű user (aki szerintem egy nevesebb kriptográfus, talán Bruce Schneier vagy Ross J Anderson, de ez csak privát tippem) mondja is, hogy ''arnezami'' user túl hamar játszotta ki az ütőkártyát. Látszik, hogy evdberg előre gondolkozik legalább pár hónappal. Amúyg én azt mondom, hogy a törás elkerülhetetlen volt. Ez el volt rendeltetve. Ha nem arnezami, akkor más viszi véghez. -
-
tocsa
senior tag
A feltörhetetlenséggel kapcsolatban szólnék, WN31RD, róland és ngabor2 usereknek is.
Itt most általánosságban tehetünk kijelentéseket azzal kapcsolatban hogy feltorhetetlen kriptográfiai rendszer van vagy nincs.
Viszont vegyük észre, hogy mi most a kriptográfiai rendszerek egy részhalmazának egy képviselőjéről beszélünk. Konkrétabban: DRM technológiákról, illetve az AACS DRM technológia feltörhetőségéről.
Kedves barátaim. Matematikailag bizonyítható, hogy a DRM rendszer feltörhető.
Elnézést a cross-link-ért, de olvassa el mindenki Cory Doctorow DRM kritikáját magyar fordításban:
[link]
(Egyébként ezzel a beszéddel próbálta meggyőzni a Microsoftot is, amikor több ezres hallgatóságuk előtt próbált érvelni, a beszéd ezzel a megszólítással kezdődik: ''Üdvözöllek benneteket, kalóztársaim!'')) )
A lényeg az, hogy józan paraszti ésszel belátható, hoyg a DRM rendszerek nem működhetnek. Nézzük leegyszerűsítve a dolgot. Mik adottak, ha otthon le akarsz játszani egy DRM tartalmat?
1. Ott van a kezedben a megvásárolt jogvédett adat, ami valamilyen módon rejtjelezve van
2. Ott van a kezedben a lejátszó program, ami valamilyen módon vissza kell tudja fejteni a rejtjelezett információt, hogy lejátszhasd. Ennél fogva ott rejtőzik valahol a rendszerben a rejtjelező kulcs is.
_Minden_ ott van a kezedben, csak meg kell találni. A cikk ide vonatkozó része:
''No, alkalmazzuk ezt az egészet a DRM-re.
A DRM esetében a támadó egyben a fogadó is. Nem Annáról, Béláról és Csilláról beszélünk, csak Anna van és Béla. Anna elad Bélának DVD-t. Elad neki egy DVD-lejátszót is. A DVD-n van egy film, mondjuk a Karib-tenger kalózai, amit a CSS (Content Scrambling System) nevű algoritmussal kódoltak. A DVD lejátszóban van egy CSS visszakódoló is.
Vegyük leltárba, mi itt a titok? A titkosítás maga jól ismert. A titkosított ''szöveg'' (esetünkben ez maga film) teljesen bizonyosan az ''ellenség'' kezében van. Hát akkor? Amíg a támadó számára a kulcs titok, minden rendben.
De van itt egy kis gond. Anna szeretné, hogy Béla megvegye tőle a Karib-tenger kalózait. Béla azonban csak akkor veszi meg a filmet, ha vissza tudja kódolni a CSS-el kódolt VOB-ot (video object) a saját DVD-lejátszóján. Különben Béla a lemezt legfeljebb poháralátétnek tudja hasznosítani. Így aztán Anna el kell lássa Bélát -- a támadót -- a titkosítással, a titkosított szöveggel és a kulccsal.
Röhög az egész osztály.'' -
llax
senior tag
Szerintem ez is csak idő kérdése... A hackerek nagy többségének még a próbálkzás lehetősége sem adatott meg...
Lehet hogy nem fogja tudni mindenki otthon, saját pc-jén egyszerű szoftverekkel feltörni. Elég, ha egyvalaki egy videóval megteszi és a videót neten hozzáférhetővé teszi. Egy másik filmet meg feltör egy másik hacker, azt ő teszi hozzáférhetővé... -
Teljes sávszélességről beszéltem.
De ha már 4:2:0 stb., akkor talán nem árt megemlékezni arról, hogy a HD DVD/BlueRay lemezen már eleve veszteségesen tömörítve (csökkentett szín-sávszélességgel, ill. MPEG-elve) van a mozi, ehhez képest még a ''felezett'' SDI sem jelent veszteséget. -
Az SDI alapvetően egy tömörítetlen adatfolyam [link], ellentétben mondjuk a műholdra fellőtt MPEG streammel. Konkrétan milyen minőségvesztésre gondolsz, és mihez képest? Digitálisan állítom elő a jelet egy frame bufferben, amiből digitálisan, teljes sávszélességgel (270 Mbit/s) tolom át, amiből mondjuk ez [link] csinál DVI jelet.
-
#52
LeslieG Jr.
őstag
PPeter
#18
LeslieG Jr.
őstag
Hát igen kicsit sarkosan és pontatlanul fogalmaztam.
És teljesen igazad van mert ezt a védelmet még nem törték fel. És ha nem tudják feltörni amit ugye lehetetlen jelen esetben, akkor szépen megkerülik valamilyen módszerrel. No ez az amit a hacker éjt nappallá(ngabor2 köszi csak siettem mert munka volt és nem figyeltem a helyesírást ) téve ezt ki fogják játszani. Erre értettem azt hogy amíg ember az ember addig a védelmeket ki fogja játszani a hozzá mérten megfelelő módon. 
Bár szerintem ez nem jó irány, de hát így működik az ember.
[Szerkesztve] -
04ahgy
nagyúr
Ami meg erdekes lehet, az az, hogy ha az AACS LA ugy dont, hogy az PowerDVD-t meg az AnyDVD-t elkuldi a francba es ezzel kiiktatja a PC-s lejatszas (es kulcshalaszas) lehetoseget.
Már így sem valami életképes ez az agyonvédett technika. Mi lesz itt, ha már PC-n sem lehet majd lejátszani...
HGyu -
PPeter
addikt
Amit az utolsó bekezdésben írtál, arról szó volt korábban - hogy egy az egyben kihagyják a PC-s lejátszási lehetőséget -, aztán végül az AACS fejlesztők meggyőzték a kiadókat, hogy igenis megoldható a normális key kezelés a PC-s programokban. Erre most meg így sikerült megoldani
- a jövőben viszont biztos hogy másképp oldják meg a trükközést, a processzor regisztereiben eldugott, kevert kulcsokat nehezebb lesz elcsípni.
[Szerkesztve] -
dabadab
titán
Egyebkent egy kis kiegeszites a cikkhez:
Az elso hekkek (amiket Muslix64 csinalt) arrol szoltak, hogy az un. volume key-t szedtek ossze. Ez a konkret filmekhez tartozo kulcs, vagyis ha valaki le akarja masolni a Serenity c. filmet, akkor a Serenity volume keyet kell letoltenie az erre szakosodott website-rol.
A mostani tamadasnal az un. processing keyt szereztek be, ez az a kulcs, aminek a segitsegevel a fenit volume keyeket eloallitjak, vagyis itt mar nem kell minden lemezzel kulon tokolodni. A problema ezzel a hekkel az, hogy kell hozza a 96 bites volume ID is, azonban - legalabbis eddig - ezeket baromira amator modon csinaltak, siman ki lehet oket talalni (a film cime, kiadasi ideje, stb van benne ASCII-ben).
Az a lejatszokent egyedi kulcs (a player key) amirol a cikk ir, eddig meg nem kerult ki, szoval ezek visszavonasarol eddig meg nem volt szo.
Szoval teljesen vegleges tores meg nincs az AACS-re, de ugy tunik, hogy a SW lejatszokbol mindig ki lehet verni a megfelelo infot (es ha valamivel trukkosebb modon kezelik a kulcsokat, az se fog sokat segiteni, max akkor nem unatkozo napkozisek fogjak hekkelni ).
Ami meg erdekes lehet, az az, hogy ha az AACS LA ugy dont, hogy az PowerDVD-t meg az AnyDVD-t elkuldi a francba es ezzel kiiktatja a PC-s lejatszas (es kulcshalaszas) lehetoseget. -
Rive
veterán
Azért némileg másról van szó, bár ezt úgyis tudod
A monitor csak porlasztja az infót a levegőbe, a ketyere meg a vinyóra továbbít. Nekem sose azzal van bajom, hogy elég infót betoljak egy jelbe, hanem azzal, ha egy jelből elég gyorsan ki kell szedni mindent, ami benne van... -
04ahgy
nagyúr
Magyarul neked olyan technikai berendezés van a birtokodban, hogy az egyszer már lejátszott kódolt filmet nem kódoltan tudod utána tárolni... Utána meg a nem kódolttal azt csinálsz amit akarsz. Természetesen csakis a jog adta, legális keretek közt! Jól értelmezem?
Viszont, ha ez így van, akkor megint ugyanoda jutunk el: mi a fenének ez a foggal-körömmel történő másolásvédelem, ha elég egyetlen eredeti példány, és át lehet venni? Ha olyan árak lennének a gyári termékekre, hogy versenyképes a másolttal, akkor nem kéne ennyi technikai fejlesztés, marad pénz a gyártónál. Olcsóbb a lemez, ezért többen meg is veszik az eredeti filmet. Kisebb a különbség a másolt és az eredeti ára közt: kevéssé éri meg másolni, meg az eredetit is alapból többen veszik. Gyártó oldalról ésszerűbb lenne ezt a határt megkeresni, és átbillenteni a mérleget, nem?
Nekik végül is mindegy, hogy sok lemezt ad el olcsón, vagy keveset ad el drágán, és még a védelem kifejlesztésére is milliárdok mennek el...
Az összes bevétel megfelelő egyensúly beállítása esetén meg ugyanannyi...
HGyu -
dabadab
titán
A DVI-rol valo lementes ellen talaltak ki a DHCP-t, ami arra jo, hogy a DVI-n (ill HDMI-n, de az ebbol a szempontbol ugyanaz) meno adatokat titkositsa, igy a BD/HD DVD filmeket csak olyan gepeken lehet lejatszani, ahol a videokartya es a monitor/TV is tudja a DHCP-t.
(Az mondjuk mas kerdes, hogy amennyire utanaolvastam, a DHCP-t egy kicsit elrontottak es viszonylag konnyu feltorni, de nem hiszem, hogy barki is ezzel tokolodne.) -
Rive
veterán
A hardver.
Számolj egy pontfrekit, és keress hozzá egy megfelelő analizátort.
Aztán szorozd fel a bitek számával, és keress hozzá egy rendszert, ami folyamatos üzemben képes ezt a sávszélességt kezelni.
Aztán számolj egy szumma adatmennyiséget, és keress hozzá (megfelelő sebességű) tárolórendszert.
Lehet, hogy még a 200 milla is alsó becslés. Igazából nem ér annyit a dolog, hogy utánanézzek -
-
04ahgy
nagyúr
Egyszerűen röhej ez a foggal-körömmel történő másolásvédelem... Majd hamar arra a sorsra jut, mint az audio CD, de az legalább hosszú siker után. Ajánlom figyelmetekbe a következő 3 írást, egymás folytatásai, a téma elgondolkodtató. Jól illeszkedik a leírt anyag az új adathordozókra is...
[link]
[link]
[link]
Másik dolog: a másolásvédett film lemezre mentése. A PC-m lejátssza, ezt tegyük fel. Akkor én látok képet is. DVI monitor esetén ez a kép a DVI kimeneten nem más, mint egy pixelmátrix. Mennyiből tartana ezt lemezre venni, és ezt formálni tovább?
Ne kövezzetek meg, nem értek az AACS témához, csak egy felvetés volt. De számomra van benne logika...
HGyu -
WN31RD
addikt
Félreértetted a mondanivalómat. A civil tudományos világ szerint az AES jelenleg tetszőleges mennyiségű erőforrás (pénz, idő) rááldozásával sem feltörhető, kivéve brute force módszerekkel. Azt, hogy ''belátható időn belül'', csupán azért írtam, mert esetleg később egy tudományos áttörés változtathat a helyzeten.
-
gliskard
senior tag
azt sem kell elfelejteni, hogy elég sok film valószinüleg nem DVD vagy más kereskedelmi forgalomba került hordozóról kerül fel a netre, hanem stúdiókból vagy gyártási folyamtból szivárog ki, ilyen ''lehetöségeknél'' pedig feldughatják a másolásvédelmüket bármelyik testnyilásukba kedvük szerint...
-
ngabor2
nagyúr
csakhogy ha a lemezekhez és a lejátszókhoz is eula-t adnak, amiben le lesz írva, hogy előfordulhat, hogy a cucc csak azt nem tudja, amiért megvetted (azaz a lemezt lejátszani), akkor egy határozott vállrándítással fognak egy darabig reagálni a kiadók. ha viszont lesz olyan talpraesett a fogyasztóvédelem helyi szinten, akkor valóban földbe döngölik a kiadókat. meg is érdemelné néhány.
Bálint: nem igazán értek hozzá, így kénytelen vagyok hinni a nálam okosabbnak: ha a kulcs legalább olyan hosszú, mint a titkosítandó szöveg, akkor egy egyszerű xor is feltörhetetlen lesz... (amúgy boldog névnapot) -
gliskard
senior tag
...az óceán másik partján biztos néhányan a letiltott lejátszókból fognak profitálni, hiszen mi az, hogy én megveszek valamit és egy harmadik fél miatt nem használhatom rendeltetés szerün, vagy plusz költségem származik belöle. Biztos lesz olyan aki perre viszi a dolgot és ha egy nyer...
-
#20
ngabor2
nagyúr
LeslieG Jr.
#17
ngabor2
nagyúr
válasz
LeslieG Jr.
#17
üzenetére
valóban nincs feltörhetetlen kódolás, pontosabban van, csak értelme ''normál'' esetben nincs. itt nem úgy törték fel, hogy volt a titkosított adat, és visszafejtették, hanem a visszafejtő algoritmus vált ismertté, ezáltal már ''csak'' a kulcs kellett hozzá. ettől függetlenül a hackerek továbbra is éjt nappallá téve fogják keresni az univerzális utat a töréshez.
róland: kb. igen. ismerek olyanokat, akik csak azért vásárolnak 1-1 helyen, mert van oda pontgyűjtő kártyájuk, és ''olyan jópofa dolgokat lehet a pontokért ingyen kapni''. az nem érdekli őket, hogy pontgyűjtés nélkül talán olcsóbban kijött volna. de nem is feltétlen az ár számít, az ember már csak ilyen gyűjtögető életmódot folytat. -
#18
PPeter
addikt
LeslieG Jr.
#17
PPeter
addikt
válasz
LeslieG Jr.
#17
üzenetére
Tegyél bármilyen védelmet egy akár milyen dologra azt az EMBER úgyis feltörti.
Ugye tudod, hogy ez nem így van? Olvass már utána a kriptográfiának itt-ott. Itt sem törték meg a védelmet. Ha normálisan kezelnék (kezelték volna) a kulcsokat, évekig kellett volna várni hasonló sikerre az új generéációs védelmek feltörésével, kijátszásával kapcsolatban. -
#17
LeslieG Jr.
őstag
LeslieG Jr.
őstag
Hát nem is tudom mit szóljak ehez a mizériához ami itt folyik a Blu-Ray(Parker
) meg a HD-DVD körül. Nem csodálom hogy ha ilyen eljárásokat tesznek védelemnek a DVD-re vagy a Blu-Ray korongokra ez jócskán megnőveli az árát. Az megint más kérdés hogy mi a fenének kell ilyen védelem rá. Elárulom a titkot a nagyérdemű másolásvédelem kiötlőinek! Tegyél bármilyen védelmet egy akár milyen dologra azt az EMBER úgyis feltörti. Sajnos nem csak a kiváncsiság hajtja az embereket hanem a kihívás is. Lásd Hackerek akik éjt napalá téve dolgoznak az eljárás feltörésén! 
Ez a mezei júzernek nem mond semmit de ő már csak azért sem fog venni ilyen lemezeket mert sajnos nem biztos hogy az otthoni lejátszója le tudja-e majd játszani.
Ergó nincs olyan védelem amit fel ne törnének idővel. Elvégre azok is emberek akik a védelmet kitalálják és az közel sem tökéletes.
Lehet hogy demagóg voltam, de ez az igazság sajnos.
[Szerkesztve] -
WN31RD
addikt
Remélem, minél hamarabb és minél egyszerűbben használható módon feltörik ezt is, és remélem, hogy a kiadók irgalmatlanul nagy pénzeket buknak a másolásvédelem kifejlesztésén és megvalósításán, ennél sokkal rosszabbat is érdemelnének...
Én pl. másolásvédelemmel ellátott adathordozót elvi és gyakorlati okokból sem veszek (kivéve nagy ritkán egyszerű video DVD-t), hiába engedhetném meg magamnak esetleg anyagilag. Baromi kényelmetlen a másolásvédelemmel együtt élni, szörnyen kényelmetlen, hogy az ember nem másolhatja és rendszerezheti a saját eszközein a tartalmakat úgy, ahogyan csak szeretné, és rettentően kényelmetlen, hogy nem teheti ezt a saját jól bevált szoftvereivel. Úgyhogy inkább megelégszek a másolásvédelem nélkül elérhető dolgokkal. -
ngabor2
nagyúr
első hallásra lehet, hogy furcsán fog hangzani, de én örülök annak, hogy ennyire slendrián módon bánnak az aacs-szel. lehet akármilyen bonyolult egy zár, ha a kulcsot benne hagyják... remélem a kiadókból rájönnek páran, hogy nem az egyedüli üdvözítő mód a vásárlás ösztönzésére a feltörhetetlen másolásvédelem.
naív leszek: ne védjék másolásvédelemmel a filmet. ne tegyenek rá átléphetetlen reklámokat és figyelmeztetéseket. viszont tegyenek bele egy kupont, amivel mittudomén 3 kuponért cserébe egy filmet féláron vásárolhatsz meg, vagy egy moziláncnál ingyen kapsz egy nagy popcornt. a lényeg: ne technikailag akadályozzák a film másolását, hanem tegyék érdekeltté a filmkedvelő nézőket az eredeti lemez megvásárlásában. ekkor a lejátszók is olcsóbbak lehetnek (hisz nem kell beléjük mindenféle hw-s titkosítás), és összességében a film kiadója is jobban jár (ha a mozis és a lemezes eladást együtt vesszük). -
róland
veterán
Előre látom, hogy a fél világ tiltólistán lesz.
Bizonyára majd itt is megjelennek a különböző alkalmazások, amivel ideig-óráig ki lehet iktatni a védelmet. Ezeket persze az amatőr többség letölti, s valószínű, jó párszor anyázni fog a szükséges frissítések miatt.
Aki meg ebből él, annak nem lesz gond akár havonta venni egy-egy új eszközt, amivel gond nélkül folytatja a tevékenységet.
Meg persze egyre erőssebb lesz a fájlcserélők szerepe. -
PPeter
addikt
December óta van Blu-ray és január közepe óta HD DVD meghajtó (író) a gépemben. Világröhej, mennyire slendrián annak a két lejátszóprogramnak az AACS kezelése, amit eddig próbálgattam. Én nagyon régóta nem foglalkoztam alacsony szintű program visszafejtéssel, ha úgy tetszik: más programok feltörésével - leszámítva a firmware-eket - de a kulcsok tárolása, kezelése egy kevésbé gyakorlott embernek is úgy világít a memória dumpokon, mint magyar politikus szájában a negrócukor. Korábban rengeteget írtam arról, hogy milyen durva - túl durva - lett a HD DVD/Blu-ray védelme és hogy ezt nem fogják túl hamar megtörni. De úgy látszik nem is kell megtörni, a lejátszószoftverek felől nézve olyan sebezhetően implementálták, hogy az borzalom, annek idején - ha nem is ennyire, de nagyon hasonló módon - így könnyítette meg a Xing lejátszó hibás kulcskezelése a CSS gyors megkerülését.
-
Renwick
őstag
Ha tiltólistára került a lejátszód és nem frissítesz (PC-s progiknál egyszerű update, asztali cuccoknál és konzoloknál gondolom firmware-frissítés), akkor az újabb lemezeket nem fogod tudni lejátszani. Visszamenőleg ez értelemszerűen nem működik, tehát amit eddig is meg tudtál nézni, azt eztán is meg fogod tudni nézni.
üdv
R.
, de soha nem is allitottam, hogy konnyu, amire ra akartam vilagitani az a kovetkezo: Alap valoszinusegszamitasbol kovetkezik, hogy letezik ilyen 128 bit /sot tetszoleges 128 bit ilyen/. Namost a gyakorlati tores egyaltalan nem biztos, hogy igenyli, hogy ennel tobb nagysagrendel tobbet kene modositani, bar ez nyilvan csak talalgatas, mivel egy nemletezo tores bitmodositas igenyerol van szo.
, franc se akar meg most is matematikai tetelekkel szorakozni, gyakorlati jelentosege amugy sincs sok.
A titkositas egyszeruen csak ugy mukodik, ha keves szereplo vesz benne reszt.
Bár szerintem ez nem jó irány, de hát így működik az ember. 
- a jövőben viszont biztos hogy másképp oldják meg a trükközést, a processzor regisztereiben eldugott, kevert kulcsokat nehezebb lesz elcsípni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- sziku69: Fűzzük össze a szavakat :)
- Milyen videókártyát?
- Házimozi belépő szinten
- Azonnali fotós kérdések órája
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Milyen autót vegyek?
- Autós topik
- Anglia - élmények, tapasztalatok
- További aktív témák...
- Eladó egyben 17 db HDD
- Toshiba Enterprise Capacity MG09 18TB - 512MB, 7200rpm, SATA3 - 100/100 -as - Eladó!
- Lexar NM790 4TB M.2 NVME PCI-E 4.0 x4 - Új - 7400-6500 MBs - Eladó!
- SKhynix PC811 2TB NVMe SSD! 7000-6500MB/s
- Szuper ár! 480GB Ipari Minőségű, Sata SSD-k, kevés írt adattal! PC-be és Laptopba is kiváló!
- Eladó ANDROID TV box 4/64GB tárhely / 12 hónap jótállás
- BESZÁMÍTÁS! Asus B450 R7 2700X 16GB DDR4 512GB SSD RTX 2070 8GB Rampage SHIVA TT 500W
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RX 9060 XT 8GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Gigabyte G5 KC Gamer notebook - i5 10500H 16GB DDR4 512GB SSD RTX 3060 6GB WIN10
- Eladó karcmentes állapotban levő Xiaomi 14T 12/256GB / 12 hónap jótállás
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest