Options
9200T Hard Drive Analysis
![[Deleted User]](https://wc.vanillicon.com/v2/c832bb1c8d3d202ff0915947bd501ce3.svg)
[Deleted User]
Posts: 4,131 Forum Member
✭✭✭
As promised (in this thread http://forum.digitalspy.co.uk/board/showthread.php?t=372944) here are some preliminary tests, results and ideas...
Thanks to marcdavis and phew here are details of using the TwinRip software...
Just like Marc, once the TwinRip (TDU 1-6.exe) runs and changing the drive to 1 (the Hummy's attached drive) - where do we go from here? All I get is the info in this JPEG, here: http://roo.st-andrews.ac.uk/humax/twinrip1.jpg
The partitions are definitely different from Marc findings (in this thread: http://www.hummy.org.uk/forum/viewtopic.php?t=156&postdays=0&postorder=asc&highlight=twinrip&start=0) which I expected as he used his original 160Gb and the one I have is a standard 250Gb, and are:
P1 0x00005960
P2 0x1C740000
P3 0x1C7C0000
From what this screen seems to say, is that the hard disk format in the 9200T is not AVFS...
I have a version of Ontrack's EasyRecovery software which is a set of data recovery tools. There is a raw disk recovery utility which attempts to read any disk and recover files via their formats. Unfortunately, in the list of formats it can detect, there is no transport stream data format, so I didn't feel it could retrieve anything useful from the disk.
I downloaded the lastest version of this from Ontrack's website and ran it on the disk. It thought it could detect five different files (IQY, EXE, MOF, DB and BMP) - see http://roo.st-andrews.ac.uk/humax/ontracktrial.jpg - but since it was a trial piece of software, I could not use it to recover any of the files. My old version of EasyRecovery only detected one file type, and that was ANM, see http://roo.st-andrews.ac.uk/humax/ontrack.jpg. I did try to recover two of these files but couldn't play them or find out what exactly their file types were...
My idea is related to this 'raw' recovery. If a raw recovery like Ontrack's method is possible then a track by track analysis of the HDD for the 'transport stream' file structure will surely result in our recorded programmes files.
The three problems that need further investigation are:
1. How do we do a 'raw disk' analysis.
2. How to we detect a ts file (first thing is to find out what this structure is).
3. How we copy this ts file completely to a formatted disk.
[The easiest way to do this is to talk to Ontrack to see if they can include this file format in their software, if so wait for them to release the new edition and purchase and use!]
The hard way will be to learn the three points above and write a simple program to do this... who is willing?
I have access to another data recovery program called R-Studio and will have ago on the Hummy's HDD once I am in work. We will see what results this brings...
I will also try parish's dd command, maybe this is a method of reading the raw disk which will result in a file which we can further priocess to extract the ts data...
Any other ideas?
Thanks to marcdavis and phew here are details of using the TwinRip software...
Just like Marc, once the TwinRip (TDU 1-6.exe) runs and changing the drive to 1 (the Hummy's attached drive) - where do we go from here? All I get is the info in this JPEG, here: http://roo.st-andrews.ac.uk/humax/twinrip1.jpg
The partitions are definitely different from Marc findings (in this thread: http://www.hummy.org.uk/forum/viewtopic.php?t=156&postdays=0&postorder=asc&highlight=twinrip&start=0) which I expected as he used his original 160Gb and the one I have is a standard 250Gb, and are:
P1 0x00005960
P2 0x1C740000
P3 0x1C7C0000
From what this screen seems to say, is that the hard disk format in the 9200T is not AVFS...
I have a version of Ontrack's EasyRecovery software which is a set of data recovery tools. There is a raw disk recovery utility which attempts to read any disk and recover files via their formats. Unfortunately, in the list of formats it can detect, there is no transport stream data format, so I didn't feel it could retrieve anything useful from the disk.
I downloaded the lastest version of this from Ontrack's website and ran it on the disk. It thought it could detect five different files (IQY, EXE, MOF, DB and BMP) - see http://roo.st-andrews.ac.uk/humax/ontracktrial.jpg - but since it was a trial piece of software, I could not use it to recover any of the files. My old version of EasyRecovery only detected one file type, and that was ANM, see http://roo.st-andrews.ac.uk/humax/ontrack.jpg. I did try to recover two of these files but couldn't play them or find out what exactly their file types were...
My idea is related to this 'raw' recovery. If a raw recovery like Ontrack's method is possible then a track by track analysis of the HDD for the 'transport stream' file structure will surely result in our recorded programmes files.
The three problems that need further investigation are:
1. How do we do a 'raw disk' analysis.
2. How to we detect a ts file (first thing is to find out what this structure is).
3. How we copy this ts file completely to a formatted disk.
[The easiest way to do this is to talk to Ontrack to see if they can include this file format in their software, if so wait for them to release the new edition and purchase and use!]
The hard way will be to learn the three points above and write a simple program to do this... who is willing?
I have access to another data recovery program called R-Studio and will have ago on the Hummy's HDD once I am in work. We will see what results this brings...
I will also try parish's dd command, maybe this is a method of reading the raw disk which will result in a file which we can further priocess to extract the ts data...
Any other ideas?
0
Comments
After allowing the box to obtain channels etc. I recorded several minutes from two channels, shut the box down and pulled out the HD.
While looking at the disk I found the two streams of data that I had recorded.
It turns out that the data on the disk needs the word swapped (ie 01234567 is held on disk as 67452301).
so:
00000020 6C73 3A20 5375 6E64 6179 2047 7261 6E64 ls: Sunday Grand
00000030 7374 616E 6400 0000 0000 0000 0000 0000 stand...........
is held on disk as:
00000020 203A 736C 646E 7553 4720 7961 646E 6172 :sldnuSG yadnar
00000030 6E61 7473 0000 0064 0000 0000 0000 0000 nats...d........
To allow me to play the data I had recorded, I had to flip the words on all of the data.
I will try later today to track down offset information to my known recorded programs and see if I can come up with some means that would allow us a consistant way of recovering them.
Later, I will hook up the disk to a (Debian) Linux box and use dvbsnoop (http://dvbsnoop.sourceforge.net/dvbsnoop.html) to see if it can see anything on the disk...
(Wish me luck!)
If you get the time could you test this on your larger HD?
At offset 0x20fc I'm thinking is a pointer to the file table:
0000020E0 0D 00 00 E0 00 00 F0 02 79 1E 06 00 FE FF FF FF ...à..ð.y...þÿÿÿ
0000020F0 00 00 00 00 12 00 00 00 00 00 00 00 76 00 00 00 ............v...
000002100 00 00 00 00 76 02 00 00 00 00 00 00 F2 1A 00 00 ....v.......ò...
000002110 64 00 00 00 00 01 00 00 BE 83 F9 11 3E 0C 00 00 d.......¾ƒù.>...
From my 160g HD the value is as above 76 00 00 00.
Multiplying that by the sector size of 0x200 gives 0xec00.
If you view from there you'll see some texts (file names on disk?)
va.0, va.1 then le.2, va.2 etc.
I think the va.0 & va.1 are internally used by the 9200T for buffer stuff.
For me, I followed the data just above the va.2 entry on my unit:
00000ED80 00 00 00 00 00 00 00 00 00 00 00 00 62 15 F1 00 ............b.ñ.
00000ED90 00 00 00 00 E2 E2 F8 00 00 00 00 00 70 D0 07 00 ....ââø.....pÐ..
00000EDA0 00 00 00 00 00 5A 9D 0F 02 10 00 00 11 00 00 00 .....Z.........
00000EDB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000EDC0 76 61 2E 32 00 00 00 00 00 00 00 00 00 00 00 00 va.2............
00000EDD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000EDE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000EDF0 00 00 00 00 00 00 00 00 00 00 00 00 12 96 53 ED .............–Sí
The data at 0xed8c points to the start of my 1st recording
62 15 F1 00 = F11562 x 200 = 1E22AC400 START POSITION as offset on HD
The length of the recoring is stored at 0xeda4
00 5A 9D 0F = F9D5A00. so: 1E22AC400 + F9D5A00 = 1F1C81E00 'end of clip
I saved the data from 1E22AC400 to 1F1C81DFF to my PC
then I had to 'flip' each DWord (32 bit) and it played OK as a .TS file.
If your HD follows the same or similar pattern, it gives us a starting point.
...later,
phew.
I dont know what half the stuff you are talking about is but find I am quite exceited about it
The dvbsnoop utility didn't seem to work directly on the disk I attached - seems to want a DVB card. I used the dd command to transfer the data across but still had no luck. For starters, I didn't know what to look out for.
phew could you point out some disk analysis tools (the ones that you are using if they are free) so that I could examine (and extract the data stream from) the 250Gb disk as instructed above.
All I have is the Ontrack tools, with this a disk viewer that shows the data sector by sector. I searched on the va.0 tag and found this: http://roo.st-andrews.ac.uk/humax/diskviewer.jpg
Hope this was what you are expecting...
Another (non) result: I have a peice of software called 7tools Partition Imager (comes under various titles like Paragon) which I use to image Linux/Windows boxes... I loaded this up to see if it recognise the Hummy's HDD, but no it doesn't (http://roo.st-andrews.ac.uk/humax/partimager.jpg) I suppose it would image it if I told it to, however. I also tried fdisk, testdisk and gpart Linux disk tools but they could not tell me anything about the HDD. So the HDD is definitely not any Linux or DOS/Windows FS (we knew that already, yes?!)
I found this table: http://www.osdever.net/documents/partitiontypes.php?the_id=35 which lists partition types with their Hex IDs. Does anyone know where the ID is kept on a formatted HDD? Not that the Hummy's HDD format is any of these - the table looks like the list seen when installing a Linux system and being asked to partition the disk - if fdisk on Linux doesn't recognise the HDD then it can't be any of the types listed...
av == Audiovisual (i.e. MPEG files)?
el == eLinker (i.e. MP3s/JPEGs)?
Just a thought.
I have found 8 'el's, from 2 to 9 (which doesn't sound right - I'm expecting 9 MP3s and 4 JPEGs).
I have found some 'a's and 'e's... See this shot: http://roo.st-andrews.ac.uk/humax/diskviewer2.jpg
And I've found a duplicate of the original va.0 search: http://roo.st-andrews.ac.uk/humax/diskviewer3.jpg
Physical Sector 118 = 0x76, so I suspect that this may be the start of the 'file list' regardless of disk size (ie 0x76 x 0x200 = 0xEC00) with two 'always there' files 0.av & 1.av.
From the .jpg I would reckon that you have a recording starting from the value at 018c (on your .jpg ):
= 0xF123A6 * 0x200 = 0x1E2474C00
The size would be (if this is correct so far): 0x61527000
So, if you can get to absolute file offset of 0x1E2474C00
and copy from there to (0x1E2474C00+0x61527000) = 0x24399BC00(-1)
That gives a 1,632,792,576 byte file (which you need to 'flip' (mips)words on....I wrote a quick&dirty VBA Excel program to do that...took forever, but done the job).
I am playing with a VB6 proggy that will do the reading and 'flipping' to produce a .ts file, but ultimately a 'c' proggy would benifit Linux/Mac/M$ users...and I can't spell 'c'
If DWord (mips word...32bit)swapped gives:
00000140 322E 656C 7500 0000 0000 0000 0000 0000 2.elu...........
00000150 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170 0000 0000 0000 0000 0000 0000 6056 B64D ............`V.M
00000180 0000 0000 0000 0000 0000 0000 00F1 1562 ...............b
00000190 0000 0000 00F8 E2E2 0000 0000 0007 D070 ...............p
000001A0 0000 0000 0F9D 5A00 0000 1002 0000 0011 ......Z.........
000001B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001C0 322E 6176 0000 0000 0000 0000 0000 0000 2.av............
...never thought about the 'el'inker association though, good thinking!
im not really into hacking hardware, but im into the subject, it occures to me that the Humax 9200T
pdf pics look very much like linux gfx, now i cant say its runing linux and indeed it might not, judgeing by
this link/blog http://www.asklater.com/matt/wordpress/?p=13
"The CPU appears to be a uPD61120 “EMMA2″ MIPS-based processor with integrated MPEG decoder. It also seems to have a Philips ISP1581 device USB controller. And a JTAG port, but I’m not sure if you’d have to wire it up manually. This information is visible in string data sections of the Humax firmware, but if anyone could confirm it and find out what other chips are in the box..?"
so, shouldn't it be possible to run a Mips or PPC emulator
on top of linux x86 to avoid the byte-swapping.
or just plug the drive into a real PPC machine
like the genesi PPC machines or a mac running linux.
http://www.ppczone.org/forums/search.php?mode=results
infact if you can be bothered to look for the hacker sites/blogs relating to putting a standard linux on this box you may find it far easyer to get the info you require to pull the st stream off the hd, indeed if the box is using a form of linux already (as many embeded kit does today)then Humax themselves may already have the difs and so on for this box on their website somewere to help you find out how the inbuilt mpeg to pc SW works saving many hours work perhaps.
you might be able to also compile an app and copy it over to the box and run that app inplace of the default recording stuff.
its just a thought and there may be reasons why it wont work as outlined, but werth looking at perhaps.
you might look into using rebol byte swap command
bswap and many of the binary/file option commands
http://www.rebol.com/docs/rebcode.html
http://www.rebol.com/faq.html
rebol/view is best for gui front ends
were as rebol/core (shell/cli)is on more platforms
http://www.rebol.com/view-platforms.html
http://www.vnunet.com/articles/print/2151937
http://www.avforums.com/forums/archive/index.php/f-47-p-8.html
using nothing more than http://search.ntlworld.com/ntlworld/search.php?q=humax+9200T+linux+firmware&cr=countryUK%7CcountryGB&x=21&y=11 to find relevent info
perhaps someone with more interest can spend time looking for definative answers, i may get one of these boxs soon so will be more inclinded to find out someday LOL.
Interesting stuff popper... will look into it with more time...
Nigel.
Whilst its certainly possible to run GNU tools over a Nucleus kernel I don't see any GPL source offer so its unlikely. Don't see any telltale strings in there in any case.
Who told you it was Linux? Will you now stop blindly passing on what they tell you or start questioning whether you're being used?
We've ported Nucleus and used it in some DVB products. The only filing system that ATI supply is FAT based, but I guess other middleware vendors will have offerings, of maybe Humax rolled their own.
Of course, there could be a light OS for handling the initial boot/reflash, but the charging structure of Nucleus is such that you wouldn't use it for this.
Regards
Ian
The avfs file system appears to be journalled, which should protect it from unexpected power downs. Given the way file loss seems to happen after restarting machines, with files intact on an apparently working machine in some cases right up till then I'd be looking at a journal playback problem. Something leaving a false journal when there's no fault or a bad one, at restart repairing the avfs would then actually destroy it. The habit mine has of overwriting random files would easily let it trash something vital like the journal.
Nigel, whats the score with mpeg4-AVC/H.264 boxs at the moment in the UK ?, are there any in the near future.
is there any sign of pci/pcmcia/USB cards with an FPGA embeded AVC encoder that can encode S-video signals (better than)real-time ?.
Im interested in this tool for extracting files from raw partitions. I can see how this would work in theory, but I'm baffled as to how it would handle fragmentation. Without knowledge of the allocation mechanism, such a tool wouldn't possibly be able to reassemble a fragmented file, surely? And I recon because of the nature of a PVR, fragmentation is high.
With my limited knowledge of these things, I believe the AVFS (or whatever) file system used by the Humax and other PVRs, have a segment size that is on the rather large side. Obviously, this is due to the reather large files that will be stored on the drives, and so using large segments minimises the chances of fragmentation.
If a HDD fragmented too much in a PVR it would slow the box down making it unable to record live broadcasts reliably.
[flameproof suit on]
Agreed, large 'segments' (I guess a better word is blocks or allocation units) would minimise fragmentation, or at least make it more managable, as constant allocation lookups don't have to be made. It would improve performance.
However, where the allocation unit size is less that the potential filesize, some fragmentation is almost inevitable, as holes will always form, that need filling. This has to be a consideration. We will need to work out how to follow segment links in order to retreive entire streams.