# Undo nvme-format

## Gh0str1d3r

Hi everyone,

I made a very bad mistake. My ssd had some problems and I couldn't run hdparm anymore. I found some post in the internet suggesting to fix this by executing 

```
nvme format <device>
```

 on the device. The man page was kind of cryptic to me and I thought it would cause the drive to be scanned and some header to be fixed. What it seemed to have done is wipe the entire disk. At least I can't even read the disk anymore in the bios of the laptop. Assuming that I can boot from a thumb drive, is there a way to undo this command? The laptop crashed immediately after the command completed.

Thanks for any tips!

----------

## bunder

I believe nvme format is essentially a secure erase, if so then it's probably gone.   :Sad: 

----------

## Gh0str1d3r

 *bunder wrote:*   

> I believe nvme format is essentially a secure erase, if so then it's probably gone.  

 

It says that the default option is "No secure erase operation requested". Is there still hope?

Edit: Booting from a live stick shows that the partition table of the disk has been wiped. I still believe that the data has not been securely erased (for this, the command finished too quickly, in a fraction of a second).

----------

## hhfeuer

testdisk would be the first thing I'd try.

----------

## Gh0str1d3r

 *hhfeuer wrote:*   

> testdisk would be the first thing I'd try.

 

That's a good tip! I ran this tool from a kubuntu live system. It found the linux partition, but not the boot, swap, and the 2 windows partitions. I guess it has to do with the missing endmark 0xAA55:

```
TestDisk 7.0, Data Recovery Utility, April 2015

Christophe GRENIER <grenier@cgsecurity.org>

http://www.cgsecurity.org

OS: Linux, kernel 4.18.0-10-generic (#11-Ubuntu SMP Thu Oct 11 15:13:55 UTC 2018) x86_64

Compiler: GCC 7.3

ext2fs lib: 1.44.4, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none, curses lib: 

ncurses 6.1

Hard disk list

Disk /dev/nvme0n1 - 1024 GB / 953 GiB - CHS 976762 64 32, sector size=512

Partition table type default to Intel

Disk /dev/nvme0n1 - 1024 GB / 953 GiB

Partition table type: Intel

Analyse Disk /dev/nvme0n1 - 1024 GB / 953 GiB - CHS 976762 64 32

Current partition structure:

Partition sector doesn't have the endmark 0xAA55

search_part()

Disk /dev/nvme0n1 - 1024 GB / 953 GiB - CHS 976762 64 32

     Linux                238069   0  1 976762  20  8 1512843912

     ext4 blocksize=4096 Large_file Sparse_SB Recover, 774 GB / 721 GiB

get_geometry_from_list_part_aux head=64 nbr=1

get_geometry_from_list_part_aux head=8 nbr=1

get_geometry_from_list_part_aux head=16 nbr=1

get_geometry_from_list_part_aux head=32 nbr=1

get_geometry_from_list_part_aux head=64 nbr=1

interface_write()

 1 * Linux                238069   0  1 976762  63 32 1512845312

simulate write!

No extended partition

TestDisk exited normally.

```

Is there a trick to fix this?

----------

## hhfeuer

```
Partition sector doesn't have the endmark 0xAA55 
```

just means that the boot sector has been overwritten, stating the obvious.

Did you hit Quick Search after startup?

----------

## Gh0str1d3r

 *hhfeuer wrote:*   

> 
> 
> ```
> Partition sector doesn't have the endmark 0xAA55 
> ```
> ...

 

Yes, first quick search and then deeper search. None of them revealed any partitions apart from the Linux partition.

Maybe the partition type was not correct. I just tried "Intel / PC" and "EFI GPT". The other options sounded wrong.

----------

## hhfeuer

Then you're doomed...or at least your data. Some low-level format command on an SSD probably also erases the list of logical sectors etc. SSDs and data recovery don't go well together.

----------

## NeddySeagoon

Gh0str1d3r,

What was the partition structure.

Was it an MSDOS or GPT table ?

Use a hexeditor to look at the first few MB of the drive.

Its likely its all gone though.

----------

## Gh0str1d3r

 *NeddySeagoon wrote:*   

> Gh0str1d3r,
> 
> What was the partition structure.
> 
> Was it an MSDOS or GPT table ?
> ...

 

I don't remember setting the partition structure. I just used fdisk to change the sizes of the partitions, but never changed the type of the table itself. I assume it was MSDOS. The laptop is a Dell XPS 13 9350 and came with Windows 10 pre-installed.

Actually, with GPT I only did a quick scan. I now ran a deep scan selecting the "EFI GPT" table option and it found this:

```

Disk /dev/nvme0n1 - 1024 GB / 953 GiB

Partition table type: EFI GPT

Interface Advanced

Bad GPT partition, invalid signature.

Trying alternate GPT

Bad GPT partition, invalid signature.

Analyse Disk /dev/nvme0n1 - 1024 GB / 953 GiB - CHS 976762 64 32

Bad GPT partition, invalid signature.

Trying alternate GPT

Bad GPT partition, invalid signature.

Current partition structure:

Bad GPT partition, invalid signature.

Trying alternate GPT

Bad GPT partition, invalid signature.

search_part()

Disk /dev/nvme0n1 - 1024 GB / 953 GiB - CHS 976762 64 32

     MS Data                487565312 2000409223 1512843912

     ext4 blocksize=4096 Large_file Sparse_SB Recover, 774 GB / 721 GiB

ext2fs_dir_iterate failed with error 2133571402.

Directory /

search_part()

Disk /dev/nvme0n1 - 1024 GB / 953 GiB - CHS 976762 64 32

     MS Data                487565312 2000409223 1512843912

     ext4 blocksize=4096 Large_file Sparse_SB Recover, 774 GB / 721 GiB

     MS Data               1243033208 2755877119 1512843912

     ext4 blocksize=4096 Large_file Sparse_SB Recover, 774 GB / 721 GiB

This partition ends after the disk limits.

     MS Data               1243033624 2755877535 1512843912

     ext4 blocksize=4096 Large_file Sparse_SB Recover, 774 GB / 721 GiB

This partition ends after the disk limits.

     MS Data               1243035576 2755879487 1512843912

     ext4 blocksize=4096 Large_file Sparse_SB Recover, 774 GB / 721 GiB

This partition ends after the disk limits.

Disk /dev/nvme0n1 - 1024 GB / 953 GiB - CHS 976762 64 32

Check the harddisk size: HD jumpers settings, BIOS detection...

The harddisk (1024 GB / 953 GiB) seems too small! (< 1411 GB / 1314 GiB)

The following partitions can't be recovered:

     MS Data               1243033208 2755877119 1512843912

     ext4 blocksize=4096 Large_file Sparse_SB Recover, 774 GB / 721 GiB

     MS Data               1243033624 2755877535 1512843912

     ext4 blocksize=4096 Large_file Sparse_SB Recover, 774 GB / 721 GiB

     MS Data               1243035576 2755879487 1512843912

     ext4 blocksize=4096 Large_file Sparse_SB Recover, 774 GB / 721 GiB

interface_write()

 1 P MS Data                487565312 2000409223 1512843912

simulate write!

```

Looks to me like the same partition as before (the size is the same) but with lots of errors regarding the exact location. I think the partition table is not GPT.

----------

## NeddySeagoon

Gh0str1d3r,

I'm fairly sure Windows 10 needs GPT.

Lets not worry too much about the partition table for now. That testdisk finds anything at all is encouraging.

```
$ sudo fdisk -l /dev/sde

Disk /dev/sde: 477 GiB, 512110190592 bytes, 1000215216 sectors

Disk model: Crucial_CT512MX1

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disklabel type: gpt

Disk identifier: 34FC1BD2-FEC6-4CEC-9A4E-0EF83A538F86

Device      Start        End   Sectors   Size Type

/dev/sde1    2048     249855    247808   121M Linux filesystem

/dev/sde2  249856 1000214527 999964672 476.8G Linux filesystem
```

The first partition starts at LBA 2048 and that's true of GPT or modern MSDOS. LBA 2048 is 1MiB from the start of the drive.

So, without using the partition table, lets try to mount a filesystem that starts there.

```
mount -o ro,offset=1048576 /dev/sde /mnt/someplace 
```

/dev/sde, not /dev/sde1 as we are trying offset=1048576 bytes from the start of the volume.

read only is a good idea when we don't know what we might find.

/mnt/someplace needs to exist

You use your whole device.

----------

## Gh0str1d3r

Thanks NeddySeagoon! I will try that tomorrow morning, when my drive is back from the disk repair shop. What these guys found is quite discouraging, though. They say the entire drive only contains zeros:

https://monosnap.com/file/hjci14i5n2twq9Gy2V7ujhxBDtAEzC

I hope that they are wrong.

----------

## NeddySeagoon

https://www.google.co.uk/,

That looks like the first sector and we already knew that as the AA 55 or is it 55 AA signature is missing.

Operations on SSDs, even long operations appear to complete quickly.

For most, the drive does not go busy. It makes a note of them and processes them in the background, so normal operations can continue.

e.g. You do a filesystem trim. The drive knows what blocks it can erase but erase is a long operation, so your discarded data is erased in the background.

That screenshot looks like windows version of hexedit.  Once you have your drive back, you can look around with hexedit.

----------

## Gh0str1d3r

The TRIM feature seems to be an issue here. Can I disable TRIM on the hard drive to prevent it from deleting further files when just powered on? (assuming there is anything left to be saved)

----------

## NeddySeagoon

Gh0str1d3r,

Not to my knowledge.

----------

## Gh0str1d3r

Thanks for the advice. Then I'll better be quick. What would be the critical step that removes the "trim" flag on the data? For example, is it enough to restore the partition table (or even any partition table that I can later adjust)?

----------

## NeddySeagoon

Gh0str1d3r,

Everything on a HDD of any sort is data. The drive knows nothing of what the data represents.

That is provided by context.

e.g. There are two partition table formants in wide use. MSDOS and GPT.

The context here is that a MSDOS partition table starts at byte 446 of LBA 0.

A GPT partition table starts in LBA 1. To the drive its just data.

A while ago HDD started to look perfect (no bad blocks) because the drive maps out bad blocks to spare sectors.

HDD only have a small number of spare sectors compared to their total size.

It follows that a sequential range of logical block addresses need not map to a sequential range of physical blocks on the drive. Indeed this can be detected by access time increases to access an remapped sector.

SSDs take this to a whole new level. They have some unused unmapped blocks that can be mapped in while used and trimmed blocks are mapped out be be erased.

Mapped out blocks cannot be accessed via the drive interface, even if they hold data that you need. 

The partial layer of indirection that was introduced in rotating rust HDD to hide bad blocks is complete in SSDs, or at least much more so.

Almost any logical block can be mapped to almost any physical block. This is used for wear levelling as well as swapping out blocks to be erased.

Once this mapping has been changed, there is no way to undo it.

Giving the drive the trim instruction is not reversible.  Stopping the trim operation part way through is not useful, even if it were possible.

----------

## Gh0str1d3r

I now have the drive back. I ran testdisk again and wrote the single partition that it found to the drive. Using hexedit, I can indeed see some fragments of data, even though most of it is zeros. Here is the start of the non-zero data:

https://imgur.com/a/XHoKS8S

I can't mount the device. 

```
# mount -o ro,offset=1048576 /dev/sda /mnt/extern/

mount: /mnt/extern: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

```

It doesn't matter what offset I use. I also tried to specify ext4 file system or mounting /dev/sda1 directly. Is there any way I can access the data?

Thanks so much.

----------

## NeddySeagoon

Gh0str1d3r,

At that location on the drive, the data would be a GPT partition table.

The UIDs should be easily identifiable but the data thats there looks nothing like a GPT.

----------

## Muso

Sorry for your loss. Gh0str1d3r

At least I learned a trick for zeroing out an SSD quickly.

----------

## Gh0str1d3r

 *NeddySeagoon wrote:*   

> Gh0str1d3r,
> 
> At that location on the drive, the data would be a GPT partition table.
> 
> The UIDs should be easily identifiable but the data thats there looks nothing like a GPT.

 

NeddySeagoon, thanks for the detailed explanation! Does that mean all is lost?

----------

## NeddySeagoon

Gh0str1d3r,

Very probably, yes.

You could try running strings on the drive.  That will pint the printable character sequences that are at least 4 characters long, see 

```
man strings
```

However, its a big step from finding file fragments to recovering files.

----------

## Gh0str1d3r

The strings command allowed me to reconstruct all the little data that was still remaining. Essentially, the few files that the system was just writing while I executed that command. Nothing of value. Still, thanks a lot to everyone who tried to help!

----------

