Hello guys,

I got another drive here which looks Encrypted (maybe), and the device as the client said is not working
this is the exact dump (1st. 2000 sectors) which looks new to me here..

Not re-init. not connected to PC (drive was not working before and we made a clone)

Any ideas`s here??

attached is the file compressed.

Thank you

btw the last 8% of the drive is filled with Zero`s (no data at all)

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

looks to me a shift on the beginning + bad sectors
did u made the clone with R-studio ?

100% clone with ZERO bads

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

you didn't answer my question

if so then the following statement:

is not true

because R-studio uses (by default) "E5" as a bad sector pattern

@ HaspHL

We NEVER USED r-studio for clone , have other tools for it
as i said drive was NOT WORKING we fixed it then Cloned it... so this E5 here is not related to the case.

you are making a good point here but its not related to the case.

Thank you

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

K then

the start of the clone is shifted
(as mentioned above)
and it has a FAT32 structure

How about if i tell you i scanned it with R-Studio and found NOTHING at alll? not even a single working 1k image

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

i can only judge what's in front of me

How do we know that's the only thing that shifted/flipped. If I look at offset 11776 (decimal) I see what appears to be a shifted FSInfo sector signature and again bytes are flipped (0x41 0x61 0x52 0x52 instead of 0x52 0x52 0x61 0x41, normally at offset 0 in sector, right?).

Edit: Oh dammit, my mentioned offsets are off because I inserted 2 bytes at start of file. And also if you do that FAT shifts too while it doesn't need to.



Carved? Then with HxD or similar search for 0x45 0x78 0x69 0x66 and then check if preceding 0xFF 0xD8 is properly sector aligned? Assuming some JPEGs present.

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

Is it a Humax?

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

Sector 0 looks like an MBR when it is dword-reversed. However, it does not follow the MS standard.


There appear to be two FAT32 partitions (ID = 0x0C).

The first begins at sector 0x10 and has a size of 0x200000 sectors.

The second begins at sector 0x200010 and has a size of 0x12819EA0 sectors.

The total size is 0x200010 + 0x12819EA0 sectors = 160.04 GB

Similarly, sector 0x10 looks like a FAT32 boot sector when it is reversed, but once again it does not totally follow the MS standard (eg the FSINFO sector pointer is 0x100 instead of 1).

The text strings are little-endian dwords. FAT64 = exFAT.

HUMAX 0.1
HUMAXI-CORDFAT64<3 spaces>

The signature is "FAT64", but the sector doesn't look like an exFAT boot sector:

https://www.ntfs.com/exfat-boot-sector.htm

original



reversed


There appears to be only 1 copy of the FAT.

Logical sector 6 appears to be a copy of the boot sector.

The 32-bit FAT is located at logical sector 0x84, ie physical sector 148 (= 0x84 + 0x10).

The number of sectors per FAT appears to be 0x7FF.

First sector of FAT (not reversed)


It would appear that Humax uses a hybrid FAT32 system and deviates from the MS standard by mixing up the endianness of the various file system components.

There is an unusal structure at physical sector 0x30.



Sector 0x33 has a directory segment which looks out of place.

Normally one would expect to find the root directory just after the last FAT. In the case of the first volume I would expect to find it at sector 2195 (= 148 + 0x7FF).

That said, the user's data would probably be located at sector 0x200010. It could very well be that the data are dword reversed, in which case one would need to reverse the entire 160GB user area before performing a raw scan.

_________________
A backup a day keeps DR away.

@ fzabkar & Arch Stanton

The one who brought this drive to us said its from DVR but seems you have a point here really, i was looking maybe to the wrong direction...
i found some traces of Channel Names (probably a receiver with hdd inside) we asked him to send us the defected device just to verify

looking into this now...

Thank you again

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

OMG fzakbar, superior bitfockery! I was kinda hoping you'd chime in.

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

The DVR appears to be a Humax I-Cord 160GB.

I believe that I could probably write a program to de-obfuscate the "mixed endianness" of Humax's FAT32 file system, so a professional programmer should make easy work of it, assuming that the available tools don't already handle this peculiar format.

That said, it may turn out to be a pointless exercise if the data are encrypted. One would need to inspect sector 0x200010 (the boot sector of the second FAT32 volume) and then locate its FAT and root directory. It would also help to see sector 2195 (dec) in the first volume.

As a test case we could possibly extract one file manually by locating its directory entry. This would tell us the file's size and starting cluster, and we could then walk through the FAT to locate the file's remaining clusters.

_________________
A backup a day keeps DR away.

I'm guessing that most of the content would be scrambled.

http://web.archive.org/web/20080312075351/http://www.humaxdigital.com/global/products/IRCI-PVR.asp

http://web.archive.org/web/20071114064935/http://www.humaxdigital.com/GLOBAL/products/new_leaflet/iCORDIRCI-PVR_leaflet.pdf

http://web.archive.org/web/20071114064626/http://www.humaxdigital.com/GLOBAL/products/new_manual/IRCI-PVR_M.pdf

_________________
A backup a day keeps DR away.

probably, some time ago i got a 500gb from DVD Recorder (has hdd inside to convert VHS2DVD) the only way i found was by fixing the unit
and connect the drive and export everything otherwise no header of any KNOWN type, like RAW recording and the UNIT itself can decode/read it.

Thnx for the update here

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

isn't there a software or guy that is the bomb-diggity on DVR stuff? I cant remember the name but it may support this

I think it might be easier to fix the unit (if possible) rather than going through the headache and waste more time

the problem is always Will the Client pay @the end?? hehehe <--- sometimes doesn`t matter for me... its all about knowing only..

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

Tell your client to buy a replacement unit on eBay (approx US$100).

In any case the user manual talks about downloading your own media files to the unit via USB, but there appears to be no facility for uploading recorded data from the unit to a USB host. ISTM that the only way to copy the data would be via a capture card attached to the AV output, but then you may need to contend with Macrovision.

At the very least you should examine one data file to determine whether it is indeed scrambled. That shouldn't take very long. I've already shown you where to find it.

_________________
A backup a day keeps DR away.

If we keep telling them HOW to solve their problems then better we shutdown our Biz.

Thank you

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein