Keresés

Új hozzászólás Aktív témák

  • ddekany

    veterán

    válasz Bici #12 üzenetére

    "Ki ne használjon "olyan programozási nyelveket"?"

    A szoftverfejlesztők akik a biztonsági réseket tartalmazó cuccokat (Acrobat Reader, Flash player, stb) készítik. De talán majd talán pár évtized múlva végleg kinövünk a C/C++-ből és hasonló ős idők körülményeire optimalizált nyelvekből (kivéve néhány speciális területen persze). És amúgy nem kell "virtuális gépes" nyelv ahhoz, hogy az ilyesmi pointer manipulálós balesetek esélye a töredékrészére csökkenjen, ha még nem is 0-ra.

  • ddekany

    veterán

    válasz Bici #15 üzenetére

    Jó akkor innentől off, mert mint mondtam, nem tudom ez miféle hiba most... annyit mondtam, nehogy az legyen már megint, mert.

    "De ha a szoftverfejlesztők le is szoknak róla, attól még a rosszindulatú kódokat író fickók még használhatják másik szivatására."

    Már feltéve, hogy "bináris" (azaz gépikódot tartalmazó) formában adhatnak meg dolgokat gonoszék... de hát ilyet azért nem tehet hivatalosan (ill. minimum hogy alá kell lennie írva a "bináris" cuccnak, plusz rákérdez a böngésző, hogy bízol-e a készítőben). Pl. swf sem tartalmazhat ilyet, meg a WMF-sem, stb., aztán minddel lehetett vicceseket csinálni. És ahogy elnéztem, a komolyabb hatású exploitok (teljes hatalomátvétel, stb) jelentős része úgy működik, hogy olyan adatokkal etetnek meg egy jóindulatú programot, amitől az nagyon specifikus, a támadó által hasznos módon hibásan kezd el működni... pl. tömb indexeket a helyes tartományon kívül visz (és egyéb pointer elcseszések), ezzel átírva a memóriában dolgokat (funkció visszatérési címet, vagy akár csak helyi váltózókat, sőt, heap-ben is lehet így jókat gázolni), ami a program logikája szerint lehetetlen, de így alacsony szinten belepiszkálva a memóriába lehetséges. Puff. Teljesen "felesleges" hiba. Ha a C++ tömbökhöz letárolódna a méret, és kötelező lenne az index helyességének ez ellenőrzése, akkor hiába rontotta volna el a készítő a programot, az vmi IndexOutOfBounds hibával elszállna és kész, nem lehetne disznóságra rávenni. De hát a C++, mint "rendszer programozási nyelv" nem efféle, teli van pointer aritmetikával (tehát ott is ahol formálisan nincs is tömb).

    Ja, az meg már mindennek a teteje, mikor adatterületre rá lehet ugrani mint gépikódra... és ezt csak mostanság próbálják orvosolni az NX bittel. Ez is már milyen, ezt már a 286 idején lehetett tudni, hogy gáz, csak hát akkor még nem érdekelt ez senkit, mert ugyanmá'. Eh, a túl gyors fejlődést káoszt okoz. Majd kinőjük...

    "Egyébként érdekelne, hogy mit javasolnál helyette (programozási területen), amiben nem lehetséges hasonlóan ocsmány hiba."

    Nem tudok róla, hogy lenne ilyen nyelv ami nem "script nyelv", és nem is "virtuális gépes", és általános célú is... Hogy miért? Talán mert ezen a területen C/C++-vel szemben senki nem próbálkozni. (OK, de, Digital Mars a D-vel... és az ugyan csodás, de az sem "biztonságos", bár valamivel talán biztonságosabb.) Meg aztán, a virtuális gépes irányba nagy nyomulás van, ezért talán felesleges is lenne máshol próbálkozni, viszont annak még fejlődni kell sokat. De talán majd megélem, hogy driverek magjától meg efféléktől eltekintve minden C#-ban vagy hasonlóban lesz írva.

    [ Szerkesztve ]

  • ddekany

    veterán

    válasz Bici #17 üzenetére

    "A C# mitől jobb a c/c++-nál?"

    C# kb olyan mint a Java, csak valamivel fejlettebb.

    "Értem a mondanivalódat, de nem értem, hogy hogy gondolod a gyakorlatban."

    Szerintem nem érted. Arról van szó, hogy mikor flash-t "futtatsz" (ideértve a ActionScript interpretert), vagy amikor egy GIF-et jelenít meg valami (pl. a böngésző), vagy amikor PDF-et jelenít meg az Acrobat Reader, stb, stb. akkor ezt manapság a háttérben általában egy C/C++-ben vagy valami hasonlóban írt program végzi a Te gépeden. Ha ennek a programnak szándékosan hibás vagy épp csak furcsa ActionScript-et, GIF-t, PDF-et, stb-t kap, és a program nincs túl jól megírva, akkor "megzavarodik", és ezt a te gépedre való betörésre lehet kihasználni. Tehát az "összezavarható" program a te gépeden volt, és nem rosszindulatú emberek rakták oda, csak az őt összezavaró tartalmat készítették azok (holott elvileg sem Flash-al sem GIF-vel sem PDF-el nem lehet ilyet csinálni). Mármost, bármiféle nyelven írt tökéletlen programot ismeretlen utakra lehet terelni hibás adatokkal, szóval egyik sem támadhatatlan, de pl. a Java-ban, C#-ben, meg effélékben írt programok esetén ezzel ritkán tudsz elfoglalni egy gépet, mert nem férsz hozzá alacsony szinten a memória tartalmához. (Persze, a gond ott van, hogy pl. Java esetén vannak C/C++-ben megírt részek a platform megvalósításában, de kevés, és remélhetőleg egyre kevesebb lesz. De akkor is, itt emberi ész nélkül, teljesen automatikusan ki lehet zárni egy rakás biztonsági rést.)

    [ Szerkesztve ]

  • Gabesz84

    őstag

    válasz Bici #20 üzenetére

    de lassabb, de valamit valamiért.
    Amúgy meg nem annyival lassabb, bár az adobe termékei így is tetű lassúak, mi lenne ha nem natív nyelven írnák? :)

  • ddekany

    veterán

    válasz Bici #20 üzenetére

    "Én arra reagáltam, hogy azt írtad, hogy aláírással kellene ellátni a bináris cuccokat.
    Ezt nem tudom, hogy mi módon gondoltad a gyakorlatban."

    Ott azt akartam mondani, hogy ez jelenleg is így van, tehát "gonoszék" nem tudnak szabályosan "veszélyes nyelven" írt cuccokat használni weboldalon keresztül. Ha egy weboldal részét natív (gépikódú) cucc is képezi (pl. DLL), akkor ott rákérdez a böngésző, hogy ezt XY cég írta alá (digitális aláírás), megbízol-e benne. Általában... de minden esetre nem fogja automatikusan letölteni és futtatni.

    "Amúgy a virtuális gépen futó progik nem lassabbak, mint egy alacsonyabb szinten írt progi?"

    Fejlett virtuális gépet feltételezve nem feltétlenül számottevően lassabb (pl. manapság már "titokban" natív gépikóddá fordulnak ezek), de valahol több erőforrást kell ennie, pl. több RAM-ot. Viszont ahogy a hardver fejlődik, ez a "vízfej" az elviselhetetlentől az észrevehetetlen felé mozdul el. Persze még igencsak ráfér a fejlődés a virtuális gépes világra. Pl. bizonyosan jó lenne, ha OS szinten lenne támogatva a dolog, hiszen ez egy alapszolgáltatás kéne hogy legyen. Így pl. a virtuális gép és a hozzátartozó sztenderd könyvtárak már az OS indulásakor betöltésre kerülnének, szemétgyűjtés szociálisabb lehetne (hiszen OS kontrollálja), lehetne ilyen-olyan cache-ek csinálni osztályok betöltésének gyorsítására OS szinten, stb. Aztán ha már ennyire alap dolog lett ez, akkor talán megjelenne a hardver támogatás is... mint ahogy multimédiára rágyúrtak a CPU-k talán erre is rá lehet.

    [ Szerkesztve ]

  • FTeR

    addikt

    válasz Bici #12 üzenetére

    én nemtok olyat mondani, ami van flash 10ben, de nincs sl3-ban, viszont fordítva több is eszembe jut (nyelvek, codecesdi, seo, sketch, deepzoom, stb.). inkább csak az elterjedség jöhet szóba, de ebben elég jól halad sl, pedig alig van tartalom.

  • FTeR

    addikt

    válasz Bici #20 üzenetére

    nem lassabb. a java egyértelműen gyorsabb tud lenni, mint c++, a .net meg közel van olyan jó.

  • FTeR

    addikt

    válasz Bici #29 üzenetére

    - asszem ezt a Pixel Bendert sl-ban pixel shadernek hívják és természetesen GPU gyorsított.
    - miben fejlettebb a vektorgrafika?
    - sztem sl-ben semmi sem akadályoz meg abban, h animációval indíts hangot.
    - flashben valóban többet lehet csinálni timelinban, de sokan ezt inkább hibának tartják, ami arra ösztönöz, h rossz kódot írjál.
    - a forrsáfájlokat teljesen másként kezelik, szvsz az sl messze jobb, amibe belefér, h kicsit többet foglal. az viszont igaz, h ha nem vigyázunk hatalmas teleszemetelt XAML-t kaphatunk a végén blend-ben (azt nemtom új blend mennyit javított ezen).
    - szép is lenne, h nem a flash lenne átjárhatóbb adobe termékek között :D inkább pozitívumnak hoznám fel, h blend-be lehet importálni psd-t (berakni háttrének vagy aktív objektumot csinálni) és layerenként még szerkeszteni is és .ai-t is lekezeli.
    hamár itt tartunk, silverlightnak a saját cuccain kívűl ott a Visual Studió, mint sokkal fejlettebb IDE, mint ami flashnek valaha lesz (a flexet inkább mint negatív példát lehet felhozni). arról nem is beszélve, h .net fejlesztők minimális utánképzéssel már gyárhatják is a sl appokat.
    + sl pozitívum még, h sokkal jobban integrálódik a HTML DOM-ba és javascriptből is jobban manipulálható.
    + asszem a tintás írás felismerős móka sincs flashben.
    + ha minden igaz új sl-ben a tapira is van extra támogatás.
    + ami így hirtelen eszembe jutott, ami még nagy hiányosság sl-ben, az a mikrofon és a webkamera kezelésének hiánya. ez az egyetlen ami korlátozó hiányosság maradt. a többi ha van is, inkább részlet tudásban különbözik és összeségében az sl több fícsört tud felmutatni.

    nagyon kíváncsi lennék arra a deepzoom implementációra. nagy zseni lehet a munkatársad, ha összedobta.

    [ Szerkesztve ]

  • FTeR

    addikt

    válasz Bici #32 üzenetére

    ööö, már hogyne lenne gpu gyorsított a pixel shader. azt honnan veszed, h nem az?
    lehet hogy csak +2-3 kodek, mpeg4, aac meg még vmi. mind1 az api mindent visz ; )
    a dolog ott kezdődik, h deepzoomnak szerver oldala is van. kliens oldalon a hangsúly a képek rendezésén, mapelésén és azon van, h nem az egész képet méretezi, hanem eleve több méret van a képből, ezért tölt be két pillanat alatt egy több gigás képet is és zoomol gond nélkül még egy fél megás neten is.

    [ Szerkesztve ]

  • FTeR

    addikt

    válasz Bici #34 üzenetére

    eh, hát ez érdekes. kíváncsi lennék a végén miért lett ez.

    nincs erről a flashes cuccról vmi online demo?

    [ Szerkesztve ]

  • ddekany

    veterán

    válasz Bici #29 üzenetére

    Ez alapján a flash-al érdemes gyártani a csicsát (bannerek, stb), Sliverlight-al meg a komolyabb oldalba ágyazott alkalmazásokat. Az SL .Net támogatása miatt már látatlanban kétlem, hogy a flash technikailag labdába rúghatna mellette utóbbi téren...

  • FTeR

    addikt

    válasz Bici #36 üzenetére

    az első változatban nincs semmi dinamikus, csak van egy asztali app ami előkészíti a képeket és legyárt egy xml-t, ami tárolódik a szerveren.
    aztán vannak dinanikus cuccok is. a response-tól van oylan szerver oldali cucc ami báremiből legeneráljaa galériát. de azt is már jó ideje fejelsztik.
    az hogy mennyire pixeles a képe az a sávszéltől és a görgetés sebességétől függ. ugynaúgy mint a térképesdinél...

    Hátránya, hogy elő kell tölteni az összes képet.
    Persze, lehet finomítani, és csinálni minden képből több méretet.

    nah, látod ez egy hatalmas különbség. a deepzzom lényege az, h neked mint fejlesztőnek erőfeszítés nélkül megjelenit a neten egy több gigás képet is (demóztak egy akárhányezer dpi-s térkép scant). adott elemhez vagy zoomhoz szöveget, hangot, videót rendel, stb. több féleképpen rendezhető navigálható, stb.
    tod, ez az a 80:20. a munka 80%-hoz elég az az idő 20%-a és a maradék 20%-hoz az idő 80%. szal a munkatársad összedobott egy proof of concept-et, ami egy bizonyos határig hasonlít a deepzoomra és kész.

    //
    + az sl-nek van dinamikus (sávszélfüggő) video streamelése.

Új hozzászólás Aktív témák