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.

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.



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.

Not "pretending" anything. I don't know AceLab and their capabilities, so I can't speak about them. But it seems like they might be a large recovery company. Probably tons of resources, but also tons of target applications.

Anyway, I had this typed up before but it fell into some mod-queue and died so...

The TAP is alive and the controller exposes a normal ARM JTAG-DP.
AP1 identifies as an ARM APB2/APB3 MEM-AP (0x44770002), with a valid CoreSight-style ROM table at 0x80000000.

That table advertises six downstream components at roughly +0x20000, +0x40000, +0x60000, +0x80000, +0xA0000 and +0xC0000.

A good bit of that space has been mapped. Two 128KB regions return 0xEAFFFFFE at every aligned word, but controlled writes showed they aren't really 128KB of RAM. They act like four writable 32-bit slots mirrored every 0x10 bytes. Another 4KB component at +0xC0000 is completely mapped and repeats a 0x20070727, 0x00000001 register looking pair every 0x100 bytes. The areas around these components fault cleanly, while the three middle ROM entries are mostly WAIT prone and still unexplored.

The stranger part is that the whole observable map repeats every 1MB. I tested addresses all the way from 0x00000000 to 0xFFFxxxxx and the same ROM entries, values, and even the same fault locations keep reappearing. I also verified that the AP really is receiving and storing the full 32-bit TAR address, so it isn't my software accidentally masking it to 20 bits. The best documented match so far is a normal ARM APB-AP feeding a narrower CoreSight debug interconnect, tho I can't tell yet whether that's just ordinary address decoding or something Samsung added downstream.

So at this point I'm thinking this 1MB space may basically be the controller's debug toolbox rather than its normal memory map. The interesting question now is what the six advertised tools actually are, especially the three that currently WAIT, and whether one of them provides the bridge into the real CPU/system memory.