Dumping Micron M500 SSD firmware MU05

Switch to full style

Post a reply Search this topic… Search

Dumping Micron M500 SSD firmware MU05 RichardR ↓

August 20th, 2016, 14:26
Summary: How to 'dump' a firmware off a Micron M500 SSD and write it to another “exactly” same
model one?

Hello Pros and Gurus;

I'd greatly appreciate if you could help us out here. It's affecting the very existence of our little company
that gave a few people job.

Where I work is rather a small broadcast services company that keeps their video archive on hundreds of
“Micron M500” SSDs. These SSDs are hidden in a caddy/cartridges. Our company commissioned this
built to an external contractor and got a batch of them about 2-3 years ago that was good until we
eventually ran out of them.

Trying to order a new batch we released the manufacturer is out of business for a while and there is no
communication means to access them and (not very surprisingly) it seems no distributes have heard of
these cartridges as they were bespoke built.
So, we found ourselves left with no media and with all our money invested on this infrastructure built
around these 'bespoke' caddies

Out of desperation I opened one of the cartridges/caddies and found it was nothing more than Micron
M500 SSD inside! (Model: MTFDDAT480MAV – Firmware MU05)

So, happy that we found the key to this mysterious lock , we ordered some SSD (Samsung, Intel,
Kingston,..) but the recorder rejected them as not being good enough.

We ended up ordering the “exact” same model of Micron M500 SSD, with same model number and we
updated them to the same firmware MU05. So, exact match.

Now the system detects them fine and plays out from them if stick them in a PC and copy files manually,
but the archive recorder won't save on them with this annoying error message that read “SSD is not
degrading and not genuine”, which are both invalid as every other test shows them healthy and genuine

So, provided everything is the exact match, we started to think that the previous contractor must have
customised the firmware to prevent others to get involved.

I contacted Micron Support and provided similar information. Their engineer replied that (1)Micron didn't
customize the firmware for client and (2) it's very unlikely for the contractor to do that on their own
without affecting the functionality of the SSD and firmware customization neeeds access to their UV
codes and Micron won't release their UV codes.

I spent days Googling this matter with every possible search phrase with no luck. At the same time going
up and down the recorder menu and found a menu item buried down there that shows SSD information
including drive size, serial number and firmware version. And I realized that on “contractor's provided”
Micron it shows “MU05 V4” (there is V4) whereas with the ones we bought from market it shows “MU05
V1”.

Micron says they only released one MU05 and there is not Vx known to them, but that must be something
that prevents our equipment to work with it.

Having both of these drives at hand, and being able to use the Micron utilities to write firmwares on them
I shall think if I can 'Write' the firmware on to the SSD chip, it must be also possible to “read” the
firmware off the chip in to a file.

How can I 'dump' the entire firmware off the old working SSD so I can write it to the new ones?

Your answers could save a company that helps a few people to provide for their families.

Many thanks
Richard

PS. In “Micron Storage Executive” software, there is an item that downloads firmware-log.bin and
identify_data and some other information (Attached). Could that be any help?

15250FD7A237.zip

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 20th, 2016, 18:35
Over the years I've seen many cases of disreputable practices such as this. I despise these people.

As a workaround, can you backup your original SSDs to alternative media and then reuse the existing
cassettes?

RichardR wrote:
So, provided everything is the exact match, we started to think that the previous contractor must have customised the firmware to prevent others to
get involved.

I contacted Micron Support and provided similar information. Their engineer replied that (1)Micron didn't customize the firmware for client and (2)
it's very unlikely for the contractor to do that on their own without affecting the functionality of the SSD and firmware customization needs access
to their UV codes and Micron won't release their UV codes.

I spent days Googling this matter with every possible search phrase with no luck. At the same time going up and down the recorder menu and found
a menu item buried down there that shows SSD information including drive size, serial number and firmware version. And I realized that on
"contractor's provided" Micron it shows "MU05 V4" (there is V4) whereas with the ones we bought from market it shows "MU05 V1".

Micron says they only released one MU05 and there is not Vx known to them, but that must be something that prevents our equipment to work with
it.

Can you show us the Identify Device information for your original "V4" SSD? BTW, CrystalDiskInfo
displays the same Identify Device data in big-endian format.

ISTM that the secret to making your V1 device work with your application may be to modify the
following [little-endian] section of the Identify Device block.

Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000100 55 4D 35 30 30 2E 2E 31 30 53 00 00 00 00 UM500..10S....
00000110 00 00 34 32 34 36 20 20 20 20 30 30 35 43 33 32 ..4246 005C32
00000120 36 31 20 20 20 20 54 4D 44 46 41 44 34 54 30 38 61 TMDFAD4T08
00000130 41 4D 20 56 AM V

I'm assuming that you applied the following firmware update:

http://www.crucial.com/wcsstore/CrucialSAS/firmware/M500/MU05/crucial-m500.mu05-01-S0-tcg.zip
The following data appear in the fwa.img file packaged with the MU05 update:

Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00087570 4D 55 30 35 2E MU05.
00087580 30 31 2E 53 30 00 00 00 00 00 00 24 52 65 76 3A 01.S0......$Rev:
00087590 20 32 34 36 34 34 24644

The data seems to match the Identify Device report.

... and here is a section from fwc.img which also matches the Identify Device report ...

Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000E270 24 52 65 76 3A 20 32 $Rev: 2
0000E280 33 31 36 35 20 3165

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 20th, 2016, 19:26
Here are the Identify Device data after byte-swapping:

Code:
Offset(h) 00 02 04 06 08 0A 0C 0E

00000000 0440 3FFF C837 0010 0000 0000 003F 0000 .@?ÿÈ7.......?..
00000010 0000 0000 2020 2020 2020 2020 3135 3235 .... 1525
00000020 3046 4437 4132 3337 0000 0000 0000 4D55 0FD7A237......MU
00000030 3035 2020 2020 4D69 6372 6F6E 5F4D 3530 05 Micron_M50
00000040 305F 4D54 4644 4441 5434 3830 4D41 5620 0_MTFDDAT480MAV
00000050 2020 2020 2020 2020 2020 2020 2020 8010 €.
00000060 4001 2F00 4001 0000 0000 0007 3FFF 0010 @./.@.......?ÿ..
00000070 003F FC10 00FB B110 FFFF 0FFF 0000 0007 .?ü..û±.ÿÿ.ÿ....
00000080 0003 0078 0078 0078 0078 40B0 0000 0000 ...x.x.x.x@°....
00000090 0000 0000 0000 001F F70E 00C6 016C 00CC ........÷..Æ.l.Ì
000000A0 03F8 0028 746B 7D09 6163 7469 BC09 6163 .ø.(tk}.acti¼.ac
000000B0 407F 0001 0001 00FE FFFE 0000 0000 0000 @......þÿþ......
000000C0 0000 0000 0000 0000 36B0 37E4 0000 0000 ........6°7ä....
000000D0 0000 0008 6003 0000 500A 0751 0FD7 A237 ....`...P..Q.×¢7
000000E0 0000 0000 0000 0000 0000 0000 0000 401E ..............@.
000000F0 401C 0000 0000 0000 0000 0000 0000 0000 @...............
00000100 8021 4D55 3035 2E30 312E 5330 0000 0000 €!MU05.01.S0....
00000110 0000 3234 3634 2020 2020 3030 4335 3233 ..2464 00C523
00000120 3136 2020 2020 4D54 4644 4441 5434 3830 16 MTFDDAT480
00000130 4D41 5620 0000 0000 0000 0000 0002 0000 MAV ............
00000140 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150 0005 0001 0000 0000 0000 0000 0000 0000 ................
00000160 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190 0000 0000 0000 0000 0000 0000 0035 0000 .............5..
000001A0 0000 4000 0000 0000 0000 0001 0000 0000 ..@.............
000001B0 0000 0001 0000 0000 0000 0000 107F 0000 ................
000001C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001D0 0000 0000 0001 00FF 0000 0000 0000 0000 .......ÿ........
000001E0 0000 0000 0000 4000 0000 0000 0000 0000 ......@.........
000001F0 0000 0000 0000 0000 0000 0000 0000 04A5 ...............¥

Words 129 - 159 (bytes 0x102 - 0x13F) are vendor specific.

Re: Dumping Micron M500 SSD firmware MU05 RichardR ↓

August 21st, 2016, 17:06
Hi fzabkar;

First and foremost, I want to thank you for your picking this up. To be very honest with you I was
hopeless a little bit. I was thinking no one might even care. So, THANKS for you willing to help:)
It all sounds amazing what you say. But let me see if I'm understanding you correctly with my little old
head...

1-
The previously uploaded was taken from the "original V4" SSD that is generated by "Micron Storage
Executive" application (there is a little Debug Report on the top that generates this zip file + OS
information)

I am now downloading CrystalDiskInfo and will try to grab Identify Device data in Big-endian and will
post it shortly.

2-
Attached to this reply is the identify_data.bin, etc.. similar to that I initially attached to the first post for
off-the-shelf V1 drive (the capacity is 240GB vs 480GB original ones)

3-
For the firmware update download, I actually used either:
- Micron Storage Executive software which detects, downloads and updates on its own
- Bootable USB stick with .iso file that you linked above

I realise that you are doing a great favour by helping us, and I cannot thank you enough for that.

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 21st, 2016, 18:00
ISTM that the firmware version is the same, ie "MU05.01.S0 2464 00C52316".

The differences in the Identify Device data are in the serial number, model number, capacity (240GB
versus 480GB), World Wide Name (WWN), plus a single bit in the security status word.

Code:
Offset(h) 00 02 04 06 08 0A 0C 0E

00000000 0440 3FFF C837 0010 0000 0000 003F 0000 .@?ÿÈ7.......?..
00000010 0000 0000 2020 2020 2020 2020 3133 3131 .... 1311
00000020 3039 3245 4531 3441 0000 0000 0000 4D55 092EE14A......MU
00000030 3035 2020 2020 4D69 6372 6F6E 5F4D 3530 05 Micron_M50
00000040 305F 4D54 4644 4441 5432 3430 4D41 5620 0_MTFDDAT240MAV
00000050 2020 2020 2020 2020 2020 2020 2020 8010 €.
00000060 4001 2F00 4001 0000 0000 0007 3FFF 0010 @./.@.......?ÿ..
00000070 003F FC10 00FB B110 FFFF 0FFF 0000 0007 .?ü..û±.ÿÿ.ÿ....
00000080 0003 0078 0078 0078 0078 40B0 0000 0000 ...x.x.x.x@°....
00000090 0000 0000 0000 001F F70E 00C6 016C 00CC ........÷..Æ.l.Ì
000000A0 03F8 0028 746B 7D09 6163 7469 BC09 6163 .ø.(tk}.acti¼.ac
000000B0 407F 0001 0001 00FE FFFE 0000 0000 0000 @......þÿþ......
000000C0 0000 0000 0000 0000 44B0 1BF2 0000 0000 ........D°.ò....
000000D0 0000 0008 6003 0000 500A 0751 092E E14A ....`...P..Q..áJ
000000E0 0000 0000 0000 0000 0000 0000 0000 401E ..............@.
000000F0 401C 0000 0000 0000 0000 0000 0000 0000 @...............
00000100 0021 4D55 3035 2E30 312E 5330 0000 0000 .!MU05.01.S0....
00000110 0000 3234 3634 2020 2020 3030 4335 3233 ..2464 00C523
00000120 3136 2020 2020 4D54 4644 4441 5432 3430 16 MTFDDAT240
00000130 4D41 5620 0000 0000 0000 0000 0002 0000 MAV ............
00000140 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150 0005 0001 0000 0000 0000 0000 0000 0000 ................
00000160 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190 0000 0000 0000 0000 0000 0000 0035 0000 .............5..
000001A0 0000 4000 0000 0000 0000 0001 0000 0000 ..@.............
000001B0 0000 0001 0000 0000 0000 0000 107F 0000 ................
000001C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001D0 0000 0000 0001 00FF 0000 0000 0000 0000 .......ÿ........
000001E0 0000 0000 0000 4000 0000 0000 0000 0000 ......@.........
000001F0 0000 0000 0000 0000 0000 0000 0000 F7A5 ..............÷¥
Here are the significant differences:

Code:
byte V4 V1
---------------
C8 - 36B0 44B0 number of addressable logical sectors (words 100-103) ...
CA - 37E4 1BF2 0x37E436B0 versus 0x1BF244B0

DC - 0FD7 092E WWN (words 108-111) ...

DE - A237 E14A 500A0751092EE14A versus 500A07510FD7A237

100 - 8021 0021 security status (word 128, bits 15:9 reserved)

Security is enabled, supported, not locked, and not frozen in both versions. However bit 15 = 1 for V4 and
0 for V1. I don't know if this is of any consequence. I'll have to read through more recent ATA standards
for more info.

In short I can't see what is causing the V4-V1 distinction.

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 21st, 2016, 18:22
FWIW here is the datasheet for the M500:
https://www.micron.com/~/media/document ... _5_ssd.pdf

At the risk of introducing a red herring, it seems strange that bit 15=1 when Micron's datasheet has it at 0.
Attachments

Identify_Device_Word_128.gif (5.1 KiB) Viewed 10451 times

Re: Dumping Micron M500 SSD firmware MU05 RichardR ↓

August 21st, 2016, 18:33
Thanks for your swift reply fzabkar;

In the meantime, I just created a through report out of CrystalDiskInfo.

I included:

- Old (so called V4) M500 480GB identify data

- New (off-the-shelf) M500 240GB identify data
- Crucial M500 480GB identify data (Crucial looks exactly the same as Micorn apart from model number
and branding sticker)

Reading your kind replies so far:

1) Am I understanding correctly that merely considering "Identify" part of the SSD is satisfactory to
decide whether or not the two device should be seen identical to an external device?

2) Is that right to think even that "1 bit" could fail these new SSDs in whatever check that disallows them
to be recognised? It must be looking at something far from guessing anyway?

3) How can I set this "bit 15" on these new SSDs? so I can put them in real-life test to make sure? I know
HDPARM cannot preform permanent changes. So can we set this in our firmware image and upload it to a
SSD and put it in actual test? (Hopefully I can?)

4) Is there anything other information that you could think I can extract from these drives that might help
at all?

5) And finally, is there a way to dump the firmware, whatever bloody stuff is in it, and upload it in the
new ones, just to put this theory in actual test?

I know I'm asking questions like crazy and I am grateful that you reply as as ever.
During the past month I've read so much (and mostly not understood!) in various forums that I actually am
going crazy...

Cheers;

Re: Dumping Micron M500 SSD firmware MU05 RichardR ↓

August 21st, 2016, 18:42
At the risk of introducing a red herring, it seems strange that bit 15=1 when Micron's datasheet has it at 0.

This sounds like a breakthrough!

Any suggestion on how this can get set?

Re: Dumping Micron M500 SSD firmware MU05 RichardR ↓

August 21st, 2016, 19:13
Security is enabled, supported, not locked, and not frozen in both versions

I also attached HDPARM report of two different of those older 480GB SSDs. There is something about
Security in them (towards the end of each output)
Hope this helps a bit

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 21st, 2016, 19:32
fzabkar wrote:
Security is enabled, supported, not locked, and not frozen in both versions. However bit 15 = 1 for V4 and 0 for V1.

Sorry, that should have been "security is NOT enabled". Also, enhanced security erase is supported.

In any case I'm still not sure whether bit 15 is important. It might be worth asking Micron about it.

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 22nd, 2016, 1:59
FYI, I have previously analysed a Micron firmware update:

Analysis of Micron RealSSD C400 Self-Encrypting Drive (SED) SSD Firmware Update:
http://www.hddoracle.com/viewtopic.php?f=59&t=1617
There are many similarities to your M500 firmware update, but also many differences.

That said, an SSD would probably have numerous firmware modules, some with code and others with
data (eg SMART attributes, SMART logs, bad block lists, Flash Translation Layer, serial number, WWN).
A typical update might only touch 4 out of 100 (?) of these modules -- it wouldn't touch the drive specific
data modules.

Currently I'm puzzled by the "MU05 V4" and "MU05 V1" text strings. An examination of the MU05
update finds "V1" in the fwc.img file and nowhere else. I've also searched for "1V" without success.
Fwc.img is the boot block code that is written to the very first section of the 8-pin SPI serial flash IC. I
would be very interested to see a dump of this IC on your V4 SSD. If we find "V4", then that would be
conclusive. I think I'm drawing a long bow, though.

BTW, you can extract the various files from the MU05 update using 7-Zip. Just drill down to the
following level:

crucial-m500.mu05-01-S0-tcg.zip\crucial-m500.mu05-01-S0-
tcg.iso\BOOT\ISOLINUX\BOOT2880.IMG\

AUTOEXEC.BAT launches the update.

Dosmcli.exe is the update tool.

The following command is executed by AUTOEXEC.BAT:

dosmcli.exe --bus ALL -U fwa.img --segmented 10 -p M500:S0:MU05 -t None --asic-fw fwb.img -

-bl fwc.img

These are the 3 firmware images. Each is written to a different chip.

fwa.img = main firmware (NAND flash array)

fwb.img = asic-fw (MSP430 power controller IC)
fwc.img = boot loader (8-pin SPI serial flash)

This is the embedded help documentation for the dosmcli parameters:

Code:
--bl <bootloader firmware file>
Used to update bootloader firmware. Must be used with either the
[-u] or [--serial-number] options to specify a particular drive or
with the [--ssd-only] or [-p] options to update multiple drives.

-p <product:customerId:FirmwareRevision>
--product <product:customerId:FirmwareRevision> (ie. C400:00:8435)
Specify a product family, customerId and the firmware revision
that will result from the update. Devices that have firmware at
the specified revision will be skipped.
Specify NO for customerId or NONE for firmware revision to bypass those checks.

--segmented <#> The size of a segment (for ATA download command 92h, mode 3
when updating device firmware or SCSI Write Buffer command 3Bh,
mode 7 when updating SATL bridge firmware), in number
of blocks, defined as a hex number.
Example: --segmented 7f
The default is 1.

-t <directory/fileName>
--tcg-table-update <directory/fileName | None>
 The file specified is the TCG table data to download to the drive.
If "None" is given for the file name this is a TCG drive firmware
update but the TCG tables are not being updated with the firmware.
To be used in conjuction with [-D] to specify deviceId unless using
the -U option where no specific deviceId is needed.

--bus [ATA | SCSI | ALL]

Specifies which bus to look for devices on. Defaults to ALL
on Windows and DOS and SCSI on Linux.

-U <directory/fileName>
--update-by-product-customer <directory/fileName>
Update firmware for product and customer specified in -p switch.

IMHO the best way to approach this problem would be to monitor the SATA traffic with a SATA analyser.
I'm still on the lookout for a cheap one, but you may be able to hire one for a day. All you would need to
do would be to log the V4 and V1 traffic during a typical backup session. In this way you would be able to
capture Micron's "VU" commands.

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 22nd, 2016, 2:24
Here are some hi-res photo of the interior:
http://goughlui.com/2014/06/08/review-teardown-crucial-m500-240gb-solid-state-drive/

http://cdn1.goughlui.com/wp-content/uploads/2014/06/DSC_6354.jpg
http://cdn1.goughlui.com/wp-content/uploads/2014/06/DSC_6356.jpg

The serial flash memory chip is the "25P16". The "MSP430" is on the other side.

New discovery! [Re: Dumping Micron M500 SSD firmware MU05] RichardR ↓
August 22nd, 2016, 16:46
OK! I made a little discovery today that I think can possibly help:

While I was looking around our whatever of these SSD remaining for us, I found an older one -probably
the first one they gave us for demo- that is NOT Micron, and is Kingston 120GB (instead of normal
Micron 480GB) and it works fine

I immediately bought Kingston 120GB, 240GB and 480GB and again all these new ones fail...
The main issue with Kingston is the the model that I found and works is SMS100 (RBU-
SMS100S3/120GD1 99M4740), but there is absolutely no SMS100 in stock anywhere, so I got SMS200
that are available. So no wonder they arn't compatible.

BUT, what I like to think is important is that there is now a way to compare TWO pattern across two
different manufacturer to possibly realise what is that prevents our SSD from working.

I attached the Identify data, etc. from CrystalDiskInfo, hoping this could lead us to a clue.

Attachment contains
1- Kingston 120GB RBU-SMS100S3/120GD1 (works fine without any hesitation whatsovever)
2- Kingston 120GB SMS200S3/120G (Comes up as "Error: Unknown Media")

Is it possible to see the similarities between Kingston (1) and Micorn 480 to possibly figure out this
bloody secret?

Thanks again as ever

PS: On a side note these are mSATA form factor SSDs going through a simple interface adaptor (PCIe to
SATA)
Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓
August 22nd, 2016, 17:18
It doesn't appear that the security bits (in Identify Device) are the secret:

120: 4015 0000 0000 0000 0000 0000 0000 0000 0021 0000

120: 4018 0000 0000 0000 0000 0000 0000 0000 0021 0000

... or perhaps the "Unknown Media" error occurs before the security bits are examined?

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 22nd, 2016, 19:20
normal SSD

Code:
Model : KINGSTON SMS200S3120G
Firmware : 608ABBF0
Serial Number : 50026B726700A51A

working SSD

Code:
Model : KINGSTON RBU-SMS100S3120GD1
Firmware : S8FM08.0
Serial Number : 50026B725A04B4FD

I wouldn't use the following tool in case it is data destructive, but it would appear that the two SSDs use
different flash controllers, in which case their vendor specific commands would also be different.

Silicon Power Velox V55 S8FM08.0 and 600ABBF0 (42MB):

http://www.silicon-power.com/file/driver/V55_SSD_Firmware_EN.rar

Silicon Power SSD Update Tool 1.0.0.0:

http://www.necacom.net/index.php/ssd/sp-ssd/8891-silicon-power-ssd-update-tool-1-0-0-0

- Updating the firmware version S8FM08.0 for SSD equipped with Phison controller.
- Updating the firmware version 600ABBF0 for SSD equipped with a SandForce controller.

Phison Tool Box_Complete_v1.05.exe

SPCC_Field Updater V136 for Windows.exe

Re: Dumping Micron M500 SSD firmware MU05 bubaleh ↓

August 23rd, 2016, 8:12
As a assumption, your equipment could linking to serial numbers of the SSD's. You can change the drive's
serial by PC3000 SSD. It's pretty expensive tool, so try to look around for data recovery service that has it.

P.S. Sorry, I have Russian version of this tool, so the screenshot is in Russian too.
Attachments
 Manufacture data editing form

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 23rd, 2016, 17:03
AIUI, the OP's system recognises several vendor supplied cartridges, so I can't see how this could be a
serial number issue. Moreover, the error messages differ depending on the SSD model.

I suspect that the machine is issuing Vendor Specific Commands (VSCs) to each SSD, and testing the
results against a database of "genuine" candidates.

For example, it could be that the software is issuing a list of supported VSC_Enable commands to the
SSD and waiting for an acknowledgement. If an SSD does not support a particular VSC_Enable
command, then it would respond with Command Aborted. If the SSD responds with Command Aborted to
every VSC_Enable in the list, then it would trigger the "Unknown Media" error. Otherwise, if the SSD
acknowledges the command, then the software would probe deeper and look for the "genuine" marker
buried within the firmware. If it doesn't find this marker, then it responds with "SSD is not degrading and
not genuine". That's my theory, anyway.

Just FYI, here are examples of VSC Enable/Disable commands for various HDDs:
http://www.hddoracle.com/viewtopic.php? ... 192&p=5486

IMHO, the best approach is to hire a SATA analyser for a day and capture the SATA traffic for each of the
genuine and non-genuine SSDs. If my theory is correct, then the SandForce SSD (KINGSTON
SMS200S3120G, f/w 608ABBF0) would cause the software to test the VSC Enable command for every
supported device in its internal list.
Edit: We could test the serial number idea by using HDDHackr to modify a suitable WD HDD so that it
identifies itself with the model number, serial number, firmware version and capacity of a "genuine" SSD.

Re: Dumping Micron M500 SSD firmware MU05 RichardR ↓

August 23rd, 2016, 18:02
Thanks bubaleh and fzabkar;

The "Unknown media" error comes up quick, in 5-6 seconds after inserting SSD in at most. The
"Degrading..." error comes up in about 15 seconds or so (noticeably longer than "Unknown..." one). This
could be some indication that fzabkar theory is right?

I started to think that serial number could be the issue a while back, but later though unless serial numbers
have a predictable pattern (or are consequential) there must be a relatively large list/database of them in
the recorder firmware (or am I talking non-sense?) I'm sure there must a formula to them, but they looked
random to me.

It can be only a check as simple as checking Model against capacity against firmware version. One
problem I actually have is that I cannot find M500 480GB Micron anywhere (I can find Crucial that is -at
least visually- the exact same design, but not Micron) So, HDDHackr is actually a great idea!! I have a
very positive feeling about this.

I think it must be more complicated than just downloading and double clicking on it? But please let give it
a try...

In the meantime, I have spoken to Kingston Customer service (their Europe Headquarter in UK). Their
representative (Nadia) was an extremely nice person but had basic technical knowledge and she promised
to put my question through to their engineers. But basically she confirmed fzabkar that SMS200 is
fundamentally different from SMS100 and although it's newer and faster in sequential operations, it
doesn't support many good old feature that our application needed (such as Multiple Sector Transfer)

You won't believe me, but I also contacted Intel (I'm not even sure why I chose them) and surprisingly, at
least on the phone they don't have speed and knowledge you guys have in here. I went through a lengthy,
mostly irrelevant questions and nothing!

Regarding device rental, I don't have any problem hiring SATA analyser, I just don't know anything about
its operation. I guess I have to remove the recorder cover and attache it between SSD and the connector.

I'd say, if HDDHackr can alter capacity indication, lets give it a shot first
I can do either Micron 240GB or Crucial 480GB (in case HDDHackr can change the manufacturer
identifier)

I'm keeping my fingers crossed

Re: Dumping Micron M500 SSD firmware MU05 RichardR ↓

August 23rd, 2016, 18:44
Oh, Sorry. Just realised about Western Digital only thing...And it appeas that WD doesn't do SSDs?

Can PC-3000 SSD clone Micron M500 ROM into a either Crucial M500? or another Micorn M500?

Is getting hold of PC-3000 SSD a solution to our misery?

Re: Dumping Micron M500 SSD firmware MU05 fzabkar ↓

August 23rd, 2016, 19:17
HDDHackr only hacks WD HDDs, nothing else. I only suggested the WD HDD for testing purposes. This
is because there are plenty of free tools that would allow us to modify its serial number, etc, and thereby
impersonate your "genuine" SSD. That said, if my theory is correct, I expect that we would encounter the
"Unknown Media" error.
 If you wish to reduce the capacity of a non-genuine SSD to match the genuine one, then you could do so
with a HPA (Host Protected Area). A tool such as HDAT2 (freeware) can do this. However, I doubt that
this approach would be fruitful.

I've never used a SATA analyser, but I would think that you would interpose it between the SATA host and
SATA peripheral, and then log the traffic to its internal memory. There would have to be some way to
copy these data to an external storage device, otherwise it would be difficult for us to work with.

BTW, have you priced PC-3000 SSD?

Post a reply
Jump to: Flash storage, SSD Go
Powered by phpBB © phpBB Group.

Board index #