RBT tool's cache

I did explained why it will not work,

http://www.sat-universe.com/showpost.php?p=2036895858&postcount=813

I will try to explain as I do to my kids.

Imagine you have scissor and/or a Electric Trimming Machine. Both Cut hair. But can you use the plastic adapters of the Electric Trimming Machine on the scissor? Clearly not.

ZinnetiG said:

Hi, first of all, sorry if I'll go astray
I love RBT tool and I was thinking:
How long will it take to create the biggest cache possible?
Is it possible to do it?
Is there anybody capable to create a specific tool to do that?
How long will be the search then?
What about integrate the cache to DVB player to decrypt B*SS?

Thanks :thum:

Click to expand...

Your cache for one plain would take up more disk space than all your tables combined, it's totally impractical.

Martin.Wigston said:

Your cache for one plain would take up more disk space than all your tables combined, it's totally impractical.

Click to expand...

I disagree with you

ZinnetiG said:

Is there anybody capable to create a specific tool to do that?

Click to expand...

Hi ZinnetiG, thanks for good idea :thum:

on our forum no one will help you in this matter, here everyone keeps everything in secret, then I can explain - I many times asked to share the created new tables, but obviously everyone keeps saying that they did not save these tables, or they told me that I can do everything myself this is done, they say what I myself know ...

I just remember my friend @ shishmish, who always does this job and creates CV_ATTASK_LIST and this helps our forum, for this I say THANKS to him:thum:

But I agree with You that can make a special program for hashes, and it will be much smaller than all the tables

1) I am new.
But I have read the forum from time to time in the past. Just decided to post and help recently.

Now helping you guys in this one mean telling you the truth. But sadly the truth about RBT, cashe?, look up tables, etc, seems to show as a Negative comments from us the ones that try to help. Sorry it is not the intention to look negative.

* 1rst I do not do use "CV_ATTASK_LIST" so I have even not seen what is inside. Well I have a good Idea. So I will be looking at one next.
* yes I seen shishmish list been posted. I guess we thank him for that.
* I do think/read this is nothing new and there may had been many post on this.

Now that you guys know I am not trying to be negative let see if I can help you. But If you do not what to read the Thesis Below just trust me. You can do small tables like shishmish. But not a full table.



So you still reading then lets go in to the thesis. Lets do it like our friend tglito does.
Here you can search web, read and help yourself and learn.

2) Theory or Knowledge.
Required to understand the concepts so that you guys do not blame us of hiding the DATA or TABLES.
* In programing people use
data vs tables
data compression
loop unrolling
Space–time tradeoff => _https://en.wikipedia.org/wiki/Space–time_tradeoff

* In cryptanalysis people use:
cryptanalysis => _https://en.wikipedia.org/wiki/Cryptanalysis
side-channel attacks => _https://en.wikipedia.org/wiki/Side-channel_attacks
Data_Tradeoff_attack => _https://en.wikipedia.org/wiki/Time/Memory/Data_Tradeoff_attack

Reverse Lookup tables => _https://en.wikipedia.org/wiki/Reverse_lookup
_https://en.wikipedia.org/wiki/Talk:Lookup_table

"A rainbow table is a way to store the same information using less space"
Rainbow tables => _https://en.wikipedia.org/wiki/Rainbow_table

3) Why this concept/analysis is wrong
Now in Theory you guys are fighting becouse you want to use a data compression mechanism like RBT just like it was a regular Reverse Look Up Table. But simple answer is You can not use RBT inside a Reverse Look Up Table one is compressed the other do not.
RBT are focus in just ONLY in two(2) numbers 0x0000000000000000 or/and 0xFFFFFFFFFFFFFFFF. To make it more compress RBT uses ONLY 6 digits instead of 8.
Reverse Look Up Table try to give answer to ALL numbers!!! Yes a lot of numbers, From 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF

4) Impossibility to have all data in 1 table. Witch also means How impossible will be to search such a table!!!
Now How Big of a table we are talking. every hex 0x00 is = 256 decimal. So you have 256 ^ 8 = 18446744073709551616. possibilities
But Every possibility requires 8 byte of input data so now your final formula is

8 x 256 ^ 8 = 36893488147419103232 possibilities

Now lets see how many terabytes of disk we need to store that data table.
1 KB = 1024
1 MB = 1024 * 1024 = 1048576
1 GB = 1024 * 1024 * 1024 = 1048576
1 TB = 1024 * 1024 * 1024 * 1024 = 1099511627776

So we need a Hard Disk
36893488147419103232 / 1099511627776 = 33554432 TB of data

And in theory it should not be any type of HDD but instead a SDD => _https://en.wikipedia.org/wiki/Solid-state_drive
No one has build such a device!!!!

Now Imaging the Super Computer you need to Rapidly do a Binary Search => _https://en.wikipedia.org/wiki/Binary_search_tree

5) I know a smart guy is going to say. But you need ONLY 6 of the 8 bytes to be save. Well true but then you are doing a small "Space–time_tradeoff"

well in general you Required SDD Hard drive is .75% of the original 33554432*.75 = 25165824 TB of data
Still can not buy that SDD, Can you?


Why I did this? This is refreshing my mind. Because I spent the whole night trying to understand why I can not get a CW from an old posted file of T V3. Just to find there is a trick hiding the answer that I can not understand.

I for got the note

ZinnetiG said:

...It's about creating the maximum possible cache of RBT tool's search...

Click to expand...

If you still in confusion, ALL same answer some how. Sorry again. If you try to include ALL answers in an RBT you will end up with double of look up table.

Yes clearly RBT is compressed to prevent that. So NO you in fact understand RBT vs Look up table. and you really looking for "maximum possible cache of RBT". I am ignoring "cache".

But the answer now is defining "maximum possible RBT". You can not figure that. Why? because the RBT Lines have "Hash collision" see _http://crppit.epfl.ch/documentation/Hash_Function/WiKi/Hash_collision.htm

Consequence is that many results now repeat making the table bigger but without reaching all or at least maximum number of solutions. See you will never be able to have it all.

...with many of Your words agree, thanks for applying your knowledge to the forum, but I do not agree with you here (quote)

cayoenrique said:

See you will never be able to have it all.

Click to expand...

if you think so then dozens of years ago you thought that seeing people in a box is a miracle! But in fact it was made? Do we watch TV?
And also, if you want you can make such a program that will collect all the cash in one !

So I agree with @ZinnetiG

Like I said I only posted because I was frustrated with my own project. Funny it relates to this article some how. As I was trying to go against probability by forcing to find a CW that it is by design not ment to be found. Just like you guys want to have ALL cw the hard way in this so call cache. Now my initial thought was to post the wiki links only, TGILITO stile. But my own frustration got me to add comments. I was only trying to relax myself.

Now most of us use English as a second language. This cause misinterpretation in the translation. You guys keep speaking about: Cache. I do not know what you mean really when you say "cache". I believe now you speaking about colibri RBT. I have only play with Version 1. I do not see your desperation trying to get it ALL. My self I only have I think Table 1 of CSA_B8hx00h_10000h.rbt & CSA_B8hxFFh_10000h.rbt. I am not even sure if I have complete table 1 of CSA_B8hx00h_10000h.rbt. And I know he even posted at least a second table for each. And for the most part I survive with that. Clearly I am not into Feed Hunting for now.

lets talk about file type found:
B8hx00h_table1.zip ( B8hx00h_table1.z01 ).......................The File you download from colibri's links.
CSA_B8hx00h_10000h.rbt..............................................The File you end up after unziping.
CSA_B8hx00h_10000h_5F4E0B1A323CFBBE.ecw................Temporary file. This is what I called cache. I may be wrong I think it means Expanded CW.

Now the Real RBT (CSA_B8hx00h_10000h.rbt) can grow any size. As you can locally create more and Merge. But the cache ECW (for example CSA_B8hx00h_10000h_5F4E0B1A323CFBBE.ecw) has a fix size. I think is 393,216 bytes
Lets see if I remember
( 6 byte CW ) x RBT size = 6 x 0x10000 = 6 x 65536 = 393,216 bytes = 384Kb

I see you use metaphor to in your TV history. I like that. It is true. You can change the way you think. But you can not change a physical/theoretical FACT.

I see you like example I give you one to show why you will NOT get it ALL.
Zeno's Dichotomy paradox see _https://en.wikipedia.org/wiki/Dichotomy_paradox

Suppose Homer wishes to walk to the end of a path. Before he can get there, he must get halfway there. Before he can get halfway there, he must get a quarter of the way there. Before traveling a quarter, he must travel one-eighth; before an eighth, one-sixteenth; and so on.

Click to expand...

Paradox = He will spent all his life walking 1/2 of the reminder distance and never to arrive.

In out RBT problem the paradox is that RBT Lines have "Hash collision" Consequence is that with each RBT creation and Merge you end up adding same hidden tables lines. So your table gets bigger but with duplicate hidden data.

There are a couple of thread here that speak about editing the tables to try to eliminate the easy ones. The ones that end up with same values. But those are a really small amount of them as there are MANY MANY more that cycle same CW rounds but do not end in same ones. I think some one ones said that 160 GB of table was enough to find most of the CW.

Now Clearly it has been posted in the past People showing off saying they have many giga bytes of RBT table V1. At the time those guys posted, bandwidth was expensive so no ones posted links. Now most if not all do gets only table 1 & 2 of V1 and is enough for them. Just ask here for the crypt8 they can not find. Yes I know Most of the people move to Version 2 as they are faster and I guess colibri also realize smaller the round less hash collisions.

Conclusion.
Be smart realized what is the problem here!! You can not get the CW for those h.264 feeds with the table you have.
But how it work in the past, but now it is not working? Well for the most part h.264 in the past was a fake. Lots of dark area around or in fact low quality. this created a lot of opportunities for crypt8 to exist. But now the Quality is at it best!!! Nice picture games. But the result is that h.264 now is been use as it capacity as result less opportunity for REAL Crypt8 to show up. As result Fake crypt8 becomes more that real or crypt 8 do not show at all. And we know how the industry is fighting all of us ensuring that Real crypt8 do not show anyway.

Just wake up guys, you can not get those CW not because you need bigger tables but because Real CW are not showing up anymore.

Listen I was interested in showing that it is not realistically possible to have it ALL. But You can create and merge as many tables you feel happy with. Your table gets bigger and slower. So you need to find a SDD Bigger for your table.