U3 is an 8-bit microcontroller (PIC16F883) with 4K words of Program Memory and 256 bytes of flash based data memory. After examining the traces on the underside of the PCB, it does indeed appear that U3 is responsible for decoding the keypad.

ISTM that there would be three possible locations for the failed password attempt counter. It could be stored in a different sector beyond the visible user area on the HDD (not the "key" sector), or it could be stored in the SPI flash IC at U4 (bridge firmware), or it could be stored within the data memory of U3. My bet is on the latter.

The fact that the password challenge succeeds with a blank foreign drive would suggest that the password is stored on the PCB, probably within U3. If so, could defeating the password really be as simple as transferring U3 from a donor with a known password, or does U3 contain some data that matches it to the PCB?

Your testing would seem to confirm that U3 is communicating with the Initio bridge, and that the bridge is communicating with the drive. Therefore ISTM that the bridge has a faulty USB port. This then begs the question, how likely is it that the eSATA port would also be faulty?

You haven't told us the markings on U4, but Initio's documentation states that its bridge supports generic SPI flash, so my suggestion to short pin #7 to ground should be OK. Do this before you apply power to the device. If the device enumerates as an Initio Default Controller, then this will prove that the USB port is OK, otherwise the port will most likely be bad. Note that both USB ports supply power to the device, not just the port that is referred to as the power port in the manual. AFAICT, the outside port (J2) powers the HDD while the centre port (J1) powers the bridge PCB.

May I ask how you cabled the device when connecting via eSATA? Did you use a powered on non-powered eSATA port? Which USB cable(s) did you also connect when doing this?

ISTM that the power to the bridge PCB may be controlled by U1. Can you tell us its markings?


References:

PIC16F883, Microchip Technology, 28-Pin, Enhanced Flash-Based 8-Bit CMOS Microcontroller, 2.0V - 5.5V:
http://ww1.microchip.com/downloads/en/D ... 41291b.pdf

Si4835BDY, Vishay Siliconix, P-Channel 30-V (D-S) MOSFET, -7.5A:
http://www.vishay.com/docs/72029/72029.pdf

2009 Initio bridge controller roadmap:
http://semisolution.koreasme.com/fsbCli ... oadmap.pdf

INIC-1610 USB to SATA Bridge Specification:
http://www.innortech.com/pdf/inic-1610% ... 0v1.00.pdf

INIC-1610 Product Brief:
http://www.initio.com/Html/Doc/INIC-161 ... 0Brief.pdf

_________________
A backup a day keeps DR away.

It just occurred to me that the USB "data" and the USB "power" cables may not be identical. Is it possible that the data conductors are missing from the power cable? If so, then interchanging the two cables would give the symptoms that you describe, namely that the device powers up, completes the password challenge, but does not communicate via USB. Of course this wouldn't explain the failure to communicate via eSATA.

_________________
A backup a day keeps DR away.

Some things I noticed when I was working on my case..

The original device came with a regular USB2 cable and an additional USB>power cable, I tried with USB only, USB + power and esata + power. No dice.

As per OP's findings, the unit unlocked with correct code (mine was also set with default, highly secure!) with a blank HDD in, but did not allow recognition as a USB device. This suggests that the keycode is on the PCB.

When I took a clone of the original drive and replaced the key sector with that from the donor (working and key coded) drive and put it in the donor chassis, it was instantly recognised as a USB device once the keypad code was put in, and allowed LBA access, but encrypted.

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

AISI Lenovo's user manual is misleading.

The three supplied cables are incorrectly referred to as ...

- USB data cable
- USB power cable
- eSATA data cable

AFAICT they should be more appropriately described as ...

- USB data + USB power for bridge PCB
- USB power for HDD
- eSATA data (non-powered port) OR eSATA data + eSATA power for bridge PCB (powered port)

That would explain why a powered eSATA connection still requires the "USB power" cable.

It would also explain why an eSATA data-only connection requires the "USB data" cable.

_________________
A backup a day keeps DR away.

Markings on U4 are:
PC725VF010A
33-4C-5AE
1111001-C

Markings on U1 are:
LCPP
N681
120

When attached with only the 'data' USB cable shorting pin 7 on U4 to ground does allow the device to be detected in Windows device manager as:
Initio Default Controller
Hardware ID: USB\VID_13FD&PID_163F&REV_0100
The hard disk drive does not spin up.

Regarding wiring combinations:
From information in the product manual it suggests that the USB 'data cable' and eSATA are plugged in together for eSATA functionality. The additional USB 'power cable' should only be used if the USB 'data cable' cannot provide enough power to the drive. This means potentially you need all 3 cables connected for eSATA if a non-powered eSATA cable is being used. And that only the USB 'data cable' should be required when (most) computers can power a USB HDD.

The owner of this drive confirms that during its normal use only the USB 'data cable' was required for functionality.

When connecting with only the USB 'data cable' the HDD spins up normally and initialises, and from the tests I have conducted it appears that data is being written to the disk at 976,773,105

When connecting the HDD with any combination of cables I get no drive recognition after a successful unlock and the same symptoms as described previously.

A faulty USB port would seem obvious answer to this situation. I've tested the output for all wiring the USB and it seems OK. But perhaps to be sure I shall remove the port completely and wire to it directly.

I would agree that the main password information seems to be stored on the PCB. I expect there must be some sort of match required between the content on the PCB and the key sector on the HDD.

Unfortunately without a matching donor PCB I am limited in further testing. I do have an Apricorn INC Aegis Padlock 3.0 in. Obviously this is quite different, but holds a similar sized U3 component. However I cannot identify the critical components as the manufacturer has covered these in a hard epoxy.

All the best,
J

_________________
CDR - Manchester Data Recovery Services
0161 408 4857
http://www.cheadledatarecovery.co.uk/

Your testing proves that the USB port is functional. AISI, there is some kind of logical problem rather than hardware.

The LCPP device is an LTC4413-1. AFAICT, this device, in conjunction with the 3 switching transistors (Q1, Q2, Q3), combines power from all 3 ports while maintaining isolation. This prevents a powered eSATA port on PC #1 from feeding power back into the USB port on PC #2, or vice versa.

LTC4413-1, Linear Technology, Dual 2.6A, 2.5V to 5.5V Fast Ideal Diodes, marking LCPP:
http://cds.linear.com/docs/en/datasheet/441312fd.pdf
http://www.farnell.com/datasheets/1692600.pdf

The 25VF010A device is an SPI flash.

SST25VF010A-33-4C-SAE, Silicon Storage Technology, 1 Mbit SPI Serial Flash:
http://ww1.microchip.com/downloads/en/D ... 25081A.pdf

_________________
A backup a day keeps DR away.

Were any of these bad sectors at the end of the drive, in the hidden user area?

Is there any possibility that the enclosure is not the original one? Is there a manufacture date on the HDD that we could use to compare against the date codes on the ICs?

Can you see any evidence that the drive has been removed and attached directly to a SATA port? For example, is there a non-encrypted MBR or boot sector? If so, could there be a non-encrypted backup boot sector on the last track of the drive (beyond the key sector), and could this have overwritten some important encryption related code/data???

_________________
A backup a day keeps DR away.

@cheadledatarecovery, I've reread this thread a few times, but it isn't clear whether you are working with the clone HDD or the patient. You also didn't mention whether the original drive exhibited the same "no-USB-detection" symptom.

Would it be worth changing the model number, serial number, and firmware version of the clone so that it identifies itself in the same way as the patient?

_________________
A backup a day keeps DR away.

Don't think it will help.

In my working drive , I cloned the Toshiba 500gb to a WD 640gb (with HPA cut) and it still worked.

Shame I still don't have the drives here, or I would have been able to assist further

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

Hi Fzabar & PcImage,

There were only 2 unreadable sectors in the middle of the drive - by the looks of the data around them ("FF") it appears to be an unallocated area of the disk. I expect that it is just coincidence that the drive has a couple of unreadable sectors rather than this being the fault itself. The original HDD came in as a result of the 'no-usb-detection'.

The symptoms described are the same when using either the clone or the patient.

Sectors 0 and 63 are encrypted. Data beyond 976,773,105 is encrypted. There looks to be no unencrypted boot sector/MBR written to the device.

When the customer came in with the disk in the caddy did not look as if it had been tampered with. I was also able to question him about the drive and its normal use. I am fairly certain that no attempts had been made to remove the HDD and connect it directly to a computer which may have altered the data, and that this is the original HDD and encrypting PCB combination.

The patient HDD details as follows:
MK5076GSX
HDD2J93 C SL01 T
DATE: 26SEP2011
010 A0/GS001A

I think we have got to the stage where options are running low? Thank you for all your help so far on this. My only thought is to find a donor encrypting PCB and to transfer the critical components to it on the basis that there is some currently unknown fault with the patient PCB. I've multimetered around the patient PCB and compared the results with the non-matching USB3 Apircorn device I have in, and there is nothing that stands out as an obvious failure of a component.

The only other way to test that the patient encrypting PCB is working is to follow the user instructions in manual to reset the PCB back to factory defaults. This will of course lead to complete data loss on the current HDD, so is not an option.

_________________
CDR - Manchester Data Recovery Services
0161 408 4857
http://www.cheadledatarecovery.co.uk/

Why not try resetting the defaults with another clone?

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

The date codes appear to be consistent.

There is an "1142" code printed on the PCB near the keypad. That would be around October 2011.

The date codes on the ICs are 1111, 1120, 1127 and 1118. The latest date is around July 2011.

IMHO Sean's latest suggestion is an excellent one that may answer all our questions. I have one other observation and that is that his drive arrived with zeros in the key sector whereas the OP's did not. He was able to correct the "no USB" symptom by using a key sector from a donor drive. The OP's drive, OTOH, was able to regenerate this same sector after the OP zeroed it. Why did the two drives behave differently in this regard? Perhaps the answer to the problem lies in the answer to this question.

_________________
A backup a day keeps DR away.