- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Speciális Gaudi 3-akat kap Kína
- ThinkPad (NEM IdeaPad)
- Amazon Kindle
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Szünetmentes tápegységek (UPS)
- TCL LCD és LED TV-k
- Milyen asztali médialejátszót?
- Vezeték nélküli fülhallgatók
- A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
Hirdetés
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Egyre több európai használja a Telegramot, ezért megkereste az EU
it Hamarosan sokkal szigorúbb szabályozás alá esik az EU-ban a Telegram, mivel egyre több a helyi felhasználója.
-
Mozgásban a Conscript
gp A túlélőhorror PC-re és konzolokra érkezik, a steames új demó jövő hónap elején lesz kipróbálható.
Aktív témák
-
Agyzuzo
addikt
Kíváncsi vagyok hogy fog beválni a gyakorlatban és mit lépnek erre a ''tisztelt'' vírusírók.
Listen up, maggots. You are not special. You are not a beautiful or unique snowflake. You're the same decaying organic matter as everything else. ::: http://meatytears.hu :::
-
Turmoil
senior tag
A gyakorlatban úgy kellene használni, hogy a proci egy kivételt generál, ha ilyen történne, és ennek felhasználásával a feljlesztők kijavítanák a hibás szoftverüket.
Mert ha fordítva történik (''a processzor úgyis megvéd''), akkor az további minőségromlást eredményez a szoftvereknél, ami senkinek nem jó.
Szóval remélem nem a hamis biztonságérzet lesz a végeredmény...Aki tud, és tudja hogy tud, az veszélyes. Tőle féljetek. Aki tud, és nem tudja hogy tud, az bölcs. Tőle tanuljatok. Aki nem tud, és tudja hogy nem tud, az okos. Őt tanítsátok. Aki nem tud, és nem tudja hogy nem tud, az hülye. Őt hagyjátok ..
-
L3zl13
nagyúr
Ha túlcsordul a buffer, akkor az aktuális program szerintem mindeképp behal. Tehát ezek után is ki kell majd javítani.
Csak nem tudják majd feltörni ennek szándékos előidézésével a gépeket.
Szóval nem is annyira vírusok, mintsem hackerek ellen véd a dolog.Aki hülye, haljon meg!
-
WN31RD
addikt
Linuxban pl. a GRSecurity patch szoftveresen megcsinálja ugyanezt (ha jól értem a hírt), persze (legalábbis az x86 architektúrán) némi teljesítménycsökkenés árán.
Csakhogy: sok fontos program (pl. XFree 4, JRE, wine) nem működik ezzel, mert szüksége van arra, hogy a heapre vagy a stackbe rakott kódot végrehajtsa.
Kíváncsi vagyok, a 64 bites Windowsban hogy oldják ezt meg... az új 64 bites programokat már írhatják erre felkészítve, és akkor azokkal nem lesz gond, de a régi 32 bitesek problémásak lesznek.''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
dabadab
titán
[ Azert ezt virusvedelemnek hivni kevesse pontos dolog, konkretan egy virusrol sem tudok, ami buffer overflowt hasznalt volna, max wormok lehettek ilyenek ]
''az elmúlt két év során kiadott javítások közel fele szükségtelenné vált volna, ha a technológia korábban is létezett volna''
Dehogy lett volna folosleges, egy buffer overflow - az exploitokat leszamitva - jobb esetben genproterrort okoz, rosszabb esetben viszont nem, csak csendben elrontja az adatokat, vagyis egy buffer overflowt mindenkeppen ki kell javitani. A korrekt megoldas nyilvanvaloan az lenne, ha olyan fejlesztoeszkozoket hasznalnanak, ami eleve kizarja a buffer overflow lehetoseget, mert checkeli a hatarokat (vagyis alap valtozatban sprintf() helyett snprintf(), de sokkal inkabb C helyett vmi modernebb nyelv).DRM is theft
-
shtml
őstag
Nem igazán a témához tartozik, de az írás szerzőjének, Erasmusnak szól a kérdésem:
Miért nem adod meg a forrás pontos URJ-jét? Más PH-s szerzők ezt megteszik és ez igen hasznos, ha valaki ellenőrizni akarja a forrást (ami rendszerint bővebb) vagy a forrás weblapon további információkat szeretne keresni a témához.
Kiegészítés:
Jelen esetben pl. szívesen utánanéznék az eredeti cikknek, mert elég gáz lenne, ha ott is kevernék a vírust és a buffer overflow-s exploitokat. Te biztos rendelkezel a cikk URL-jével, akár meg is adhattad volna, más szerzőkhöz hasonlóan. De így semmi kedvem ahhoz, hogy elkezdjek keresgélni a Cneten.
[Szerkesztve]A szakember olyan barbár, akinek tudatlansága nem terjed ki mindenre. (Stanislaw Lem: Az Úr hangja)
-
Hory
aktív tag
Auuuuuu, ez a cikk is fajt.
Már marha régóta lehetőség van a stack-ről leszedni az execute flaget, linuxban meg is csinálták. A marha rég kb. a 386-ot jelenti...
Nem csoda, hogy hirtelen mindenki támogatja. :)
Amúgy szerintem is teljesen másról szólt a cikk, csak elbaltáztátok a fordítását, mert ez így ahogy van, egy nagy hablatty, nem több. -
klumbik
tag
szerintem ez a tcpa implementáció egy része (lesz)
''This is horseshit. Horseshit, horseshit, horseshit. And for those of you who don't know what that means, it's the shit that comes from a horse!'' -- Greg, Columbia Internet
-
Darth Vader
csendes tag
Tudjatok ezzel csak az a baj, hogy az Intel es AMD processzorok jelenleg is tamogatjak ezt.
Csak ugy hivjak, hogy Szegmentalas. A nagy Linux kernel is hasznalna, akkor nem lennenek ilyen gondok. A kerdes persze az, hogy miert nincs szegmentalas a Linuxban?
Most ugy nez ki, hogy minden szegmenst 0-4G-ig megy. Tudjatok, mar az egyszeru i386-osban is benne volt. Van kulon adat, stack es code szegmens is. Az Adat (Data) segment vagy csak olvashato v. irhato is, a stack szegmens is ilyen, de az lefele bovulo, a code szegmens meg csak futtathato, vagy futtathato es olvashato. Ez egy tokeles vedelem. Igy nem is ertem a cikket, meg ezt az egesz buveszkedest.
Az mondjuk igaz, hogy ha csak lapozast hasznalunk, akkor ott nem lehet a futtatasi flaget leszedni, mert ilyen flag jelenleg nincs. -
WN31RD
addikt
''szerintem ez a tcpa implementáció egy része (lesz)''
A cikkben (elolvastam az eredetit is) semmi nem utal erre.
Meg tudnád indokolni, miért gondolod ezt?''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
WN31RD
addikt
válasz Darth Vader #10 üzenetére
Elsőre nem is jutott ez eszembe:
A szegmentálásos védelemmel az a gond, hogy az amúgy sem túl nagy (legalábbis manapság már nem) 4 GB-os logikai címteret tovább csökkenti. De egy 64 bites proci esetében ez már nem lesz gond, nyugodtan lehet külön pakolni az adat/kód/stb. szegmenseket.
Viszont akkor mi értelme van ennek az új feature-nek?
Ha csak annyit tud, hogy a lapozási mechanizmusba berak egy execute-only flaget, akkor az egyetlen haszna ennek az lehet, hogy a 32 bites alkalmazásoknál is legyen védelem, ahol a kód és az adat címtér nem választható szét (ha szükség van a 4 GB-ra). Viszont ezeknek a régi progiknak a nagy része nem úgy íródott, hogy erre fel legyen készítve, és így is fusson. Ha meg módosítják őket, akkor ilyen erővel fordíthatják már 64 bitesre is.
Érti valaki, hogy miről van itt szó igazából? :F''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
Darth Vader
csendes tag
Ez most nem ertem. Miert csokkenti a 4GB-os teruletet?
Egy szegmens merete tetszoleges lehet. Siman lehet minden programnak kulon adat es code es stack szegmense is. A szegmensek ugyan ugy darabolhatjak a memoriat, mint ahogy a lapozas darabolja. Ugy kellene a memoriamanaggert megirni, hogy a lapozast es a szegmentalast egyszerre hasznaljak. -
WN31RD
addikt
válasz Darth Vader #15 üzenetére
(Elég régen foglalkoztam már ilyesmivel, tehát lehet, hogy tévedek, vagy nem veszek figyelembe valami új procikban meglévő lehetőséget... úgyhogy javítsatok ki, ha szükség van rá!)
Mivel nem lehet szegmensenként elválasztva mappelni a lineáris címteret, szükségszerű, hogy egy processznek a szegmensei ugyanazon lineáris címtartomány eltérő részein legyenek, ha különböző tartalmuk van. Márpedig lineáris címekből 4 GB-nyi van, ezen kell osztozni, tehát nem lehet szegmensenként különböző 4 GB-ot használni.
(Tekintsünk el a 36 bites PAE-től, és maradunk a ''hagyományos'' 4 GB-nál.)''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
dabadab
titán
válasz Darth Vader #10 üzenetére
Milyen szegmentalas?... Az x86-ok 32 bites modjaban max. szelektorok vannak, nem szegmensek, a szegmens az a 16 bites mod 64K-s szeleteire fenntartott terminus technicus.
Amugy meg konkretan Linuxhoz van is patch, ami a stackrol leszedi az execution flaget, amit egy elozo hozzaszolasban emlitett is valaki, amint azt is hozzatette, hogy a vilag azert messze nem ilyen egyszeru, hogy chmod a-x /proc/stack, aztan jolvan :)
[Szerkesztve]DRM is theft
-
Erasmus
őstag
Kiegészítettem az URL-t.
Én nem értek ahhoz, hogy hogyan működik a buffer overflow, ezért sem írtam részleteket (amelyekről egyébként az eredetiben sincs szó) és ezért bőven lehet benne hülyeség. Szívesen is venném, ha azok, akik értenek a dologhoz, leírnák (pl. a hőzöngés helyett), hogy hol baromság a szöveg, mert módosítani bármikor lehet.
üdv, -
WN31RD
addikt
Szegmentálás alatt nyilvánvalóan a szelektor-deszkriptor rendszert értette Darth Vader (mint ahogyan én is)... :)
Mellesleg ezt szegmentálásnak (is) szokás hívni, legalábbis legjobb tudomásom szerint.''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
-
Darth Vader
csendes tag
Szeretnem figyelmedbe ajanlani az Intel gyari Pentium doksijat.
Ott egyertelmuen ir szegmentalastrol es lagozasrol vedett uzemmodban!!!
Egy szegmens merete 4GB is lehet. Ajanlom figyelmedbe a Linux kernel head.S nevu file-jat. Toltsd le egy linux kernelt, mondjuk a 2.4.24-et. Majd a linux/arch/i386/kernel konyvtar alatt megtalalod ezt a filet. Nezd meg a legveget es ott megtalalod a GDT-t. Ennek a pontos bit kiosztasat pedig megtalalod az intel doksiban. -
dabadab
titán
válasz Darth Vader #22 üzenetére
Ugy most ezzel nem azt akarod mondani, hogy mivel minden program megkapja a maga 4GB-os address space-et, ez azt jelenti, hogy mindegyikuk ugyanazt a fizikai memoriat latja?... Merthogy termeszetesen ez nem igy van.
DRM is theft
-
WN31RD
addikt
válasz Darth Vader #22 üzenetére
Van szegmentálás, csak nem használják ki ennek a lehetőségeit.
Na de nem kötözködöm: effektíve tényleg nincs szegmentálás a Linuxban, hanem lineáris címteret használ (legalábbis pl. a GRSecurity patch megfelelő opciójának a bekapcsolása nélkül).
Amit leírtál az teljesen oké, csak az a gond, hogy ha használnák a szegmentálást, akkor vagy előre el kellene dönteni, hogy a 4 GB-os lineáris címtéren hogyan osztoznak a szegmensek (ez történik a GRSecurity-ban, ha ...PAX_SEGMEXEC=y), és ha valamelyik proginak többre van szüksége pl. az adatszegmensben, akkor gond van, vagy pedig menet közben kell tologatni és növelgetni a szegmenseket, ennek megfelelően átírni a laptáblátkat, ráadásul mindezt osztott kódot (libek) tartalmazó rendszerben, stb. Ez viszont már nagyon jelentősen bonyolítaná a memóriakezelést.''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
kisfurko
senior tag
-
WN31RD
addikt
Az lehet, hogy nem lenne bonyolultabb, mint a lapozás, de akkor is növelné a memóriakezelő rész bonyolultságát (mert lapozásra mindenképpen szükség van, de most még szegmensek kezelésére is szükség lenne). :)
Ha nemcsak egy-egy szegmens van egy adott fajtából, akkor a fordítókat úgy kell írni, hogy szelektor:offszet típusú mutatókat kezeljenek... ez elég komoly változás lenne, bonyolítaná a fordítókat, lassítaná a programokat, stb. :O
Nem véletlenül hagytak fel ezzel.
[Szerkesztve]''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
Darth Vader
csendes tag
Adott esetben elkepzelheto, hogy lassitja, de csak akkor, mikor epp szegmenst kell valtani. Amugy egyebkent most is selector:offset a cimzesmod. Altalaban a nagyobb biztonsag ara, a lassabb mukodes. Pl: a Vedett uzemmodba a programok is lassabban futnak, mint valos modban.
-
kisfurko
senior tag
Szerintem nem lenne gáz a sel:offs típusú címzés, feltéve, hogy csak lib-enként lenne külön szegmens (máskülönben minek máshova rakni). A BSS-részüket meg egy nagy közösbe. BSS alatt értem a dinamikusan foglalt, futás alatt módosuló szegmenst.
Egyszerűen csak azért hagyták ki az op.rendszerekből, mert másik architektúra nem támogatta. Szerintem, persze... -
WN31RD
addikt
Hát... nekem sosem volt szimpatikus ez a szegmensezés...
De szerencsére a 64 bites címtér + execute-only flag fölöslegessé teszi a szegmenseket. :D
Vagy tudtok olyan dolgot, amit szegmensekkel meg lehet csinálni, de nagy címtér+e-o. flag-gel nem (vagy nem hatékonyan)?''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
-
kisfurko
senior tag
Eleinte nekem sem tetszett (főleg az el.....-t valós módú:)). Biztonságosabbak lehetnének egy nagyságrenddel a programok. Persze ez az execute-only page is OK. Hogy miért nem csinálták meg előbb...
Egyébként a szegmensek annyival jobbak még, hogy ha a szegmens nem nagyobb, mint 1 MB, akkor byte-ra pontosan megadhatod a méretét. -
rog
addikt
akkor most, hogy a fenébe fog ez működni?
nem engedi meg hogy írjon egy program a stack-re? vagy hogy?
(ez a túlcsordulás nem úgy mókázik, hogy felülírja a stack-ben lévő visszatérési címet, és amikor a végrehajtást vissza kéne adni a függvényt, programot hívó kódnak akkor a vezérlés a gonosz programrészre kerül nem pedig oda ahova kéne.?)
vagy valaki elmesélhetné, mert zavarodok össze-vissza. :) -
WN31RD
addikt
Azt nem engedi, hogy a program a veremben levő kódot végrehajtsa.
Tehát hiába kerül be a verembe a gonosz programrész, és a rá mutató visszatérési cím, mert a veremben levő programrész nem fog tudni elindulni (védelmi hibával elkapja az oprendszer).''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
kisfurko
senior tag
Nem olvastam még el, de én úgy tudom elképzelni, hogy csak az futhat (lap), aminek be van állítva az execute flag-je. A rendszer pedig csak a kód lapjainak állítja be. A kód lapjait meg nem lehet módosítani, mert read-only. Tehát nincs gonosz kód. Vagy valamit kifelejtettem?
-
klumbik
tag
(sajnos most igazi konkrétumot nem tudok fölhozni, de körbejártam a linux thinkpad-en témát a neten, és mintha láttam volna valahol a linuxos ibm tcpa driver képességei között, hogy elvileg alkalmazható hardveres puffer túlcsordulás védelemre, így jutottam arra, hogy elhamarkodottam fölvessem)
nem tudom milyen új védelmi lehetőségeket kínál még a k8 (pl. most kiderült számomra egy), de így érdekes kérdések merülhetnek föl a hírek szerinti prescottal kapcsolatban is, miszerint, ha azt mondják, hogy ez hardveres dolog és win támogatja, akkor jó eséllyel hardverszintű kompatibilitást kell mutatniuk ez ügyben (kb. valami flag ami azonos amd és intel procin is; közös amd-intel kiterjesztés(?)), ellenben a win kernel legalapvetőbb elemeinek kétféle verzióban, elég különbőzően kellene működniük
a hírrel, sötétben tapogatózunk, nem tudjuk, hogy egy fícsör jellegű, altalános szinten a szoftverek szempontjából transzparens megoldásról van-e szó.
szó van servicepackról ami jelenthet kernel foltozást (mert sztem, azért ilyen dolgokhoz be kell nyúlni oda), de jelenthet mást is.
ezért nem ejteném még ki a képből tcpa-t mivel egy egységes dolog, bár nem vagyok benne biztos, hogy egy sp-vel már át is lehetne térni rá. viszont, sztem magának fritz chipnek mint hardver, vajmi kevés köze lehet a deszkriptorokhoz és deszkriptor táblákhoz, inkább erősen tőle függő szoftverrel lehet ezt a védelmet kihasználni; azonosításnál ill. engedélyezésnél lehet kihasználni, hogy hardverrel (elsősorban egy csomó sokszázbites titkositást segítő dolog, erre saját memória...) vannak ezek a folyamatok segítve az általa leírt technikák szerint
persze csak találgatok
na közben találtam tcpa-ra vonatkozót:
[L]http://www.research.ibm.com/gsal/tcpa/[/L]
[L]http://www.linuxjournal.com/article.php?sid=6633[/L]
[Szerkesztve]''This is horseshit. Horseshit, horseshit, horseshit. And for those of you who don't know what that means, it's the shit that comes from a horse!'' -- Greg, Columbia Internet
-
WN31RD
addikt
''szóval az ip-t nem lehet olyan címre küldeni, ami a stack-en van?''
Pontosan. (De nem csak a veremről van szó, hanem az adatszegmensről is.)
''de mivan ha a gonoszság nem a veremben van? vagy olyan nem lehet?''
Elvileg olyannak nem kellene lenni, hogy kifejezetten gonosz programrész máshol legyen, de előfordulhat az, hogy egy teljesen normális rutin gonosz paraméterekkel meghívva gonosz dolgot csinál. A verem átírásával (a verembe írást semmi nem akadályozza meg) ilyen módon továbbra is támadható marad a gép.
''az ellen nem véd'' :D
''hogy működik egészen pontosan ez a túlcsordításos történet?''
Pl. így működhet:
A memóriában (veremben) a következők vannak:
... valamilyen puffer ... visszatérési cím ...
A program beolvas a pufferbe, de hibás a beolvasó kód, és nem ellenőrzi a beolvasandó adat méretét, és ha túl sokat kap, akkor felülírja a puffer utáni területet is, beleértve a visszatérési címet.
A támadó felülírja a visszatérési címet pl. a puffer bizonyos helyére mutató pointerrel, oda pedig berakja a kódot, és kész.''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
rog
addikt
ja azt tudom, hogy a stackon hogy kell túlcsordultatni, de azt nem értem hogy aktiválja az ártó részeket.
mert ugye ennek az lenne értelme, hogy védelmi szintet lép a program vagy ilyesmi.
van egy programom aminek egy függvénye úgy van megírva, hogy direkte verem túlcsordulást okoz, és ezáltal a verem mutató körbeér, és a programrész hívása elötti állapotra vonatkozó verem adatokat felülírja. és így a függvény végi return, a vezérlést nem a hívóra adja, hanem oda ahova én szeretném.
mit érek el ezzel? az op-rendszer az hiszi, hogy már a saját kódja fut, holott nem?
vagy ezt most így hogy? -
kisfurko
senior tag
''de előfordulhat az, hogy egy teljesen normális rutin gonosz paraméterekkel meghívva gonosz dolgot csinál. A verem átírásával (a verembe írást semmi nem akadályozza meg) ilyen módon továbbra is támadható marad a gép.''
Persze ez nem az architektúra hibája, hanem a szubrutiné. Illetve a rendszeré, ha nem azonos jogú dolgok egy vermet használnak. -
WN31RD
addikt
Védelmi szinteken nem lehet ezzel a módszerrel átmenni, de a program jogait megkapja a gonosz kód is, tehát pl. egy vírus terjedhet a programot futtató felhasználónak a jogaival, ha pedig egy privilegizált (pl. root-ként futó) szerverprocessz az áldozat, akkor ugye nem kell tovább magyarázni...
''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
WN31RD
addikt
Pontosan az átvétel a lényeg. Mert hiába szúrom be a gonosz kódot, aminek ugyanazok a jogai, mint annak a processznek, amibe beszúrtam, ha nem tudom elindítani. Éppen az elindítást akadályozza meg az új feature (ha jól spekulálunk).
''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
shtml
őstag
-
WN31RD
addikt
Tényleg nem az architektúra hibája.
Természetesen a privilegizált szinteknek külön verme van, viszont itt szó nincs különböző jogú processzekről... :F''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
klumbik
tag
akkor tulajdonképpen mi ez az amd féle execution protection? mert x flaget eddig is lehetett állítani. sajna nem nagyon jártam utána, milyen újításokat hoz védett módba a k8.
felváltunk x86-64-be úgy mint 386-oson? hoz új opciókat gdt/ldt-ben?
címzés hogy megy, ugyanúgy csak a táblákban a báziscím ki van bővítve?
aki tud valami pár oldalban összefoglalt irományt ne habozzon linkelni! :)''This is horseshit. Horseshit, horseshit, horseshit. And for those of you who don't know what that means, it's the shit that comes from a horse!'' -- Greg, Columbia Internet
-
rog
addikt
ja igen majd segyt.
de mi az amit megakadályoz.
vagyis mi történik ilyenkor?
ezt nem értem.
''A'' process fut a gépen. elindítja ''B'' processt. adott védelmi szinten, jogokkal.
''B'' process megbssza a stackot. ezáltal a vezérlés nem ''A'' processra kerül vissza, hanem ottmarad ''B'' processnál. és hogyan tovább? mit tud csinálni, amit addig nem tudott?
Aktív témák
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Arena Breakout: Infinite
- Itt van az eddig legjobban teljesítő kétfiókos NAS a TerraMastertől
- Autós topik látogatók beszélgetős, offolós topikja
- Samsung Galaxy S20 és S20+ duplateszt
- Törvénnyel pörgetné fel az európai zöldtechnológiát az EU
- exHWSW - Értünk mindenhez IS
- Speciális Gaudi 3-akat kap Kína
- ThinkPad (NEM IdeaPad)
- Autós topik
- További aktív témák...
- ÚJ, Bontatlan AMD Ryzen 7 7800X3D
- Beszámítás! Intel Core i3 8100 4mag 4szál processzor garanciával hibátlan működéssel
- Intel I7 12700KF 12mag/20szál - Új, Tesztelt - Eladó! 85.000.-
- Quad Core AMD Phenom II X4 945 (HDX945WFK4DGM) processzor
- Beszámítás! Intel Core i9 9900K 8mag 16szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen