search

Drive-Trust-Alliance / sedutil

DTA sedutil Self encrypting drive software
613 stars 237 forks source link

PSID revert for Intel SSD Pro 1500? (TCG Opal SSC Specification Version 1.0 Rev 3.0 compliant) #417

Open l3iggs opened 1 year ago

l3iggs commented 1 year ago

I recently recovered two Intel SSDs from an e-waste bin (they were in old Lenovo T440p laptops). They seem to be ATA password locked and since I don't know anything about the person who used them or put them into the bin, I'll never learn the origional password. I don't care about the data on them. I think it would be nice if I could use them them (keeping them out of the e-waste stream for a few more years)

Should I expect sedutil to be able to PSID revert these? (hint it can't). If sedutil isn't the right thing to make these usable, is there any other tool out there anyone could recommend (an old version of sedutil or its parent projects maybe)?

Any attemps with sedtul look like this (nothing works because sedutil thinks they're not OPAL ready):

# sedutil-cli --scan
Scanning for Opal compliant disks
/dev/sda   No  INTEL SSDSC2BF240A4L                     LS2i

# sedutil-cli --query /dev/sda
Invalid or unsupported disk /dev/sda

hdparm info is like this

# hdparm -V
hdparm v9.65

# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       INTEL SSDSC2BF240A4L                   
        Serial Number:       [REDACTED] 
        Firmware Revision:  LS2i   
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Used: unknown (minor revision code 0xffff)
        Supported: 9 8 7 6 5
        Likely used: 9
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:   468862128
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:      228936 MBytes
        device size with M = 1000*1000:      240057 MBytes (240 GB)
        cache/buffer size  = unknown
        Nominal Media Rotation Rate: Solid State Device
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Advanced power management level: 254
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
           *    Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
           *    Advanced Power Management feature set
           *    48-bit Address feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    64-bit World wide name
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Gen3 signaling speed (6.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Host-initiated interface power management
           *    Phy event counters
           *    DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Software settings preservation
                Device Sleep (DEVSLP)
                unknown 78[10]
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Data Tables (AC5)
           *    Device encrypts all user data
           *    Data Set Management TRIM supported (limit 1 block)
           *    Deterministic read data after TRIM
Security:
        Master password revision code = 16385
                supported
                enabled
                locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        Security level high
        4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: [REDACTED]
        NAA             : 5
        IEEE OUI        : [REDACTED]
        Unique ID       : [REDACTED]
Device Sleep:
        DEVSLP Exit Timeout (DETO): 20 ms (drive)
        Minimum DEVSLP Assertion Time (MDAT): 10 ms (drive)
Checksum: correct

Thanks!

watersb commented 1 year ago

Great question.

I'm struggling a bit along the same lines with an Intel 905p SSD. If I figure it out, I'll post something here.

Meanwhile, take a look at Intel's Memory and Storage Tool.

sudo intelmas start -intelssd -psidrevert ${PSID}

Error: Unsupported Operating System. This feature is only supported on Windows.

Charming.

For some additional non-Intel perspective...

I also have some Seagate enterprise hard drives that work with sedutil. I managed to lock one at some point, but the PSID unlock wasn't working...

I used sedutil-cli to dump that alternate code, an MSID, via

sudo sedutil-cli --printDefaultPassword /dev/sda

Then I used hdparm commands to unlock the drive with that password.


MSID="$(sudo sedutil-cli --printDefaultPassword /dev/sda)"

sudo hdparm --user-master m --security-unlock "${MSID}" /dev/sda

In my case, going back and forth between Windows and Linux, there seem to be at least two distinct levels of operation in play, two different APIs. One level seems to support self-encrypted storage devices, where the keys never leave the low-level device's embedded controller. Another approach is more general, operating via the host device -- your computer, in particular for BIOS-mediated Secure Boot... in which case, it's likely the host CPU that's performing the bit manipulation crypto of the data stream.

My Seagate self-encrypting drives have the PSID printed on the disk label, and it's not otherwise exposed to the host; I don't think you're going to retrieve it from sedutil-cli... But my Intel SSDs don't have the PSID printed on them anywhere, and yes, sedutil-cli reports these Intel devices as TCG/Opal NO, not compliant.