From kraken at fea.st Wed Mar 2 08:24:40 2016
From: kraken at fea.st (Kraken Skulls)
Date: Tue, 01 Mar 2016 23:24:40 -0800
Subject: [A51] a51 tables need seeders!
Message-ID: <1456903480.3469269.537067634.58B0CD3F@webmail.messagingengine.com>
Hi!
I wanted to attempt the DRIZZLECHAIR project so a week ago I began
downloading the A5/1 tables and got 800gb (halfway) but then the seeder
quit. Now there is just one (jetstream.xtra.co.nz) that doesn't transfer
at all. Could someone with the whole set please rejoin the torrent so I
can finish downloading? Or point me to a different torrent of the files?
Thank you in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From gurgalof at gmail.com Wed Mar 2 09:08:12 2016
From: gurgalof at gmail.com (=?UTF-8?Q?Andr=C3=A9as_Gustafsson?=)
Date: Wed, 2 Mar 2016 09:08:12 +0100
Subject: [A51] a51 tables need seeders!
In-Reply-To: <1456903480.3469269.537067634.58B0CD3F@webmail.messagingengine.com>
References: <1456903480.3469269.537067634.58B0CD3F@webmail.messagingengine.com>
Message-ID:
Hi,
I have them, I will start seeding when I can.
I can't promise a 24/7 seed but I will do my best.
On Mar 2, 2016 8:24 AM, "Kraken Skulls" wrote:
> Hi!
>
> I wanted to attempt the DRIZZLECHAIR project so a week ago I began
> downloading the A5/1 tables and got 800gb (halfway) but then the seeder
> quit. Now there is just one (jetstream.xtra.co.nz) that doesn't transfer
> at all. Could someone with the whole set please rejoin the torrent so I can
> finish downloading? Or point me to a different torrent of the files? Thank
> you in advance!
>
> _______________________________________________
> A51 mailing list
> A51 at lists.srlabs.de
> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nytspur at gmail.com Thu Mar 10 19:23:36 2016
From: nytspur at gmail.com (funny guy)
Date: Thu, 10 Mar 2016 23:53:36 +0530
Subject: [A51] For SALE: E16 FPGA from pico computing
Message-ID:
Hello list, I bought e16 FPGA for computational purposes but unfortunately
that project died, thus I have no use of these FPGAs, It is in brand new
condition.
If anyone interested, please let me know, I will send details and
everything else required.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From palm.wang at hotmail.com Fri Mar 11 03:46:21 2016
From: palm.wang at hotmail.com (wangpalm)
Date: Fri, 11 Mar 2016 10:46:21 +0800
Subject: [A51] GSMmap.org updated
In-Reply-To:
References:
Message-ID:
As mentioned in documents of GSMmap.org, known plaintexts preferred to use in A51 cracker are ciper mode complete message, NULL frames, and System Information message. However, these frames all has some uncertainties (positions, or possible modified bytes), which times the complexity of A51 cracker. Is there any method to judge if the chosen plaintext (containts and positon) is right before cracking it with Kraken? In other words, can we verify if the xored 114-bits is a possible(legal) output of A51 ciperstream?
> From: nohl at srlabs.de
> To: gsmmap at lists.srlabs.de; a51 at lists.srlabs.de
> Date: Tue, 2 Feb 2016 06:30:40 +0000
> Subject: [A51] GSMmap.org updated
>
> Dear Friends of Mobile Network Security,
>
> We are happy to announce an update of GSMmap: https://gsmmap.org/
>
> 1. New countries added
> - North Korea
> - Macedonia
> - Paraguay
> - Togo
> - Yemen
>
> 2. Many countries improved
> - Newly uploaded data integrated
> - More aggregation in countries with many MNC’s per network such as India and the USA
> - Disentangled networks that share a RAN (that is: use the same base stations) such as in Sweden and Norway
>
> Generally, the trend in almost all countries is positive. Slowly, we are seeing reasonable security being implemented.
>
> Thanks so much to everybody who contributed data! [1]
>
> Your -SRLabs mobile security team
>
>
> [1] You can contribute, too, from your Android phone: https://opensource.srlabs.de/projects/snoopsnitch
> _______________________________________________
> A51 mailing list
> A51 at lists.srlabs.de
> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From axilirator at gmail.com Sat Mar 12 20:12:14 2016
From: axilirator at gmail.com (=?UTF-8?B?0JLQsNC00LjQvCDQr9C90LjRhtC60LjQuQ==?=)
Date: Sun, 13 Mar 2016 01:12:14 +0600
Subject: [A51] Kraken segfault
Message-ID:
Hello all!
I just got a segmentation fault from Kraken.
I tested the last sequence one more time and got a segfault again.
Can anyone try to crack?
110110001011011101010010101011001001101010110100011000001011110101011001111101100000111110000110100010111011100100
С наилучшими пожеланиями,
Яницкий Вадим.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From fritchkornia at keemail.me Fri Mar 18 10:33:45 2016
From: fritchkornia at keemail.me (fritchkornia at keemail.me)
Date: Fri, 18 Mar 2016 09:33:45 +0000 (GMT)
Subject: [A51] Bit position , table structure and gpu in A51 tables
Message-ID:
Hi
I have a few questions regarding the A5/1 tables. I tought after a quick
reading that the plaintext equivalent of the tables was the LFSRs state
after 122 clocking and the output the 64 first bit of keystream (after 64
further clocking) with a simple reduction function output = new plaintext
However while testing there is a Bit position that poped up . Does it mean
that the compute function differ for each steps or is it just different in
each tables ?
IS there a simple guide to understand the table structure somehow .
Finally what is the purpose of the GPU when finding new KC ? Is it just for
the compute/reduction step ?
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jenda at yakumo.hrach.eu Fri Mar 18 11:39:46 2016
From: jenda at yakumo.hrach.eu (Jan Hrach)
Date: Fri, 18 Mar 2016 11:39:46 +0100
Subject: [A51] Bit position , table structure and gpu in A51 tables
In-Reply-To:
References:
Message-ID: <56EBDAF2.30500@yakumo.hrach.eu>
https://brmlab.cz/project/gsm/deka/attack-theory
https://brmlab.cz/project/gsm/deka/attack-implementation
> I tought after a quick reading that the plaintext equivalent of the tables was the LFSRs state after 122 clocking and the output the 64 first bit of keystream (after 64 further clocking) with a simple reduction function output = new plaintext
No, it's the last 64 bits of keystream after 99+64 clockings. The reduction functions are XORed constants generated using A5/1 itself (does anyone know if there is any special purpose in this, or if it is just convenient?)
See http://jenda.hrach.eu/gitweb/?p=deka;a=blob;f=genkernel32.sh;h=96ec2fc0a6b540101f6f6e8fa418c7b385b460d8;hb=HEAD for the actual chain computation (which is unfortunately a bit hard to read, as it is a hand-vectorized code).
> However while testing there is a Bit position that poped up . Does it mean that the compute function differ for each steps or is it just different in each tables ?
By bit position, you probably mean the offset if the 64bit sample in the 114bit burst.
> Finally what is the purpose of the GPU when finding new KC ? Is it just for the compute/reduction step ?
The chain is computed to the nearest endpoint on the GPU, then the corresponding startpoint is looked up on disk, and then the chain is reconstructed from that startpoint on the GPU again.
On 18.3.2016 10:33, fritchkornia at keemail.me wrote:
>
> Hi
>
> I have a few questions regarding the A5/1 tables. I tought after a quick reading that the plaintext equivalent of the tables was the LFSRs state after 122 clocking and the output the 64 first bit of keystream (after 64 further clocking) with a simple reduction function output = new plaintext
>
> However while testing there is a Bit position that poped up . Does it mean that the compute function differ for each steps or is it just different in each tables ?
>
> IS there a simple guide to understand the table structure somehow .
>
> Finally what is the purpose of the GPU when finding new KC ? Is it just for the compute/reduction step ?
>
>
> Best Regards
>
>
>
> _______________________________________________
> A51 mailing list
> A51 at lists.srlabs.de
> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
>
--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
From fritchkornia at keemail.me Fri Mar 18 15:31:44 2016
From: fritchkornia at keemail.me (fritchkornia at keemail.me)
Date: Fri, 18 Mar 2016 14:31:44 +0000 (GMT)
Subject: [A51] Bit position , table structure and gpu in A51 tables
In-Reply-To: <56EBDAF2.30500@yakumo.hrach.eu>
References: <>
<56EBDAF2.30500@yakumo.hrach.eu>
Message-ID:
If there is a "bit offset" this means that the "distinguish end point
computing" before disk lookup will be done in fact 51 times as 64 consecutive
bits can fit 51 times in 114bits ?
--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com
18. Mar 2016 11:39 by jenda at yakumo.hrach.eu:
> https://brmlab.cz/project/gsm/deka/attack-theory
> https://brmlab.cz/project/gsm/deka/attack-implementation
>
>> I tought after a quick reading that the plaintext equivalent of the
>> tables was the LFSRs state after 122 clocking and the output the 64 first
>> bit of keystream (after 64 further clocking) with a simple reduction
>> function output = new plaintext
>
> No, it's the last 64 bits of keystream after 99+64 clockings. The reduction
> functions are XORed constants generated using A5/1 itself (does anyone know
> if there is any special purpose in this, or if it is just convenient?)
>
> See >
> http://jenda.hrach.eu/gitweb/?p=deka;a=blob;f=genkernel32.sh;h=96ec2fc0a6b540101f6f6e8fa418c7b385b460d8;hb=HEAD>
> for the actual chain computation (which is unfortunately a bit hard to
> read, as it is a hand-vectorized code).
>
>> However while testing there is a Bit position that poped up . Does it mean
>> that the compute function differ for each steps or is it just different in
>> each tables ?
>
> By bit position, you probably mean the offset if the 64bit sample in the
> 114bit burst.
>
>> Finally what is the purpose of the GPU when finding new KC ? Is it just
>> for the compute/reduction step ?
>
> The chain is computed to the nearest endpoint on the GPU, then the
> corresponding startpoint is looked up on disk, and then the chain is
> reconstructed from that startpoint on the GPU again.
>
>
> On 18.3.2016 10:33, > fritchkornia at keemail.me> wrote:
>>
>> Hi
>>
>> I have a few questions regarding the A5/1 tables. I tought after a quick
>> reading that the plaintext equivalent of the tables was the LFSRs state
>> after 122 clocking and the output the 64 first bit of keystream (after 64
>> further clocking) with a simple reduction function output = new plaintext
>>
>> However while testing there is a Bit position that poped up . Does it mean
>> that the compute function differ for each steps or is it just different in
>> each tables ?
>>
>> IS there a simple guide to understand the table structure somehow .
>>
>> Finally what is the purpose of the GPU when finding new KC ? Is it just
>> for the compute/reduction step ?
>>
>>
>> Best Regards
>>
>>
>>
>> _______________________________________________
>> A51 mailing list
>> A51 at lists.srlabs.de
>> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
>>
>
>
> --
> Jan Hrach | > http://jenda.hrach.eu
> GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jenda at yakumo.hrach.eu Fri Mar 18 15:48:24 2016
From: jenda at yakumo.hrach.eu (Jan Hrach)
Date: Fri, 18 Mar 2016 15:48:24 +0100
Subject: [A51] Bit position , table structure and gpu in A51 tables
In-Reply-To:
References: <
<56EBDAF2.30500@yakumo.hrach.eu>
Message-ID: <56EC1538.7030005@yakumo.hrach.eu>
Yes.
(actually, it's done 16320 times -- 51 samples * 8 colors * 40 rainbow tables)
On 18.3.2016 15:31, fritchkornia at keemail.me wrote:
>
> If there is a "bit offset" this means that the "distinguish end point computing" before disk lookup will be done in fact 51 times as 64 consecutive bits can fit 51 times in 114bits ?
> --
> Securely sent with Tutanota. Claim your encrypted mailbox today!
> https://tutanota.com
>
> 18. Mar 2016 11:39 by jenda at yakumo.hrach.eu :
>
> https://brmlab.cz/project/gsm/deka/attack-theory
> https://brmlab.cz/project/gsm/deka/attack-implementation
>
> I tought after a quick reading that the plaintext equivalent of the tables was the LFSRs state after 122 clocking and the output the 64 first bit of keystream (after 64 further clocking) with a simple reduction function output = new plaintext
>
>
> No, it's the last 64 bits of keystream after 99+64 clockings. The reduction functions are XORed constants generated using A5/1 itself (does anyone know if there is any special purpose in this, or if it is just convenient?)
>
> See http://jenda.hrach.eu/gitweb/?p=deka;a=blob;f=genkernel32.sh;h=96ec2fc0a6b540101f6f6e8fa418c7b385b460d8;hb=HEAD for the actual chain computation (which is unfortunately a bit hard to read, as it is a hand-vectorized code).
>
> However while testing there is a Bit position that poped up . Does it mean that the compute function differ for each steps or is it just different in each tables ?
>
>
> By bit position, you probably mean the offset if the 64bit sample in the 114bit burst.
>
> Finally what is the purpose of the GPU when finding new KC ? Is it just for the compute/reduction step ?
>
>
> The chain is computed to the nearest endpoint on the GPU, then the corresponding startpoint is looked up on disk, and then the chain is reconstructed from that startpoint on the GPU again.
>
>
> On 18.3.2016 10:33, fritchkornia at keemail.me wrote:
>
>
> Hi
>
> I have a few questions regarding the A5/1 tables. I tought after a quick reading that the plaintext equivalent of the tables was the LFSRs state after 122 clocking and the output the 64 first bit of keystream (after 64 further clocking) with a simple reduction function output = new plaintext
>
> However while testing there is a Bit position that poped up . Does it mean that the compute function differ for each steps or is it just different in each tables ?
>
> IS there a simple guide to understand the table structure somehow .
>
> Finally what is the purpose of the GPU when finding new KC ? Is it just for the compute/reduction step ?
>
>
> Best Regards
>
>
>
> _______________________________________________
> A51 mailing list
> A51 at lists.srlabs.de
> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
>
>
>
> --
> Jan Hrach | http://jenda.hrach.eu
> GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
>
--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
From fritchkornia at keemail.me Fri Mar 18 16:32:03 2016
From: fritchkornia at keemail.me (fritchkornia at keemail.me)
Date: Fri, 18 Mar 2016 15:32:03 +0000 (GMT)
Subject: [A51] Bit position , table structure and gpu in A51 tables
In-Reply-To: <56EC1538.7030005@yakumo.hrach.eu>
References: <>
<56EBDAF2.30500@yakumo.hrach.eu>
<> <56EC1538.7030005@yakumo.hrach.eu>
Message-ID:
First of all , big thanks :) Those informations are hard to get for people
trying to cover the inner working / structure of those tables. Hope it will
help further people as well.
Regarding this calculation : 51 samples * 8 colors * 40 rainbow tables
Why the * 40 multiplications ? i tought that it was just one big tables
splitted in 40 files based on the non zero values of the "distinguish end
point" used for raw device indexing.
Does it means that the colors for same columns positions are differents in
each tables ?
Btw, why choosing 8 colors and what it the max chain length ?
Best Regards
18. Mar 2016 15:48 by jenda at yakumo.hrach.eu:
> Yes.
>
> (actually, it's done 16320 times -- 51 samples * 8 colors * 40 rainbow
> tables)
>
> On 18.3.2016 15:31, > fritchkornia at keemail.me> wrote:
>>
>> If there is a "bit offset" this means that the "distinguish end point
>> computing" before disk lookup will be done in fact 51 times as 64
>> consecutive bits can fit 51 times in 114bits ?
>> --
>> Securely sent with Tutanota. Claim your encrypted mailbox today!
>> https://tutanota.com
>>
>> 18. Mar 2016 11:39 by >> jenda at yakumo.hrach.eu>> <>>
>> mailto:jenda at yakumo.hrach.eu>> >:
>>
>> >> https://brmlab.cz/project/gsm/deka/attack-theory
>> >> https://brmlab.cz/project/gsm/deka/attack-implementation
>>
>> I tought after a quick reading that the plaintext equivalent of
>> the tables was the LFSRs state after 122 clocking and the output the 64
>> first bit of keystream (after 64 further clocking) with a simple reduction
>> function output = new plaintext
>>
>>
>> No, it's the last 64 bits of keystream after 99+64 clockings. The
>> reduction functions are XORed constants generated using A5/1 itself (does
>> anyone know if there is any special purpose in this, or if it is just
>> convenient?)
>>
>> See >>
>> http://jenda.hrach.eu/gitweb/?p=deka;a=blob;f=genkernel32.sh;h=96ec2fc0a6b540101f6f6e8fa418c7b385b460d8;hb=HEAD>>
>> for the actual chain computation (which is unfortunately a bit hard to
>> read, as it is a hand-vectorized code).
>>
>> However while testing there is a Bit position that poped up . Does
>> it mean that the compute function differ for each steps or is it just
>> different in each tables ?
>>
>>
>> By bit position, you probably mean the offset if the 64bit sample in
>> the 114bit burst.
>>
>> Finally what is the purpose of the GPU when finding new KC ? Is it
>> just for the compute/reduction step ?
>>
>>
>> The chain is computed to the nearest endpoint on the GPU, then the
>> corresponding startpoint is looked up on disk, and then the chain is
>> reconstructed from that startpoint on the GPU again.
>>
>>
>> On 18.3.2016 10:33, >> fritchkornia at keemail.me>> <>>
>> mailto:fritchkornia at keemail.me>> > wrote:
>>
>>
>> Hi
>>
>> I have a few questions regarding the A5/1 tables. I tought after a
>> quick reading that the plaintext equivalent of the tables was the LFSRs
>> state after 122 clocking and the output the 64 first bit of keystream
>> (after 64 further clocking) with a simple reduction function output = new
>> plaintext
>>
>> However while testing there is a Bit position that poped up . Does
>> it mean that the compute function differ for each steps or is it just
>> different in each tables ?
>>
>> IS there a simple guide to understand the table structure somehow
>> .
>>
>> Finally what is the purpose of the GPU when finding new KC ? Is it
>> just for the compute/reduction step ?
>>
>>
>> Best Regards
>>
>>
>>
>> _______________________________________________
>> A51 mailing list
>> >> A51 at lists.srlabs.de>> <>> mailto:A51 at lists.srlabs.de>> >
>> >> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
>>
>>
>>
>> --
>> Jan Hrach | >> http://jenda.hrach.eu>> <>> http://jenda.hrach.eu>> >
>> GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
>>
>
> --
> Jan Hrach | > http://jenda.hrach.eu
> GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jenda at yakumo.hrach.eu Fri Mar 18 17:59:04 2016
From: jenda at yakumo.hrach.eu (Jan Hrach)
Date: Fri, 18 Mar 2016 17:59:04 +0100
Subject: [A51] Bit position , table structure and gpu in A51 tables
In-Reply-To:
References: <
<56EBDAF2.30500@yakumo.hrach.eu>
< <56EC1538.7030005@yakumo.hrach.eu>
Message-ID: <56EC33D8.1090208@yakumo.hrach.eu>
> Why the * 40 multiplications ? i tought that it was just one big tables splitted in 40 files based on the non zero values of the "distinguish end point" used for raw device indexing.
No, these are completely independent tables (e.g. with independent reduction functions).
> Btw, why choosing 8 colors and what it the max chain length ?
There used to be XLS from Karsten Nohl where they computed optimal parameters. I have uploaded a copy here: http://jenda.hrach.eu/brm/kraken_magic/Rainbow.Tables.xls
The max chain length is not limited, it is only probabilistically distributed. The expected length is 2**12, as the distinguished point has 12 bits zero.
On 18.3.2016 16:32, fritchkornia at keemail.me wrote:
> First of all , big thanks :) Those informations are hard to get for people trying to cover the inner working / structure of those tables. Hope it will help further people as well.
>
> Regarding this calculation : 51 samples * 8 colors * 40 rainbow tables
>
> Why the * 40 multiplications ? i tought that it was just one big tables splitted in 40 files based on the non zero values of the "distinguish end point" used for raw device indexing.
>
> Does it means that the colors for same columns positions are differents in each tables ?
>
> Btw, why choosing 8 colors and what it the max chain length ?
>
> Best Regards
>
>
> 18. Mar 2016 15:48 by jenda at yakumo.hrach.eu :
>
> Yes.
>
> (actually, it's done 16320 times -- 51 samples * 8 colors * 40 rainbow tables)
>
> On 18.3.2016 15:31, fritchkornia at keemail.me wrote:
>
>
> If there is a "bit offset" this means that the "distinguish end point computing" before disk lookup will be done in fact 51 times as 64 consecutive bits can fit 51 times in 114bits ?
> --
> Securely sent with Tutanota. Claim your encrypted mailbox today!
> https://tutanota.com
>
> 18. Mar 2016 11:39 by jenda at yakumo.hrach.eu >:
>
> https://brmlab.cz/project/gsm/deka/attack-theory
> https://brmlab.cz/project/gsm/deka/attack-implementation
>
> I tought after a quick reading that the plaintext equivalent of the tables was the LFSRs state after 122 clocking and the output the 64 first bit of keystream (after 64 further clocking) with a simple reduction function output = new plaintext
>
>
> No, it's the last 64 bits of keystream after 99+64 clockings. The reduction functions are XORed constants generated using A5/1 itself (does anyone know if there is any special purpose in this, or if it is just convenient?)
>
> See http://jenda.hrach.eu/gitweb/?p=deka;a=blob;f=genkernel32.sh;h=96ec2fc0a6b540101f6f6e8fa418c7b385b460d8;hb=HEAD for the actual chain computation (which is unfortunately a bit hard to read, as it is a hand-vectorized code).
>
> However while testing there is a Bit position that poped up . Does it mean that the compute function differ for each steps or is it just different in each tables ?
>
>
> By bit position, you probably mean the offset if the 64bit sample in the 114bit burst.
>
> Finally what is the purpose of the GPU when finding new KC ? Is it just for the compute/reduction step ?
>
>
> The chain is computed to the nearest endpoint on the GPU, then the corresponding startpoint is looked up on disk, and then the chain is reconstructed from that startpoint on the GPU again.
>
>
> On 18.3.2016 10:33, fritchkornia at keemail.me > wrote:
>
>
> Hi
>
> I have a few questions regarding the A5/1 tables. I tought after a quick reading that the plaintext equivalent of the tables was the LFSRs state after 122 clocking and the output the 64 first bit of keystream (after 64 further clocking) with a simple reduction function output = new plaintext
>
> However while testing there is a Bit position that poped up . Does it mean that the compute function differ for each steps or is it just different in each tables ?
>
> IS there a simple guide to understand the table structure somehow .
>
> Finally what is the purpose of the GPU when finding new KC ? Is it just for the compute/reduction step ?
>
>
> Best Regards
>
>
>
> _______________________________________________
> A51 mailing list
> A51 at lists.srlabs.de >
> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
>
>
>
> --
> Jan Hrach | http://jenda.hrach.eu >
> GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
>
>
> --
> Jan Hrach | http://jenda.hrach.eu
> GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
>
--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
From kraken at fea.st Sun Mar 20 23:34:34 2016
From: kraken at fea.st (Kraken Skulls)
Date: Sun, 20 Mar 2016 15:34:34 -0700
Subject: [A51] help, kraken index file corrupt
Message-ID: <1458513274.900286.554665626.22D36D29@webmail.messagingengine.com>
Hello all,
I managed to get all the rainbow tables downloaded, thanks to anyone who
helped seed! Now I am trying to convert the tables, but I've hit a snag.
I am following this guide[1]. I ran Behemoth.py successfully and
everything seemed great. The problem is when I run
./kraken /mnt/drizzlechair/kraken/indexes
I get this output:
Device: /dev/sde2 40
/dev/sde2
Allocated 41404056 bytes: /mnt/drizzlechair/kraken/indexes/132.idx
Allocated 41257176 bytes: /mnt/drizzlechair/kraken/indexes/388.idx
Allocated 41259888 bytes: /mnt/drizzlechair/kraken/indexes/324.idx
Allocated 41252956 bytes: /mnt/drizzlechair/kraken/indexes/172.idx
Allocated 41269576 bytes: /mnt/drizzlechair/kraken/indexes/140.idx
Allocated 41237644 bytes: /mnt/drizzlechair/kraken/indexes/148.idx
Allocated 41301076 bytes: /mnt/drizzlechair/kraken/indexes/260.idx
Allocated 41254252 bytes: /mnt/drizzlechair/kraken/indexes/412.idx
Allocated 41247488 bytes: /mnt/drizzlechair/kraken/indexes/116.idx
Allocated 41235184 bytes: /mnt/drizzlechair/kraken/indexes/180.idx
Allocated 41247816 bytes: /mnt/drizzlechair/kraken/indexes/420.idx
Allocated 41249180 bytes: /mnt/drizzlechair/kraken/indexes/156.idx
Allocated 41260184 bytes: /mnt/drizzlechair/kraken/indexes/428.idx
Allocated 41257064 bytes: /mnt/drizzlechair/kraken/indexes/108.idx
index file corrupt: /mnt/drizzlechair/kraken/indexes/108.idx
So I tried Step 6 (you dun goof'ed!) to retry building the index. I
deleted 108.idx and added a # in front of the table in tables.conf, and
reran Behemoth.py. It rebuilt 108.idx with no errors. But again, I got
an error about 108 being corrupt when I ran kraken. I have verified the
downloaded torrent table. I am using the kraken code from the github[2].
I have searched for any pages with this error message and am currently
reviewing the archive of this mailing list. Any suggestions about what I
should try? Here is the code that is throwing the error. It seems like
maybe the index is outside the acceptable bounds? Thanks for any help!
https://github.com/joswr1ght/kraken/blob/master/Kraken/DeltaLookup.cpp
line 71:
if (offset >= 0x7fffffff || offset <=-0x7fffffff) {
fprintf(stderr,"index file corrupt: %s\n", index.c_str());
exit(1);
}
Here is my tables.conf
#Tables: dev id(advance) offset
Table: 0 132 388867252
Table: 0 428 102322209
Table: 0 388 81857880
Table: 0 140 10231686
Table: 0 148 153500680
Table: 0 196 112557295
Table: 0 260 225118679
Table: 0 156 40934817
Table: 0 364 0
Table: 0 292 358165185
Table: 0 220 61396028
Table: 0 412 133036633
Table: 0 436 71623787
Table: 0 172 296767964
Table: 0 500 30701322
# here is table 108, very big number
Table: 0 108 409366910
Table: 0 180 399138026
Table: 0 372 245596133
Table: 0 188 276299072
Table: 0 100 51167172
Table: 0 164 143270246
Table: 0 324 378632240
Table: 0 396 214888429
Table: 0 204 92092220
Table: 0 340 194423848
Table: 0 420 163730175
Table: 0 348 337697417
Table: 0 356 184192134
Table: 0 230 307001257
Table: 0 380 122788190
Table: 0 404 204656170
Table: 0 492 317235622
Table: 0 238 173962193
Table: 0 116 327465481
Table: 0 212 266065701
Table: 0 268 20469102
Table: 0 332 235363908
Table: 0 276 286538884
Table: 0 250 255825440
Table: 0 124 347926544
[1] http://frostyhacks.blogspot.com/2015/04/gsm-wtf-bbq.html
[2] https://github.com/joswr1ght/kraken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: