try the files ive put on
Those settings allow anyone to piggy back on your line
reeves1985
Inactive User
- Joined
- Oct 10, 2012
- Messages
- 44
- Reaction score
- 4
Sorry mate just picked your pm up and these messages
All you should have to do is unzip and edit the server file with your line details then ftp restart oscam confirm it clears channels
Then run abm.
But saying that I am having troubl on my second receiver not clearing any channels yet I'm using identical oscam and files
So it should work but be prepared it may not
when I ftp then go to config file
my details of my line are not in there
so when I get to config file I open it drag the files you sent ino config file after filling in server file then how do I send them files to me box and also there is 2 newcamd files in there should I delete or leave thanks mate
Might be worth checking out some well known auction sites.............
"Free gift and Teach yourself Lip Reading video included"...........................................................
Not funny I know (well I thought it was), anything to disrupt cs I thinks.......
"Free gift and Teach yourself Lip Reading video included"...........................................................
Not funny I know (well I thought it was), anything to disrupt cs I thinks.......
reeves1985
Inactive User
- Joined
- Oct 10, 2012
- Messages
- 44
- Reaction score
- 4
Delete those newcamd files target were put in by mistake and will contain my line details.
I really don't get what you mean
You don't edit the config file at all
You edit the oscam.server file
Then ftp to your receiver using a ftp program
no but this line
httpallowed = 0.0.0.0 - 255.255.255.255 /////
allows any device on the net to use your line
It should be
httpallowed = 127.0.0.1,192.168.0.0-192.168.255.255
Which will just allow your internal network
how do I remove it of here then thanks
Edit the line with notepad++ then FTP it back to the box
REALDEAL68
New Member ++
- Joined
- Apr 29, 2017
- Messages
- 24
- Reaction score
- 0
what the score on this then guys, proper fix or just temporary, and whats the current method to try-
I have always used Oscam - latest on Vix- Xtrend 8500 ( 2 cable tuners , 2 sat tuners) , and my issue is - recording HD and watching another HD channel ---
channels affected by NAR either fixed with ABM or edited manually- SD fine when recording---
have read all 17 pages about patches , scripts etc, working then next day not---
sorry to go over old ground-
whats the latest?
I have always used Oscam - latest on Vix- Xtrend 8500 ( 2 cable tuners , 2 sat tuners) , and my issue is - recording HD and watching another HD channel ---
channels affected by NAR either fixed with ABM or edited manually- SD fine when recording---
have read all 17 pages about patches , scripts etc, working then next day not---
sorry to go over old ground-
whats the latest?
Well it's been a few days since the audio problems were introduced on Virgin Media and so far we've have only crappy suggestions
such as editing the PID's manually, hacks to ABM with a 'bodge' to replace scanned results with hard coded data... but so far nobody
has explained how original boxes seem unaffected or attempted to understand what the root cause is, knowledge which would required to fix the issue.
To understand the issue we need to first understand some basics.
Using a program like TSReader you can tune to the TP of the affected stream. In this post I will use TSID:28. The frequency this is
on will vary area by area but once found the channels & data will be the same. This transponder contains 2 services of interest:
- SyFy HD
- TCM HD
The reason these are interesting is they both show slightly different symptoms.
- SyFy HD has no audio at all
- TCM HD has audio, but with narrative.
What is happening is the E2 boxes are seeing the narrative audio tracks as normal (which are regular MPEG2 audio), but not seeing the regular audio which is broadcast in AC3 format.
SyFy HD only has a single AC3 audio track, so with this now 'invisible' to E2, we get no sound!
TCM HD has 2 tracks, the AC3 audio track that is 'invisible' to E2, and a regular MPEG2 audio narrative one that it can see - which it
then selects as default.
Using TSReader & a suitable capture you should tune to this TP (or load in some pre-made capture)
We first want to look at the PAT.
PAT on PID 0 (0x0)
The PAT (Program Association Table) is stream of data sent on PID 1. It lists all the services on the current transponder, along with pointers
to each services PMT (Program Map Table). Each PMT contains data that is sent on it's own PID.
The PID of the PMT for TCM HD is: PID 45 (0x002d)
Capture this to file - extract the single repeating packet.
The packet is the standard 188 bytes long. I've removed the tail padding (FF's) for clarity)
The first 5 bytes are headers - for simplicty we will ignore these. The 'payload' data (the stuff we interpret) starts after this.
02 - Table ID
B0 6A - A set of 16 bits broken up below.
0x1 : Section syntax indicator (1 bit)
0x0 : Private bit (1 bit)
0x3 : Reserved bits (2 bits)
0x0 : Section length unused bits (2 bits)
0x6A : Section length (10 bits)
Syntax section/Table data:
For the purpose of this post, I won't explain this here (if you really want to understand it ask later)
We now want to to break down this second level of payload.
0A F4 - Table ID extension
ED - A set of 16 bits broken up as.
0x3: Reserved bits (2 bits)
0x16: Version: 22 (5 bits)
0x1: Current/next indicator (1 bit)
00 Section number
00 Last section number
The verson number will change and could be different by the time you read this... It's just a 5 bit counter that wraps round whenever the packet
changes. DVB devices can use this to know if the packet has changed from the version it already has.
This packet only has 1 section (Section ID: 0)
We now want to to break down this third level of payload.
E1 99 PCR on PID: 409 (0x0199)
F0 0C Length of data to follow (0C) - Top 4 bits are reserved so set to 1, then 2 off
So what we end up with following this is a series of 'Descriptors'.
Descriptors are blocks of 'configuration' data.
They are structured as follows:
Each 'Tag' byte has a specific meaning, for example tag 0x09 is used to specify the ECM PID. As there are 2 versions of Nagravision currently present, we would expect 2 Tag 0x09's, one for each encryption system.
Some code must be written to parse this tags.
So lets look at the 2 simple ECM cases...
Followed by:
Nothing to complicated.
Tag 09 has 4 bytes that follow: 2 that specifiy the CAID this is relevent too, and 2 that contain the PID to look for incoming ECM's on.
Ok, following this we have a section what we call the ES_Info, which contain tags to specify the bits that make up what you see (the video PID, the audo PID's, teletext PID's etc.)
There are a number of these - which we can see in TSReader as follows:
We want to look at the AC3 one, which as you can see is clearly listed - but E2 boxes don't see it (hence 'invisible')
So lets look at our raw hex ES info entry:
This ES_Info is made up of a number of tags, 0x06 been the initial tag, and some sub-tags 0x6A, 0x0A, 0x52
Now this is where the problem is: The tag 0x6A is malformed.
"It specifies a data length of 0x02, which we see the 2 bytes 0xCF and 0x00"
If we use the DVB specification to look at the structure of the AC3 descriptor:
We can see if starts with a tag (0x6A) and length (0x02 in our case)
The next byte that follows this is what is a byte that contains a series of flag.
The lower 4 bits are all reserved (set to 1) so this leaves the upper 4 bits which are defined as follows:
So for each bit that is set to 1, and extra byte must be included/processed
The upper 4 bits of 0xCF in binary are 1100, so this specifies that the the component_type and bsid are set, requiring 2 more data bytes after the 0xCF - but we only have 1 extra byte remaining (a value of 0x00)
So what happens?
Well the 0x00 gets interpreted as the component_type field, and the next byte after is is 0x0A. This is the start of the next descriptor, this gets interpreted as the bsid field.
In TSReader we see this:
AC3 Type is the component_type field, and BSID is 10 in decimal, which in hex is 0x0A (that tag byte of the following descriptor).
At this point we have overflowed the end of the tag 0x6A... so what happens next?
Well this is down to the parser code. After processing the tag 0x6A, how do we locate the next tag:
2 ways:
1. Assume the next tag starts after the end of the first tag. This is what should happen in normal case.
2. Take the start of the current tag on, and add '2 + the value of <TAG DATA LENGTH>.
If the parser code follows option 1 - then it will start trying to parse the next tag 1 byte to late, and will interpret it as nonsense, and end up discarding it - which is what I suspect E2 is doing.
If the parser code follows option 2 - then the next tag will start at the correct position. The byte 0x0A will be 're-used', as it's both the data at the end of the last tag and the tag byte of the next descriptor. The remaining tags which specify the language ('eng') etc. will be processed correctly.
This is probably accidental rather than by design. My guess is the bsid bit it not supposed to be set... but since it is this is what happens.
I refer to these tags as 'overlapped' tags. I guess E2 cannot handle these overlapped tags correctly, where as official boxes can.
There are some simple code hacks that could allow the parser of E2 to code with these malformed overlapped tags correctly, or they could do a propper job. Thats assuming they do anything at all.
I find it funny that VM try so hard to secure there system, then during a routine upgrade accidently break all the E2 Linux boxes, I really don't know if I should congratulate them on this or slap them for a dirty interpretation of the DVB specification.
I'd like to say sorry to Rat but I did say he probably would not understand my post
Hackmax
PS I will update this post to fix typo's and better explain things but it's close to 4am.
such as editing the PID's manually, hacks to ABM with a 'bodge' to replace scanned results with hard coded data... but so far nobody
has explained how original boxes seem unaffected or attempted to understand what the root cause is, knowledge which would required to fix the issue.
To understand the issue we need to first understand some basics.
Using a program like TSReader you can tune to the TP of the affected stream. In this post I will use TSID:28. The frequency this is
on will vary area by area but once found the channels & data will be the same. This transponder contains 2 services of interest:
- SyFy HD
- TCM HD
The reason these are interesting is they both show slightly different symptoms.
- SyFy HD has no audio at all
- TCM HD has audio, but with narrative.
What is happening is the E2 boxes are seeing the narrative audio tracks as normal (which are regular MPEG2 audio), but not seeing the regular audio which is broadcast in AC3 format.
SyFy HD only has a single AC3 audio track, so with this now 'invisible' to E2, we get no sound!
TCM HD has 2 tracks, the AC3 audio track that is 'invisible' to E2, and a regular MPEG2 audio narrative one that it can see - which it
then selects as default.
Using TSReader & a suitable capture you should tune to this TP (or load in some pre-made capture)
We first want to look at the PAT.
PAT on PID 0 (0x0)
Code:
You don't have permission to view the code content. Log in or register now.The PAT (Program Association Table) is stream of data sent on PID 1. It lists all the services on the current transponder, along with pointers
to each services PMT (Program Map Table). Each PMT contains data that is sent on it's own PID.
The PID of the PMT for TCM HD is: PID 45 (0x002d)
Code:
You don't have permission to view the code content. Log in or register now.Capture this to file - extract the single repeating packet.
The packet is the standard 188 bytes long. I've removed the tail padding (FF's) for clarity)
Code:
You don't have permission to view the code content. Log in or register now.The first 5 bytes are headers - for simplicty we will ignore these. The 'payload' data (the stuff we interpret) starts after this.
02 - Table ID
B0 6A - A set of 16 bits broken up below.
0x1 : Section syntax indicator (1 bit)
0x0 : Private bit (1 bit)
0x3 : Reserved bits (2 bits)
0x0 : Section length unused bits (2 bits)
0x6A : Section length (10 bits)
Syntax section/Table data:
Code:
You don't have permission to view the code content. Log in or register now.For the purpose of this post, I won't explain this here (if you really want to understand it ask later)
We now want to to break down this second level of payload.
0A F4 - Table ID extension
ED - A set of 16 bits broken up as.
0x3: Reserved bits (2 bits)
0x16: Version: 22 (5 bits)
0x1: Current/next indicator (1 bit)
00 Section number
00 Last section number
The verson number will change and could be different by the time you read this... It's just a 5 bit counter that wraps round whenever the packet
changes. DVB devices can use this to know if the packet has changed from the version it already has.
This packet only has 1 section (Section ID: 0)
Code:
You don't have permission to view the code content. Log in or register now.We now want to to break down this third level of payload.
E1 99 PCR on PID: 409 (0x0199)
F0 0C Length of data to follow (0C) - Top 4 bits are reserved so set to 1, then 2 off
So what we end up with following this is a series of 'Descriptors'.
Descriptors are blocks of 'configuration' data.
They are structured as follows:
Code:
You don't have permission to view the code content. Log in or register now.Each 'Tag' byte has a specific meaning, for example tag 0x09 is used to specify the ECM PID. As there are 2 versions of Nagravision currently present, we would expect 2 Tag 0x09's, one for each encryption system.
Some code must be written to parse this tags.
So lets look at the 2 simple ECM cases...
Code:
You don't have permission to view the code content. Log in or register now.Followed by:
Code:
You don't have permission to view the code content. Log in or register now.Nothing to complicated.
Tag 09 has 4 bytes that follow: 2 that specifiy the CAID this is relevent too, and 2 that contain the PID to look for incoming ECM's on.
Ok, following this we have a section what we call the ES_Info, which contain tags to specify the bits that make up what you see (the video PID, the audo PID's, teletext PID's etc.)
There are a number of these - which we can see in TSReader as follows:
Code:
You don't have permission to view the code content. Log in or register now.We want to look at the AC3 one, which as you can see is clearly listed - but E2 boxes don't see it (hence 'invisible')
Code:
You don't have permission to view the code content. Log in or register now.So lets look at our raw hex ES info entry:
Code:
You don't have permission to view the code content. Log in or register now.This ES_Info is made up of a number of tags, 0x06 been the initial tag, and some sub-tags 0x6A, 0x0A, 0x52
Now this is where the problem is: The tag 0x6A is malformed.
"It specifies a data length of 0x02, which we see the 2 bytes 0xCF and 0x00"
If we use the DVB specification to look at the structure of the AC3 descriptor:
Code:
You don't have permission to view the code content. Log in or register now.We can see if starts with a tag (0x6A) and length (0x02 in our case)
The next byte that follows this is what is a byte that contains a series of flag.
The lower 4 bits are all reserved (set to 1) so this leaves the upper 4 bits which are defined as follows:
Code:
You don't have permission to view the code content. Log in or register now.So for each bit that is set to 1, and extra byte must be included/processed
The upper 4 bits of 0xCF in binary are 1100, so this specifies that the the component_type and bsid are set, requiring 2 more data bytes after the 0xCF - but we only have 1 extra byte remaining (a value of 0x00)
So what happens?
Well the 0x00 gets interpreted as the component_type field, and the next byte after is is 0x0A. This is the start of the next descriptor, this gets interpreted as the bsid field.
In TSReader we see this:
Code:
You don't have permission to view the code content. Log in or register now.AC3 Type is the component_type field, and BSID is 10 in decimal, which in hex is 0x0A (that tag byte of the following descriptor).
At this point we have overflowed the end of the tag 0x6A... so what happens next?
Well this is down to the parser code. After processing the tag 0x6A, how do we locate the next tag:
2 ways:
1. Assume the next tag starts after the end of the first tag. This is what should happen in normal case.
2. Take the start of the current tag on, and add '2 + the value of <TAG DATA LENGTH>.
If the parser code follows option 1 - then it will start trying to parse the next tag 1 byte to late, and will interpret it as nonsense, and end up discarding it - which is what I suspect E2 is doing.
If the parser code follows option 2 - then the next tag will start at the correct position. The byte 0x0A will be 're-used', as it's both the data at the end of the last tag and the tag byte of the next descriptor. The remaining tags which specify the language ('eng') etc. will be processed correctly.
This is probably accidental rather than by design. My guess is the bsid bit it not supposed to be set... but since it is this is what happens.
I refer to these tags as 'overlapped' tags. I guess E2 cannot handle these overlapped tags correctly, where as official boxes can.
There are some simple code hacks that could allow the parser of E2 to code with these malformed overlapped tags correctly, or they could do a propper job. Thats assuming they do anything at all.
I find it funny that VM try so hard to secure there system, then during a routine upgrade accidently break all the E2 Linux boxes, I really don't know if I should congratulate them on this or slap them for a dirty interpretation of the DVB specification.
I'd like to say sorry to Rat but I did say he probably would not understand my post
Hackmax
PS I will update this post to fix typo's and better explain things but it's close to 4am.
Last edited by a moderator:
Great to see a post like this again where a member yet again shows he knows his stuff. I found it a really interesting read even though there are major gaps in my understanding of it. Always wanted to know more about this side of things but getting on a bit now. Years ago nozzer started an au tutorial thread here, I sometimes revisit it but still don't get it.
eamondo
Member ++
- Joined
- Mar 9, 2007
- Messages
- 257
- Reaction score
- 3
The big part of that post is this
"There are some simple code hacks that could allow the parser of E2 to code with these malformed overlapped tags correctly, or they could do a proper job. Thats assuming they do anything at all."
The question is can we get the hack to allow our E2 boxes to handle this and if so when would that be available. i have been watching closely without making any changes at all. Happy with SD for now. i have seen some users lose everything and then having to revert which indicates waste of time with oscam fix.
i think its a waiting game to see what the future holds but for now sit tight until the people who understand the encryption have a solution
"There are some simple code hacks that could allow the parser of E2 to code with these malformed overlapped tags correctly, or they could do a proper job. Thats assuming they do anything at all."
The question is can we get the hack to allow our E2 boxes to handle this and if so when would that be available. i have been watching closely without making any changes at all. Happy with SD for now. i have seen some users lose everything and then having to revert which indicates waste of time with oscam fix.
i think its a waiting game to see what the future holds but for now sit tight until the people who understand the encryption have a solution
Well it's been a few days since the audio problems were introduced on Virgin Media and so far we've have only crappy suggestions
such as editing the PID's manually, hacks to ABM with a 'bodge' to replace scanned results with hard coded data... but so far nobody
has explained how original boxes seem unaffected or attempted to understand what the root cause is, knowledge which would required to fix the issue.
To understand the issue we need to first understand some basics.
Using a program like TSReader you can tune to the TP of the affected stream. In this post I will use TSID:28. The frequency this is
on will vary area by area but once found the channels & data will be the same. This transponder contains 2 services of interest:
- SyFy HD
- TCM HD
The reason these are interesting is they both show slightly different symptoms.
- SyFy HD has no audio at all
- TCM HD has audio, but with narrative.
What is happening is the E2 boxes are seeing the narrative audio tracks as normal (which are regular MPEG2 audio), but not seeing the regular audio which is broadcast in AC3 format.
SyFy HD only has a single AC3 audio track, so with this now 'invisible' to E2, we get no sound!
TCM HD has 2 tracks, the AC3 audio track that is 'invisible' to E2, and a regular MPEG2 audio narrative one that it can see - which it
then selects as default.
Using TSReader & a suitable capture you should tune to this TP (or load in some pre-made capture)
We first want to look at the PAT.
PAT on PID 0 (0x0)
Code:You don't have permission to view the code content. Log in or register now.
The PAT (Program Association Table) is stream of data sent on PID 1. It lists all the services on the current transponder, along with pointers
to each services PMT (Program Map Table). Each PMT contains data that is sent on it's own PID.
The PID of the PMT for TCM HD is: PID 45 (0x002d)
Code:You don't have permission to view the code content. Log in or register now.
Capture this to file - extract the single repeating packet.
The packet is the standard 188 bytes long. I've removed the tail padding (FF's) for clarity)
Code:You don't have permission to view the code content. Log in or register now.
The first 5 bytes are headers - for simplicty we will ignore these. The 'payload' data (the stuff we interpret) starts after this.
02 - Table ID
B0 6A - A set of 16 bits broken up below.
0x1 : Section syntax indicator (1 bit)
0x0 : Private bit (1 bit)
0x3 : Reserved bits (2 bits)
0x0 : Section length unused bits (2 bits)
0x6A : Section length (10 bits)
Syntax section/Table data:
Code:You don't have permission to view the code content. Log in or register now.
For the purpose of this post, I won't explain this here (if you really want to understand it ask later)
We now want to to break down this second level of payload.
0A F4 - Table ID extension
ED - A set of 16 bits broken up as.
0x3: Reserved bits (2 bits)
0x16: Version: 22 (5 bits)
0x1: Current/next indicator (1 bit)
00 Section number
00 Last section number
The verson number will change and could be different by the time you read this... It's just a 5 bit counter that wraps round whenever the packet
changes. DVB devices can use this to know if the packet has changed from the version it already has.
This packet only has 1 section (Section ID: 0)
Code:You don't have permission to view the code content. Log in or register now.
We now want to to break down this third level of payload.
E1 99 PCR on PID: 409 (0x0199)
F0 0C Length of data to follow (0C) - Top 4 bits are reserved so set to 1, then 2 off
So what we end up with following this is a series of 'Descriptors'.
Descriptors are blocks of 'configuration' data.
They are structured as follows:
Code:You don't have permission to view the code content. Log in or register now.
Each 'Tag' byte has a specific meaning, for example tag 0x09 is used to specify the ECM PID. As there are 2 versions of Nagravision currently present, we would expect 2 Tag 0x09's, one for each encryption system.
Some code must be written to parse this tags.
So lets look at the 2 simple ECM cases...
Code:You don't have permission to view the code content. Log in or register now.
Followed by:
Code:You don't have permission to view the code content. Log in or register now.
Nothing to complicated.
Tag 09 has 4 bytes that follow: 2 that specifiy the CAID this is relevent too, and 2 that contain the PID to look for incoming ECM's on.
Ok, following this we have a section what we call the ES_Info, which contain tags to specify the bits that make up what you see (the video PID, the audo PID's, teletext PID's etc.)
There are a number of these - which we can see in TSReader as follows:
Code:You don't have permission to view the code content. Log in or register now.
We want to look at the AC3 one, which as you can see is clearly listed - but E2 boxes don't see it (hence 'invisible')
Code:You don't have permission to view the code content. Log in or register now.
So lets look at our raw hex ES info entry:
Code:You don't have permission to view the code content. Log in or register now.
This ES_Info is made up of a number of tags, 0x06 been the initial tag, and some sub-tags 0x6A, 0x0A, 0x52
Now this is where the problem is: The tag 0x6A is malformed.
It specifies a data length of 0x02, which we see the 2 bytes 0xCF and 0x0010
If we use the DVB specification to look at the structure of the AC3 descriptor:
Code:You don't have permission to view the code content. Log in or register now.
We can see if starts with a tag (0x6A) and length (0x02 in our case)
The next byte that follows this is what is a byte that contains a series of flag.
The lower 4 bits are all reserved (set to 1) so this leaves the upper 4 bits which are defined as follows:
Code:You don't have permission to view the code content. Log in or register now.
So for each bit that is set to 1, and extra byte must be included/processed
The upper 4 bits of 0xCF in binary are 1100, so this specifies that the the component_type and bsid are set, requiring 2 more data bytes after the 0xCF - but we only have 1 extra byte remaining (a value of 0x00)
So what happens?
Well the 0x00 gets interpreted as the component_type field, and the next byte after is is 0x0A. This is the start of the next descriptor, this gets interpreted as the bsid field.
In TSReader we see this:
Code:You don't have permission to view the code content. Log in or register now.
AC3 Type is the component_type field, and BSID is 10 in decimal, which in hex is 0x0A (that tag byte of the following descriptor).
At this point we have overflowed the end of the tag 0x6A... so what happens next?
Well this is down to the parser code. After processing the tag 0x6A, how do we locate the next tag:
2 ways:
1. Assume the next tag starts after the end of the first tag. This is what should happen in normal case.
2. Take the start of the current tag on, and add '2 + the value of <TAG DATA LENGTH>.
If the parser code follows option 1 - then it will start trying to parse the next tag 1 byte to late, and will interpret it as nonsense, and end up discarding it - which is what I suspect E2 is doing.
If the parser code follows option 2 - then the next tag will start at the correct position. The byte 0x0A will be 're-used', as it's both the data at the end of the last tag and the tag byte of the next descriptor. The remaining tags which specify the language ('eng') etc. will be processed correctly.
This is probably accidental rather than by design. My guess is the bsid bit it not supposed to be set... but since it is this is what happens.
I refer to these tags as 'overlapped' tags. I guess E2 cannot handle these overlapped tags correctly, where as official boxes can.
There are some simple code hacks that could allow the parser of E2 to code with these malformed overlapped tags correctly, or they could do a propper job. Thats assuming they do anything at all.
I find it funny that VM try so hard to secure there system, then during a routine upgrade accidently break all the E2 Linux boxes, I really don't know if I should congratulate them on this or slap them for a dirty interpretation of the DVB specification.
I'd like to say sorry to Rat but I did say he probably would not understand my post
Hackmax
PS I will update this post to fix typo's and better explain things but it's close to 4am.
Do you mind if I post this over at the OpenVix forum as it might help them fix the issue?
I will obviously say that it was your work
