Very interesting solution!
I selected another way. I have used 256 bytes XOR values array.
If use your notations then my solution written in pseudo-Pascal looks like this:
Code:
lookup: array[0..15] of array[0..15] of BYTE =
[0xF0, ..., 0xF0]
[0x10, ..., 0x10]
[0xC0, ..., 0xC0]
[0x20, ..., 0x20]
[0x90, ..., 0x90]
[0x70, ..., 0x70]
[0xA0, ..., 0xA0]
[0x40, ..., 0x40]
[0x30, ..., 0x30]
[0xD0, ..., 0xD0]
[0x00, ..., 0x00]
[0xE0, ..., 0xE0]
[0x50, ..., 0x50]
[0xB0, ..., 0xB0]
[0x60, ..., 0x60]
[0x80, ..., 0x80];
b: array of BYTE;
i: Integer;
for i := 0 to Length(b)-1 do
b[i] := b[i] xor lookup[b[i]];
I think your solution is more elegant, but my solution is more general.
Since it allows to use any array of XOR values and abandon a nibble division.
What deals with unpacking of firmware from previous drives like MLC SSD (VBM18C1Q, VBM19C1Q, VBM1AD1Q,...)?
By the way question of dumb procedure recedes given firmware protection.
Did you start research of check sums of microcode? You can see whatever ranging from CRC16 to Elliptic Curve DSA (ECDSA).
And firmware is protected by several control sums concurrently.
Seems like Samsung developers don't like if somebody modifies the firmware of their SSD.
There is idea that if they read this topic then they will change encryption algorithm.