Introduction
I’ve had a Western Digital Netcenter WD2500P019 die on one of my customers.
Someone else commented: “It has a broadcom BCM 4780 cpu , 32 MB RAM and 8 MB flash ROM. Furthermore there is a USB-chip (VIA VT621) and a IDE-chip (ATP865).”
Disassembling the chassis
To disassemble, slide the top and bottom plates (long with a curve at one end, feet on one of them) to the back of the device about 1 inch, then they lift off.
Secondly, pry the front panel off (short edge, straight with curves at each end) by lifting each end of it to unclip each of the two large clips (one at each end of the the curves) then the straight bit prys off with 8 small clips.
Then along the top and bottom there is 3 clips each side on the clamshell, easy to lift apart. (Lifting these apart separated the warranty stickers, breaking the warranty on the netcenter (NOT the hdd warranty, this is on the disk itself)
Inside, there is two screws holding a metal cover over the molex, ide and network ports. Undo these and lift the metal cover off.
You can now disconnect the molex power, and ide data cables, and unscrew the disk with it’s heatsinks and lift out.
The Hardware
Mine has a motherboard with p/n “2061-701373-000 Rev A”
Broadcom BCM4780PKPBG Cpu
2x 16mb Ramchips (46V8M16)
Acaro ATP865-B (ATA)
Via VT6212L (USB)
The disk inside is a WD2500JB (3.5″ 250gb ide)
SMART switched on, never self-tested.
The Diagnosis
When powered on, it sits doing nothing for a while with an orange light (normally means “booting”) then powers itself off. The disk spins up, and doesn’t make any unusual noises.
The disk has no SMART faults reported, and passed a SMART short test.
I therefore conclude that the motherboard in the Netcenter has died (failing to boot for some reason)
Recovery Attempts
Disk set to single/master, powered by a software-controlled molex and a 2 inch 80-pin IDE cable.
I’ve had the disk out and connected it first to a windows system (no readable partition table, data rumoured to be in ReiserFS format)
I then connected the disk to a Knoppix system… no partition table, even in parted which will read mac-type etc. Further, gpart (partition table guesser) gets nothing. Tried reiserFS drivers on the raw disk (in case of no partition table) – no luck.
I then connected the disk to my data recovery Linux system, where I learned more:
This disk seems to be fine – I have never experienced a read failure on it.
dd bs=1M count=1 if=/dev/sdb of=First-MB.bin
I read the first megabyte of the disk into a hex editor and got these results:
1) “file” identifies the first megabyte as “x86 boot sector”
2) The first few bytes of the disk correspond to the ASCII for:
Broadcom NAS Version 1.1 MBR Tag
This tells us it’s based on a Broadcom NAS reference design – it appears that huge numbers of these things exist with various different plastic cases and logos stuck on. This tells me that it’ll have a Reiserfs partition on it somewhere.
Digging through the rest of what would normally be the MBR, it’s mostly zeroes.
Character 0x23F6 is the start of an occupied section. This offset is the start of the string “SWAPSPACE2”
In this partition (I guess this is a swap partition used by the OS) there’s lots of strings, mostly linux device paths (notably including md devices – the software would appear to support RAID) and several html pages about configuration via wlan (the Netcenter doesn’t have that) and multiple disks (also not in the Netcenter)
Further on, I started finding company-related strings (filenames and paths) at about the 7mb mark. This seems to be stuff which happened to be swapped out to disk when the device went pop.
Recovery
The device uses a ReiserFS partition.
To determine the start of the reiserFS partition I needed to find it’s superblock.
I made a reiserfs partition in a 10Mb loopback file for comparison…
dd count=100 bs=1M if=/dev/zero of=ZExample-ReisersFS.bin mkfs.reiserfs -f ZExample-ReisersFS.bin
Looking at the hex in my example Reiserfs partition, there’s a “magic number” of ReIsEr2Fs in ASCII.
Searching for the same thing on the Netcenter disk found it at offset 0x1e859834 (or about 500Mb in). This suggests that the partition start is at:
0x1e859834 = 512071732 in Dec
51207173/512 = 1000140.1 blocks.
ReiserFS start theoretically at:
512071680 – 65536 = 1000140 blocks – 128 blocks = 512 006 144
The solution
So, we put a loopback device together to make a virtual partition device file (which is what we’d have gotten, if the partition table existed, as /dev/sdc2)
losetup -o $[ 512071680 - 65536 ] /dev/loop1 /dev/sdc
Then try mounting it:
mount -r -t reiserfs /dev/loop1 /mnt/sdc
So, what’ve we found? Let’s have a look:
ls -l /mnt/sdc
Directories listed of “Shared Files”, “__drivers”, “__var” and a file called “__share_list.txt”
Excellent! Time to copy onto a more reliable device (one of my scratch drives).
cp -rv /mnt/sdc/Shared Files /mnt/scratch1/
Time for lunch, as this’ll take quite some time!
References
OpenWRT Comments – Lots of devices including open routers seem to be based off this Broadcom reference design.
Filesystem notes from Open-Netcenter (german)
[…] How can I fix that? I compared the disk content and the .dsk file in a hexadecimal editor and they look the same! Ref: http://tristanscott.co.uk/computers/…data-recovery/ […]