- Apple iPhone 15 Pro Max - Attack on Titan
- Realme GT 2 Pro - papírforma
- Android alkalmazások - szoftver kibeszélő topik
- Poco X6 Pro - ötös alá
- Okosóra és okoskiegészítő topik
- Redmi Note 10S - egy a sok közül
- Magisk
- Megérkezett a Google Pixel 7 és 7 Pro
- Ennyibe kerülhet a Xiaomi Watch S4 európai változata
- Xiaomi Watch 2 Pro - oké, Google, itt vagyunk mi is
Új hozzászólás Aktív témák
-
#74
Laci_a_Paci
tag
Laci_a_Paci
tag
Hát az én gépemen is tuti van vagy 20 vírus, akkor lesz 21... huhu...
-
dabadab
titán
"Csak oda másztak, ahová a programíró engedte."
Persze, mert a C programok buffer overflowjai azok direkt szandekosak voltak.
"De ez ma is így van."
A modern nyelvekben hatarozottan jellemzo a runtime ellenorzes.
"És ha van a mai szoftverfejlesztő, futtató eszközökben ellenőrzés a határokra, akkor azok a pufferek mitől tudnak túlcsordulni ?"
Leginkabb attol, hogy C-ben (vagy C++-ban, de C stilusban) keszulnek.
-
mezis
félisten
szinte semmi ellenorzes nem volt a hatarokra, a pointerek, a tombok meg a bufferek oda masztak el, ahova akartak.
Csak oda másztak, ahová a programíró engedte. De ez ma is így van.
Az Algol68-ban volt indexhatár ellenőrzés. A Fortran IV-ben nem. Tudomásul vettük és a programban irtuk meg az indexhatár ellenőrzéseket. Ott, ahol szükség volt rá. Legalábbis igyekeztünk.És ha napjainkban van ellenőrzés a szoftverfejlesztő, futtató eszközökben a határokra, akkor azok a pufferek mitől tudnak túlcsordulni ?
Szabotázs ? -
mezis
félisten
Igen, valóban tapasztaltuk anno, hogy a billentyűzet (számítógép) elérhetetlensége gondolkodásra ösztönöz, míg az ellenkező eset inkább cselekvésre.
Vagyis ha sikerült végre számítógépre kerülni, akkor gyorsan igen hosszú programrészeket összecsapott az ember, aztán a várakozási időben töredékére csökkentette.
Ma bizony egy ember több számítógépet kezelhet egyszerre, mint ahány keze, feje (esze) meg csak egy van, keletkezik is időnként néhány eszement program
-
Rive
veterán
'Régen' a programozás illetve a futtatás időtartama nagyon másképp alakult és nagyon más viszonyban volt a termékciklussal, mint ma. Az embernek volt egy hete megirni egy fikarc programot, aminek a futtatásához legalább annyit sorba is állt a GÉPre várva, akkor megérte kicsit többet fektetni a kódba, mert a következő futtatás az megint egy hét, ugye. Ma meg egyszerűen compile, run, debug, majd lesz valahogy határidőig.
Az a régi stilus ma is megvan még, de már csak az igazán drága life-critical rendszerekkel kapcsolatban éri meg kifizetni az árát.
-
dabadab
titán
Hat, marpedig akkor tudnod kellene, hogy regi idok programozoi is sporoltak az ellenorzeseken, sot, csak ok sporoltak igazan (a gets() se mai talalmany), a regi programnyelvekben szinte semmi ellenorzes nem volt a hatarokra, a pointerek, a tombok meg a bufferek oda masztak el, ahova akartak.
Meg nyilvan azt is tudod, hogy a teszteles az a program komplexitasaval nem linearisan, hanem sokkal durvabban no, igy a mai, feature-okben gazdag programokat eleg nehez tenyleg alaposan letesztelni. Persze, pl. telekommunikacios eszkozok vagy vasuti biztositoberendezesek szoftverenel mas a helyzet, de ott persze mas a koltsegvetes is. -
-
mezis
félisten
Ma már nyugdíjas vagyok.
Az előző bő harminc évben alap és felhasználói szoftverfejlesztéssel foglalkoztam. (Odra 1013/Most1, Odra-1204/Algol 68,CDC-6500/FortranIV, PDP-8,11/assamler,Focal,Fortran,Midibol, Commodore-64/Basic, IBM PC(klón)/Fortran,Foxbase,Clipper)
A szofvereim (szoftvereink) természetesen nem voltak tökéletesek, lehetett volna még tovább fejleszteni, bizonyára maradtak ki jogos felhasználói igények, de akkor adtuk át a felhasználónak, amikor biztosak voltunk abban, hogy nem fog "fejreállni" a felhasználó által kitalált bármilyen adatoktól. Legfeljebb félbeszakítja a futást, a lehető legpontosabb hibaüzenettel (hol, milyen adat, számított érték miatt nem szabad folytatni a program futását.) -
Hiftu
senior tag
Egy program fejlesztése lehet hatékony vagy lehet tökéletes (közeli).
A hatékony fejlesztés azt követeli meg, hogy JÓ programot írjunk, de közel se tökéleteset.
Miért? Természetesen a költségek és határidők miatt. Ha végtelen sok időnk és pénzünk lenne, akkor lehetne tökéletes programot írni, de persze látszik, hogy szinte soha nem készülne el.Tehát nem kell nyavalyogni, hogy miért van itt rés, meg ott rés.
Ezek azért vannak, mert valamire nem gondoltak a fejlesztők, akik ugyanúgy emberek, mint bárki más.
Megfelelő eljárásokkal próbálják minimalizálni a hibák számát, de persze, ha ennek is tökéletesnek kellene lennie, akkor visszaérünk a korábban leírtakhoz.
Ennyi. -
mezis
félisten
Az ellenőrzések sokat tudnak lassítani a program futásán, ezért volt szokás elhagyni őket.
Egy ellenőrzés inkább a program megírását lassítja jelentősen, de a futását csak akkor, ha az a program mindössze két utasításból áll. Ugyanis egy feltételvizsgálat, többnyire az egész számok körében egy, esetleg néhány ciklusidő alatt megtörténik.De egyébként nem is megtellés volt sokszor a hiba, hanem a túl kicsinek lefoglalt bufferbe pl. egy másik rutin (ami mondjuk eleve csak a pointert kapta meg, a méretet nem) túl nagy adatot akar tenni.
Hogy lehet egy programot késznek tekinteni úgy, hogy a programozónak fogalma sincs arról, hogy bizonyos esetekben milyen utasításokra fog rászaladni ? (Hiszen lehet az, hogy del c:*.*, ....). Ezt más esetekben gondatlanságnak (szellemileg gyenge) vagy szélhámosságnak (tudta, hogy mit csinál) nevezik.Érdekes módon amikor a processzorok sebességét MHz-ben mérték, a memóriát pedig KByte-okban (és aranyáron), akkor még a szoftverfejlesztők nem hagyták el a szükséges feltételvizsgálatot. Igaz, akkor valaki úgy jellemezte pl. a PDP-8 op.rendszeríróit, hogy bitművészek voltak. A PDP-11-re, ahol már MByte-ban mérték a memóriát, már azt mondták a szoftveresekre, hogy csak egyszerű iparosok.
Nevetséges számomra, amikor egy képmegjenítő programnál nem futotta még néhány elengedhetetlenül szükséges feltételvizsgálatra, és akár vírust is lehet ezáltal a képet megtekinteni óhajtó számítógépére juttatni.
Van egy olyan hipotézisem, hogy ezek egy jelentős része szándékosan beépített (CIA, USArmy,...), aztán ha valahogy kiderült, akkor foltozunk....
Nem lehet ennyi trehány, hülye,... szoftverfejlesztő. -
Rive
veterán
Au contraire! Minden modern virusirtoban van heurisztika, ami a program kodjat elemzi (tulkeppen egy virtualis gepben futtatja a programot egy kicsit, hogy megnezze, mit csinal). Ezt plusz egy mag erdemben nem befolyasolja, az viszont sokkal inkabb, ha egy teljesen uj utasitaskeszletu vegrehajtoegyseg kerul a kepbe.
Nem gondolom, hogy ez igazi gond. Az OS, ami a CPU-n fut vagy tud jó homokozót csinálni, vagy nem tud. Ha tud, akkor a legnagyobb gond ami a GPGPU környékén előfordulhat, hogy a kártékony kód nagyobb számitási kapacitást tud bevonni. Ha nincs homokozó, akkor lásd fenn: székház leromol, helye sóval behint.Pillanatnyilag az egész koncepció arról szól, hogy egyes komplex, erőforrásigényes feladatokat exportálni a GPU-ba. Nem arról, hogy a GPU majd bármiféle tevékeny részt vállal mondjuk az OS futtatásában, vagy akár csak potenciálisan is teljes hozzáférést kap az erőforrásokhoz.
-
#52
hejesírásó
senior tag
hejesírásó
senior tag
ez lesz ma a fő hír a 8 órási hiradóban a story tv-n
-
Seregély
tag
Hihi. Diplomamunkám címe ez volt:
"Kártékony kódok futtatása illetve védekezés - heterogén utasításkészletű processzorokat tartalmazó számítógépes rendszereken".
A konklúzióm az volt, hogy egy megfelelően preparált kódot, gyakorlatilag lehetetlen visszafejteni emberi idő alatt, így a víruskeresők harca kilátástalan lenne. Nem gondoltam, hogy ilyen rövid idő múlva téma lesz ez. -
sghc_toma
senior tag
-
dabadab
titán
"Másrészt a GPGPU semmivel se jelent nagyobb kockázatot, mint egy extra mag. Sőt, sokkal kevesebbet."
Au contraire! Minden modern virusirtoban van heurisztika, ami a program kodjat elemzi (tulkeppen egy virtualis gepben futtatja a programot egy kicsit, hogy megnezze, mit csinal). Ezt plusz egy mag erdemben nem befolyasolja, az viszont sokkal inkabb, ha egy teljesen uj utasitaskeszletu vegrehajtoegyseg kerul a kepbe.
szente: a GPU-k bizonyos feladatokban nagyon gyorsak, tipikusan olyanokban, amikor egy csomo adaton ugyanolyan muveleteket kell vegrehajtani. Az u.n. altalanos felhasznalasnal (minden adattal mas szamitast kell vegezni, elagazasok vannak a kodban, stb) viszont sehol sincs egy hagyomanyos CPU-hoz kepest.
-
sghc_toma
senior tag
D4rkAv3ng3r (#33):
khm: [link]
dezz] (#36):
az altalam ismert megoldasoknal (OpenCL, CUDA, shaderek) a videokartyan puffereket hozol letre, amiknek a tartalmat tudja modositani a GPU.. ha a CPU-n akarod feldolgozni a GPU-n megtermelt adatot, neked kell lemasolnod a fo memoriaba a VGA RAM-ban levo pufferbol.. esetleg olyat tudok elkepzelni, hogy egy device->host masolas kozben a masolo fv. rossz parameterezese miatt becsuszik egy overflow, es ezt valahogy ki lehet hasznalni, de ebben az esetben ugye maris nem GPU-n futo kartevorol beszelunk..
meg egyebkent is, a GPU-t a host "iranyitja", tehat egy, a host programban levo kihasznalhato hiba nelkul hozza se fersz a GPU-hoz, tehat uj veszelyforrast nem jelent.. a mar emlitett code obfuscation*-on kivul nem latok mas realis lehetoseget a GPU kartekony celra valo felhasznalasara.. nem allitom, hogy nincs, csak en jelenleg igy latom a dolgot..*ezt meg ugye fel lehet hasznalni kevesbe gonosz celra is: masolasvedelmek.. probalkozom ilyesmivel, konkretan egy GPU-n megvalositott x86 emulatort szeretnek, amivel egy program bizonyos reszei atkerulnenek a GPU-ra, ezzel nehezitve a visszafejtest..
-
szente
addikt
lenne egy fél off kérdésem:ha ilyen "brutális teljesítményűek" a gpgpu-uk és nekem tök az jön le a cikkekből,hogy "brutálisabbak a cpu-knál,akkor miért nem azt használnak cpu-k helyett?vagy rosszul szűröm le az erejüket a cikkek alapján?nem igazán vágom az ilyen témát,csak fel ötlött bennem a kérdés,szóval nem szekálást szeretnék kapni,hanem okítást!
-
Rive
veterán
Rive: Az OS hogy ellenőrzi, mi fut a GPU-n pl. CUDA alatt?
Hogy nem jelent nagyobb kockázatot egy teljesen ellenőrízetlenül hagyott végrehajtás?
Tudtommal az allokált erőforrásokat ellenőrzi - ez elég, a PCI-e kommunikációt meghatározó határokat a procc felől állítják.De ha mégsem akkor átkozott hülyék tervezték, akiknek a székházát földig kell rombolni és a helyét sóval behinteni.
-
dezz
nagyúr
válasz
sghc_toma
#21
üzenetére
1. A GPU hozzáfér a main ramhoz. És nem tudom, milyen kontroll alatt áll.
2. Ha jól tudom, korábban egyszerre egy alkalmazás birtokolhatta a GPU-t, majd amikor átadta másnak, azon már nem futott tovább semmi. Ha jól vettem ki, CUDA alatt több alkalmazás is futtathat kódokat, megosztva az erőforrásokat. (De mintha a DX11 is erre törekedne.) Ráadásul ezek jóval önállóbbak lehetnek, mint az eddigi shader-kódok.(#27) mezis: Az ellenőrzések sokat tudnak lassítani a program futásán, ezért volt szokás elhagyni őket. De egyébként nem is megtellés volt sokszor a hiba, hanem a túl kicsinek lefoglalt bufferbe pl. egy másik rutin (ami mondjuk eleve csak a pointert kapta meg, a méretet nem) túl nagy adatot akar tenni.
(#30) Rive: Az OS hogy ellenőrzi, mi fut a GPU-n pl. CUDA alatt?
Hogy nem jelent nagyobb kockázatot egy teljesen ellenőrízetlenül hagyott végrehajtás? -
#35
Picturemaker
őstag
mezis
#27
Picturemaker
őstag
Egy ideig programozgattam én is. Egyet megtanultam: igazi programozó csak lusta emberből lesz!
(ezzel senkit nem akarok megsérteni)
Ha tökéletesre akar csinálni valaki egy programot, akkor soha nem lesz készen. Üzleti életben: a másik "lekaszálja" a piacot.
Ezzel nem azt mondom, hogy így ez jó, de ez van. A rossz programok javítására (hibákat kihasználó vírusok, stb.) külön iparág jött létre. Kvázi most már nincs is érdeke senkinek sem "túl jó" programot írni. -
#33
D4rkAv3ng3r
senior tag
D4rkAv3ng3r
senior tag
Nos a hacker-ek már használnak GPU-t úgyhogy már megvalósult. Láttam már nem egy password recovery programot amelyik GPU-t is használja így jóval kevesebb idő alatt fel lehet törni jelszavakat. (Sőt mondhatjuk úgy is hogy olyan jelszavakat vagy titkosításokat is ami nem érte volna meg meg olyan lassan törte volna fel.)
-
oPalRx7
aktív tag
hát igen. egy bure force kódtörő programmal ami gpu-n fut elég sokmidnent lehet csinálni.
pl irtak már ati stream-re wpa2 feltörő progit. egész gyorsan végez a dologgal most ez helyeett virusként valamit megirni, ugyanmár. pár napig ne mveszed észre, és a titkositottnak hitt hdd-ről is kikerülhetnek egy mási virus/trójai közrejátszásával az adatokpersze nem átlag user a célpont itt se.
-
#27
mezis
félisten
Picturemaker
#22
mezis
félisten
válasz
Picturemaker
#22
üzenetére
Sokkal könnyebb lenne az életünk, ha megfelelő gondossággal írnák a szoftvereiket a tisztelt programozók. Számomra nevetséges, amikor egy vírus olyat tud kihasználni, hogy túlcsordul egy puffer. A pufferek már csak ilyenek. Vajon miért nincs ellenőrzés a pufferbe töltéskor, hogy van-e még hely ?
Vagy a másik, amikor egy nem szabványos címmel tud manipulálni egy vírus. Programozócska megírta a programját, aztán elment imádkozni, csak nehogy olyan inputot kapjon a programja amitől fejre áll ?
(Sokszor a program készítésekor a legtöbb időt az igényli, hogy az input adatok bármilyen halmazára megfelelő feldolgozást végezzen, ami természetesen sok esetben olyan output-ot eredményez, hogy hibás adat - kiegészítve azzal, hogy hol, melyik adat nem fogadható el.)
-
#25
darkarthur
senior tag
darkarthur
senior tag
Lehet nem kéne tuningolni azt a processzort?
Így a vírusok is gyorsabban szaporodnak -
#22
Picturemaker
őstag
Picturemaker
őstag
Igazából ez nem hülyeség.
Csak annyi, hogy az antivir szoftvernek a VGA-t (annak műveleteit, adatait) is komolyan figyelnie kell. -
sghc_toma
senior tag
tenyleg fel lehet hasznalni a GPU-t rossz celokra is, de olyan formaban, ahogy itt le van irva, elegge elkepzelhetetlennek tunik a dolog..
a valos veszelyt szerintem inkabb a GPU-ra megirt packerek, protectorok jelenthetik.. egy ilyennel becsomagolt kartevo visszafejtese joval nehezebb lehet, hiszen az elemzo dobhatja a kukaba a jol megszokot eszkozeit, nagy valoszinuleggel meg kell tanulnia egy tok ismeretlen assembly-t, raadasul a GPU-n ugye futhat egyszerre egy rakas szal, szoval jol ossze lehet kuszalni egy programot..
-
#17
dabadab
titán
juliabrilke
#15
dabadab
titán
válasz
juliabrilke
#15
üzenetére
Nem, hanem ugy, hogy adott egy uj tamadasi felulet. Husz evvel ezelott az e-mailben terjedo virus aprilis elsejei trefa volt.
-
#15
juliabrilke
veterán
juliabrilke
veterán
Ezt hogyan gondolták? A háttérbe fut majd egy szőrös kocka, ami leterheli a gépet?
-
Szerintem pedig az Intel processzorok a legveszélyesebbek, mert azokon fut a legtöbb vírus...
-
Most mit figyelmeztetget itt az Intel ilyen dolgokra? Addig amíg nem fedeznek fel egy kártevőt, addig úgysem tudnak ellene védekezni.
Én meg figyelmeztetek mindenkit, hogy a NAP felépítéséből adódóan egyszer csak vörös óriássá alakul és a Földön elpusztul minden élet. Jó lesz ha vigyáztok ám.twollah: én aktívan használom a MediaCoder-t, és bár eltekintve a ténytől, hogy minél újabb verziót használok, annál több benne a bug, nagyon jó kis program. Nekem csak a részletes beállításának módjával meg CUDA-val vannak gondjaim, nevezetesen, hogy mindkettő valamihez kötött. Se Firefoxom, se nV kártyám, és nem is vágyom rájuk.
-
twollah
nagyúr
Itt egy pici teszt, hogy mennyit szamit ha a GPU-t is bevonjuk a videokodolasba.
-
tzsolesz
nagyúr
Nah ez egyre jobb. Vírus a gpu-n fog futni. az lesz csak a nagy szám, 3D-és vírusok fognak megjelenni tervezés, vagy kódolás közben.
előre látom magam előtt a T vírust a Resident Evil-ből. A számítógépünkön fellelhető összes játékban szereplő karaktert zombivá fogja változtatni, vagy egy átkódolt filmben mindenki vérengző fertőzött vadállat lesz.
Abu85: Az AMD-nek nem lesz GPGPU-ja?
-
dchard
veterán
Beszartak.
Egyszerűen erről van szó.
Mert az intel processzorok ugye nem futtatnak le akármilyen kódot, mi? Hát komolyan mondom ezt a bullshit dumát... Valószínű, hogy GPU-ra fognak vírust írni, miközben a központi egységek minden további nélkül lefuttatják az ártalmas kódot... Kezük járna a szájuk helyett. Ha csendben maradtak volna, bölcsek maradtak volna.
Dchard
-
Psych0
őstag
ennyi erővel a processzor a legnagyobb veszélyforrás.
nem tudom mit görcsölnek a veszélyekkel, csak meg kell nyitni a fájlokat egy editorban és rá kell keresni a VIRUS kifejezésre , mint ahogy a cikkben levő képen is látszik.
sőt ki lehet cserélni MONEY-ra és máris nem kártékony a kód... 
-
#06658560
törölt tag
Egyrészt azért szerintem a kártékony kódok valahogy máshonnan jönnek majd be a gépre, nem ott születnek, vagyis továbbra is a levelező kliensek, im-kliensek, nethez hozzáférő dolgok lesznek a kockázati tnyezők, amiket frissíteni kell, másrészt ezzel sikerült semmi újat nem mondani. Esetleg lesz valami, hogy krízisben a lövedék visszafele repül ha vírus kerül a GPU-ra, vagy mi?
Szabotázs ?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Xiaomi Redmi Note 13 256GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9700X 32/64GB RTX 5070 12GB GAMER PC termékbeszámítással
- 130+131+132+133 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4080
- Telefon felvásárlás! Samsung Galaxy A15, Samsung Galaxy A25, Samsung Galaxy A35, Samsung Galaxy A55
- BESZÁMÍTÁS! MSI B450M R5 5500 32GB DDR4 512GB SSD RTX 3060 12GB Rampage SHIVA Chieftec 600W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest