Behemoth (or, more precisely, TableConvert, which is the program that it calls) 
created .idx (the block index) and .ins (the table data); the ins can be stored 
on a raw block device to reduce filesystem overhead (usually multiple .ins are 
stored on one block device, simply one after another, the same way as if you 
would do "cat *.ins > /dev/sdb").

In tables.conf, you then point Kraken to both idx and ins (.ins is there as 
file:offset, where file might be a block device, as you can just open(2) a 
block device the same way as a file on unix).

So the important thing is that you don't point Kraken to idx and dlt, but to 
idx and ins.

See https://brmlab.cz/project/gsm/deka/deka-admin#installing_tables for info on 
how to use TableConvert


On 04. 01. 19 12:59, norah67 wrote:
> Hi,
> Thanks for your reply.
> I had downloaded 40 dlt files from 
> https://drive.google.com/drive/folders/0B-8F5I-fE6lFQk1HY1pTWGJyM3M and then 
> converted them to idx files using Behemoth.py script without mounting the sdb 
> drive with unknown file system(raw). Whether this sdb drive has to formatted 
> as ext4? I am not able to understand my which step went wrong. Can you please 
> suggest something that can help me in troubleshooting.
> 
> 
> 
> 
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, January 4, 2019 4:45 PM, Jan Hrach <[email protected]> wrote:
> 
>> I think you stumbled upon the problem where the "Found" message is printed, 
>> the formatting string is wrong and it prints it garbled (Fragment.cpp, ^F 
>> Found).
>>
>> The "Found" should be a 64-bit hexadecimal number and bitpos should be 
>> between 0 and (114-63), so certainly this is wrong.
>>
>> The # value is the job number -- the same reference which kraken tells you 
>> when you submit a job ("cracking 0101010101XXX #123").
>>
>> See https://brmlab.cz/project/gsm/deka/deka-test for some test vectors from 
>> the Berlin table set.
>>
>> On 04. 01. 19 9:48, norah67 wrote:
>>
>>> I am facing problem in using find_kc tool to get kc from kraken result. 
>>> I got the following result -
>>>                                                                             
>>>                                  XOR data                                   
>>>                                                                        
>>> Modified GSM frame number
>>>
>>> 1.  
>>> 011100010011000010010111110001010110111000111111101100000010010101101000100111001101111010110111110001011111100011
>>>          -     445455
>>>
>>> 2.  
>>> 011011111011001010111001011011001010100100110110110101111000001110000010110010111010010000101110101111110100100100
>>>        -      445488
>>>        Result of kraken - Found 0000002730576953x @ -1444020227  #18  
>>> (table:1)
>>>
>>> 3.  
>>> 111101111111011100000011111001000110110101111111000100000100010011101000111101001110010110111101001000111101011110
>>>          -    445521
>>>
>>>
>>> 4. 
>>> 010000011010110000111110110000011110000011101011000011001110110010111100011110000010011111110011000001001101000001
>>>           -  445554
>>>
>>> 5.  
>>> 101011010100000100011101010001010000011100110111111011110110011011001001100000001101001001000110010000000000100110
>>>        -     445442
>>>
>>> 6.  
>>> 011100011100111001111010110110011011000001100101011100111011011101010010110011010011111110110011110111010110011000
>>>        -      445475
>>>
>>> 7.  
>>> 011010100001100110111000000001101110101010111110101010000100010011010110001000010100100110011011111011110010010001
>>>      -        445508
>>>        Result of kraken - Found 0000004007151928x @ 142048478  #26  
>>> (table:0)
>>>
>>> 8.  
>>> 010000011010110000111110110000011110000011101011000011001110110010111100011110000010011111110011000001001101000001
>>>          -    445541
>>>
>>>
>>> When I am giving the kraken result to find_kc, I am not getting desired 
>>> results. When I provide 142048478 or -1444020227 as bitpos , find_kc tool 
>>> dosen't work at all. Moreover I want to know what is the significance of 
>>> value after # in kraken result.
>>> Thanks
>>>
>>> A51 mailing list
>>> [email protected]
>>> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
>>
>> --
>>
>> Jan Hrach | https://jenda.hrach.eu/
>> GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
>>
>> A51 mailing list
>> [email protected]
>> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
> 
> 
> 


-- 
Jan Hrach | https://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
_______________________________________________
A51 mailing list
[email protected]
https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51

Reply via email to