Forum Index page

I know only very little of Hardware. I tried to find the shorting points with the help of an AI Assistant and measuring the pads with a multimeter, but in the end I trialed a bit and then found the pins. I then got me some mass production tools from chinese websites (you gotta pay in chinese currency) and a external M.2 NVMe via USB enclosure to use them. But in the end I could not restore my drive to a working state, as the "Jump to system" after the R/W Test did not work. I've spent some 15+ hours trying to get the drive back to live, but to no avail. I wish you better luck If you want I can dump a generated summary of my AI assistance of what I tried, but I don't want to clutter the thread here. I think the shorting points are the only real help I can give you, as the rest sadly did not work.

@einstein9, you claimed that there is a copy of the MCU key in the SA. IIUC, @Doomer offered to send you a complete SA dump together with an encrypted sector. Your challenge was to recover the key from the SA and use it to decrypt the sector. That would involve no shipping. It appears that you have declined that challenge. This suggests one of two things: 1. You were wrong and there is no key in the SA. 2. You were right, but you are unable to regenerate the MCU key from the copy.

In DMDE, if you check Advanced Mode and drag the vertical scrollbar from top to bottom, do you see anything other than zeros? If you run a read benchmark in HD Tune, do you see a discontinuity between the two partitions? I'm wondering whether the drive is just serving up zeros instead of reading the actual data. You may need to experiment with the stroke setting to see the first partition.

gold6565 wrote: HannsGruber wrote: gold6565 wrote: I found a firmware file I had—I was interested in it at one point, but after looking at the contents, I lost interest. I didn't even finish reading it through. Yep, I have that file. It falls out when you unpack the iso. It's still AES256 encrypted, it's sent over to the drive encrypted and decrypted on the device. It has some metadata you can look at, but the body is encrypted. I haven't seen that in ISO images. That is the format in which the firmware is stored on the SSD. It spills out once you remove the encryption and archive layers. Here's the full file, yours is missing like ~7500 bytes from the end. RVT04B6Q_01190903.rar The updater (fumagician) in the bootable ISO is basically: IDENTIFY DEVICE, READ BUFFER (E4h) to select the matching component, then it decrypts and removes the package wrappers, and sends that .bin component via DOWNLOAD MICROCODE (92h) to the drive. The attached .bin is the 01 component, specifically.

HannsGruber wrote: gold6565 wrote: I found a firmware file I had—I was interested in it at one point, but after looking at the contents, I lost interest. I didn't even finish reading it through. Yep, I have that file. It falls out when you unpack the iso. It's still AES256 encrypted, it's sent over to the drive encrypted and decrypted on the device. It has some metadata you can look at, but the body is encrypted. I haven't seen that in ISO images. That is the format in which the firmware is stored on the SSD.

Could we see the whole PCB, for context?

I've also done some voltage modification and identified three unique startup power states. A 0.038a held state A 0.124a latched state and a normal 0.219a boot-idle state without SATA At 0.038a the JTAG transport and debug port come alive very early, before the downstream AP/debug fabric is fully available or powered. This is found by bridging a few points through a 1kOhm resistor. Removing the bridge sends the drive to a full boot. Under-volting the 1.8v VTref can get you into a latched 0.124a startup state where you get unstable / corrupted JTAG read behavior. The problem is that state isn't recoverable. Restoring the VTref voltage doesn't push it along to a full startup, so no way to use the misbehaving JTAG to, say, modify some bytes with a malformed write and release the drive to finish booting.

gold6565 wrote: I found a firmware file I had—I was interested in it at one point, but after looking at the contents, I lost interest. I didn't even finish reading it through. Yep, I have that file. It falls out when you unpack the iso. It's still AES256 encrypted, it's sent over to the drive encrypted and decrypted on the device. It has some metadata you can look at, but the body is encrypted.

I found a firmware file I had—I was interested in it at one point, but after looking at the contents, I lost interest. I didn't even finish reading it through.

Yes. Normally, when the T9 is locked, Windows only exposes the small ~76.5 MB partition containing Samsung’s Portable SSD Software. I launch the Samsung tool from that partition, enter the password, and the software sends the unlock request to the drive. I don’t know the exact challenge/authentication protocol used internally. In my case, the correct password is accepted, but instead of the full volume appearing, the disk becomes Offline and remains in the locked/restricted layout.

Does anyone know what SMD this is? from nvme ssd. Thank you

I don't know anything about these drives. How do you normally unlock it? Do you launch some tool inside the FAT partition, and does this tool set up a password challenge?