Are you sure? I scan a BISS feed - D-278 2M9 BAMG GBIMG
Hacking CA system challenge *Tandberg [ NO Keys Allowed in Chat Section/s ]*
- Thread starter Colibri.DVB
- Start date
Are you sure? I scan a BISS feed - D-278 2M9 BAMG GBIMG
Tested
I think Tandberg.mdl Needs to fix again
It does not work even with the AES keys active and correct
We have to wait to return @Anubis_Ir
:thum:
Ts full log for @Anubis_Ir
7E 12573 H 7120 on Tandberg
Des 84
Aes 02
http://www.mediafire.com/file/hem9arg6k8nbl0d/ARQ-PL9+CLIPS+noevent+20171012_204932+%231.rar
-http://www.mediafire.com/file/hem9arg6k8nbl0d/ARQ-PL9+CLIPS+noevent+20171012_204932+#1.rar
Last edited:
- Messages
- 24,783
Afraid your 100% Wrong .
Ident Changed for Basketball
IMG3 EU NEW ID = D-278 2M9 BAMG GBIM
BISS
- Messages
- 24,783
Download link:
File name: HD Telemundo Este - 2017-10-12_13h30m01s.ts - 421.6 Mo
https://mega.nz/#!pqwHSBJI!8j0-Ho6spS-wjuTYcHI2odhBIwNJ32yupkeqV3WWpnA
Satellite infos:
CHANNEL Name: "Ch 20 Telemundo East HD"
Provider: "NBC Telemundo"
TRANSPONDER 3940, H, 30000 8PSK FEC 3/4
105.0°W (2550 - AMC 18 C)
IDs NetwordID: 65535 TransponderID: 1 ServiceID: 20
PIDs
Video: 517(H.264)
Audio: 655 - eng (MPEG-1)
PCR: 517
PMT: 265 Teletext: 0
ECM/EMM LIST
1) CA-Type: 4112 (0x1010) Tandberg
ECM: 102 (0x0066) <-- SELECTED
DATE/TIME 2017-10-12 13:35:23 (GMT -5)
Video File Infos:
General
ID : 1 (0x1)
Complete name : HD Telemundo Este - 2017-10-12_13h30m01s.ts
Format : MPEG-TS
File size : 422 MiB
Duration : 5mn 0s
Start time : UTC 2017-10-12 17:34:58
End time : UTC 2017-10-12 17:35:08
Overall bit rate mode : Variable
Overall bit rate : 11.8 Mbps
Video
ID : 517 (0x205)
Menu ID : 20 (0x14)
Format : AVC
Format/Info : Advanced Video Codec
Format version : Version 2
Format profile : [email protected]
Codec ID : 27
Duration : 5mn 0s
Maximum bit rate : 15.0 Mbps
Frame rate : 29.970 fps
Chroma subsampling : 4:2:0
Encryption : Encrypted
Audio #1
ID : 655 (0x28F)
Menu ID : 20 (0x14)
Format : MPEG Audio
Format profile : Layer 2
Codec ID : 3
Bit rate mode : Constant
Maximum bit rate : 206 Kbps
Compression mode : Lossy
Language : English
Encryption : Encrypted
Audio #2
ID : 665 (0x299)
Menu ID : 20 (0x14)
Format : MPEG Audio
Format profile : Layer 2
Codec ID : 3
Bit rate mode : Constant
Maximum bit rate : 206 Kbps
Compression mode : Lossy
Language : English
Encryption : Encrypted
Audio #3
ID : 675 (0x2A3)
Menu ID : 20 (0x14)
Format : MPEG Audio
Format profile : Layer 2
Codec ID : 3
Bit rate mode : Constant
Maximum bit rate : 206 Kbps
Compression mode : Lossy
Language : English
Encryption : Encrypted
Menu
ID : 265 (0x109)
Menu ID : 20 (0x14)
Duration : 5mn 0s
List : 517 (0x205) (AVC) / 8144 (0x1FD0) () / 655 (0x28F) (MPEG Audio, English) / 665 (0x299) (MPEG Audio, English) / 675 (0x2A3) (MPEG Audio, English)
Language : / / English / English / English
Service name : Ch 20 Telemundo East HD
Service provider : NBC Telemundo
Service type : digital television
Maximum bit rate : 16634000
Can the receiver only have one "active" XML file? If not how does it know which one to use, is there perhaps different indexes more than the 20 we have seen?
fiji
Member
- Messages
- 1,095
The 1st byte of the posted AES keys is the actual index of the key and shouldn't be used as part of the actual key.
For example if you have this key
Ignore the first byte (1st 2 characters), Then the actual AES-KEY01 would be XYXYXYXYXYXYXYXYXYXYXYXYXYXYXYXY. And you can get consecutive DCW's with it (which means the algo is correct), but without picture.
@Those who work with `CSA Rainbow tables`. Can you get working CWs of these channels lately?
Can you search these values in tables B8xFF or B8x00? 779B1CA2582FA0F7 and 0FEB5AAE7AC18AD0 for this file
_https://mega.nz/#!19AiFKQQ!xdjfQVpreWI4epkXFC-CRlSBg_Qt9pKTsWuBvAASErg
For example if you have this key
Code:
<Struct N="key#2" V="01XYXYXYXYXYXYXYXYXYXYXYXYXYXYXYXYD152"/>@Those who work with `CSA Rainbow tables`. Can you get working CWs of these channels lately?
Can you search these values in tables B8xFF or B8x00? 779B1CA2582FA0F7 and 0FEB5AAE7AC18AD0 for this file
_https://mega.nz/#!19AiFKQQ!xdjfQVpreWI4epkXFC-CRlSBg_Qt9pKTsWuBvAASErg
Last edited:
C
campag5242
@K2TSET came to the conclusion it wasn't CSA, having searched the whole keyspace (twice) for one crypto period of video: http://www.sat-universe.com/showpost.php?p=2036824988&postcount=1552
No luck with FFh/00h V1 tables. I tried some time ago with other C8s and found nothing. Brute force also failed. It looks like CSA64 or something else. I also tried with brute force any byte combination with DWs after AES decryption and still nothing.
fiji
Member
- Messages
- 1,095
How this work ?
- Messages
- 24,783
77 9B 1C A2 58 2F A0 F7 #CW:not found
0F EB 5A AE 7A C1 8A D0 #CW:not found
nothing found in my V2 B8hx00h and B8hxffh Tables :mecry:
sorry @ Anubis_IR my friend .
Are you saying the AES keys you posted are valid still ?
i have tried with dropping the "00" and "01" etc.. from AES Keys in your text file but still no picture on ARQ-PL9 Clips Feed yesterday i tried all AES Keys that were in the text file too .
i will wait for IMG3 EU to Go Tandberg V3 at some point Today and test further but so far i have not yet had any success . :mecry:
cheers !
The posted AES key is a new key of an Asian provider. So it's still valid, at least for the posted .ts file.
These are possible scenarios now:
- The in use AES `IV` can be different. It's possible to get consecutive DCWs with a different `IV` too.
Or
- The `IV` is correct, But the normal `CSA` is not in use.
These are possible scenarios now:
- The in use AES `IV` can be different. It's possible to get consecutive DCWs with a different `IV` too.
Or
- The `IV` is correct, But the normal `CSA` is not in use.
Did you drop the last 4 bytes?
- Messages
- 24,783
i did not , sorry i did not think about last digits at all but now you mention it i will for sure drop last 4 next time Tandberg V3 Feed shows up .
i could see the first 2 bytes needed to be dropped
but never dropped last 4 but i will try that the very next time there is a Tandberg V3 Feed which should be sometime later today .
Cheers !
C
campag5242
You probably have the same keys as I do Barney. What "worked" for yesterday's Arqiva, was T 0001 02 7Fxxxxxxxxxxxxxxxxxxxxxxxxxxxx33
You won't see a picture, cos the keys are currently being stuffed into a final CSA decryption pass of the actual AV streams, and it looks like that is not appropriate (or as Anubis_Ir says above, IV wrong). You will see the dCWs dance nicely between odd/even updates at every crypto period cycle change.
You won't see a picture, cos the keys are currently being stuffed into a final CSA decryption pass of the actual AV streams, and it looks like that is not appropriate (or as Anubis_Ir says above, IV wrong). You will see the dCWs dance nicely between odd/even updates at every crypto period cycle change.
Last edited:
- Messages
- 24,783
i do indeed @ campag5242
glad it just not me then that can not see any pictures
i thought i was doing something seriously wrong
but hopefully then the final CSA decryption can be figured out as it does seem like this is algo is very close to being broken now just missing the final steps it seems ,
whether or not these AES Keys will be valid and work is i guess is another story it does seem like a very complex change which was done very rapidly indeed , There is likely an awful lot we still do not know about with this quite old Tandberg encryption ?
glad it just not me then that can not see any pictures
i thought i was doing something seriously wrong
but hopefully then the final CSA decryption can be figured out as it does seem like this is algo is very close to being broken now just missing the final steps it seems ,
whether or not these AES Keys will be valid and work is i guess is another story it does seem like a very complex change which was done very rapidly indeed , There is likely an awful lot we still do not know about with this quite old Tandberg encryption ?