Hacking CA system challenge *Tandberg [ NO Keys Allowed in Chat Section/s ]*
- Thread starter Colibri.DVB
- Start date
Wich packets are needed to get the best recorded *.ts file in Tandberg encryption system ?
Does it need all the packet pids in the recording file *.ts to get ECM and EMM keys ?
Should the below pids inculded in the *.ts file ?
PAT
CAT
NIT
SDT
EIT
TDT
PMT
Audio
MPEG Audio
MPEG2 Video {DVB-S,SD,MPEG2,QPSK}
H.264 Video {DVB-S2,HD,MPEG4,8PSK}
PCR
Null Packets
Does it need all the packet pids in the recording file *.ts to get ECM and EMM keys ?
Should the below pids inculded in the *.ts file ?
PAT
CAT
NIT
SDT
EIT
TDT
PMT
Audio
MPEG Audio
MPEG2 Video {DVB-S,SD,MPEG2,QPSK}
H.264 Video {DVB-S2,HD,MPEG4,8PSK}
PCR
Null Packets
Last edited:
just found a good info
Code:
[B]
The [COLOR="Blue"]EMM Pid[/COLOR] can be found in [COLOR="Red"]CAT table[/COLOR] with PID value [COLOR="Red"]0x0001[/COLOR] under [COLOR="Purple"]CA Descriptor[/COLOR].
While the [COLOR="Blue"]ECM PIDs[/COLOR] can be found in [COLOR="Purple"]CA Descriptor[/COLOR] under [COLOR="Red"]PMT[/COLOR].[/B]see the picture below from ts_0100_12689H_28499_prg19.ts
*******
*******
Not sure which program you can chose which pids to record,but as a must,a PAT and PMT should be present in a TS in order to find ECM pid.Then CAT shows EMM pid.
I saw many devices and programs not following this rule,though.
JimBizkit
In raw EMM mode,I guess only binary files are accepted,not text logs,correct?
I saw many devices and programs not following this rule,though.
JimBizkit
In raw EMM mode,I guess only binary files are accepted,not text logs,correct?
Here some shots taken from DVB players to show how the setting is made
ProgDVB pro 6.11
DVB Dream
ALT DVB
Wish this will help the members
Cheers !!!
Yes, only binary files at the moment.
Text file support can be added, but then I need to know how your text files look like.
@harshy
as long as the recorded ts at least contains CAT and EMM you can record with any tool you like.
Last edited:
Is not a problem,JimBizkit.
Text log files makes it easier for me to see the data (binary is not a problem either)
But that's my specific case,not asking to change things around for a single case.
Raw EMM mode works wonders as it is.
You can record EMM for hours and will not produce a super big file like a TS,and specially with HD content.
Way easier to handle.
Text log files makes it easier for me to see the data (binary is not a problem either)
But that's my specific case,not asking to change things around for a single case.
Raw EMM mode works wonders as it is.
You can record EMM for hours and will not produce a super big file like a TS,and specially with HD content.
Way easier to handle.
TheHighLander
Super VIP
- Messages
- 4,144
I think the best to record ts files is TSWriter module (but you must inactive other plugins such as vPlug) and record mux through TSReader.
http://www.sat-universe.com/showpost.php?p=1035635&postcount=2
http://www.sat-universe.com/showpost.php?p=1035635&postcount=2
Trying to figure this out
Morning, Afternoon, Evening, depending on where you are!
I have been trying to figure this out since I stumbled upon it yesterday.
I am a user in the US with a DVB card using DVBDream. I record a stream from 103 W SES3. 3760-H-30000. I am using the stream recorder module and it generates a large file very fast.I use poc 1.6 and here are the results:
poc test.ts 4112 text.txt
poc 1.6
TS mode
[Emu] info: FFDecsa parallel mode = 32
[Emu] stream found emm_pid: 1F4
[Emu] got EMM nano tag E0 (EMM_TAG_RECEIVER_ALLOCATION_DESCRIPTOR) for the first
time
[Emu] got EMM nano tag E4 (EMM_TAG_SECURITY_TABLE_DESCRIPTOR) for the first time
[Emu] Keys found in EMM: new nano E4 ram keys 30 to 3F
[Emu] Keys found in EMM: new nano E4 ram keys 0 to F
[Emu] Keys found in EMM: new nano E4 ram keys 10 to 1F
[Emu] Keys found in EMM: new nano E4 ram keys 20 to 2F
[Emu] Keys found in EMM: new nano E4 ram keys 30 to 3F
The TEXT.txt file is always empty.
How long do I have to record?
Is the TEXT.txt from my example supposed to give me CWs?
Am I missing software,modules, etc..that would help me?
I realize this is a challenge from Colibre but any help is appreciated.
Morning, Afternoon, Evening, depending on where you are!
I have been trying to figure this out since I stumbled upon it yesterday.
I am a user in the US with a DVB card using DVBDream. I record a stream from 103 W SES3. 3760-H-30000. I am using the stream recorder module and it generates a large file very fast.I use poc 1.6 and here are the results:
poc test.ts 4112 text.txt
poc 1.6
TS mode
[Emu] info: FFDecsa parallel mode = 32
[Emu] stream found emm_pid: 1F4
[Emu] got EMM nano tag E0 (EMM_TAG_RECEIVER_ALLOCATION_DESCRIPTOR) for the first
time
[Emu] got EMM nano tag E4 (EMM_TAG_SECURITY_TABLE_DESCRIPTOR) for the first time
[Emu] Keys found in EMM: new nano E4 ram keys 30 to 3F
[Emu] Keys found in EMM: new nano E4 ram keys 0 to F
[Emu] Keys found in EMM: new nano E4 ram keys 10 to 1F
[Emu] Keys found in EMM: new nano E4 ram keys 20 to 2F
[Emu] Keys found in EMM: new nano E4 ram keys 30 to 3F
The TEXT.txt file is always empty.
How long do I have to record?
Is the TEXT.txt from my example supposed to give me CWs?
Am I missing software,modules, etc..that would help me?
I realize this is a challenge from Colibre but any help is appreciated.
The principal reason to have raw EMM mode in poc is because you can log ONLY emm in binary format for hours and won't make a file bigger than 30 mb or 50 mb.
Recording a TS for hours makes a big file,and bigger if is HD.
So,those interested should build a setup to record ONLY emm,vplug can do.
In dreambox,you can use dvbsnoop using the options "-b"
as an example,in telnet
dvbsnoop -b -n 1 0x1F4 > /media/hdd/emm.bin
the option "-n 1" mean it will dump 1 emm packet,you surely must set this value high,maybe 10000 or more,I suggest you test different values since it is not known when the 0x83 packets show up in the stream.
There is a way you can look ONLY for 0x83 packets by making it search for the string "008370" with dvbsnoop.
This mode would be useful to leave it overnight,and use time stamps to see the frequency of the packets,but it won't be useful without collecting the base emm key that is used to decrypt it.
Recording a TS for hours makes a big file,and bigger if is HD.
So,those interested should build a setup to record ONLY emm,vplug can do.
In dreambox,you can use dvbsnoop using the options "-b"
as an example,in telnet
dvbsnoop -b -n 1 0x1F4 > /media/hdd/emm.bin
the option "-n 1" mean it will dump 1 emm packet,you surely must set this value high,maybe 10000 or more,I suggest you test different values since it is not known when the 0x83 packets show up in the stream.
There is a way you can look ONLY for 0x83 packets by making it search for the string "008370" with dvbsnoop.
This mode would be useful to leave it overnight,and use time stamps to see the frequency of the packets,but it won't be useful without collecting the base emm key that is used to decrypt it.
Last edited:
I recorded a TS file from a Director H264 channel, and DemuxToyLite only shows a ECM stream (no EMM stream).
Also, it detects General Instrument (motorola) system (see image).
I think Director is not the same than Tandberg..
Nicovil
Look at the CAT,if the CA id is 0x1010,its Tandberg.
In fact ANY CA id you see between 0x1000 to 0x10FF is Tandberg.
But you do not see that.
You clearly see 0x4749,which is NOT tandberg,is GI.
GI uses the range 0x4700 to 0x47FF
Not sure what's your confusion,different security providers have assigned a different CA id,this are clearly not related.
That is clearly NOT a Director channel.
And whenever you see this posted as Director,is clearly wrong.It is possible this channel was,some time ago,using Director,and another possibility is is symulcrypt both,GI and tandberg,but not by the picture you are showing.
If the receiver is showing this channel as tandberg,is clearly the case the receiver firmware uses a CA id list that is WRONG.
Source : ETSI
_http://www.dvbservices.com/identifiers/ca_system_id?page=1
Look at the CAT,if the CA id is 0x1010,its Tandberg.
In fact ANY CA id you see between 0x1000 to 0x10FF is Tandberg.
But you do not see that.
You clearly see 0x4749,which is NOT tandberg,is GI.
GI uses the range 0x4700 to 0x47FF
Not sure what's your confusion,different security providers have assigned a different CA id,this are clearly not related.
That is clearly NOT a Director channel.
And whenever you see this posted as Director,is clearly wrong.It is possible this channel was,some time ago,using Director,and another possibility is is symulcrypt both,GI and tandberg,but not by the picture you are showing.
If the receiver is showing this channel as tandberg,is clearly the case the receiver firmware uses a CA id list that is WRONG.
Source : ETSI
_http://www.dvbservices.com/identifiers/ca_system_id?page=1
Last edited:
Hi!
My confusion was because the page I query for tp shows that:
It says "Director", but it's wrong, it is really DC2 as you said.
ViaHussun
Donating Member
- Messages
- 4,098
dale_para_bajo
Well Known Member
- Messages
- 646
@kebien
I been reading you. Did you had any luck finding the "0x83 packets" on your logs for America?
I to have signal some what weak, but I try it any way. Stupid mean I recorded whole night of wrong Pid $01ff. I will try again latter.
I been reading you. Did you had any luck finding the "0x83 packets" on your logs for America?
I to have signal some what weak, but I try it any way. Stupid mean I recorded whole night of wrong Pid $01ff. I will try again latter.