G00gle tells me - BeoutQ firmware updates!
Can we find a Biss key with fake crypt8! for discussion.
- Thread starter asoom_jamjom
- Start date
G00gle tells me - BeoutQ firmware updates!
I'm using the file posted at the link supplied in this post
http://www.sat-universe.com/showpost.php?p=2036916607&postcount=10
"26.0E 11919 H 07-23 14-43-12.ts"
I've now just about identified the contents of all 64 PIDs.
http://www.sat-universe.com/showpost.php?p=2036916607&postcount=10
"26.0E 11919 H 07-23 14-43-12.ts"
I've now just about identified the contents of all 64 PIDs.
I doubt the files are different as I also found the string you found here.
I now suspect the 0x10 byte number following the file name could be a checksum on the file.
There are three other firmware update labels as well. There could also be an OTA firmware update too on PID 142 (0x8E) (not confirmed).
However, for clarity I've zipped the file I have and uploaded it here 93MB - better than the unzipped which is 983MB!!!
-https://ufile.io/8iqaz
Are you using TSReader? I did not have much success with that.
I've been using "MPEG-2 TS packet analyser.exe" from here
-http://www.pjdaniel.org.uk/mpeg/
Code:
001b6ed4h: 47 40 8E 10 00 3B B0 8D 00 00 C1 00 00 11 03 10 ; G@Ž..;°?..Á.....
001b6ee4h: 06 00 01 00 00 FF 00 00 78 FF FF FF FF FF FF FF ; .....ÿ..xÿÿÿÿÿÿÿ
001b6ef4h: FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 ; ÿÿÿÿÿÿÿÿÿÿÿÿÿ...
001b6f04h: 60 00 01 00 00 00 04 03 12 53 F8 00 0D 00 01 02 ; `........Sø.....
001b6f14h: 09 01 FE D4 C6 01 00 04 84 00 00 43 02 17 76 37 ; ..þÔÆ...„..C..v7
001b6f24h: 2E 32 2E 31 31 31 32 2D 76 37 2E 32 2E 31 31 35 ; .2.1112-v7.2.115
001b6f34h: 36 2E 7A 69 70 03 23 65 6E 67 31 38 43 30 34 37 ; 6.zip.#eng18C047
001b6f44h: 35 43 45 36 45 38 39 34 46 44 42 39 41 42 43 37 ; 5CE6E894FDB9ABC7
001b6f54h: 41 30 33 35 37 31 45 38 37 36 90 03 00 04 58 00 ; A03571E876?...X.
001b6f64h: 00 A8 A1 88 E5 ; .¨¡ˆåI now suspect the 0x10 byte number following the file name could be a checksum on the file.
There are three other firmware update labels as well. There could also be an OTA firmware update too on PID 142 (0x8E) (not confirmed).
However, for clarity I've zipped the file I have and uploaded it here 93MB - better than the unzipped which is 983MB!!!
-https://ufile.io/8iqaz
Are you using TSReader? I did not have much success with that.
I've been using "MPEG-2 TS packet analyser.exe" from here
-http://www.pjdaniel.org.uk/mpeg/
My humble apologies.
I've been trying to work out why you guys were getting different results to me and I have just discovered I've been looking at a different TS file.
The one I've been studying was 12383H TS (another beoutq transponder) from November 2017. This has since stopped transmitting.
There a lot of similarities eg the firmware update PIDs and ten video channels, but obviously a lot of differences, such as lack of SDT and other tables, as well.
Let us now concentrate on the current 11919H TS file.
Sorry again for any confusion. Entirely my fault.
I've been trying to work out why you guys were getting different results to me and I have just discovered I've been looking at a different TS file.
The one I've been studying was 12383H TS (another beoutq transponder) from November 2017. This has since stopped transmitting.
There a lot of similarities eg the firmware update PIDs and ten video channels, but obviously a lot of differences, such as lack of SDT and other tables, as well.
Let us now concentrate on the current 11919H TS file.
Sorry again for any confusion. Entirely my fault.
I think it refer to some version of "Enthuware" java and if you search for that you will see Comcast STB properly use that
Another thing if you view the ts as hex in 188 length you will notice that almost all TS 188 packets ends with FF FF's in clear
After some thinking I'm now pretty sure they are using a 128 bit key.
I agree. 16 byte blocks leaving 8 bytes in the clear at the end.
On the video PIDs these are more often than not just 8* 0xFF padding as K2TSET has said, but there are some packets ending with
FFFFFFFFFFFFFF80.
However, on the two other lower bitrate PIDs associated with each channel (audio????) the 8 bytes of plain data are usually 8 * 0x00. But there are quite a few packets with other non-zero values such as, for example
0340681BFFC00000
100340681BFFC000
According to Electrik_DZ the scrambling method used is AES128 and, because of the Initialising Vector, I assume in CBC mode.
http://www.sat-universe.com/showpost.php?p=2036900176&postcount=1
I've tested these old keys and they do not work. We need the current keys!
Has anyone got a recent dump from an official box or know the key/algo to decrypt the updates?
I think the ts are a bit weird.
If you open the ts in Mpeg2-TS packet analyser and look for the PID list you will get 36Pid's in use
Eg PID 2232 0x8B8 will have 495912 counts and take 9% of the file
If you then find the PUSI for PID 2232 and step through the packets for that PID you will see the content are static even it's encrypted, this tells me that there will never be any audio video in that PID.
If you open the ts in TSreader you will not get any normal PID info for what PID are for audio / video
If you open it in tsdemusx it fails.
So my question are if the ts are corrupted somehow or does not compile to Mpeg2ts?
If you open the ts in Mpeg2-TS packet analyser and look for the PID list you will get 36Pid's in use
Eg PID 2232 0x8B8 will have 495912 counts and take 9% of the file
If you then find the PUSI for PID 2232 and step through the packets for that PID you will see the content are static even it's encrypted, this tells me that there will never be any audio video in that PID.
If you open the ts in TSreader you will not get any normal PID info for what PID are for audio / video
If you open it in tsdemusx it fails.
So my question are if the ts are corrupted somehow or does not compile to Mpeg2ts?
I agree the TS is weird!
I assume each "channel" is empty. ie the high bitrate PID packets (eg 2232) are all 0xFF (scrambled) and the associated lower bitrate ones (eg 2234 and 2235) are mainly 0x00 (scrambled, probably with the same key).
Each channel (group of three PIDs eg 1182,1184,1185 or 2232,2234,2235 etc) are scrambled with a different key.
Why they are broadcasting "empty" channels, I have no idea.
Another full TS log may give us more info. Can someone please upload about 1 minute full TS log (zipped) of 11919H or 12207V on 26°E when programming is actually being shown.
I assume each "channel" is empty. ie the high bitrate PID packets (eg 2232) are all 0xFF (scrambled) and the associated lower bitrate ones (eg 2234 and 2235) are mainly 0x00 (scrambled, probably with the same key).
Each channel (group of three PIDs eg 1182,1184,1185 or 2232,2234,2235 etc) are scrambled with a different key.
Why they are broadcasting "empty" channels, I have no idea.
Another full TS log may give us more info. Can someone please upload about 1 minute full TS log (zipped) of 11919H or 12207V on 26°E when programming is actually being shown.
sattechtips
Registered
- Messages
- 426
I have a little different question, If i record some file with wrong biss key, can i repair ts file, with open with hex editor change something and after to decrypt with right CW ?
no,CSA is not reversible,so,in case the emulator tried to decrypt with wrong key,you cannot revert back.
sattechtips
Registered
- Messages
- 426
OK, thanks
some guy say he made his own soft where is like TS offline decryptor and he decrypt right , after record some ts with wrong biss CW, he repair file, but he don't want to share how.
Youknowme02
Registered
- Messages
- 246
What is the best software for pulling biss keys?