» »

[Java] Kako izračunati hash diska.

[Java] Kako izračunati hash diska.

111111111111 ::

Ima kdo idejo kako bi izračunal Hash diska1 in diska2, da bi videl če se je kaj spremenilo.

Primer:
Doma imam 2 diska. Prvi je produkcijski drugi pa za backup. Sedaj bi rad iz diska1(produkcije), presnel vse na disk2(backup). Potem pa bi poračunal hash nad vsemi datotekami in primerjal oba diska med seboj, da se je res vse pravilno preneslo.

Vse skupaj pišem v Javi, zanimajo pa me predvsem postopki računanja Hasha na diskih, direktorijih in datotekah, da bi si izdelal možnost incremental backupa.

krneki0001 ::

A to hočeš sam narest? Ali moraš narst za šolo?

Ker drugače imaš Cobian backup, ki to dela zate in še zastonj je.

111111111111 ::

Sam bi rad naredil.

Rad bi kakšen nasvet, link, skratka usmeritev, kako se zadeve lotit. :)

krneki0001 ::

rabiš potem kaj takega:
MessageDigest md = MessageDigest.getInstance("MD5");
try (InputStream is = Files.newInputStream(Paths.get("file.txt"));
     DigestInputStream dis = new DigestInputStream(is, md)) 
{
  /* Read decorated stream (dis) to EOF as normal... */
}
byte[] digest = md.digest();


Ali pa kaj takega:
import java.io.*;
import java.security.MessageDigest;

public class MD5Checksum {

   public static byte[] createChecksum(String filename) throws Exception {
       InputStream fis =  new FileInputStream(filename);

       byte[] buffer = new byte[1024];
       MessageDigest complete = MessageDigest.getInstance("MD5");
       int numRead;

       do {
           numRead = fis.read(buffer);
           if (numRead > 0) {
               complete.update(buffer, 0, numRead);
           }
       } while (numRead != -1);

       fis.close();
       return complete.digest();
   }

   // see this How-to for a faster way to convert
   // a byte array to a HEX string
   public static String getMD5Checksum(String filename) throws Exception {
       byte[] b = createChecksum(filename);
       String result = "";

       for (int i=0; i < b.length; i++) {
           result += Integer.toString( ( b[i] & 0xff ) + 0x100, 16).substring( 1 );
       }
       return result;
   }

   public static void main(String args[]) {
       try {
           System.out.println(getMD5Checksum("apache-tomcat-5.5.17.exe"));
           // output :
           //  0bb2827c5eacf570b6064e24e0e6653b
           // ref :
           //  http://www.apache.org/dist/
           //          tomcat/tomcat-5/v5.5.17/bin
           //              /apache-tomcat-5.5.17.exe.MD5
           //  0bb2827c5eacf570b6064e24e0e6653b *apache-tomcat-5.5.17.exe
       }
       catch (Exception e) {
           e.printStackTrace();
       }
   }
}


HashCode hc = Files.hash(file, Hashing.sha1());
"SHA-1: " + hc.toString();


HashCode md5 = Files.hash(file, Hashing.md5());
byte[] md5Bytes = md5.asBytes();
String md5Hex = md5.toString();

HashCode crc32 = Files.hash(file, Hashing.crc32());
int crc32Int = crc32.asInt();

// the Checksum API returns a long, but it's padded with 0s for 32-bit CRC
// this is the value you would get if using that API directly
long checksumResult = crc32.padToLong();

Zgodovina sprememb…

111111111111 ::

Hvala za namige in linke.

BigWhale ::

Hasha celotnega diska pravzaprav noces delati, ker bo predolgo trajalo.

111111111111 ::

Zakaj? Predstavljam si nekako tako, da prvi krog naredim imena datotek in njihovo velikost in iz tega izračunam hash.

Invictus ::

111111111111 je izjavil:

Zakaj? Predstavljam si nekako tako, da prvi krog naredim imena datotek in njihovo velikost in iz tega izračunam hash.

Če ne boš dodal datuma, ne boš vedel, če se je kaj spremenilo.
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

c3p0 ::

MD5 datotek delaj, ostale metode so bolj kilave. Velikost je lahko enaka, vsebina pa čisto drugačna. Na datum se tudi ne bi preveč zanašal.

galu ::

Kombinacija podatkov iz zbirčnega sistema in hitrih hash/checksum/CRC metod (npr. CRC32) bi znala biti najboljša za učinkovito in zanesljivo preverjanje sprememb posameznih datotek.

MD5, SHA256 in podobni one-way hash (with security in mind) metode, katerih namen je tudi čimvečja časovna zahtevnost, bi znale biti problem zaradi hitrosti.
Tako to gre.

Zgodovina sprememb…

  • spremenil: galu ()

DavidJ ::

Enosmerne zgoščevalne funkcije niso namerno počasne: ena izmed zahtev "dobrih" enosmernih zgoščevalnih funkcij je ta, da so "učinkovite" tj. "hitre". Tisto, kar daje počasnost je tipično sekvenčna narava. Primer paralelne zgoščevalne funkcije je Blake.

Ali so "nepotrebne" pa je odvisno od tega, v kakšnem okolju se nahajaš. CRC je namenjen detekciji naključnih napak, ne namernih. Za detekcijo namernih sprememb je nujna uporaba močnih enosmernih zgoščevalnih funkcij.
"Do, or do not. There is no 'try'. "
- Yoda ('The Empire Strikes Back')

galu ::

Tako to gre.

Horejšio ::

rsync.

BigWhale ::

111111111111 je izjavil:

Zakaj? Predstavljam si nekako tako, da prvi krog naredim imena datotek in njihovo velikost in iz tega izračunam hash.


Kako bos pa na ta nacin zaznal, da je 'drek' postal 'shit'? :)

kunigunda ::

Ce hocs ceu disk bos moral vec krogov.
1 - hash fajlov
2 - hash direktorija (naredis hash iz hash fajlov)
3 - hash diska (naredis hash is hash direktorijev)

lohk seveda sam 1 pa preskeniras vse hash fajle ce so spremembe, lohk ti pa to en thread v ozadju sproti dela, ce se direktorij/file spremeni

BigWhale ::

Da ugotovis a se je v direktoriju spremenil kak file ne potrebujes hasha direktorija, lahko samo modified time direktorija gledas in ce je razlicen od prejsnjic, ko si pogledal direktorij, potem je prislo do neke spremembe. Vprasanje je samo, a je mozno spremeniti file brez da bi se spremenil modified time. :)

kunigunda ::

Mozno da je tko na windowsih, na linuxih se mtime direktorija spremeni sam ce dodas al zbrises fajl, ne pa vsebine.

MrStein ::

To se da narediti z dvema vrsticami skripte, ni treba tople vode izumljat (ker je velika možnost, da boš napačno odkril).

Oporne točke:
http://superuser.com/questions/458326/s...
http://superuser.com/questions/371572/w...

Imajo še linke na sorodna vprašanja, ali pa še iskanje uporabi.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

DavidJ ::

galu je izjavil:

Ni tak simpl.
http://openwall.info/wiki/john/essays/f...

Polinkan prispevek je precej poenostavljen in tudi zavajajoč.

Najprej, zgoščevalne funkcije niso hitre in počasne, ampak so samo take, za katere poznamo kolizije in jih zaradi tega ne smatramo več kot varne (MD5), in take, za katere jih (še) ne in jih zato smatramo za varne. (SHA-1 je zdaj v nekakšnih vicah, kjer smatramo, da ni več varna, čeprav kolizij še nismo našli.)

Enosmerne zgoščevalne funkcije morajo biti "učinkovite". To v teoriji pomeni, da se morajo izvesti vsaj v polinomskem času, v praksi pa "dovolj hitro".

Nadalje, bcrypt, scrypt in ostale v prispevku omenjene "počasne" enosmerne zgoščevalne funkcije, dejansko niso zgoščevalne funkcije, temveč key-streching pristopi, katerih namen je otežit izdelavo mavričnih tabel, preko katerih bi lahko iz izvlečka izračunali prvotno sporočilo; tako onemogočimo napade s surovo silo.

Za potrebe OP-ja pa utegnejo biti tudi enosmerne zgoščevalne funkcije prepočasne, saj bi v naivnem primeru moral za detekcijo spremembe posamezne datoteke izračunati hash celotnega diska.

Kot je že bilo omenjeno, rešitve za take probleme že obstajajo (rsync), če pa to ne pride v poštev, pa svetujem, da se OP pobližje spozna s pojmom Merkle drevesa.
"Do, or do not. There is no 'try'. "
- Yoda ('The Empire Strikes Back')

Zgodovina sprememb…

  • spremenil: DavidJ ()

galu ::

DavidJ je izjavil:

galu je izjavil:

Ni tak simpl.
http://openwall.info/wiki/john/essays/f...

Polinkan prispevek je precej poenostavljen in tudi zavajajoč.

Čist zadovoljivo pove bistvo.

Najprej, zgoščevalne funkcije niso hitre in počasne, ampak so samo take, za katere poznamo kolizije in jih zaradi tega ne smatramo več kot varne (MD5), in take, za katere jih (še) ne in jih zato smatramo za varne. (SHA-1 je zdaj v nekakšnih vicah, kjer smatramo, da ni več varna, čeprav kolizij še nismo našli.)

Delitev (uporabnih in neuporabnih) je lahko poljubno mnogo. Vidik varnosti zgoščevalne funkcije, ki se bi rabila za detekcijo sprememb na podatkih, je recimo čisto irelevanten.

Enosmerne zgoščevalne funkcije morajo biti "učinkovite". To v teoriji pomeni, da se morajo izvesti vsaj v polinomskem času, v praksi pa "dovolj hitro".

precej poenostavljeno in tudi zavajajoče.

Nadalje, bcrypt, scrypt in ostale v prispevku omenjene "počasne" enosmerne zgoščevalne funkcije, dejansko niso zgoščevalne funkcije, temveč key-streching pristopi, katerih namen je otežit izdelavo mavričnih tabel, preko katerih bi lahko iz izvlečka izračunali prvotno sporočilo; tako onemogočimo napade s surovo silo.

Cmon, na wikipediji in še celo avtorja bcrypta (npr.) ga uvrščata v zgoščevalne funkcije. Seveda da spadajo v kategorijo zgoščevalnih funkcij, ker je sama definicija hash funkcij tako preprosta in široka.

Za potrebe OP-ja pa utegnejo biti tudi enosmerne zgoščevalne funkcije prepočasne, saj bi v naivnem primeru moral za detekcijo spremembe posamezne datoteke izračunati hash celotnega diska.

Taka implementacija IMO več ne bi spadala v izraz naivna metoda, ampak neumna metoda. :D
Tako to gre.

Zgodovina sprememb…

  • spremenil: galu ()

DavidJ ::

Delitev (uporabnih in neuporabnih) je lahko poljubno mnogo. Vidik varnosti zgoščevalne funkcije, ki se bi rabila za detekcijo sprememb na podatkih, je recimo čisto irelevanten.

Pri takih rešitvah želiš uporabit varno ezf, ker ne želiš imeti kolizij. Odsotnost kolizij (katero dobiš z uporabo varnih ezf) je namreč pomemben del zagotavljanja integritete. Če se lahko zgodi, da bo datoteka po spremembi imela enak hash, kot ga je imela pred spremembo, se sprememba ne bo zaznala. Git denimo uporablja SHA-1.

Enosmerne zgoščevalne funkcije morajo biti "učinkovite". To v teoriji pomeni, da se morajo izvesti vsaj v polinomskem času, v praksi pa "dovolj hitro".

precej poenostavljeno in tudi zavajajoče.

Lahko sicer dodaš še "na determinističnem Turingovem stroju", sicer pa je to del definicije ezf.

Cmon, na wikipediji in še celo avtorja bcrypta (npr.) ga uvrščata v zgoščevalne funkcije. Seveda da spadajo v kategorijo zgoščevalnih funkcij, ker je sama definicija hash funkcij tako preprosta in široka.

Da, drži: scrypt in bcrypt sta še vedno ezf, a imata dodatne lastnosti, zaradi katerih bi ju bilo v tem primeru neumno uporabiti. Sam sem svetoval uporabo varnih ezf: denimo SHA2+ ali Blake.
"Do, or do not. There is no 'try'. "
- Yoda ('The Empire Strikes Back')

Zgodovina sprememb…

  • spremenil: DavidJ ()

BigWhale ::

kunigunda je izjavil:

Mozno da je tko na windowsih, na linuxih se mtime direktorija spremeni sam ce dodas al zbrises fajl, ne pa vsebine.

bigwhale@thefish:~/11/22$ mkdir 33
bigwhale@thefish:~/11/22$ ls -l
drwxr-xr-x 2 bigwhale bigwhale 4096 dec 18 17:42 33
bigwhale@thefish:~/11/22$ cd 33
bigwhale@thefish:~/11/22/33$ vim a
bigwhale@thefish:~/11/22/33$ ls -l
-rw-r--r-- 1 bigwhale bigwhale 7 dec 18 17:42 a
bigwhale@thefish:~/11/22/33$ cd ..
bigwhale@thefish:~/11/22$ ls -l
drwxr-xr-x 2 bigwhale bigwhale 4096 dec 18 17:42 33
bigwhale@thefish:~/11/22$ cd 33/
bigwhale@thefish:~/11/22/33$ vim a
bigwhale@thefish:~/11/22/33$ ls -l
-rw-r--r-- 1 bigwhale bigwhale 13 dec 18 17:43 a
bigwhale@thefish:~/11/22/33$ cd ..
bigwhale@thefish:~/11/22$ ls -l
drwxr-xr-x 2 bigwhale bigwhale 4096 dec 18 17:43 33


Na EXT4 se spremeni timestamp direktorija, ce se v njem spremeni vsebina kaksne datoteke.

MrStein ::

MrStein je izjavil:

To se da narediti z dvema vrsticami skripte,

S pomočjo omenjenih sem jaz za podoben problem uporabil tole:

 (cd /original/korenska/mapa ;  find  -type f  -exec md5sum   {} + | tee  ~/tule_shranimo_hashe_za_pozneje.md5sums | ( cd /kopija/korenska/mapa ; md5sum --quiet  -c )  | tee ~/tule_shranimo_morebitne_razlike.check )

Za prvič se požene vse, pozneje pa se lahko primerja samo s shranjenimi MD5.

Namesto md5 se lahko uporabi tudi kaki drugi, recimo sha1sum ali sha256sum (tile imajo enako sintakso in se lahko direktno vstavijo v zgornjo skriptico, za druge pa treba morebiti kaj prilagoditi).

Torej v datoteki ~/tule_shranimo_morebitne_razlike.check bodo vpisane (in tudi na ekran) najdene razlike (po imenu fajlov).
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

kunigunda ::

BigWhale je izjavil:


Na EXT4 se spremeni timestamp direktorija, ce se v njem spremeni vsebina kaksne datoteke.


Poanta je, da se dela neodvisen APP od OS-a, polovico fajl sistemov tega ne dela

BigWhale ::

Tega ni blo v osnovnih specifikacijah. Evo, tipicen primer scope creep-a. :>

kunigunda ::

BigWhale je izjavil:

Tega ni blo v osnovnih specifikacijah. Evo, tipicen primer scope creep-a. :>

Saj se ne ve niti, na katerem OS op rabi :)

111111111111 ::

Na Windows NTFS. :) Sploh ne morem slediti še... Berem članke in reference in tole temo. Hvala za odlične nasvete in kar nadaljujte z debato, da si pridem na čisto kaj je sploh možno in kaj hočem v mojem primeru.

kunigunda ::

NTFS ne poznam v detajle, na FAT vem da direktorij ne spremeni modify timestampa se v slabsih primerih

krneki0001 ::

Tole preberi o NTFS, je kr dobro razloženo vse skupaj:
http://www.pcguide.com/ref/hdd/file/ntf...

Recimo tole je zelo zanimiv del NTFS:
The biggest part of NTFS file system security revolves around controlling access to different types of objects. Obviously, it is quite important to deal with security in the present: managing what users are doing and ensuring that access is correct for various files and folders. However, there's another important aspect to security that also deserves attention: keeping records of the past. There are many situations where it is essential for system administrators to be able to not only manage what security happenings are occurring immediately, but what they have been in recent days as well. To allow administrators and managers this capability, NTFS includes a feature called auditing.

When auditing is enabled, the system can be set to keep track of certain events. When any of these events occur, the system will make an entry in a special auditing log file that can be read by administrators or others with the appropriate permission level. Each entry will indicate the type of event, the date and time that it occurred, which user triggered the event, and other relevant information.

Auditing within NTFS is really just a small part of the various auditing features offered by the Windows NT and Windows 2000 operating systems. These tools allow administrators to keep track of everything from logins, to the use of printers, to system errors. Within NTFS, auditable events are generally accesses of various types, roughly corresponding to the different types of permissions. Auditing can be selected for files and for folders, and can be selected for individual objects or hierarchies of folders, just like permissions can.


Lahko bi že iz tega auditinga spremljal, če se je kaj spremenilo in imel na to postavljen trigger, da ti spremenjeno datoteko prenese še na drug disk. S tem ne rabiš potem nič računat, ker že sam sistem vse dela zate.

Zgodovina sprememb…

pegasus ::

Pred leti (10+) sem nekje videl tako rešitev, ki jo je nekdo implementiral za lokalno knjižnico. Iz vsakega fajla je naredil vsaj tri kopije in shranil njihove poti in hashe. Te je potem periodično preverjal in tako spotoma odkrival in popravljal bitrot. Stvar je bila napisana v javi.
Kasneje sem si za domače potrebe zadevo reimplementiral v bashu. Osnovna logika je nekaj 10 vrstic, nič posebnega, a ko se spraviš pokrivat vse robne pogoje, stvar eksplodira. Odsvetujem :)

MrStein ::

To lahko danes nastaviš v dveh vrsticah:
- use a modern FS (ki ima data hashing, recimo ZFS, ReFS, btrfs...)
- scrub
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

pegasus ::

Drži. A ideja iz tiste knjižnice je bila uporabit okrog ležeče stare pcje (recimo 486ke, pentiume in tak crap iz devetdesetih), podeseterit en file in vzdrževati zdravo večino preko lovljenja sprememb hasha, vse to v userspaceu. Ker tiste stare mašine niso sposobne furati današnjih kompleksnih fsjev.

Horejšio ::

Izumljate toplo vodo :)

kunigunda ::

Horejšio je izjavil:

Izumljate toplo vodo :)

On se pac hoce mal naucit, poleg tega bo lahko njegova voda bila plava :)


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Izračunana uspešna kolizija nad SHA-1

Oddelek: Novice / Varnost
188834 (6537) matijadmin
»

Kompresija s pomočjo /dev/random (strani: 1 2 )

Oddelek: Znanost in tehnologija
517198 (6673) BaToCarx
»

zgoščevalna funkcija

Oddelek: Programiranje
51317 (1148) misek
»

SHA1 hash - prevod

Oddelek: Programiranje
103911 (3568) darkolord
»

Nov preboj na področju zgoščevalnih funkcij

Oddelek: Novice / Znanost in tehnologija
153884 (3439) pecorin

Več podobnih tem