- A hozzászóláshoz be kell jelentkezni
- 1611 megtekintés
Hozzászólások
Vajon mennyire hibatűrőek a gigászi mentések, tar.gz-k és társaik? Mert hogy pár intim jpg és docx elhasal egy dolog... :-)
Files below the size of 5000 bytes cannot be recovered. For files between 5000 bytes and 1GB in size, full recovery is possible. For files larger than 1GB, the first 5000 bytes will be lost but the remainder can be recovered.
- A hozzászóláshoz be kell jelentkezni
hibatűrőek??!
sokkal inkább erősen tömörítettek, amiben 'hibatűrés' kb értelmezhetetlen, hiszen az redundanciát jelentene - szerintem.
Az lehet, hogy az file elején van pár byte header, amit bizonyos esetekben akár manuálisan is helyre lehet állítani... de ennyi.
- A hozzászóláshoz be kell jelentkezni
hát, -sajnos- van aki nem is érti miért írtam. ACE, UC2, ARJ, RAR, stb. Mint tudta/tudja 1.2,.1.4.MB-os file-okba tömöríteni az amúgy nagyobb tömörítvényt. Ha nem solid, hanem más redundáns módon ezen szeletekbe teszed az infót, pár szektorhiba a floppykon, pár blokkhiba ellenére is sikerült akár 10-20+ floppyról visszaszerezni a tömörítvényt. :-)
De a kor halad, manapság letükrözzük RAID-be az encryptált bithalmazt is. Majd georedundánsan jól tároljuk is. :-)
- A hozzászóláshoz be kell jelentkezni
pár szektorhiba a floppykon, pár blokkhiba ellenére is sikerült akár 10-20+ floppyról visszaszerezni a tömörítvényt
dehogy sikerült... max kiírta, hogy crc error...
a floppy disk controller próbálta újraolvasni n-szer és sikerült az errort kijavítani, nem az arj
az a file, amelyik érintve volt az archive-ban, annak annyi volt...
- A hozzászóláshoz be kell jelentkezni
a RAR tudott opcionalisan hibajavito (ECC) infokat is tarolni, nyilvan ezzel par %-al novelve a rar file meretet, de par szektor hibat ki tudott vele javitani.
- A hozzászóláshoz be kell jelentkezni
igen, a rar tud "recovery record"-ot hozzáadni, de azt expliciten meg kell adni
- A hozzászóláshoz be kell jelentkezni
Ilyet az arj és a jar (ugyanaz volt a fejlesztőjük) is tudott a 90-es évek vége felé már - és működtek is.
- A hozzászóláshoz be kell jelentkezni
lehet, de a 90-es evekbe mar senki se hasznalt arj-t :)
a jar meg zip atnevezve, a java-ban hasznaljak...
- A hozzászóláshoz be kell jelentkezni
Volt egy ilyen is JAR néven, de nem igazán terjedt el: http://www.arjsoftware.com/jar.htm
- A hozzászóláshoz be kell jelentkezni
na ez az igazi retro site!
- A hozzászóláshoz be kell jelentkezni
de mennyivel kevesebb erőforrást eszik :)))
- A hozzászóláshoz be kell jelentkezni
"a jar meg zip atnevezve, a java-ban hasznaljak"
hát nem igazán, ahogy lejjebb írta más is, az arj-sek is kiadtak egy jar nevű cuccot
- A hozzászóláshoz be kell jelentkezni
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Most jönnek azok, akik ilyen fájlokat helyre pofoznak. :D
- A hozzászóláshoz be kell jelentkezni
hat anno a legelso ransomwarek meg csak a file elso 512 bytejat titkositottak, ami arra eleg volt hogy ne nyiljanak meg, de a legtobb filetipusnal ezt meg helyre lehetett allitani, bar nem volt annyira trivialis:
- OLE2 (doc/xls/ppt) eseten az egesz header ment a levesbe, de szerencsere a maradek elemzesevel ki lehetett talalni mi kell a headerbe
- ZIP (docx/xlsx/stb) eseten a header es eselyesen az elso tomoritett file veszett oda. erdekes modon az office eleg sok paddinget hasznalt igy altalaban a file elso 1-2 byteja serult csak, amit viszont a CRC32-bol vissza lehetett szamolni.
- PDF altalaban ujraepitessel javithato volt
- JPG eseten az EXIF metadata es/vagy a thumbnail ment a levesbe, a kep maga altalaban megmaradt. persze uj headert kellett generalni hozza...
- A hozzászóláshoz be kell jelentkezni
Persze, hogy arra mentek rá, mert ha csak 512 bájtnyit titkosít, akkor nem hívja fel magára a figyelmet nagy erőforrás-fogyasztással. Persze ha már szemetek akarnak lenni, nem lett volna nagy skill leprogramozni, hogy random offszeten kezdje azt az 512 bájtos titkosítást, akkor meg a nagy elemzések, meg paddingok, CRC32 mehet a levesbe. Bár az is igaz, hogy akkor meg a fizető áldozatoknak biztosított feloldó tool nem tudta volna, hogy melyik 512 bájtot kell helyreállítani, de valami ökoszisztémát kidolgozhattak volna, pl. fájlmérettől legyen függő.
A maiak mindent titkosítanak, bár azért válogatnak fájltípusban, hogy inkább a fontosabb fájlok menjenek a levesbe.
Általában a legtöbb ransomware-hez lesz előbb-utóbb decryptor, mivel a titkosításhoz csak pár kulcsot használnak, azt meg ki szokták okoskodni végül. Erről a Black Bastáról nem is hallottam még.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
ezert hasznalok rar -t ; az tud recocery recordot ha nagyobb archivum szeletelve, akkor recovery particiot is.
de ha ezt lefelejtem, akkor is van repair lehetoseg, ami az 1-2 korrupt filen kivul minden mast kiszed a tomoritvenybol.
HUP te Zsiga !
- A hozzászóláshoz be kell jelentkezni
Ez valóban erőssége a Rar-nak, hogy nagyobb hibaredundanciát tud beépíteni a tömörítvénybe, és emiatt jobb a helyreállító-hibajavító képessége. Ezt egyébként meg tudnák oldani a modern FOSS tömörítőkben is, de lusták hozzá. Unixlike rendszereken a Unix filozófiával magyarázzák, hogy egy tömörítő csak tömörítsen, minden mást bízzon másik segédprogramra, a szekvenciális (egyetlen fájlként, solid archive-ként) tárolást, meg a jogosultságokat, linkeket kezelje a gnutar/bsdtar, a redundanciát meg valami másik checksum megoldás, amibe átpipe-oljuk a kész archívumot, titkosítást szintén megoldja a gpg-be, vagy openssl-be átpipe-olás.
Ennek ellenére a Rar-t használatát nem támogatom, mint már sokszor leírtam. Okok:
1) vannak nála jobb, modernebb tömörítők, amik gyorsabbak és/vagy jobban is tömörítenek (zstd, lz4, brotli, zopfli sebességben, az xz/lzma2/zpaq meg tömörítési hatásfokban veri)
2) zárt forráskodú, proprietary licencű (ezt enyhíti, hogy az unrar nyílt, és a rar meg egyébként is multiplatformos)
3) a fenti miatt egy emberes fejlesztői projekt, a jövője folyamatosan kérdéses. Nehogy azt higgye ám valaki, hogy ez csak elméleti szempont. Ez volt a nanozip closed-source freeware tömörítővel is. A finn fejlesztője (Sami Runsas) alig néhány évig fejlesztette, de 2014-ben meghalt, vitte az egész projektet magával a sírba, se forráskód, se semmi, aki ezzel a tömörítővel tömörített, az jól megszopta, beleinvesztált egy halott ökoszisztémába, tömöríthetett később mindent át.
Egy előnye volt még a Rar-nak, a GUI, de az is csak a Winrar-nak van, windowsos platformra kizárólag. Mióta a 7-zip, Peazip, stb. GUI-ja is használható, azóta már ez se szól mellette.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Te is megadtad volna a decryption kulcsot ha az egyik karosult mar a negyedik csaladtagodnak huzogatja az orrod elott egyesevel a fogait, mikozben le vagytok mindketten kotozve.
De mivel ilyen buntetest senki nem alkalmaz, igy hat marad az, hogy hibat kell talalni a titkositas implementaciojaban.
- A hozzászóláshoz be kell jelentkezni
Azt meg is érdemelnék, hogy húzogassák nekik. Írom ezt úgy, hogy én nem haragszom rájuk, mivel 1) nem estem még ilyennek áldozatul, 2) jó Linux reklámnak tartom a ransomware-eket.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Oprendszertől függetlenül titkosíthatóak a felhasználó által elérhető fájlok. Rá kell venni, hogy futtassa. Otthoni felhasználásnál azért a legfontosabb dolgok a user mappájában vannak.
- A hozzászóláshoz be kell jelentkezni
Pontosan. És persze van linuxos ransomware is, sőt olyan is amit simán portoltak windows-ból. Itt maximum az "véd", hogy olyan elhanyagolható a linux elterjedtsége, hogy minimális szinten irjnak rá ransomware-t rá.
De nem csak otthoni felhasználásnál a user mappájában vannak veszélyben a dolgok, hanem vállalati környezetben a fileszerveren is, ott is irás joga van a usereknek. (normális helyen nyilván csak az adott munkakör számára szükséges file-ok irhatóak adott usernek, bár ez mindegy, amikor megszórják levéllel az összes usert és sok hülye végigcsinálja amit irnak)
- A hozzászóláshoz be kell jelentkezni