Hacking CA system challenge *Tandberg [ NO Keys Allowed in Chat Section/s ]*

M

marrakr

Senior Member
Messages
293
IMG testing EC right now again.
I'm trying to record some sample but my current receiver (Dreambox DM 525 HD) does not include CAT in TS stream and poc does not work (even with disabled oscam) :/
I was using Ariva a year ago and there was no problem. Can I modify sth on enigma2 to get CAT to working with poc?
 
K

kebien

Well Known Member
Messages
1,329
marrakr said:
IMG testing EC right now again.
I'm trying to record some sample but my current receiver (Dreambox DM 525 HD) does not include CAT in TS stream and poc does not work (even with disabled oscam) :/
I was using Ariva a year ago and there was no problem. Can I modify sth on enigma2 to get CAT to working with poc?
Click to expand...

If your dreambox has dvbsnoop installed you can simply record using dvbsnoop command line in telnet.
Read about dvbsnoop in sourceforge
 
H

h3nch4

Senior Member
Messages
201
abra26 said:
Can someone try to find all CW keys from ViaHussun's example please? (if it is possible due to short record...)

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

Thanks a lot !!!
Click to expand...

PID: 200h B8h-Crypt8:8E 70 58 0A A7 F7 57 CF [E] Count:15
PID: 200h B8h-Crypt8:E2 87 BC 2D BB F8 42 CA [E] Count:15
PID: 200h B8h-Crypt8:27 E9 83 EA 7D 94 19 5E [O] Count:13
PID: 200h B8h-Crypt8: D7 6E EE 22 49 39 FC 08 [O] Count:13
PID: 200h B8h-Crypt8:56 B1 2F 67 CA 84 06 3C [O] Count:9
PID: 200h B8h-Crypt8:BE AB 34 F9 15 7A 0F D3 [O] Count:9
PID: 200h B8h-Crypt8:0E 93 DB 54 B6 4E 95 05 [E] Count:8
PID: 200h B8h-Crypt8:62 6B D2 4F 85 2B 11 E7 [E] Count:8
...

PID:1010h B8h-Crypt8:20 C7 48 A4 EF F5 ED EC [O] Count:84
PID:1010h B8h-Crypt8:22 7A 3D 68 D4 E0 23 5C [E] Count:84
PID:1010h B8h-Crypt8:38 17 E2 3E 5B 61 BB 35 [O] Count:84
PID:1010h B8h-Crypt8:4B 91 36 61 58 F0 2C 5B [E] Count:84
PID:1010h B8h-Crypt8:4F 66 D1 38 C6 E7 AB 1C [O] Count:84
PID:1010h B8h-Crypt8:75 66 C2 33 63 CD 92 D7 [O] Count:84
PID:1010h B8h-Crypt8:A6 55 E8 A4 5A EB 65 08 [E] Count:84
PID:1010h B8h-Crypt8: DB 87 40 BB C4 0E 54 10 [E] Count:84
...

PID:1020h B8h-Crypt8:13 DB C2 D2 01 D9 4C 47 [E] Count:84
PID:1020h B8h-Crypt8:52 31 65 F8 27 3C A8 7A [E] Count:84
PID:1020h B8h-Crypt8:52 A0 43 39 E9 A7 48 8F [O] Count:84
PID:1020h B8h-Crypt8:6C BF 3D C5 EA FA BB 41 [O] Count:84
PID:1020h B8h-Crypt8:94 24 C4 62 BF CF 9B CB [E] Count:84
PID:1020h B8h-Crypt8:A7 C6 C3 78 11 74 B9 88 [E] Count:84
PID:1020h B8h-Crypt8:AC 61 06 E5 1A 46 C2 D6 [O] Count:84
PID:1020h B8h-Crypt8:B1 A6 A8 4A 93 36 83 E5 [E] Count:84
...

PID:1030h B8h-Crypt8:0A 94 2B D8 22 73 0B F7 [O] Count:84
PID:1030h B8h-Crypt8:0B A0 21 D6 63 25 FB F1 [E] Count:84
PID:1030h B8h-Crypt8:19 25 6E A6 32 31 D6 47 [E] Count:84
PID:1030h B8h-Crypt8:65 20 B1 82 EF 86 8D C4 [O] Count:84
PID:1030h B8h-Crypt8:8C 0C B9 88 F9 3E 3D 37 [O] Count:84
PID:1030h B8h-Crypt8:A6 D7 FA 48 0D 3F 26 28 [E] Count:84
PID:1030h B8h-Crypt8:BA 28 36 DF 7A AB 35 9A [E] Count:84
PID:1030h B8h-Crypt8:BC 3B E5 2F DE B2 DC 3E [O] Count:84
...

PID:1040h B8h-Crypt8:03 2F E2 2D 9F DF 91 0A [E] Count:84
PID:1040h B8h-Crypt8:0D 96 27 66 C0 30 E0 93 [O] Count:84
PID:1040h B8h-Crypt8:17 D7 60 54 18 25 79 65 [E] Count:84
PID:1040h B8h-Crypt8:19 9C D7 A1 E0 EB CB A7 [E] Count:84
PID:1040h B8h-Crypt8:3A 03 26 4C AC 5F 55 8E [O] Count:84
PID:1040h B8h-Crypt8:3B 02 7F 5B AF 72 A8 32 [O] Count:84
PID:1040h B8h-Crypt8:5E EF 69 9B C2 FF 57 96 [E] Count:84
PID:1040h B8h-Crypt8:68 FF BA 90 07 E4 EA 7A [E] Count:84
 
M

marrakr

Senior Member
Messages
293
kebien said:
If your dreambox has dvbsnoop installed you can simply record using dvbsnoop command line in telnet.
Read about dvbsnoop in sourceforge
Click to expand...
Still no success :(
I'm tring with
Code: 
dvbsnoop -b -n 500000 -nph -s ts 0x0200 > /media/hdd/movie/emm.ts
And can't get correct emm with 837022...
Even:
Code: 
dvbsnoop -n 500000 -nph -ph 2 -s ts 0x0200 | grep "83 70 22 00"
never catch output.

And using poc I'm getting only
Code: 
[Emu] error: unknown permissionDataType E9 (pos: 3)
and
Code: 
[Emu] error: TandbergParseEMMNanoData: pos(0) + 2 + sectionLength(3607) > maxLength(2845)
errors.
 
barney115

barney115

Donating Member
Staff member
Administrator
Messages
24,846
poc tool works fine and does give ECM Keys in log
that is not the problem Tandberg V3 is something new and looks to be very difficult the Ident is either hidden or encrypted therefor any keys that is found will obviously be fakes or no chance to work without know the ident on IMG3 EU
and possibly now will be affected all EPL Feeds inc. EPL Muxx and ARQ-PL9 Also .
Whatever has changed with Tandberg V3 it was not major change but enuff to require someone with correct expert knowledge to try and figure it out for us ,
it will very likely require a new Tandberg EMU for it to at least work again on DVB Cards .
Last season was something similar aswell but thanks to @ Anubis_IR and @ Colibri a fix was made within a week or so ,
we can only hope for those experts to help us once more .
cheers !
 
C

campag5242

Hi Barney. The Entitlement_ID of this 3rd type of ECM is not hidden, it's there in plain sight. As kebien had already said on 04-09-2017 @ 18:50 here: http://www.sat-universe.com/showpost.php?p=2036818822&postcount=1480

What is different is the ECM_TAG_CW_DESCRIPTOR, now 0xEC.

The original 0xEE ECM_TAG_CW_DESCRIPTOR was simple in structure, check back to colibri's post #16 of this thread:
81: Table ID
70 18: & 0x0FFF -> Section length
EE: Tag ECM_TAG_CW_DESCRIPTOR
16: Length
00 00 16 AB: Entitlement ID
A9 D4 0A 26 FE 79 CB AF: encrypted CW
09 AC 49 F5 B3 42 B3 71: encrypted CW
AA 02: Checksum

For TAG EE, a simple DES ECB decrypt with the key on each 8-byte eCW was sufficient to give usable dCWs.


Then around October '16 came the 0xED ECM TAG with a 32-byte encrypted payload. This time a DES CBC decrypt was required, with the dCWs re-assembled from bytes scattered through this 32 byte block at fixed positions. You can spot the positions in this sequence of decrypted 32-byte blocks:
Code: 
Consecutive ECMS:
81 70 28 ED 26 00 00 00 C9 D0 9A AA 5E 62 7C 99 ED CA 05 C3 19 D2 4D 61 88 4C 26 88 9C 61 20 85 7B 4D F0 79 90 76 DE 16 30 17 E3 
80 70 28 ED 26 00 00 00 C9 F7 4F F2 E4 36 85 92 4F 3B 86 4F AB 5B 25 6A 1D 5C 8E 67 87 B7 53 9B C5 F2 D5 1C 2E 26 66 E5 CB 57 E3 
81 70 28 ED 26 00 00 00 C9 2B 02 B0 19 99 91 B3 24 E7 2E F3 32 5E 92 B2 C5 E3 D0 67 4B 52 E8 48 FA 39 C1 DF 61 F5 E4 7C CC 0A 3C

T C9 01 D097A72F1E367A00 changed from T C9 01 3775D9621C86BC01 simultaneous with algo change!

Decrypted blocks:
3c 27 01 95 38 ba 69 ed 72 24 c7 a2 2a 6c 6a 69 c8 77 28 d6 cd dd 9a 6d 7a d3 9a 10 e3 06 08 26
54 cd 15 6d 38 ba da 36 b7 6b 1e a2 34 ee 69 8f 42 3e 28 d6 be 93 32 42 3c d3 9a d4 6e 06 24 a0
41 b0 15 6d fa 58 4b b3 15 6b dc ec cb ed 69 b7 42 3e 38 a5 d3 e6 32 74 3c cc d8 4f 6b 73 e4 87
Note the bytes which remain unaltered compared to the previous line - those bytes form the odd or even dCW.


Now we have this latest TAG, 0xEC. See these consecutive ECMs taken from ViaHussun's log posted above:
Code: 
8170 2a ec28 00000692 ffeb 00b529ee810dc9c6ea94925693321203668bda98111a074bae3651402c75cfc2 e454
8070 2a ec28 00000692 ffeb a9449ae8f436de73ed356d908e12ef9d4b6474367a17c80cfaefaaf2343e2cbc b063
8170 2a ec28 00000692 ffeb 22f95c0a18ab9cd9f6b6dce0973059417b8861dd071f79e4e41b1c1c6d10e07a 57e3
8070 2a ec28 00000692 ffeb 8f258d390d611e7b4f95e73b7816840128f69445d0d5a00963f33de2759bd855 d7e3
There you can plainly see the Entitlement_ID 0x692 and that, along with a 32-byte ecrypted block there's an extra two bytes, currently ffeb.

Current emus don't know how to handle this 0xEC TAG, nor what to do with those two bytes 0xFFEB.

I haven't check whether the EMM handling is different, but it wouldn't suprise me if they have uploaded new keys by some new method at the same time as changing the ECM algo, preventing us from guessing/testing how this 0xEC operates. It'll most likely be down to those who can reverse the STB firmware to work it all out.
 
A

abra26

Senior Member
Messages
263
campag5242 said:
Hi Barney. The Entitlement_ID of this 3rd type of ECM is not hidden, it's there in plain sight. What is different is the ECM_TAG_CW_DESCRIPTOR, now 0xEC.

The original 0xEE ECM_TAG_CW_DESCRIPTOR was simple in structure, check back to colibri's post #16 of this thread:
81: Table ID
70 18: & 0x0FFF -> Section length
EE: Tag ECM_TAG_CW_DESCRIPTOR
16: Length
00 00 16 AB: Entitlement ID
A9 D4 0A 26 FE 79 CB AF: encrypted CW
09 AC 49 F5 B3 42 B3 71: encrypted CW
AA 02: Checksum

For TAG EE, a simple DES ECB decrypt with the key on each 8-byte eCW was sufficient to give usable dCWs.


Then around October '16 came the 0xED ECM TAG with a 32-byte encrypted payload. This time a DES CBC decrypt was required, with the dCWs re-assembled from bytes scattered through this 32 byte block at fixed positions. You can spot the positions in this sequence of decrypted 32-byte blocks:
Code: 
Consecutive ECMS:
81 70 28 ED 26 00 00 00 C9 D0 9A AA 5E 62 7C 99 ED CA 05 C3 19 D2 4D 61 88 4C 26 88 9C 61 20 85 7B 4D F0 79 90 76 DE 16 30 17 E3 
80 70 28 ED 26 00 00 00 C9 F7 4F F2 E4 36 85 92 4F 3B 86 4F AB 5B 25 6A 1D 5C 8E 67 87 B7 53 9B C5 F2 D5 1C 2E 26 66 E5 CB 57 E3 
81 70 28 ED 26 00 00 00 C9 2B 02 B0 19 99 91 B3 24 E7 2E F3 32 5E 92 B2 C5 E3 D0 67 4B 52 E8 48 FA 39 C1 DF 61 F5 E4 7C CC 0A 3C

T C9 01 D097A72F1E367A00 changed from T C9 01 3775D9621C86BC01 simultaneous with algo change!

Decrypted blocks:
3c 27 01 95 38 ba 69 ed 72 24 c7 a2 2a 6c 6a 69 c8 77 28 d6 cd dd 9a 6d 7a d3 9a 10 e3 06 08 26
54 cd 15 6d 38 ba da 36 b7 6b 1e a2 34 ee 69 8f 42 3e 28 d6 be 93 32 42 3c d3 9a d4 6e 06 24 a0
41 b0 15 6d fa 58 4b b3 15 6b dc ec cb ed 69 b7 42 3e 38 a5 d3 e6 32 74 3c cc d8 4f 6b 73 e4 87
Note the bytes which remain unaltered compared to the previous line - those bytes form the odd or even dCW.


Now we have this latest TAG, 0xEC. See these consecutive ECMs taken from ViaHussun's log posted above:
Code: 
8170 2a ec28 00000692 ffeb 00b529ee810dc9c6ea94925693321203668bda98111a074bae3651402c75cfc2 e454
8070 2a ec28 00000692 ffeb a9449ae8f436de73ed356d908e12ef9d4b6474367a17c80cfaefaaf2343e2cbc b063
8170 2a ec28 00000692 ffeb 22f95c0a18ab9cd9f6b6dce0973059417b8861dd071f79e4e41b1c1c6d10e07a 57e3
8070 2a ec28 00000692 ffeb 8f258d390d611e7b4f95e73b7816840128f69445d0d5a00963f33de2759bd855 d7e3
There you can plainly see the Entitlement_ID 0x692 and that, along with a 32-byte ecrypted block there's an extra two bytes, currently ffeb.

Current emus don't know how to handle this 0xEC TAG, nor what to do with those two bytes 0xFFEB.

I haven't check whether the EMM handling is different, but it wouldn't suprise me if they have uploaded new keys by some new method at the same time as changing the ECM algo, preventing us from guessing/testing how this 0xEC operates. It'll most likely be down to those who can reverse the STB firmware to work it all out.
Click to expand...

In this example for entitlement ID 692 is present "FF EB". You can find another example with entitlement ID "84" and you can see that there is "FF E0" so my guess is that it is some identification for some extra codes of map for CW keys or some XOR or another pre-decoding or after-decoding codes... who knows... we can only make theories......

And after better analysing my another theory is that algo for EMM is still old so maybe only new nanoEC is on. ECM keys are probably still the same.
 
Last edited:
K

K2TSET

Senior Member
Messages
125
I did a full BF CSA (48) search for the file FTS-IMG3_EU_11020_H_7200_20170904_1309_VPID-512.ts on PID: 0x200 and no working hit (only 1 false).

So there could be a few reasons:

File could be faulty,
I did a also try to filter all the clear FF FF away and out of 54 MB source file the FF FF are 45 MB and if you filter the 0x200 only the encrypted part it only 4 MB of payload (Pretty bad use of transponder)

The CSA are mayby not 48 but 64... it could be an easy way since the the chksum from the ECM are normal are wrong and corrected, maybe it should not be corrected here?

Or it not CSA..
 
N

nautilus7

VIP
Messages
607
abra26 said:
In this example for entitlement ID 692 is present "FF EB". You can find another example with entitlement ID "84" and you can see that there is "FF E0" so my guess is that it is some identification for some extra codes of map for CW keys or some XOR or another pre-decoding or after-decoding codes... who knows... we can only make theories......

And after better analysing my another theory is that algo for EMM is still old so maybe only new nanoEC is on. ECM keys are probably still the same.
Click to expand...

There is also "FF E9"

Code: 
80 702A EC 28 00000691 FF E9 E100834952088EC6ED47D624CF32650F57DD056534F681CD0C6B6FA61B2219B062EE
80 702A EC 28 00000691 FF E9 E8B3DB08A453555847256EBA0AF0EB770B458909D3F1884736EA31CAA94CD279AFEE
80 702A EC 28 00000691 FF E9 E1BEC3B0F452D0AD054B79EF29F0391C0A339BD338792A2B6AD7AAD83A74C274B463
80 702A EC 28 00000691 FF E9 751E10EB67F2853D3AFA2793B3F739FFE0792D1A9B4863BC8120CA20315C39693152
80 702A EC 28 00000691 FF E9 BB3945ECC3BFBDA626169B2F4A73B0FDB56425D22996F95FF2ED63772DA84B2AE563
80 702A EC 28 00000691 FF E9 6851F11B6CBFB19BD511AFEF12C1CA9A6CFE1880B95B1D530F1550A4F3DDC98317E3
80 702A EC 28 00000691 FF E9 90598986F27351F235CFEF78E89558B8D4FDAA1B81805E9A753CE615F35A63C84864
80 702A EC 28 00000691 FF E9 3B8975A5B4097394DEAD69149F75E702DB3842D779D7E3DF54AB779851995EE49763
 
You must log in or register to reply here.
Top