My new Biss Server plans

B

BLACKCRUSADER

Senior Member
Messages
1,995
I have decided to build another biss server so I will have two.
Redundency is always nice.

Nvidia GeForce RTX 3080 Ti with Core configuration:
10,240 CUDA cores (80 SMs)

AMD Zen 3 CPU 64gb RAM

ASUS ROG STRIX Z590-F GAMING/WIFI motherboard/ LGA1200 11th generation/ DDR4 Intel 2.5G network Four M.2 slots with heat sink
PCIe 4.0 / USB 3.2 Gen 2

Two Sabrent 4TB Rocket 4 Plus NVMe 4.0 Gen4 PCIe M.2 Internal SSD Extreme Performance Solid State Drive R/W 7200/6600MB/s (SB-RKT4P-4TB)
One for V1 and one for V2

A 1TB Samsung M2 SSD for Windows OS

With a 10240 Cuda biss Cores and 7200mb/s read speed should be able to get a crypt and CW pretty quick, maybe 20 seconds total time. :D:D
 
C

campag5242

Feed Hunter
Messages
2,585
That's bordering on insane, spending so much money to shave a pitiful few 10's of seconds off a v1 B8h search. There again, so is investing countless hours getting even better results from far inferior hardware :hammer:.

If that rig landed on my desktop it'd be dedicated to making chains or brute force, where it would save days instead of seconds.
 
B

BLACKCRUSADER

Senior Member
Messages
1,995
campag5242 said:
That's bordering on insane, spending so much money to shave a pitiful few 10's of seconds off a v1 B8h search. There again, so is investing countless hours getting even better results from far inferior hardware :hammer:.

If that rig landed on my desktop it'd be dedicated to making chains or brute force, where it would save days instead of seconds.
Click to expand...

I can always do both. Or I can play games on it :)

It will do some brute force as well :)

Also there are four M2 slots so I could slip in four x 4TB cards and then RAID V1 and V2 for even faster speeds :)
 
Last edited:
C

campag5242

Feed Hunter
Messages
2,585
For even faster speeds, you should pick up a book on programming in C, then cuda. No amount of $ spent on hardware will match the gains spent on smarter software in this application. This is old software you are using: Colibri hasn't updated it since 2014, that's seven years!

Here's how my PC (i7-6700 / 8GB / GTX1070TI / SATA3 SSD) fares with Colibri V1.23, on a v1 08h search, crypt8 E7 D8 AB 61 9C 4A B9 E6, table 08hx000300h:

Code: 
Search CW Start
RBT file: D:\08hx000300h_table4\CSA_08hx000300h_10000h.rbt
Calc all 10000h end values for this crypt ... (using file cache)
Search end values in RBT ...
Searching CW in RBT ...
Found 61949 possible chains (harddisk only search time = 260 sec.)
Analysing chains ... (will be 10 times slower if an other thread is keeping the GPU busy)
found CW: 5E XX XX XX XX XX XX B6 
Search CW done (279 sec.)

Said useless 08hx000300h table resides on a slower SSD here. But same PC, different software, 3 years of learning applied:
Code: 
wini7@DESKTOP-6LFTMK0:~/libdvbcsa$ rbtv1-08 000300 E7 D8 AB 61 9C 4A B9 E6
Using table D:\08hx000300h_table4\CSA_08hx000300h_10000h.rbt, 8.2 billion chains. End6 range 000000019660h-FFFFFFFF9C7Bh.
Searching rainbow table for C8: E7 D8 AB 61 9C 4A B9 E6, range 1000h links per round.
0.7s: 1000h end6 values calculated in 0.15s, commencing disk search 0000h-0FFFh

1.6s: 7547 chains found. Rebuild using 1 grids @ 30 x 256 threads needed for max link 0FFFh:
2.3s: 6981 chains found. Rebuild using 2 grids @ 28 x 256 threads needed for max link 1FFEh:
3.1s: 6201 chains found. Rebuild using 3 grids @ 25 x 256 threads needed for max link 2FFFh:
3.9s: 6076 chains found. Rebuild using 4 grids @ 24 x 256 threads needed for max link 3FFFh:
4.7s: 5743 chains found. Rebuild using 5 grids @ 23 x 256 threads needed for max link 4FFFh:
5.5s: 5284 chains found. Rebuild using 6 grids @ 21 x 256 threads needed for max link 5FFEh:
6.3s: 4608 chains found. Rebuild using 7 grids @ 18 x 256 threads needed for max link 6FFFh:
7.0s: 4120 chains found. Rebuild using 8 grids @ 17 x 256 threads needed for max link 7FFEh:
7.7s: 3542 chains found. Rebuild using 9 grids @ 14 x 256 threads needed for max link 8FFDh:
8.5s: 3113 chains found. Rebuild using 10 grids @ 13 x 256 threads needed for max link 9FF8h:
9.1s: 2724 chains found. Rebuild using 11 grids @ 11 x 256 threads needed for max link AFFFh:
9.8s: 2143 chains found. Rebuild using 12 grids @ 9 x 256 threads needed for max link BFFCh:
10.4s: 1676 chains found. Rebuild using 13 grids @ 7 x 256 threads needed for max link CFFBh:
RBTv1 kernel 08hx000300h hit using CW: 5E 1B 50 C9 89 CD 60 B6 @ link C7BAh
RBTv1 kernel 08hx000300h hit using CW: 5E 1B 50 C9 89 CD 60 B6 @ link C7BAh
RBTv1 kernel 08hx000300h hit using CW: 5E 1B 50 C9 89 CD 60 B6 @ link C7BAh
RBTv1 kernel 08hx000300h hit using CW: 5E 1B 50 C9 89 CD 60 B6 @ link C7BAh
RBTv1 kernel 08hx000300h hit using CW: 5E 1B 50 C9 89 CD 60 B6 @ link C7BAh
RBTv1 kernel 08hx000300h hit using CW: 5E 1B 50 C9 89 CD 60 B6 @ link C7BAh

Found CW: 5E XX XX XX XX XX XX B6  Mean search time: 179us, seeks: 3.77 End6 hits: 25841 / 54784

61440 end6s calculated in 1.4s, 60200 chains found in 10.2s, 59758 chains rebuilt in 1.0s. Total 10.5s
Luck was not on my side in this example... had it been, the CW would have been found in a little over 1.6 seconds. Being generous, I'm calling that a 26 fold improvement.

There are HUGE gains to be made over the public tools which don't involve ridiculous hardware upgrades eg time to identify the crypt8: "ermm... this seems like a high count, maybe try a search?" vs "100% nailed on, tagged ASAP in cyphertext, automatic RBT search"... done.
 
C

cayoenrique

Member
Messages
475
@BLACKCRUSADER & campag5242
If you like the hobby, and most important, If you have the $$$ ( God bless you for that ), UHH please use all available resources at you hand to feed your needs. Lets us know once you purchase what was the end results.

@campag5242
I found disturbing the speed
campag5242 said:
...61440 end6s calculated in 1.4s, 60200 chains found in 10.2s, 59758 chains rebuilt in 1.0s. Total 10.5s
Click to expand...

Let me rephrace.
You claim to use a GTX1070TI. That seems to have 2432 Stream Processor (CUDA Cores)(clock rate at 1998MHz)

And from output you claim to make "61440 end6s calculated in 1.4s" Thats strange. Now I never worked personally with "08hx000300h" may be there is something there I have not study.

... Ahhh I see now
"...0.7s: 1000h end6 values calculated in 0.15s"

You are comparing an old V1 type 10000h end6 values against 1000h end6 values. That is not a fair comparison. Still extrapolating (0.15s x 16 =) 2.4 seconds for a 10000h end6 is kind of too fast for your GPU model. I know I have very old machine and my PCI Express speed may be a bottle neck. Buy I see 2.4 seconds to fast, Something is wrong here.

Now regards searching using multi threading is understandable faster. And if performed the same look up for second time, well the cache of the disk and PC make it look faster that what it really is the 1rst time.
 
Last edited:
C

C0der

Registered
Messages
267
Note that this example is about 08h tables, not b8h.
That is not 23 but just 1 round, which is about 10 times faster.
The disk read is the same tho.
 
C

campag5242

Feed Hunter
Messages
2,585
Yes COder, 08h chosen to highlight the main area the public tools are weak: the disk search. No GPU upgrade is going to fix that.

@cayoenrique, yes repeating the search would show huge gains from disk caches, but I was careful to avoid that. And my search does not follow the same seek path through the file as the public tool, hence the speed difference.
 
C

cayoenrique

Member
Messages
475
@campag5242 Let me start by saying I agree with you 100% on tools are old and never upgraded. So I do expect quite an improve on any mod you have made.

I got no issue with improve, but numbers where out of the scale. Now I see, from coder responce "That is not 23 but just 1 round" I can now extrapolate and see an average on 10000h end6 values of

(0.15s x 16 x 23)= 55.2 seconds for a 10000h end6 or if by ten
(0.15s x 16 x 10)= 24.2 seconds
witch is some where I expect for V1 table search. I know V2 search is faster. But the initial comparative was with V1.

Thanks C0der for the clarification 10 to 23. exact numbers are of no importance.

Now it is funny you seems to have made improve on the search seek. As you seems to mention indirectly multi-threading search. But then insinuate "the disk search, No GPU upgrade is going to fix that." True no GPU... But as you said changing HHD for SSD make a huge difference. What about using USB Flash? Or what about instead of 1 storage device use multiple, and multiple search threads. Or even better just buy Huge amount of FAST RAM. Or Run Search threads on multiple(Different) PC.

I had run test. Just using one 0x00 and one 0xFF V1 table. Table had been shrink to about 300 Mgb by removing none essential characters. This only help with size as I do have to search same or all amount of possibilities in the tables. I use 2 threads on two different USB Flash memories (* See no SDD ) on USB2 ports ( yes slow). And I reduce search time to about 3.5 minutes on 1 table v1.

Please note that the 2 search treads, start reporting found end tables, after 30 seconds. So second GPU time is neglected as it gets hidden by search on Flash memories.

1rst 10000 end values still takes about 30 seconds to complete on a 1792 stream processors @ 900 mghz. In conclusion. Doing search using 1 table V1 with no SDD on 4 minutes average for executive search ( NOT FOUND CW ). But If CW is found on 1rst Search Thread report it takes about 1 minute or so. Table size just about 300GB that includes 0x00 and 0XFF.



In conclusion I am 100% with you, it can be improve.
 
Last edited:
B

BLACKCRUSADER

Senior Member
Messages
1,995
campag5242 said:
For even faster speeds, you should pick up a book on programming in C, then cuda. No amount of $ spent on hardware will match the gains spent on smarter software in this application. This is old software you are using: Colibri hasn't updated it since 2014, that's seven years!

Here's how my PC (i7-6700 / 8GB / GTX1070TI / SATA3 SSD) fares with Colibri V1.23, on a v1 08h search, crypt8 E7 D8 AB 61 9C 4A B9 E6, table 08hx000300h:

Code: 
Search CW Start
RBT file: D:\08hx000300h_table4\CSA_08hx000300h_10000h.rbt
Calc all 10000h end values for this crypt ... (using file cache)
Search end values in RBT ...
Searching CW in RBT ...
[B][I]Found 61949 possible chains (harddisk only search time = 260 sec.)[/I][/B]
[/quote]

Here's my scan time...  Samsung EVO 4TB SSD with 3.6TB of data and my RGB table is 319 GB

Searching ...
Using payload size: 184
Time for searching Crypt8 = 3 sec.
Search CW Start
RBT file: D:\Biss V1 file\B8hx030000H\B8hx030000h_table1\CSA_B8hx030000h_10000h.rbt
Calc all 10000h end values for this crypt ... (using file cache)
Search end values in RBT ...
Searching CW in RBT ...
[B][I]Found 133973 possible chains (harddisk only search time = 105 sec.)[/I][/B]

Now imagine my V1 on an M2 SSD 4TB Sabrent with a read of 7100mb/s  easily 12 times faster perhaps :)  Would only need 8 seconds to scan the chains tables hehehehe
Click to expand...
 
Last edited:
C

cayoenrique

Member
Messages
475
BLACKCRUSADER

Nice info. 105 sec about 1 minute on search. That is nice.

Now I will have to look a the devices you mention to see if we can find the good data. See read @ 7100mb/s means nothing in the search time. What is more important is the seek & response time. There is a name for that, I do not recalled it now. So unless new device is capable to do those seek faster It will not matters. Please take a note of what I am saying.

Then I bet you using Windows. And Windows and all the apps you run have a tendency of doing Search them self on the disk!! Those mother f**** will still many of your seek making your search slower. So better start disabling all those unneeded services before you begin those 8 sec search!. So it will be smart to better use a very bare bone Linux Core and your own search program.

Anyway as I said let us know your final results. Personally I have no money to invest on state of the art hardware. I will be waiting your future comments.

A quick look did not show he item I was trying to remember. But take a look at:

_https://en.wikipedia.org/wiki/Solid-state_drive#Hard_disk_drives

And search for "Random access performance" best I could find.

SSD technology can deliver rather consistent read/write speed, but when many individual smaller blocks are accessed, performance is reduced.
Click to expand...


I think you need to look for Random read IOPS

see

_https://en.wikipedia.org/wiki/IOPS
 
Last edited:
B

BLACKCRUSADER

Senior Member
Messages
1,995
cayoenrique said:
BLACKCRUSADER

Nice info. 105 sec about 1 minute on search. That is nice.

Then I bet you using Windows. And Windows and all the apps you run have a tendency of doing Search them self on the disk!!
Click to expand...

Thanks for the tips. BTW yes I run Windows 7 Pro with no other apps on the except the satellite card to catch the stream. SO my windows is not loaded with other programs.

Legacy software you might find it better sometimes. Also there is a difference between home and pro systems.

:)
 
C

campag5242

Feed Hunter
Messages
2,585
BLACKCRUSADER said:
Here's my scan time... Samsung EVO 4TB SSD with 3.6TB of data and my RGB table is 319 GB

Found 133973 possible chains (harddisk only search time = 105 sec.)

Now imagine my V1 on an M2 SSD 4TB Sabrent with a read of 7100mb/s easily 12 times faster perhaps :) Would only need 8 seconds to scan the chains tables hehehehe
Click to expand...
No that table is not 319GB, it's more like 200GB. If it were 319GB there'd be > 200,000 chains reported as being found.

As cayoenrique has said, RBT disk performance is about seek time time / random small reads, not continuous / sustained transfers. Go to https://www.userbenchmark.com/ and compare results for Random 4k reads for existing & proposed SSD to see what factor speedup you might obtain.
 
C

campag5242

Feed Hunter
Messages
2,585
cayoenrique said:
@campag5242 Let me start by saying I agree with you 100% on tools are old and never upgraded. So I do expect quite an improve on any mod you have made.

I got no issue with improve, but numbers where out of the scale. Now I see, from coder responce "That is not 23 but just 1 round" I can now extrapolate and see an average on 10000h end6 values of

(0.15s x 16 x 23)= 55.2 seconds for a 10000h end6 or if by ten
(0.15s x 16 x 10)= 24.2 seconds
witch is some where I expect for V1 table search. I know V2 search is faster. But the initial comparative was with V1.

Thanks C0der for the clarification 10 to 23. exact numbers are of no importance.

Now it is funny you seems to have made improve on the search seek. As you seems to mention indirectly multi-threading search. But then insinuate "the disk search, No GPU upgrade is going to fix that." True no GPU... But as you said changing HHD for SSD make a huge difference. What about using USB Flash? Or what about instead of 1 storage device use multiple, and multiple search threads. Or even better just buy Huge amount of FAST RAM. Or Run Search threads on multiple(Different) PC.

I had run test. Just using one 0x00 and one 0xFF V1 table. Table had been shrink to about 300 Mgb by removing none essential characters. This only help with size as I do have to search same or all amount of possibilities in the tables. I use 2 threads on two different USB Flash memories (* See no SDD ) on USB2 ports ( yes slow). And I reduce search time to about 3.5 minutes on 1 table v1.

Please note that the 2 search treads, start reporting found end tables, after 30 seconds. So second GPU time is neglected as it gets hidden by search on Flash memories.

1rst 10000 end values still takes about 30 seconds to complete on a 1792 stream processors @ 900 mghz. In conclusion. Doing search using 1 table V1 with no SDD on 4 minutes average for executive search ( NOT FOUND CW ). But If CW is found on 1rst Search Thread report it takes about 1 minute or so. Table size just about 300GB that includes 0x00 and 0XFF.



In conclusion I am 100% with you, it can be improve.
Click to expand...

Yes 23 rounds vs 1 for B8h vs 08h, but both have an extra initial step "key expansion" which takes around the same time as one round, so the comparison is more like 24:2 or 12:1, or approximately the same as C0der's rule of thumb "10x"

Calc all end6 time on 1070ti was about 11.5s if I recall, but now I choose to do it in slices, & with less efficiency. Doing the search in slices is best (as you seem to be doing).

Search of my biggest v1 table, 900GB 08hxFFh held on HDD, takes around 8 minutes here for a failed search - or about 2-3x what the public tool does on SSD on my system, but for a much smaller file.

SSD on USB adapter is about half speed vs motherboard SATA port.

Hints to improve your search cyroenrique: remember, we are not doing one search, but 65,536 of them. (don't think threading, think that these are sequential searches... ). And try to keep everything busy, both CPU & GPU, at every stage of every slice.
 
J

jenseneverest

Registered
Messages
178
i didn't even know they made M2 drives that big, then i saw the price i now realise why i didn't know :eek: lol
Looks like im going to struggle with the public tools and my tiny 2gb graphics card, still downloading the tables.... day 9


I may be missing the obvious here, but what is the need to do things any faster ? The key is normally found before the event starts anyways ??
Or are those nearly always from known CW's ?
 
C

campag5242

Feed Hunter
Messages
2,585
@jenseneverest if it's the Rv2 tables you are downloading, your tiny 2GB GPU won't be so bad: even a strong CPU can cope with the workload of a v2 search on HDD.

You are right, there is no good reason for the key to be found any faster, other than to be the first to post. And it certainly does not warrant massive expenditure to gain a few 10s of seconds. Speed is useful if you have to do speculative searches.. better to know you have the correct crypt8 before even getting your GPU warm.

For me it's just an interesting hobby, chasing as much performance as I can. Tiny gains in GPU RBT search code translate to minutes or hours on GPU brute force code, the core algorithm is the same (albeit BC crypt for RBT, BC & SC decrypt for brute force)
 
C

cayoenrique

Member
Messages
475
@jenseneverest

There are people wanting to find a real-time or on-the-fly brute-force so that they can watch anything they like without any special procedure. As a temporary objective they want to reach speed less than 10 seconds per brute force. For a one hacker ( no group like in biss team ) with normal resources ( 1 PC + 1GPU), this will not be reach any time soon. But it is nice to see people like BLACKCRUSADER doing their best to get close to that objective.

In the other hand be smart. If you find a method, do not publish it. It will hurt us all. As new more secure method will be put in place in few month. So it may means no TV for anyone.

But you guys can report speed you reach with your new hardware. And how you are approaching this goal.
 
Last edited:
B

BLACKCRUSADER

Senior Member
Messages
1,995
People do not concern yourself with how much my planned server setup would cost. It's my money to spend. I do it because I can. It will be interesting to see the performance of such a system.

It will either be a great bruteforce machine or a great gaming machine. :D
 
You must log in or register to reply here.
Top