Only SD files, sorry I didn't make it clear. I haven't tried to get an HD recording off the Foxsat HDD yet - it sounds fiddly from what I've read here: you either have to physically remove the disk and plug it into a Linux-enabled PC or else record in non-Freesat mode (from where you will be limited to 4Gb file size transfer). I'll start transferring HD stuff when somebody comes up with a "cunning plan".

The 4Gb file limt only applies to a fat (PC) file system. No problem with a Linux EXT3 file system usb device

Getting closer:

I have just recoded Nick's test file (without any preprocessing to remove unwanted bits). I installed Haali Media Splitter, and used the most recent version of Super(c) with the DirectShow box ticked. (Windows XP MCE with SP3.)

It isn't perfect. It's watchable, but lip-synch is not quite there. Maybe it would be better with the unwanted bits removed.

The latest version of videoredo TV suite will open Nick123's file, and you can edit it with frame accuracy and make a DVD of it with absolutely no loss of sync (sync is one of videoredo's major strengths). There is no re-encoding either in this case, though it would re-encode with a GOP limit of 15 if you really wanted it to be bomb-proof on old dvd players. This wouldn't take long on a full length file.

After faffing around with free solutions I bought this and never looked back.

A start on a cunning plan would be if someone could figure out why the junk stripper from jack plug runnable in Excel (post 40, and modified for general use by grahamlthompson in post 67) gets kicked out of a HD recording at the point where encryption seems to assert itself (post 69 from son_t). It's such a simple program this seems like spectacular behaviour.

THe following code dumps the last blocks of data (in decimal) junk to col 1 and a to col 2 of worksheet 1. Note I got the nos of bytes wrong in my initial post (forgot VB arrays start at zero). On a SD file the data is all zeros

Public Sub trimTS()

' Dim object to store data
Dim DestSheet As Object
Set DestSheet = Sheets(1)
' Dim Row counter
Dim rowcounter As Integer
rc = 1
' erase contents of sheet 1)
With DestSheet
.Cells.ClearContents
End With
' Dim Loop Counter
Dim LC As Integer

' Dimension array variable junk to hold 4 bytes

Dim junk(3) As Byte

' Dim array variable a to hold 188 bytes

Dim a(187) As Byte

' Dim Single Byte Constant as 47Hex

Const sync_byte As Byte = &H47

' note this declares variable fni and fno out as a variant will work but Dim fni as string, fno as string is more efficient

Dim fni As String, fno As String

fni = Application.GetOpenFilename(, , "File To Open")



fno = Application.GetSaveAsFilename(, , , "File Name To Save")



' open source file to read byte by byte as file 1

Open fni For Binary Access Read As #1

' open destination file to write byte by byte as file 2

Open fno For Binary Access Write As #2

' read first 4 bytes from source file - forgot 0 element

Get #1, , junk

' read next 188 bytes from source file

Get #1, , a
'MsgBox a(0)

' continue until first byte in 188 byte block is not 47Hex

While a(0) = sync_byte
' write 187 byte block to output file
Put #2, , a
' read next 3 bytes from source
Get #1, , junk
' read next 187 bytes from source
Get #1, , a
' loop back to while statement
Wend
' close both source and destination files
Close
' dump the contents of junk and a to sheet 1
For LC = 0 To 3
DestSheet.Cells(rc, 1) = junk(LC)
rc = rc + 1
Next
rc = 1
For LC = 0 To 187
DestSheet.Cells(rc, 2) = a(LC)
rc = rc + 1
Next

End Sub

This should be very handy for anyone trying to figure out the encryption. Nice work!

It won't be me, though, since I got a bit annoyed with all this business and got a Fortec Passion+ ! 7 day epg and no encryption. Marvellous.

I would say it is pretty clunky and wouldn't do as a main pvr, but if you just want it for HD it's good enough atm.

As an aside, how does one convert ts files to mp3

You need to demux the .ts file into the two component video and audio file. Then take the audio file and convert it into MP3...

ProjectX can probably demux the HDR's .ts file for you, once you've pumped that through the m2tstots utility...

Just ran the above code on a short encrypted HD file.

The reason why it bombs out at the start of encryption is that the sync byte value changes and is also not a consistant value.

On the file I tried the sync byte in the first block is C0Hex (192D) and the next block is B5Hex (181D)

That's really interesting. I wouldn't know what to do next apart from pursuing the pattern a bit further--assuming these sequences contains picture data and aren't some sort of block of junk which the humax can understand and cope with but will cause other players to choke.

Hopefully someone will take this further.

I almost wish I had an encrypting box now.

The .ts files almost certainly always start with the 4-byte prefix to the first ts packet. So if you assume this you don't need to search for the sync packet. Just read the first 4 bytes into the header array, and the next 188 into the packet array, then just loop to the end of the file, writing the ts packets as you go. It looks like the encoding scrambles all of the packet, hence the changing sync byte. For those intent on cracking the scrambling it (slightly) helps a known plaintext attack - you know the plaintext for that byte is always 0x47.

Well, I'm slightly lost here. From the first part of what you say it seems that if you just split the file 4:188 you will get rid of the junk. Job done. But then you say (as far as I can see) the header scrambles the rest of the packet, and talk about cracking the scrambling on the basis of known characteristics.

Is cracking the scrambling necessary to getting a working file, or are you talking about revealing the encryption algorithm for the sake of elegance? I'm afraid it's the former, which is well out of my league.

The header may or may not be relevant to cracking the scrambling - I'm just assuming that the variability of the sync byte points to the whole packet being scrambled. I'm also assuming, as you do, that there is genuine scrambling of the packets rather than just some interfering junk within otherwise clear data that could easily be removed. I'm not personally interested in cracking it, except perhaps as an intellectual exercise, as I can record the HD stuff on Mythtv anyway.

There's an easy way to test this theory. I will replace the spurious sync byte of a few hundred blocks with 47H and see if the modified file is playable with a recognisable image.

I did have a quick look at the first two sync bytes at a binary level to see if there was any recognisable pattern and the binary 47H to see if there was some common pattern but could not find one.

Same here--I was so alienated by the restrictions I got a non-freesat box. I don't have a scrambled file, but I don't think I could do it anyway without a shedload of research, if at all, from what you say.

Great-keep us posted!

Not sure if I believe this myself, used the following code to add 200 packets simply replacing the duff sync bytes.

Public Sub trimTS()
' counter for nos of modified packets to write'
Dim modcount As Integer
modcount = 200

' Dim object to store data
Dim DestSheet As Object
Set DestSheet = Sheets(1)
' Dim Row counter
Dim rowcounter As Integer
rc = 1
' erase contents of sheet 1)
With DestSheet
.Cells.ClearContents
End With
' Dim Loop Counter
Dim LC As Integer

' Dimension array variable junk to hold 4 bytes

Dim junk(3) As Byte

' Dim array variable a to hold 188 bytes

Dim a(187) As Byte

' Dim Single Byte Constant as 47Hex

Const sync_byte As Byte = &H47

' note this declares variable fni and fno out as a variant will work but Dim fni as string, fno as string is more efficient

Dim fni As String, fno As String

fni = Application.GetOpenFilename(, , "File To Open")



fno = Application.GetSaveAsFilename(, , , "File Name To Save")



' open source file to read byte by byte as file 1

Open fni For Binary Access Read As #1

' open destination file to write byte by byte as file 2

Open fno For Binary Access Write As #2

' read first 4 bytes from source file - forgot 0 element

Get #1, , junk

' read next 188 bytes from source file

Get #1, , a
'MsgBox a(0)

' continue until first byte in 188 byte block is not 47Hex

While a(0) = sync_byte
' write 187 byte block to output file
Put #2, , a
' read next 3 bytes from source
Get #1, , junk
' read next 187 bytes from source
Get #1, , a
' loop back to while statement
Wend
a(0) = sync_byte
Put #2, , a
' write modified packets
For LC = 1 To modcount - 1
' read first 4 bytes from source file - forgot 0 element

Get #1, , junk

' read next 188 bytes from source file

Get #1, , a
a(0) = sync_byte
Put #2, , a
Next
Close

End Sub

Due to the speed of my laptop vlc playback of HD is a bit choppy but the modified file played all the way to the end.

Is 200 packets enough for a good test, going to try with more.

It works with 10000 extra packets

Really? You mean all the 'encryption' seems to do is scramble the sync bytes and replacing them with a fixed value makes the HD file playable?

Top marks if it works. I was expecting it to be much harder to decode.

Mike

To be sure need to try it with a much bigger file, vba not the ideal language due to file size limitation. Will try with 15 min recording. Watch this space

I'm trying to work here but this is very distracting!

I bring sad news

I set a reservation to record 15 mins of BBC HD preview.

Transferred file is 1942883136 bytes or 10119183 blocks of 192 bytes. Interestingly the first synch byte is not 47 hex (perhaps because it was recorded automatically so no warning required) so I modified code to simply junk 4 bytes, read 188 bytes, change 1st to 47H and transfer 188 bytes to end of file.

It won't play in vlcplayer so no oscar I am afraid.

Rather easier than expected! So easy, in fact, that it looks rather like Humax blowing a large raspberry to whichever control freak insisted on the restriction in the freesat spec!

How did you copy the file? I manually scanned transponder 10847V, selected BBC HD in non-freesat mode & manually recorded 30 sec whilst I had Mythtv recording as well, for comparison purposes. However the recording is marked as not copyable, and I'm not about to undo the HDR to get at the SATA connector just for this test.