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

• #104379 Dißnäëß nagyúr sh4d0w #104377

  Új Válasz 2025-06-13 10:57:38 #104379

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Dißnäëß

  nagyúr

  válasz sh4d0w #104377 üzenetére

  Már hogy venné észre akármilyen random Linux ?
  Ugyanazt a mozit nézzük ?
  
  Egyik HDD-m a négyből, ez a nyers drive nézete (nem a /dev/mapper-es felnyitott ekvivalenséé értelemszerűen). Ez full disk encryption LUKS-al. Amit LUKS-ban lehet amúgy offset-elni, hogy ne a legelső szektornál indítsa, ergo akkor csak kevesebbet titkosít le belőle. Se kontroller, se más OS, se emberfia meg nem mondja, mi az a random szemét ...
  
  A Windows ugyanezt látja és amikor a SAS kontrollert bekapcsolom (mert le van tiltva eszközkezelőben), detektálja mind a 4 HDD-t és megkérdezi, hogy inicializálja-e őket, mert tök szüzek. Nyilván cancel, különben száll minden, hiszen nem szüzek..

  Spéci szoftver is akkor tudja nagyjából megtippelni, hogy bármivel is titkosított a drive (úgy egyáltalán), ha a header-je rajta van az elején. Nálam ez sincs, külön vettem, akárcsak a kulcsokat, de ez mindegy is.. a header-t is tartalmazó nyers LUKS titkosított drive is tök láthatatlan azon OS-ek számára (mind számára), amik rajta kívül állnak. Lehet egy NSA-nek van féltve őrzött tool-ja ilyenek kinyitására, minthogy minden opensource kripto- és szteganográfiai projektben ott vannak (lásd backdoor), de most ezzel komolyan nem foglalkoznék mélyebben, meg ha vki rájönne, hogy van ilyen, az nagyot durranna.

  Az, hogy Te hozol létre egy normál GPT partíciós táblát és azon belül egy formázatlan akármilyen partíciót, majd azt titkosítod LUKS-al, vagy mással, engedi magát detektálni - értelemszerűen, de itt szó nincs erről és nem is utaltam rá. A Windows partícióim között ott éktelenkedik a szintén LUKS-os linux gyökerem, evidens, hogy egy nemtitkosított táblában látszik, még label is adható neki, nem csak a típusa, hogy az ott adat lesz, ha tudod a jelszót..

  Ember legyen, aki a telibe titkosított HDD-ről felnyalt "random adatszemétről" megmondja, hogy valódi fájlrendszer van felette értelmes adattal, pláne úgy, hogy nem írtam végig dd-vel nullákkal a /dev/mapper eszközt a mindennapi ajánlások ellenére, magyarul az alatta lévő rétegen sem írta random szarral tele a diszket a LUKS, csak ahova tényleg kitett adatot a felette lévő felnyitott rétegben (amiben olyan fájlrendszer van nyilván, amit csak akarunk, teljes értékű eszköznek látszik). Ergo, kívülről nézve egy editorból nagyjából random szemét és előző tulajtól származó további szemét és nullák váltják egymást.

  Ha ugyanezt megcsinálod egy SSD-vel, addig fogja tudni a kontroller, hogy mely részein van értelmes adat, amíg a titkosítást létrehozó oprendszer erről árulkodik neki bármit is (mivel a LUKS is tud discard-ot, a biztonság rovására, de azért az sem úgy megy, mint a filmekben).

  Ahogy bootolsz másik OS-el, a másik OS azt fogja jelenteni a kontrollernek, hogy "üres diszk" és amint létrehozol rajta egy partíciót (kicsit vagy telibe, mindegy), egy fájlrendszerrel, azonnal indul a trim parancsok kiadása és az SSD megtudja, hol van adat és mi a free space, utóbbit már szabadítja is fel.

  Hja, csak közben belerondíthat az ott lévő "random szemétbe" ami nagyonis rendezett, semmi random, csak annak látszik. Ez HDD-n nem fordulhat elő, mivel csak akkor nyúl a fej ezen részekre, ha konkrét access érkezik ide, nem pedig üresjáratban is dolgozgat a háttérben és írogat felül cellákat, blokkokat, page-eket, akármiket, mert úgy hiszi hogy dolgozhat vele.

  Amikor a Samsung SSD Magician is Overprovisioning-et állít be, lényegében egy formattálatlan nyers partíciót hoz létre a meglévők közé, jelezve ezzel OS-nek (és az meg az alatta lévő SSD vezérlőnek TRIM által), hogy az ott üres terület, lehet vele játszani. Holott fizikailag ki tudja milyen randomszemét van azokban a cellákban is, de az SSD onnantól simán felülírogatja őket, pakolgat ide-oda-amoda, wear leveling dolgozik, Neked meg ugrik a titkosított részed.

  Mire ezeket bepötyögtem, megerősítettek, hogy csak úgy működik a dolog, ha nincs átfedés a látható - mondjuk - NTFS partíció és a mellé tett (láthatatlan) LUKS konténer között.

  A működési elv: ha a fájlrendszer töröl egy inode-ot (vagy típustól függően hasonló logikai alapegységet), akkor a TRIM parancsot küldi az SSD-nek és informálja arról, hogy az ahhoz az inode-hoz társított adatblokkot felszabadíthatja. Mivel egy NTFS fájlrendszer nem menedzseli azokat a blokkjait egy SSD-nek, amik titkosítottak, nem is fogja azt mondani az SSD-nek, hogy szabadítsa fel azokat, kivéve ha kiterjesztem átméretezéssel az NTFS partíciót arra a területre is.

  Magyarul, amíg a látható NTFS (vagy egyéb) és a láthatatlan titkosított adat egymás mellett vannak logikailag, nem lesz gond. Ha a látható átlapolódik részben vagy egészben a láthatatlanra, SSD esetén TRIM miatt kinyírja azonnal a láthatatlan titkosított részt ezzel, mert annak vezérlője a területtel elkezd "játszani", felszabadíthatónak tekinti onnantól, míg HDD esetén eljátszható simán, hogy egy NTFS partíciót kiterjesztünk rá a titkosított területre és amíg nem írunk rá, illetve arra a területre (amire nincs ráhatásunk), addig az nem is lesz bántva. Értelme nem sok, max fóbia-paranoia esetén, hisz veszélyeztetjük NTFS írás esetén a titkosított, ott és akkor üresnek látott területet, de mint megoldás működik.

  Jót beszélgettünk.

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