H2H Movie channels audio stream NAR on

[hackmax]

It's amazing I've already seen people misinterpret this post and describe it an "Encryption changes".... This is NOT encryption this is configuration data. The DVB specification says how data should be transmitted, including the tables that tell the DVB device where to find information (such as audio streams) and how to interpret the raw data (mpeg2 audio or ac3 etc.)

This is a tweak or minor violation on the format of this configuration data, not encryption data. You know who you are eamondo @ techkings.

 

[hackmax]

I wanted to edit my post to correct some typos but it seems I can no longer edit it

 

[Rat]

It's obvious to me who understands the format

 

[eamondo]

hackmax im just trying to get people to wait. i dont understand the difference between encryption and configuration. what you rputting up looks like encryption to me.

i appreciate you update i will amend my post

 

[hackmax]

hackmax im just trying to get people to wait. i dont understand the difference between encryption and configuration. what you rputting up looks like encryption to me.

i appreciate you update i will amend my post

http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.11.01_60/en_300468v011101p.pdf

This is a version of the spec.

Table D.2: AC-3 descriptor syntax

This is the important table - this specifies the format of the AC3 Descriptor Tag 0x6A that VM have malformed.

A quick and dirty fix to get the tags to process correctly again would be to add a hack into the part that processes this specific tag:

You don't have permission to view the code content. Log in or register now.

 

[eamondo]

So you said in your first post the reason the E2 boxes cant read the AC3 output is because of overlapping configuration. What reads that and why can it not do it anymore?

 

[hackmax]

There parser assumes the tags don't overlap and the next one starts directly after the end of the first one. So processing the first one should leave them pointing at the start of the second one. With overlapped/malformed tags this is no longer case.

The pointer to the start of the 'next' tag should be calculated by adding the size of the 'advertised' length onto the starts 'current tag'.

 

[eamondo]

max...

Does ATV and VIX etc need to change there firmware and add this hack to it? is that what we are all waiting on?

 

[eamondo]

There parser assumes the tags don't overlap and the next one starts directly after the end of the first one. So processing the first one should leave them pointing at the start of the second one. With overlapped/malformed tags this is no longer case.

The pointer to the start of the 'next' tag should be calculated by adding the size of the 'advertised' length onto the starts 'current tag'.

So the parser doesnt know when the tag starts and ends ? does the parser run from the image?

 

[JonMMM]

max...

Does ATV and VIX etc need to change there firmware and add this hack to it? is that what we are all waiting on?

I am not sure that they can as that might mess up other countries

 

[hackmax]

max...

Does ATV and VIX etc need to change there firmware and add this hack to it? is that what we are all waiting on?

Well it's my best guess based on the fact the malformed/overlapping tags will confuse many parsers. I know some of my own tools I got here 'borked' at the malformed descriptors for the same reason.

 

[hackmax]

I am not sure that they can as that might mess up other countries

The dirty fix I posed would only affect this specific situation. To affect other countries they would have to be malformed in exactly the same way. The reason I call it dirty is for that reason ... it covers one case and one case only.

And given the number of 'hacks' in the E2 codebase already I'd think adding one more hack would go unnoticed. It would be like just one more set of road works on the motorway.... people expect them by now so wouldn't question it.

 

[JonMMM]

The dirty fix I posed would only affect this specific situation. To affect other countries they would have to be malformed in exactly the same way. The reason I call it dirty is for that reason ... it covers one case and one case only.

And given the number of 'hacks' in the E2 codebase already I'd think adding one more hack would go unnoticed. It would be like just one more set of road works on the motorway.... people expect them by now so wouldn't question it.

Sounds great so 2 lines of code will solve all our problems, really need to get this out the the firmware teams

 

[eamondo]

This information would be so valuable in the right forums max...do you have access to vix forum to post this?

 

[hackmax]

Sounds great so 2 lines of code will solve all our problems, really need to get this out the the firmware teams

My code was only pseudo code ... I've not looked at the real E2 code to see how/where they would implement it ... but yeah just a few lines to handle this bug could solve it.

 

[Napster]

I'm just lost, I wish this fix was a matter of clinking a apk or exe file all this adding code does my head in

 

[hackmax]

Can somebody edit my main post for me:

"It specifies a data length of 0x02, which we see the 2 bytes 0xCF and 0x0010"

Should read:

It specifies a data length of 0x02, which we see the 2 bytes 0xCF and 0x00"

Not sure where the extra 10 came from on the end - typing @ 3.30am ffs.

 

[eamondo]

max again sorry for misinterpreting your post I have amended it on my end.

i appreciate the updates its the best information i have had on this to date. Also give me hope image providers will find a similar solution to you

 

[hackmax]

I'm just lost, I wish this fix was a matter of clinking a apk or exe file all this adding code does my head in

Well this information is now in the public domain - it's just a matter of the teams who make images implementing it (either dirty fix or proper, depending on the code quality and skill level)

Just wait back and you may see some new images posted.

 

[eamondo]

out of curiosity is anyone tested using amiko firmware thats not E2