Hard Disk
Memory Card
RAID Systems
USB Stick
SSD

Восстановление данных с Seagate SED

Вопреки бытующему мнению о запрете на продажу самошифрующихся (SED, Self-Encryping-Drive) дисков в Российской Федерации, они все-таки продаются и используются довольно часто. Например, все внешние жесткие диски на 4-5 ТБ моделей ST4000LM024, ST5000LM000 (внешние коробки с моделями STKM4000400, STKC4000400, STGD4000400, STEA5000402,STKC5000400,STKC5000400 и прочие). Внутри таких внешних боксах установлены SED накопители. Достоверным индикатором такого типа накопителей является терминальный лог диска на команду Ctl+A

 

Prod Desc: M11 CheopsLiteA SATA 2.0 RAP30.8.2 SMR 2MB Flash 150 zn zonedservo 5400RPM
Package Version: M1A1804D6.SDMA.MD0052.0001
Serial #: WCK6FYM0
Changelist: 01856099
Model #: ST4000LM024-2AN17V
ID: 100
Servo FW Rev: D60A
Heads: 8
PCBA SN: 0000K1027JMJ
Default factory config: SED
Active config: SED

 

Работает оно так:

1. Некие данные поступают в жесткий диск и шифруются уникальным ключом, зашитом в микропроцессоре платы управления.

2. Далее данные шифруются сложными алгоритмами, ключ к которым находится уже в служебной области жесткого диска (на пластинах)

 

Замысел производителя следующий: после продажи диск попадает к пользователю. Он сохраняет на него свои файлы и работает с ним. В случае выхода диска из строя пользователь возвращает его по месту приобретения. Далее диск по цепочке возвращается произодителю. Конечно, произодитель заинтересован в причине выхода диска из строя и проводит ряд диагностических тестов (FA, Failure Analysys). Проблема в том, что у пользователя там могут находиться некие данные, которые бы ему не хотелось передавать в чужие руки. А удалить данные самостоятельно у пользователя нет возможности (диск может совсем никак не определяться в операционной системе).

Для проведения диагностических тестов инженеру сначла необходимо разблокировать доступ к служебной области накопителя. Вот на этом этапе диск меняет ключ шифрования данных. Таким образом, даже если инженер FA получает возможность читать пользовательскую область, то он уже увидит "кашу" данных и не при каких обстоятельствах не увидит данных пользователя.

 

Информация для "продвинутых": У диска есть некие Security LifeCycle States: В том числе: 0x80 - Use, 0x81 - Diagnostics, 0x00 - Setup. Так вот как только значение становится отличное от 0x80 - диск меняет модуль 40 (sysfile 3_1d2), ключ шифрования user area. Исключение составляет статус 0xFF - Failed. Такой статус становится при попытке установить плату управления от другого диска.

 

Проблемы начинаются когда у пользователя выходит из строя накопитель, а данные ему очень нужны. Инженеру по восстановлению данных необходимо разблокировать доступ к служебной области таким образом, чтобы накопитель не смог (или даже не пытался изменить ключ шифрования). Без получения такого доступа невозможны никакие манипуляции для восстановления данных.

Особенно серьезные проблемы возникают когда некие неквалифицированные инженеры из-за незнания особенностей таких накопителей пытаются работать с ними обычными методами. В результате чего наблюдается такая картина: клиент обращается в File-service после некого стороннего "сервиса", где "не смогли восстановить данные". По факту накопитель определяется, но вместо данных на нем шифрованный "мусор". В этом случае уже необходимо восстановление исходного ключа шифрования. Это гораздо более сложные (и соответсвенно более дорогостоящие) манипуляции, которые можно избежать путем грамотных действий с накопителем с самого начала.