● news.bsdnet.hu

A kiberbiztonságban létezik egy íratlan aranyszabály: ami szoftverből van, az előbb-utóbb feltörhető. A MetaSpace.Bio projekt fejlesztői azonban bedobtak a köztudatba egy új koncepciót és egy ahhoz tartozó sandboxot, aBioOS Cyber Genesis Challenge-et, ami nyíltan szembe megy ezzel az axiómával. Azt állítják, hogy az általuk alkalmazott "Digitális Okozatisági Zártság" (Digital Causal Closure) elve miatt a rendszerük matematikailag és logikailag feltörhetetlen. Az eddigi statisztika beszédes: 71 regisztrált, komplex támadási kísérlet (memóriaszivárogtatástól a GPS spoofingig), 0 sikeres behatolás. Vajon tényleg találtak egy sebezhetetlen architektúrát, vagy csak még nem nézett rá a megfelelő ember? A projekt (amelynek kódja és leírása a GitHubon is elérhető:LemonScripter/cyber-genesis-challenge) nem egy hagyományos CTF (Capture The Flag). A fejlesztők egy olyan "Logic Engine" modellt építettek fel, amely radikálisan korlátozza a kódvégrehajtás feltételeit. A mögöttes elmélet: Szándék nélkül nincs végrehajtásA BioOS rendszer védelmének magja az úgynevezett kauzális kapu. A koncepció lényege, hogy elválasztja a szoftveres autonómiát a fizikai/szándékos beavatkozástól (IRQ - Interrupt Request). A fejlesztők állítása szerint minden autonóm kód és szoftveres manipulációs kísérlet elvérzik ezen a ponton, mivel a rendszer hardveres szintű "szándéknyilatkozat" nélkül megtagadja a végrehajtást. Ez a gyakorlatban azt jelentené, hogy a hagyományos exploitok – amelyek a memóriakezelési hibákra vagy a futtatási környezet manipulálására épülnek – hatástalanok, mert a kiváltó ok nem egy legitim, rendszeren kívüli eseményből fakad. A Sandbox és a KihívásA fejlesztők nem csak elméletet gyártottak, hanem egy éles tesztkörnyezetet is publikáltak. Achallenge.metaspace.biooldalon elérhető a BioOS Hacker Terminal, ahol bárki megpróbálhatja átlépni a kauzális kaput. A rendszer folyamatosan monitorozza és naplózza a próbálkozásokat. A weboldal és a repó üzenete egyértelmű és meglehetősen provokatív a szakma felé:"Ez a sandbox nem csupán egy játék; ez egy empirikus bizonyíték arra, hogy a Digitális Okozatisági Zártsággal a hackelés matematikai képtelenséggé válik." Kérdések a közösség felé: A HUP népének is adott a feladat. A forráskód egy része és a keretrendszer tanulmányozható a GitHubon, az éles célpont pedig a weben várja a próbálkozókat. Linkek: A processzor architektuális hibáit is kizárja vajon? Ha nem csak hülyülünk, akkor itt egy válasz. Ha csak hülyülünk, ne olvasd tovább ;-):A processzor szintű hibák (pl. Spectre/Meltdown) alapja az, hogy a CPU 'találgat' (speculative execution), és ebből adat szivárog ki az oldalcsatornákon. A BioOS Digital Causal Closure koncepciója pont itt avatkozik be: 1. Szándék-alapú végrehajtás: Mivel minden kritikus művelethez hardveresen hitelesített 'Kauzális Token' kell, hiába spekulál a CPU, ha a logikai kapu (Causal Gate) nem kapott fizikai engedélyt a végeredmény kiadására. 2. Manifold Flattening (axióma-gyorsítás): Mi nem hagyományos módon futtatjuk a kódot, hanem a Z3-mal verifikált logikai utakat 'lapítjuk le' (flattening). Ezzel a CPU spekulatív egységei 'unatkozni' kezdenek, mert a logika determinisztikussá válik – nincs miért találgatni, így nincs mit mérni az oldalcsatornán. 3. Constant-Time Hardening: A v5.0.7 óta a rendszerünk törekszik arra, hogy a verifikációs idő független legyen az adattól, így a 'Timing Attack' típusú architektúrális rések is bezárulnak. Összegezve: Ha a processzorodban egy tranzisztor fizikailag rossz, azt mi sem forrasztjuk meg. De abban segítünk, hogy a hacker ne tudjon ebből a fizikai hibából logikai következtetést levonni a titkos adataidra nézve.Ui.: De amúgy törd fel, nem nehéz az ;-)... S akkor ünneplünk majd. 5000 "komoly" a cél, de valahol el kell(ett) kezdeni. Különben mit írtál volna? Mert minden savazással kezdődik. Nagyon helyesen ;-)... de ez milyen OS? mit tud futtatni? milyen hw-t tamogat? gondolom mindkettore a semmilyet a valasz... az OS hibak is altalaban a platformspecifikus driverekben szoktak lenni, meg az appokban. egy ures OS ami semmit se csinal tenyleg nehezen feltorheto :) Jogos, a sör mellé jár egy HUP-os 'Valóban?' díj is! 😄 És tényleg, ha egy OS nem csinál semmit, azt feltörni is művészet. A BioOS jelenleg nem egy 'Doom-képes' asztali környezet (bár ki tudja, mit hoz a jövő), hanem egy Causal Hypervisor. Hogy mit tud futtatni? Jelenleg leginkább a fejlesztők idegeit és ezt a sandboxot. De komolyra fordítva a szót: a célja nem az, hogy újabb driver-pokol legyen, hanem hogy a meglévő appok (mint a demóban látható 'Secure_Note' vagy a drón-irányítás) logikai integritását védje. A hw-támogatásról: a legfontosabb hardvert már támogatja: a felhasználót. A 'Proof of Presence' lényege pont az, hogy ne szoftveres absztrakciókkal (amikben a bugok laknak) küzdjünk, hanem rákössük a végrehajtást a fizikai valóságra (isTrusted event, hardveres időzítés). Tény: egy üres szobába nehéz betörni, ha nincs is ajtaja. Mi most azt próbáljuk megmutatni, hogy ha vágunk rá egy hatalmas ajtót (mint a demóban a szándékosan lyukas szoftveres API), a BioOS 'fizikai' lakatja akkor is tart-e, kitart-e? Törd föl, nyitva vannak a kapuk... Eddig tartott – kivéve, amikor a webes verifikátort hagytuk nyitva, de hát emberből vagyunk, nem axiómákból! 😉. Ö, izé... Csak én nem nekem tűnik úgy, hogy minden szöveged tele van olyan ködösítéssel, hogy véletlenül se lehessen kihámozni a lényeget? Igazából nagyon olyan a szöveg, mintha AI írta volna, tele felesleges hasonlatokkal és ismétlésekkel. Őszintén szólva nem tudom az egészet hova tenni, hogy ez mi akar lenni. Egy új HW architektúra, plusz OS? De akkor miért nem azt írod? Azt lehetne, hogy konkrétan kérdezel? Mert én is meg tudom kérdezni, hogy nálad éppen milyen idő van? Nézd meg a későbbi üzenetváltásokat. És mivel/kivel "harcolsz": a lényeggel vagy, hogy ki/mi írta? Használom az MIt-t is, naná, de nélkülem akármilyen okos az MI, annak annyi. Szedd szét a gondolatmenetet, a logikát, törd fel az alkalmazást. Mi akadályoz? Ha már úgyis az MI "írta" 😀. Vagy küldd rá az MI-t, miért ne. Hacsak nem azt akarod allítani, hogy az MI, pfú, de csúnya dolog, senki se használja 😀... Volt ott konkrét kérdés is: Őszintén szólva nem tudom az egészet hova tenni, hogy ez mi akar lenni. Egy új HW architektúra, plusz OS? De akkor miért nem azt írod? De úgy látszik, hogy a válasz helyett sikerült újabb 3 sornyi semmit írni. Nem zavar, ha valami AI által van megfogalmazva (én is azzal írok doksikat, sokkal szebben fogalmaz mint amire én képes vagyok) , amíg az nem megy az olvashatóság/érthetőség rovására, de a fölösleges és gyerekes hasonlatok nem segítik a megértést, épp az ellenkezőjét éred el vele (más téma, de pont ezért kell a human in the loop, hogy ne AI slop álljon elő, hanem valami értékes), hogy nem veszünk komolyan. Addig pedig se én se más komoly ember nem fog minimálisnál több effort-ot beletenni a "challange"-edbe, amíg nem látjuk, hogy van bármi értelme, és jelenlegi stílus és a sok ködösítés inkább afelé mutat, hogy ez inkább egy újabb komolytalan világmegváltó ötlet, aminek nincs semmi jelentőssége. Először meg kellene minket győznöd, hogy ez nem csak egy nagy halom buzzwordkupac, hanem gyakorlati jelentőssége is lehet. Pl erre a nagyon is fontos kérdésre sem válaszoltál: "de ez milyen OS? mit tud futtatni? milyen hw-t tamogat?" Erre is ment a ködösítés, hogy "legfontosabb hardvert már támogatja: a felhasználót." Ne haragudj, de ez semmit nem jelent. Pedig könnyen lehet, hogy csak a kommunikációdban van a hiba, és amúgy maga a "termék" értelmes, csak nem sikerült átadnod. De ezt nehéz eldönteni, és nem várhatod, hogy mindenki egyedileg kezdjen el kutatni, amikor annyi hasonló szenzációhajhász bejelentés történik. És hány topik lesz még belőle? :) https://hup.hu/node/189881 zrubi.hu Ezt nem tudom, biztosan jobb kettő mint egy. Mintha... Biztosan nem. :) Ugyanaz a téma itt konvenció szerint marad ugyanabban a topicban, nem szedjük szét hetvenyolc fele klikkbaitért. Egyetértünk na, de nem én vagyok a ludas, hogy újat hozott létre vki... Ja, hogy arra gondolsz, "megszerveztük"? Hát nem! "valaki" (esencoj| 2026. 05. 10., v – 11:07 ) lol Upsz, lehet, hogy én vagyok a hülye (biztos), s kétszer hoztam létre? Pfff... Bocs, zrubi! Egyet beküldtél cikként és mivel nem jelent meg azonnal (nyilván), egyet a fórumba is. Mivel én nem láttam a fórumposztot, kitettem a főoldalra. Utólag szembejött a fórumposzt is, de mivel két helyen felesleges azt le is zártam. trey @ gépház Mese nincs, én vagyok/voltam a hülye. Nem volt szándékos - bár ez a nóta végén a sej-haj... Zrubival ellentétben én értettem a miértet és jóhiszeműséget feltételeztem. trey @ gépház aha... meg bilibe lóg a kéz... Abba, de nem a kéz ;-)... Amúgy segítsetek, valóban nem jön át a lényeg, hogy mi a szándékunk? Vagy túl komolyan vettük a HUP-ot? Vagy nem jó a felvetés nyelve/nyelvezete? Amatőr vagy túl bonyolult? Idegesítő, hogy MI-t használtam (nyilván), de a franc se akarja ezt tagadni, ezért is nem dolgoztam azon, hogy IT-gegre "fordítsam" az egészet. Nem így és nem ezen a fórumon kellett volna megosztani? Hogyan formáljam át, hogy szakmai észrevételek, kritikák érkezzenek? Mert tényleg azt szeretném, ha érdemben is ránéznétek a felvetésre, a repóra, az oldalra... Amúgy segítsetek, valóban nem jön át a lényeg, hogy mi a szándékunk? Nekem nem. Vagy túl komolyan vettük a HUP-ot? Szerintem igen, de ha van valami jo kis konteod Magyar Peterrol, akkor itt talalsz ra vevoket. Hogyan formáljam át, hogy szakmai észrevételek, kritikák érkezzenek? Kezdeskent, nincs valami technikai doksi, buzzwordok nelkul, lehetoleg angolul, bevett szakkifejezesekkel? valóban nem jön át a lényeg, hogy mi a szándékunk? Egyátalán nem. De az sem igazán, hogy ez a BioOS pontosan micsoda, mire való, és milyen problémát szeretnétek vele megoldani avalóságban. pedig, eskü megnéztem az oldalt, a git repót is, és az AI-jal is beszélgettem erről/ilyesmiről :) (hint: AI adta a legtöbb használható infót.) zrubi.hu Köszi az őszinteséget, tényleg segít. Igazatok van, a 'BioOS' név és a körítés félrevezető, mert operációs rendszert sugall, miközben ez valójában egy biztonsági absztrakciós réteg. Mire jó?Arra, hogy hatástalanítsa a szoftveres bugokat. A lényege, hogy minden érzékeny műveletet (írás, hálózati export, adatbázis-elérés) egy fizikai, emberi interakcióhoz (pl. kattintás) köt. Ha egy jegyzetelő appban van egy SQL injection hiba, egy támadó szkript hiába próbálkozik: a rendszer megállítja, mert a szkript mögött nincs ott a valódi hardveres trigger. Így a bug megmarad, de nem válik exploittá. Mitől újszerű?A legtöbb védelmi rendszer azt nézi, mit akar csinálni a kód (sandboxing, whitelisting). Mi azt nézzük, hogy miért (mi a kiváltó oka): ez a Causal Security. Az újszerűség a megvalósításban van: egy Z3-alapú verifikációs réteg figyeli futásidőben a 'kauzalitást', és csak akkor engedi el a tranzakciót a memóriába, ha a szándék matematikailag igazolható.A megközelítés lényege a pozitív műveleti logika: a rendszer nem tiltani próbál (blacklisting), hanem kizárólag egy szigorúan definiált funkcionális listát ismer el létezőnek. Ez azt jelenti, hogy nemcsak a hozzáférést korlátozzuk, hanem magukat a műveleteket kötjük hozzá a konkrét funkcióhoz és a hozzá tartozó hardveres triggerhez. Ami ezen a pozitív listán kívül esik, az a rendszer számára logikailag nem értelmezhető és végrehajthatatlan, így az ismeretlen támadási vektorok (0-day) eleve kiesnek a lehetséges állapotátmenetek köréből. Összeraktam egy száraz, angol nyelvű specifikációt, ami lehámozza a 'Bio' és egyéb hangzatos kifejezéseket, és leírja a stacket (WASM-Z3, WebWorker izoláció, tranzakciós memória):https://github.com/LemonScripter/cyber-genesis-challenge/blob/master/TE… Aki a kódra kíváncsi, a bio_kernel_emu mappát nézze a repóban! A lényege, hogy minden érzékeny műveletet (írás, hálózati export, adatbázis-elérés) egy fizikai, emberi interakcióhoz (pl. kattintás) köt Ez mennyire tud a valosagban mukodni? A jegyzetelo peldanal maradva, mondjuk szeretnek egy olyat, hogy percenkent automatikusan mentsen a program, akkor is, ha nem kattintok a mentes gombra. Pont itt jön be a funkcionális kötöttség és a pozitív lista jelentősége. A BioOS-ben az automatikus mentés nem egy 'bármit megtehet' jogosultság. A fejlesztő/felhasználó a pozitív listán definiál egy specifikus Auto-Save Intent-et. Ez a művelet szigorúan kötve van:1. Egy belső, hardveresen hitelesített időzítőhöz (Trusted Timer).2. Egy fix célhelyhez (pl. csak a current_note_buffer tartalmát írhatja a backup_segment-be). A különbség: hiába fut le az automatikus mentés, egy támadó szkript ezt nem tudja úgy 'eltéríteni', hogy közben az adataidat egy külső szerverre is elküldje. Miért? Mert a hálózati export műveletéhez a rendszer továbbra is követeli a közvetlen, emberi interakciót (pl. a 'Megosztás' gomb megnyomását). Az automatikus mentés benne van a szabályrendszerben, de az is egy emberi interakcióból származtatott szándék. Nálunk az automatizmus nem önmagától létező folyamat, hanem egy kauzális lánc része: az alkalmazás elindítása vagy a szerkesztés megkezdése (ami hardveresen hitelesített esemény) hozza létre azt a felhatalmazást, ami a pozitív lista alapján lehetővé teszi az időzített mentést. A lényeg a funkcionális kötöttség: a szabályrendszer csak azt engedi meg, hogy az időzítő a jegyzetet a helyi adatbázisba mentse. Ebből a felhatalmazásból egy támadó szkript nem tud 'jogot' kovácsolni egy hálózati exporthoz vagy egy memóriatörléshez, mert azokhoz már egy újabb, közvetlen emberi trigger (pl. egy gombnyomás) kellene. Nem csak azt korlátozzuk tehát, hogy ki fér hozzá az adathoz, hanem azt is, hogy az adott művelet milyen láncolat végén futhat le – ez a pozitív műveleti logika. Tehát az automatizmus nálunk nem egy általános felhatalmazás, hanem egy szigorúan determinisztikus, funkcióhoz kötött csatorna. Nem tiltunk, hanem csak azt engedjük, ami a funkció leírásában (az axiómákban) explicit szerepel. Minden más, szoftveresen generált próbálkozás 'UNSAT' marad. Pont ellenkezőleg: a CSRF az egyik legfontosabb támadási vektor, amit a BioOS kapásból hatástalanít. A CSRF lényege ugyanis az, hogy a böngésző egy legitim, hitelesített kérést küld a nevedben, de valódi felhasználói szándék nélkül (egy külső oldal vagy egy szkript váltja ki). A BioOS-ben a kérés megléte önmagában kevés a végrehajtáshoz. Minden érzékeny művelethez szükség van egy Causal Tokenre, amit kizárólag egy fizikai hardware trigger (isTrusted esemény) tud generálni az adott doménen, egy szűk (250ms) időablakban. Mivel a CSRF kérést egy külső domain vagy egy automatizált folyamat indítja, nincs mögötte olyan hardveres esemény, amit a mi Gatekeeperünk hitelesnek fogadna el. Tehát nálunk a CSRF nem 'átcsúszik', hanem a kapuban elvérzik, mert hiányzik mögüle a fizikailag validált szándék. Pont ez a 'Digital Causal Closure' lényege: hiába legitim a kérés forrása, ha nincs mögötte bizonyítható emberi ok, akkor az a művelet nem létezik. A CSRF (vagy a Clickjacking, ha az 'on click attack' erre utalt) pont az a terület, ahol a BioOS paradigmája a legerősebb. A CSRF lényege, hogy egy külső kérés 'elrabolja' a hitelesített munkamenetedet. Nálunk ez azért nem működik, mert a művelet végrehajtásához nem elég a HTTP kérés vagy a session cookie. Szükség van egy Causal Tokenre, amit kizárólag a mi domainünkön belül lefutó, isTrusted (valódi hardveres) esemény tud generálni. Egy külső domainről érkező kérés vagy egy rejtett iframe-ben végrehajtott kattintás nem tudja produkálni ezt a tokent, mert a böngésző biztonsági modellje (vagy a mi Gatekeeperünk) látja a forrás és a szándék közötti inkonzisztenciát. A BioOS nem csak azt kérdezi: 'Ki akarja ezt?', hanem azt is: 'Miért és hogyan váltódott ki ez a kérés?'. Ha nincs közvetlen, helyi hardveres trigger, nincs művelet. Pont ez a 'Digital Causal Closure' lényege: a szoftveres automatizmus nem tudja szimulálni az emberi szándékot. "Minden rendszer biztonsága fokozható a teljes használahatatlanságig!" egy fizikai, emberi interakcióhoz (pl. kattintás) köt hat ezzel kicsit elkestetek, igy 2026-ban az AI agentes automatizalas fele megy a vilag, es nem a biorobot kattintgatasok fele. amugy meg meddig tart olyan exploitot irni, ami megvarja a tamadassal mig az user kattint valamit? Imádom, amikor a jövőkutatás találkozik a felületes olvasással. Kezdjük az első felével:"a világ az AI ágenses automatizálás felé megy". Bingo! Zseniális meglátás, jár a pont. És szerinted pont emiatt mi fogja megakadályozni azt a kedves, autonóm AI ágenst (vagy egy nullnapi sebezhetőséggel bejutó kártevőt) abban, hogy a háttérben, csendben "automatizálja" a webkamerádat, vagy "automatizálja" a bankszámlád lesz@pását? A BioOS pontosan azért született meg, MERT a világ az AI felé megy. Nem mi akarunk biorobotot csinálni belőled; mi azt akarjuk megakadályozni, hogy az AI ágensek kezeljenek téged biorobotként. A kritikus hardveres eseményeknél a fizikai kauzalitás a végső fék, hogy a gép tudja: ezt most a hús-vér felhasználója akarta, nem a háttérben futó okosított malware. Ami pedig a második felét illeti:"meddig tart egy olyan exploitot írni, ami megvárja a kattintást?" Remek ötlet, nagyjából 1998-ban, a Windows 95 idején még működött is volna a trükk. Te ott ragadtál le, hogy a BioOS csak egy butaif (mouse_clicked == true)kapcsolót vizsgál. Elárulom: meddig tart megírni egy ilyen "kivárós" exploitot? Körülbelül tíz perc. És meddig tart olyat írni, ami ezzel átveri a BioOS-t? A végtelenségig. Ugyanis hiába vár a te kis nyomorult exploitod a kattintásra a memóriában kuporogva. Amikor a "biorobot" felhasználó ténylegesen kattint, a BioOS nem a kattintástényétnézi, hanem az egész folyamat mikroszekundumokra bontott topológiai kauzalitását. Amikor az exploitod potyautasként megpróbál rácsatlakozni erre a kattintásra, és beküldi a parancsát, a miO(1)idejűre lapított Z3-as logikai motorunk megkérdezi tőle:"Haver, látom a parancsot, de hol van a te fizikai, hardveres ujjlenyomatod a lánc elejéről?"Mivel a te kódod a szoftveres térből indult, és nem a hardveres megszakítás (IRQ) fizikai analóg folyamatából, a rendszer úgy vágja le az exploitodat, mint a pinty. Szóval nyugodtan írd meg azt a kivárós exploitot! Szóval nyugodtan írd meg azt a kivárós exploitot! koszi, de inkabb haszonos, ertelmes dolgokkal toltom az idom. de ha megse, akkor se ezzel. a fizikai kauzalitás a végső fék legyen ez a vegszo! :) Ok, tegyünk úgy mintha komolyan vehető lenne ez az egész. Mit jelent az, hogy "biztonsági absztakciós réteg"? Hol van implementálva, mibe épül bele, milyen rétegek között működik? Ezt fejtsd ki légyszíves bővebben: Ha egy jegyzetelő appban van egy SQL injection hiba, egy támadó szkript hiába próbálkozik: a rendszer megállítja, mert a szkript mögött nincs ott a valódi hardveres trigger. Így a bug megmarad, de nem válik exploittá. Ki fogja meg, és honnan tudja, hogy aSELECT count(*) from data where name like '%af'; DROP TABLE data; --'SQL kártékony, amikor pontosan ugyanúgy fut, mint bármi más? És ha azt mondod, hogy azért, mert az ehhez tartozó 'intent'-ben csak az van, hogy lekérdezhet, akkor ezt ma is meg tudom csinálni, hogy az adott usernek csak olyan permission-je legyne, amire tényleg szüksége van, ez miben más architektúrálisan? Ja, és hogy jön ide a "hardveres trigger"? Ez mi? Melyik oldalon van, és mihez kapcsolódik? Tuti, hogy a kommunikációt cseszem/csesztem el; milyen szintig menjek le egy fórumbejegyzésben vagy cikkben itt, a HUP-on? Köszi a konkrét kérdéseket, íme válaszok, jöhetnek a további kérdések. Az érdekelne, s ezért próbálkoztam itt, hogy van-e olyan kérdés, amit nem tettem föl, amit nem kezel a hangzatos nevű - igaz - BioOS. 1. Mit jelent az, hogy "biztonsági absztakciós réteg"? Hol van implementálva, mibe épül bele, milyen rétegek között működik? Ez a réteg egy Ring 0 (Kernel Mode) szintű Filter Driver. Az operációs rendszer magjában az I/O Manager és a hardverspecifikus illesztőprogramok (Device Drivers / HAL) közé ékelődik be. Minden magasabb szintről (Ring 3 User Mode) érkező rendszerhívás (syscall) és az azokból generált I/O kérés (IRP) fizikailag ezen a driveren halad át, mielőtt elérné a hardvert. ​2. Ki fogja meg, és honnan tudja, hogy a SELECT count(*) from data where name like '%af'; DROP TABLE data; --' SQL kártékony? Senki és sehonnan.A BioOS nem végez csomagvizsgálatot (Payload Inspection / WAF), és nem értelmezi az SQL kódot. ​3. Miben más ez architektúrálisan, mint a klasszikus permission / RBAC? A klasszikus jogosultságkezelésállapot-alapú (State-based). Az OS azt ellenőrzi, hogy a folyamattokenjejogosult-e az adott műveletre. Ha egy támadó kompromittálja a jogosult folyamatot (pl. memóriakorrupcióval), az OS végrehajtja a kérést, mert a jogosultságok rendben vannak. A BioOSfolyamat-alapú (Causality-based). A Kernelt nem érdekli a folyamat tokenje. Ha a syscall nem vezethető vissza folyamatos láncolatként a legalacsonyabb szintű, nyers fizikai hardver-megszakításokig (IRQ), a kérés blokkolódik. A permission azt nézi,ki vagy, a BioOS azt, hogyhonnan (milyen fizikai okozati láncból)jött a parancs. ​4. Hogy jön ide a "hardveres trigger"? Ez mi? Melyik oldalon van, és mihez kapcsolódik? A hardveres trigger a kliens (host) gépen történő, emberi interakciót reprezentáló nyers hardveres megszakításkérés (Interrupt Request - IRQ), ami a legalsó fizikai rétegből (HID, billentyűzet, egér, touch controller) származik.  Ez a rendszerben a "Root of Trust": a kauzális lánc matematikai axiómája, amire az egész folyamat-validáció ráépül. Vegyük a következőt: gépelek a konzolon két parancsot: ls fájlnév rm fájlnév Ez kb. egy halom billentyűzet irq-ra vezethető vissza. Pontosan. És pont ez az a triviális különbség, amin a távoli kódfuttatás (RCE) és a zero-click malware-ek elvéreznek a BioOS Ring 0-ás szintjén. ​Nézzük meg, mi a különbség a te 'halom billentyűzet IRQ-d' és egy exploit végrehajtása között a Kernel szemszögéből: ​1. Amikor TE (a fizikai user) kiadod az rm fájlnév parancsot: ​2. Amikor egy Malware / Háttér-szkript adja ki az rm fájlnév parancsot: ​3. 'De mi van, ha a malware szimulálja a gépelést?' (A User Mode trükk) Nem. ezt olvasva olyan erzesem van, hogy valaki meg mindig aprilis 1-en erzi magat Már megint egy helikopter 😃. Mondjuk ez megy az április 1-jéhez... Asszem átterhetünk a Magyar Péter jelenségre. Ö, izé. Mert a rendszerhívás mögött ott van a validált fizikai hardveres megszakítási folyamat (billentyűleütések dinamikája). oh boy... zrubi.hu Amúgy a projekt bekerült a Google for Startups programba, de a franc tudja, hogy ez itt számít-e 😀. Értem én, hogy itt a többség helikopter, de mna... Link:https://www.linkedin.com/feed/update/urn:li:activity:742273521635357081… Igen, itt mindenki gyoker, kar rank vesztegetned az ertekes idodet. Amugy helikopter az apad fasza, en leleptem, koszi a lehetoseget.