Why RBT, Cudabiss and K2TSET PGFA BF may fail!.

cayoenrique

Member
Messages
475
Rainbow tables still have it uses. But as time goes by, providers are adjusting sending padded bytes on the clear and the use of the adaptive filed. So RBT are no good some time. That does not necessary means it is not CSA. Tandberg V3 Logs I seen does not seems to me DES-EBC like powervu, as it has been suggested.

I been reading on MPEG_TS and H.264. Uff!! confusing. some one said ( Reference 4):
Code:
there is no single standard H.264 elementary bitstream format

Some Reference
Code:
1) https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-201304-S!!PDF-E&type=items
2) http://ip.hhi.de/imagecom_G1/assets/pdfs/csvt_overview_0305.pdf
3) http://www.thefullwiki.org/Network_Abstraction_Layer
4) https://stackoverflow.com/questions/24884827/possible-locations-for-sequence-picture-parameter-sets-for-h-264-stream/24890903#24890903

Go to reference 1) H.264 Standard. Look at Annex B page 304
At top it reads:
Code:
This annex forms an integral part of this Recommendation
See this is not a Standard it is a Recommendation. Then to make it worst even in the recommendation it reads that
a "NALU Start Code" can be 3 or 4 bytes long!! I found of some one else that think like me. See reference 4):

Code:
"NALU Start Codes

A NALU does not contain is its size. Therefore simply concatenating the NALUs to create a stream will not work because you will not know where one stops and the next begins.

The Annex B specification solves this by requiring ‘Start Codes’ to precede each NALU. A start code is 2 or 3 0x00 bytes followed with a 0x01 byte. e.g. 0x000001 or 0x00000001.

I will not confuse you anymore. Main Point is that Cudabiss is an old program back when the standard was in fact just Mpeg. And start code was known as a fact as to be 3 bytes 000001:

Code:
packet start code prefix: This is a 24 Bit value, which is always set to 0x000001. It marks the beginning of a PES packet.

I look at some logs in Tandberg V3, and for what I seen most part video is H.264. Maybe 0x000001 vs 0x00000001 is the reason why Cudabiss and K2TSET PGFA BF failed. And watch does adaptive field that shift data to the end. Hope it help to those working on this.
 
Last edited:

K2TSET

Registered
Messages
125
Interesting,

The FPGA do for sure only look for 0x00, 0x00, 0x01 just after the PUSI header and after a potential AF.

It would be easy to change that to look for 0x00, 0x00, 0x00 as well but if I understand correctly it does not have to be the first bytes after the PUSI Header, it can be anywhere in the payload since there might not be stuffing bytes after the last packages to align the start bytes to the beginning of the PUSI packet, right?

To search for that in a BF way will require to decode the whole 184 bytes and see if there are any 0x00 0x00 0x01 somewhere in the packages and not just on the 3 first bytes. this will slow BF way down.

Maybe we can find a clear h.264 file to confirm this?
 

cayoenrique

Member
Messages
475
I forgot to mention that even when I had read about 00000001 I have not seen a single H.264 ts in the clear showing that!. So what I mean is, not to forget that there are other configurations.

I had read some of your post here. I know you have mention you seen in h.264 the 00 00 01 0c (ff)* 80.
So I know you know about this. But it is nothing to forget. I have a feeling it is important.

Here an old 13 years ago "tanberg encoded"/"mplayer decode" related crash report on the issue
_https://trac.mplayerhq.hu/ticket/399

See how 13 years ago they where playing with stuffing "00 00 01 0c (ff)* 80"

Here another post from 2010
_https://forum.doom9.org/showpost.php?p=1363176&postcount=1

Now for those of you that wonder here is a simple explanation
_https://forum.doom9.org/showthread.php?p=1363275#post1363275

Point is this is nothing new. New may be that most FF are now sent on the clear.

In fact I have recorded some 30W Test Cards in the night. This technique can be seen in just plain old MPEG Video. Where then the 00 are sent unecrypted.

K2TSET... said:
it can be anywhere in the payload since there might not be stuffing bytes after the last packages to align the start bytes to the beginning of the PUSI packet, right?
I said already I am no expert, just trying to guess why the available tools fail with h.264. So I read a lot. After been said that I think they could use the Adaptation Field to inject some for example timing or other data in front of the PUSI. Now I remember seen it shifted on some of the logs but not Totally sure that it was using AF.
 
Last edited:
Top