mboost-dp1
Kunsten at knække et password
#57
Men du kan godt finde en SHA-256 til ældre PHP.
Google finder bl.a. http://nanolink.ca/pub/sha256/sha256.txt
Men du kan godt finde en SHA-256 til ældre PHP.
Google finder bl.a. http://nanolink.ca/pub/sha256/sha256.txt
#56: Ja, en sådan liste ville nok være svær at have liggende hjemme hos en privatperson og det er nok også svært at få den hostet ude i byen på grund af det formål den er lavet med.
#58: Okay, super... Men var det muligt at compile din java kode til noget jeg kunne køre i en consol uden noget kendskab til java? Jeg tror umiddelbart at java i en consol vil performe lidt bedre end php...
#58: Okay, super... Men var det muligt at compile din java kode til noget jeg kunne køre i en consol uden noget kendskab til java? Jeg tror umiddelbart at java i en consol vil performe lidt bedre end php...
#61
Hvis du erstatter:
med:
Hvis du erstatter:
private static void printHash(String pw) {
System.out.println(pw + " -> " + toHex(md.digest(pw.getBytes())));
}
med:
private static void printHash(String pw) {
if(toHex(md.digest(pw.getBytes())).equals("bla bla bla")) {
System.out.println(pw);
System.exit(0);
}
}
#62: Okay, cool... Det skal da lige prøves :)
Forresten, når du snakker om at det skal optimeres, er det så sådan noget med at det skal køre threaded så det kan udnytte quad-cpu'er og sådan?
For sådan noget som det her, må da være rimelig enkelt at dele ud over flere cpu'er, så hver cpu bare får en range af de karakterer der skal køres igennem?
Forresten, når du snakker om at det skal optimeres, er det så sådan noget med at det skal køre threaded så det kan udnytte quad-cpu'er og sådan?
For sådan noget som det her, må da være rimelig enkelt at dele ud over flere cpu'er, så hver cpu bare får en range af de karakterer der skal køres igennem?
#63
Jeg optimerede lige lidt for find:
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Arrays;
public class HashFinder {
private static MessageDigest md;
private static byte[] target;
public static void main(String[] args) throws NoSuchAlgorithmException {
md = MessageDigest.getInstance("SHA-256");
// Demo : find zzzz blandt små bogstaver og tal
target = md.digest("zzzzz".getBytes());
checkAllHash("abcdefghijklmnopqrstuwvxyz0123456789");
}
public static void checkAllHash(String valid) {
int i = 1;
while(true) {
System.out.println("Checking all passwords of length " + i);
checkAllHash(valid.getBytes(), new byte[i], 0);
i++;
}
}
public static void checkAllHash(byte[] valid, byte[] buf, int ix) {
if(ix < buf.length) {
for(int i = 0; i < valid.length; i++) {
buf[ix] = valid[i];
checkAllHash(valid, buf, ix + 1);
}
} else {
checkHash(buf);
}
}
private static void checkHash(byte[] pw) {
if(Arrays.equals(md.digest(pw), target)) {
System.out.println("Found match: " + new String(pw));
System.exit(0);
}
}
}
finder "zzzzz" blandt kombinationer af små bogstaver og tal på ca. 60 sekunder.
25*36*36*36*36 / 60 = 700000 per sekund
En quad core bør kunne nå langt over 1 million så.
Jeg optimerede lige lidt for find:
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Arrays;
public class HashFinder {
private static MessageDigest md;
private static byte[] target;
public static void main(String[] args) throws NoSuchAlgorithmException {
md = MessageDigest.getInstance("SHA-256");
// Demo : find zzzz blandt små bogstaver og tal
target = md.digest("zzzzz".getBytes());
checkAllHash("abcdefghijklmnopqrstuwvxyz0123456789");
}
public static void checkAllHash(String valid) {
int i = 1;
while(true) {
System.out.println("Checking all passwords of length " + i);
checkAllHash(valid.getBytes(), new byte[i], 0);
i++;
}
}
public static void checkAllHash(byte[] valid, byte[] buf, int ix) {
if(ix < buf.length) {
for(int i = 0; i < valid.length; i++) {
buf[ix] = valid[i];
checkAllHash(valid, buf, ix + 1);
}
} else {
checkHash(buf);
}
}
private static void checkHash(byte[] pw) {
if(Arrays.equals(md.digest(pw), target)) {
System.out.println("Found match: " + new String(pw));
System.exit(0);
}
}
}
finder "zzzzz" blandt kombinationer af små bogstaver og tal på ca. 60 sekunder.
25*36*36*36*36 / 60 = 700000 per sekund
En quad core bør kunne nå langt over 1 million så.
#67 & 68
Hvis der skal udnyttes multi core så skal koden jo laves multithreaded.
Det troede jeg var nemt, men det var faktisk lidt sværere end som så - bl.a. fordi MessageDigest klassen ikke er thread safe.
Jeg endte op med følgende:
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Arrays;
public class HashFinderMT {
private int nthr;
private byte[] valid;
private boolean done;
public HashFinderMT(int nthr, String valid) {
this.nthr = nthr;
this.valid = valid.getBytes();
done = false;
}
public void findHash(byte[] target) throws NoSuchAlgorithmException {
int len = 1;
while(!done) {
System.out.println("Checking all passwords of length " + len);
findHash(target, len);
len++;
}
}
public void findHash(byte[] target, int len) throws NoSuchAlgorithmException {
Thread[] t = new FinderThread[nthr];
int[] split = new int[nthr + 1];
for(int i = 0; i <= nthr; i++) {
split[i] = valid.length * i / nthr;
}
for(int i = 0; i < nthr; i++) {
t[i] = new FinderThread(split[i], split[i + 1] - 1, this, len, target);
}
for(int i = 0; i < nthr; i++) {
t[i].start();
}
for(int i = 0; i < nthr; i++) {
try {
t[i].join();
} catch (InterruptedException e) {
}
}
}
public byte[] getValid() {
return valid;
}
public boolean getDone() {
return done;
}
public void setDone(boolean done) {
this.done = done;
}
public static void main(String[] args) throws NoSuchAlgorithmException {
// Demo : find zzzzz blandt små bogstaver og tal
HashFinderMT hfmt = new HashFinderMT(4, "abcdefghijklmnopqrstuwvxyz0123456789");
hfmt.findHash(MessageDigest.getInstance("SHA-256").digest("zzzzz".getBytes()));
}
}
class FinderThread extends Thread {
private MessageDigest md;
private int start;
private int end;
private HashFinderMT hfmt;
private byte[] buf;
byte[] target;
byte[] valid;
public FinderThread(int start, int end, HashFinderMT hfmt, int len, byte[] target) throws NoSuchAlgorithmException {
md = MessageDigest.getInstance("SHA-256");
this.start = start;
this.end = end;
this.hfmt = hfmt;
buf = new byte[len];
this.target = target;
valid = hfmt.getValid();
}
public void run() {
for(int i = start; i <= end; i++) {
buf[0] = valid[i];
checkAllHash(buf, 1);
}
}
public void checkAllHash(byte[] buf, int ix) {
if(hfmt.getDone()) return;
if(ix < buf.length) {
for(int i = 0; i < valid.length; i++) {
buf[ix] = valid[i];
checkAllHash(buf, ix + 1);
}
} else {
checkHash(buf);
}
}
public void checkHash(byte[] pw) {
if(Arrays.equals(md.digest(pw), target)) {
System.out.println("Found match: " + new String(pw));
hfmt.setDone(true);
}
}
}
men jeg ved faktisk ikke om det virker som det skal fordi jeg har ikke en multi core CPU.
Hvis der skal udnyttes multi core så skal koden jo laves multithreaded.
Det troede jeg var nemt, men det var faktisk lidt sværere end som så - bl.a. fordi MessageDigest klassen ikke er thread safe.
Jeg endte op med følgende:
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Arrays;
public class HashFinderMT {
private int nthr;
private byte[] valid;
private boolean done;
public HashFinderMT(int nthr, String valid) {
this.nthr = nthr;
this.valid = valid.getBytes();
done = false;
}
public void findHash(byte[] target) throws NoSuchAlgorithmException {
int len = 1;
while(!done) {
System.out.println("Checking all passwords of length " + len);
findHash(target, len);
len++;
}
}
public void findHash(byte[] target, int len) throws NoSuchAlgorithmException {
Thread[] t = new FinderThread[nthr];
int[] split = new int[nthr + 1];
for(int i = 0; i <= nthr; i++) {
split[i] = valid.length * i / nthr;
}
for(int i = 0; i < nthr; i++) {
t[i] = new FinderThread(split[i], split[i + 1] - 1, this, len, target);
}
for(int i = 0; i < nthr; i++) {
t[i].start();
}
for(int i = 0; i < nthr; i++) {
try {
t[i].join();
} catch (InterruptedException e) {
}
}
}
public byte[] getValid() {
return valid;
}
public boolean getDone() {
return done;
}
public void setDone(boolean done) {
this.done = done;
}
public static void main(String[] args) throws NoSuchAlgorithmException {
// Demo : find zzzzz blandt små bogstaver og tal
HashFinderMT hfmt = new HashFinderMT(4, "abcdefghijklmnopqrstuwvxyz0123456789");
hfmt.findHash(MessageDigest.getInstance("SHA-256").digest("zzzzz".getBytes()));
}
}
class FinderThread extends Thread {
private MessageDigest md;
private int start;
private int end;
private HashFinderMT hfmt;
private byte[] buf;
byte[] target;
byte[] valid;
public FinderThread(int start, int end, HashFinderMT hfmt, int len, byte[] target) throws NoSuchAlgorithmException {
md = MessageDigest.getInstance("SHA-256");
this.start = start;
this.end = end;
this.hfmt = hfmt;
buf = new byte[len];
this.target = target;
valid = hfmt.getValid();
}
public void run() {
for(int i = start; i <= end; i++) {
buf[0] = valid[i];
checkAllHash(buf, 1);
}
}
public void checkAllHash(byte[] buf, int ix) {
if(hfmt.getDone()) return;
if(ix < buf.length) {
for(int i = 0; i < valid.length; i++) {
buf[ix] = valid[i];
checkAllHash(buf, ix + 1);
}
} else {
checkHash(buf);
}
}
public void checkHash(byte[] pw) {
if(Arrays.equals(md.digest(pw), target)) {
System.out.println("Found match: " + new String(pw));
hfmt.setDone(true);
}
}
}
men jeg ved faktisk ikke om det virker som det skal fordi jeg har ikke en multi core CPU.
#72
Virker fint, bruger næsten 200% CPU på min dualcore. :)
Konceptet i at udnytte sådan et bæst er heldigvis ret simpelt: Bare fordel belastningen i flere tråde (eller processer...), (og sørg for at de ikke venter på hinanden), så skal det nok gå.
(Men det vidste du nok godt.)
Men for dem der ikke er Java-hajer:
newz.dk laver lidt fuckup i det:
skal være
Virker fint, bruger næsten 200% CPU på min dualcore. :)
Konceptet i at udnytte sådan et bæst er heldigvis ret simpelt: Bare fordel belastningen i flere tråde (eller processer...), (og sørg for at de ikke venter på hinanden), så skal det nok gå.
(Men det vidste du nok godt.)
Men for dem der ikke er Java-hajer:
newz.dk laver lidt fuckup i det:
getInstance("SHA-256&quo
t;)
skal være
getInstance("SHA-256")
Er jeg den eneste der tænker, hvorfor sådan noget ikke er krypteret med RSA? Krypter hele lortet, smid den private nøgle op på en random gmail (det bliver alligevel aldrig slettet og chancen for at de finder [email protected] er utroligt lille.) og slet den fra computerne/serveren, så den kun findes på gmailen, hvor den bliver hentet hver gang den skal bruges. Og hvis vi skal være helt sikre, så krypterer vi også den.
Self. skal niveauet være omkring 256 bits, måske endda højere, men pointen er, at TGG, eller andre (måske lige med undtagelse af NSA, meeen de har ikke så meget med sagen at gøre ;) ), ikke har computerkraften til at knække passwordet.
For de u-indviede, så benytter RSA sig af primfaktorisering, hvilket vil sige at man gange to enorme primtal sammen, hvorefter man så finder deres faktorer (de to primtal tal de er blevet ganget med). Det tager ikke ret mange sekunder, at vælge 2 primtal, men jeg siger bare stakkels gut, der skal prøve at finde de rette faktorer.
Self. skal niveauet være omkring 256 bits, måske endda højere, men pointen er, at TGG, eller andre (måske lige med undtagelse af NSA, meeen de har ikke så meget med sagen at gøre ;) ), ikke har computerkraften til at knække passwordet.
For de u-indviede, så benytter RSA sig af primfaktorisering, hvilket vil sige at man gange to enorme primtal sammen, hvorefter man så finder deres faktorer (de to primtal tal de er blevet ganget med). Det tager ikke ret mange sekunder, at vælge 2 primtal, men jeg siger bare stakkels gut, der skal prøve at finde de rette faktorer.
#76
Ja det tror jeg at du er den eneste som undrer dig over.
Problem stillingen man vil beskytte sig mod er når både kode og database er kompromiteret.
Da RSA i modsætning til hash er en reversibel algoritme, så vil det være en sikkerhedsmæssig katastrofe.
Og for de uindviede: så er RSA 256 bit totalt usikkert. Man anbefaler 2048 bit idag. Man kan ikke sammenligne bits i en hash algoritme og bits i en private-public key algoritme.
Ja det tror jeg at du er den eneste som undrer dig over.
Problem stillingen man vil beskytte sig mod er når både kode og database er kompromiteret.
Da RSA i modsætning til hash er en reversibel algoritme, så vil det være en sikkerhedsmæssig katastrofe.
Og for de uindviede: så er RSA 256 bit totalt usikkert. Man anbefaler 2048 bit idag. Man kan ikke sammenligne bits i en hash algoritme og bits i en private-public key algoritme.
Er RSA grunden til at det vil være en mindre katastrofe for computer kryptering hvis vi på et tidspunkt fik bevist matematisk hvordan primtal opstår?
I dag findes der jo ikke anden udvej end at prøve sig frem om der er andre tal end 1 og tallet selv der går op i det.
Men er det på grund af RSA eller er det noget mere generelt i computer kryptering?
I dag findes der jo ikke anden udvej end at prøve sig frem om der er andre tal end 1 og tallet selv der går op i det.
Men er det på grund af RSA eller er det noget mere generelt i computer kryptering?
#78
Det matematiske problem i RSA er faktorisering.
Hvis der blev fundet en mere effektiv metode til det så ville sikkerheden i RSA blive reduceret.
Der er andre private-public key algoritmer. DSA bruger også et eller andet med prim tal. Men ELGamel bruger et eller andet med diskrete logaritmer.
Og hvis jeg lyder lidt wishy-washy med hensyn til det matematiske, så er det korrekt - matematikken bag den her slags ligger over hvad jeg forstår.
Det matematiske problem i RSA er faktorisering.
Hvis der blev fundet en mere effektiv metode til det så ville sikkerheden i RSA blive reduceret.
Der er andre private-public key algoritmer. DSA bruger også et eller andet med prim tal. Men ELGamel bruger et eller andet med diskrete logaritmer.
Og hvis jeg lyder lidt wishy-washy med hensyn til det matematiske, så er det korrekt - matematikken bag den her slags ligger over hvad jeg forstår.
Jeg har fundet en SHA-256 brute force cracker som er skrevet i VB.NET:
http://khsw.blogspot.com/2005/01/sha256-brute-forc...
Jeg ved ikke rigtig hvordan det der med at lave en hash værdi fungerer, men det må vel tage længere og længere tid jo længere text-strengen som hash-værdien skal generes ud fra bliver?
Kombinationer som den tjekker pr. sekund falder i hvert fald hele tiden (programmet viser et gennemsnit over hele forløbet).
Efter 35.000.000 prøvede kombinationer (kun tal og bogstaver) har jeg kørt med en hastighed på 52.000 kombinationer pr. sekund. Jeg vil prøve og lede lidt videre efter andre crackere og se om jeg kan finde en der er kodet mere effektivt, men det ser ud som om vi skal nedjustere hastigheden en del fra de 1.000.000 vi regnede med i starten af denne tråd :)
Er der andre gider gider prøve at se hvor mange kombinationer pr. sekund man kan presse ud af programmet?
http://khsw.blogspot.com/2005/01/sha256-brute-forc...
Jeg ved ikke rigtig hvordan det der med at lave en hash værdi fungerer, men det må vel tage længere og længere tid jo længere text-strengen som hash-værdien skal generes ud fra bliver?
Kombinationer som den tjekker pr. sekund falder i hvert fald hele tiden (programmet viser et gennemsnit over hele forløbet).
Efter 35.000.000 prøvede kombinationer (kun tal og bogstaver) har jeg kørt med en hastighed på 52.000 kombinationer pr. sekund. Jeg vil prøve og lede lidt videre efter andre crackere og se om jeg kan finde en der er kodet mere effektivt, men det ser ud som om vi skal nedjustere hastigheden en del fra de 1.000.000 vi regnede med i starten af denne tråd :)
Er der andre gider gider prøve at se hvor mange kombinationer pr. sekund man kan presse ud af programmet?
#85
Hvis du prøver den sidste Java version på en multi core CPU, så er 1 million ikke umuligt.
Ja tiden må stige lidt med længden af teksten. Men ikke ret meget sammenlignet med hvor mange flere kombinationer der kommer. Længden bør ikke være et issue i forbindelse med password. Hasher man DVD ISO'er, så betyder længden nok noget.
Hvis du prøver den sidste Java version på en multi core CPU, så er 1 million ikke umuligt.
Ja tiden må stige lidt med længden af teksten. Men ikke ret meget sammenlignet med hvor mange flere kombinationer der kommer. Længden bør ikke være et issue i forbindelse med password. Hasher man DVD ISO'er, så betyder længden nok noget.
#87: Altså den sidste version du har skrevet her i tråden? Jeg vil nok sige jeg bliver imponeret hvis den er 20 gange hurtigere, men det kan være jeg undervurderer java og dine evner som kodehaj :)
Men okay, den jeg linkede til er fra januar 2005, så der er nok sket lidt med kode sprog siden dengang :)
Men okay, den jeg linkede til er fra januar 2005, så der er nok sket lidt med kode sprog siden dengang :)
#90: Jeg tror ikke det er skrevet til 2 kerner. Jeg kan heller ikke få den til det på min Core 2 Duo. Men det er også lavet i januar 2005 hvor dual core ikke var særlig almindeligt blandt private.
Selv nu er det jo langt fra alle programmer der bliver lavet til at køre på 2 kerner.
Jeg har indtil nu kørt 201.000.000 kombinationer på 1 time 17 minutter hvilket giver 43.655 pr. sekund...
Selv nu er det jo langt fra alle programmer der bliver lavet til at køre på 2 kerner.
Jeg har indtil nu kørt 201.000.000 kombinationer på 1 time 17 minutter hvilket giver 43.655 pr. sekund...
#89
Der er lavet adskillige forsøg som viser at der kan genereres kollisioner med MD5.
http://en.wikipedia.org/wiki/MD5#Vulnerability
De 128 bit er ikke nok.
Det gør MD5 ubrugeligt til fil checksum.
Det gør ikke nødvendigvis MD5 ubrugeligt til password, fordi der er
visse retsriktioner på password.
Men ingen har lyst til at bruge MD5 længere.
SHA-1 er der tilsvarende problemer med.
SHA-256 skulle være sikker. Bit størrelsen skulle beskytte mod de såkaldte birthday attacks.
Der er lavet adskillige forsøg som viser at der kan genereres kollisioner med MD5.
http://en.wikipedia.org/wiki/MD5#Vulnerability
De 128 bit er ikke nok.
Det gør MD5 ubrugeligt til fil checksum.
Det gør ikke nødvendigvis MD5 ubrugeligt til password, fordi der er
visse retsriktioner på password.
Men ingen har lyst til at bruge MD5 længere.
SHA-1 er der tilsvarende problemer med.
SHA-256 skulle være sikker. Bit størrelsen skulle beskytte mod de såkaldte birthday attacks.
Med list print:
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Arrays;
public class HashFinderMT {
private int nthr;
private byte[] valid;
private boolean done;
public HashFinderMT(int nthr, String valid) {
this.nthr = nthr;
this.valid = valid.getBytes();
done = false;
}
public void findHash(byte[] target) throws NoSuchAlgorithmException {
int len = 1;
while(!done) {
System.out.println("Checking all passwords of length " + len);
long t1 = System.currentTimeMillis();
findHash(target, len);
long t2 = System.currentTimeMillis();
if(!done) System.out.println((long)Math.pow(valid.length, len)*1000/(t2 - t1 + 1) + " checks per second");
len++;
}
}
public void findHash(byte[] target, int len) throws NoSuchAlgorithmException {
Thread[] t = new FinderThread[nthr];
int[] split = new int[nthr + 1];
for(int i = 0; i <= nthr; i++) {
split[i] = valid.length * i / nthr;
}
for(int i = 0; i < nthr; i++) {
t[i] = new FinderThread(split[i], split[i + 1] - 1, this, len, target);
}
for(int i = 0; i < nthr; i++) {
t[i].start();
}
for(int i = 0; i < nthr; i++) {
try {
t[i].join();
} catch (InterruptedException e) {
}
}
}
public byte[] getValid() {
return valid;
}
public boolean getDone() {
return done;
}
public void setDone(boolean done) {
this.done = done;
}
public static void main(String[] args) throws NoSuchAlgorithmException {
// Demo : find zzzzz blandt små bogstaver og tal
HashFinderMT hfmt = new HashFinderMT(4, "abcdefghijklmnopqrstuwvxyz0123456789");
hfmt.findHash(MessageDigest.getInstance("SHA-256").digest("zzzzzzzzzz".getBytes()));
}
}
class FinderThread extends Thread {
private MessageDigest md;
private int start;
private int end;
private HashFinderMT hfmt;
private byte[] buf;
byte[] target;
byte[] valid;
public FinderThread(int start, int end, HashFinderMT hfmt, int len, byte[] target) throws NoSuchAlgorithmException {
md = MessageDigest.getInstance("SHA-256");
this.start = start;
this.end = end;
this.hfmt = hfmt;
buf = new byte[len];
this.target = target;
valid = hfmt.getValid();
}
public void run() {
for(int i = start; i <= end; i++) {
buf[0] = valid[i];
checkAllHash(buf, 1);
}
}
public void checkAllHash(byte[] buf, int ix) {
if(hfmt.getDone()) return;
if(ix < buf.length) {
for(int i = 0; i < valid.length; i++) {
buf[ix] = valid[i];
checkAllHash(buf, ix + 1);
}
} else {
checkHash(buf);
}
}
public void checkHash(byte[] pw) {
if(Arrays.equals(md.digest(pw), target)) {
System.out.println("Found match: " + new String(pw));
hfmt.setDone(true);
}
}
}
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Arrays;
public class HashFinderMT {
private int nthr;
private byte[] valid;
private boolean done;
public HashFinderMT(int nthr, String valid) {
this.nthr = nthr;
this.valid = valid.getBytes();
done = false;
}
public void findHash(byte[] target) throws NoSuchAlgorithmException {
int len = 1;
while(!done) {
System.out.println("Checking all passwords of length " + len);
long t1 = System.currentTimeMillis();
findHash(target, len);
long t2 = System.currentTimeMillis();
if(!done) System.out.println((long)Math.pow(valid.length, len)*1000/(t2 - t1 + 1) + " checks per second");
len++;
}
}
public void findHash(byte[] target, int len) throws NoSuchAlgorithmException {
Thread[] t = new FinderThread[nthr];
int[] split = new int[nthr + 1];
for(int i = 0; i <= nthr; i++) {
split[i] = valid.length * i / nthr;
}
for(int i = 0; i < nthr; i++) {
t[i] = new FinderThread(split[i], split[i + 1] - 1, this, len, target);
}
for(int i = 0; i < nthr; i++) {
t[i].start();
}
for(int i = 0; i < nthr; i++) {
try {
t[i].join();
} catch (InterruptedException e) {
}
}
}
public byte[] getValid() {
return valid;
}
public boolean getDone() {
return done;
}
public void setDone(boolean done) {
this.done = done;
}
public static void main(String[] args) throws NoSuchAlgorithmException {
// Demo : find zzzzz blandt små bogstaver og tal
HashFinderMT hfmt = new HashFinderMT(4, "abcdefghijklmnopqrstuwvxyz0123456789");
hfmt.findHash(MessageDigest.getInstance("SHA-256").digest("zzzzzzzzzz".getBytes()));
}
}
class FinderThread extends Thread {
private MessageDigest md;
private int start;
private int end;
private HashFinderMT hfmt;
private byte[] buf;
byte[] target;
byte[] valid;
public FinderThread(int start, int end, HashFinderMT hfmt, int len, byte[] target) throws NoSuchAlgorithmException {
md = MessageDigest.getInstance("SHA-256");
this.start = start;
this.end = end;
this.hfmt = hfmt;
buf = new byte[len];
this.target = target;
valid = hfmt.getValid();
}
public void run() {
for(int i = start; i <= end; i++) {
buf[0] = valid[i];
checkAllHash(buf, 1);
}
}
public void checkAllHash(byte[] buf, int ix) {
if(hfmt.getDone()) return;
if(ix < buf.length) {
for(int i = 0; i < valid.length; i++) {
buf[ix] = valid[i];
checkAllHash(buf, ix + 1);
}
} else {
checkHash(buf);
}
}
public void checkHash(byte[] pw) {
if(Arrays.equals(md.digest(pw), target)) {
System.out.println("Found match: " + new String(pw));
hfmt.setDone(true);
}
}
}
Og på min gamle P4:
C:\>java -server HashFinderMT
Checking all passwords of length 1
36000 checks per second
Checking all passwords of length 2
16405 checks per second
Checking all passwords of length 3
269687 checks per second
Checking all passwords of length 4
772947 checks per second
Checking all passwords of length 5
778160 checks per second
Checking all passwords of length 6
771955 checks per second
Checking all passwords of length 7
CTRL/C
En C2D eller C2Q bør kunne klare sig meget bedre.
Husk nyeste Java og brug -server !
C:\>java -server HashFinderMT
Checking all passwords of length 1
36000 checks per second
Checking all passwords of length 2
16405 checks per second
Checking all passwords of length 3
269687 checks per second
Checking all passwords of length 4
772947 checks per second
Checking all passwords of length 5
778160 checks per second
Checking all passwords of length 6
771955 checks per second
Checking all passwords of length 7
CTRL/C
En C2D eller C2Q bør kunne klare sig meget bedre.
Husk nyeste Java og brug -server !
#96
Java kode er forholdsvis 32/64 bit agnostic. Hvis du kører programmet i en 64 bit JVM så kører det 64 bit og det er op til JVM'en at udnytte addresse space (og nye instruktioner i x86-64). Jeg forventer ikke den store forskel på 32 bit og 64 bit performance, men jeg ved det ikke.
Hvis du har en 64 bit x86 og evt. har SUN Java i både 32 og 64 bit version, så kan du jo prøve om der er en forskel.
Java kode er forholdsvis 32/64 bit agnostic. Hvis du kører programmet i en 64 bit JVM så kører det 64 bit og det er op til JVM'en at udnytte addresse space (og nye instruktioner i x86-64). Jeg forventer ikke den store forskel på 32 bit og 64 bit performance, men jeg ved det ikke.
Hvis du har en 64 bit x86 og evt. har SUN Java i både 32 og 64 bit version, så kan du jo prøve om der er en forskel.
Forresten, alt det jeg lavede tilbage i #26.... Er det det der er en rainbow table?
#26 skrev:62^8: 218.340.105.584.896 muligheder.
Hver mulighed indeholder 8 karaktere eller 8 bytes om man vil.
Det giver: 1.746.720.844.679.170 bytes
Til hver mulighed vil tabellen også indeholder den dertilhørende hash-værdi som er på 32 tegn eller bytes: 6.986.883.378.716.670 bytes
Tilsammen giver dette: 8.733.604.223.395.840 bytes.
Afrundet giver det:
8.733.604.223.395.840/1024/1024/1024/1024 = 7943 terabytes
#98
Nej. Ikke helt.
En rainbow tabel kan finde alle hashes men gemmer kun nogle af dem.
http://en.wikipedia.org/wiki/Rainbow_table
Nej. Ikke helt.
En rainbow tabel kan finde alle hashes men gemmer kun nogle af dem.
http://en.wikipedia.org/wiki/Rainbow_table
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund