Clone an SSD drive.

New to Debian (Or Linux in general)? Ask your questions here!

Re: Clone an SSD drive.

Postby CwF » 2020-12-26 03:54

p.H wrote:dd preserves data and alignment, unless it encountered read errors and conv=sync was not specified.
If MD5 sums do not match, the copy is just wrong.
What "firmware magic" are you talking about ? The drive or the host system ?

Ya, I don't know, it's not my gadget. There's a third thread on the subject to answer this. This gadget need not be 'standard', and it's not mine. Just saying I've seen a few things like this and wondered why. Maybe simpler, maybe intentional, don't know? If they don't match, It shouldn't be that hard to find the difference, but another thing to know why. Just because it appears to be a standard ssd interface does not mean you can copy it. You can of course copy it if is a 'standard' disk. There are custom firmwares...
CwF
 
Posts: 872
Joined: 2018-06-20 15:16

Re: Clone an SSD drive.

Postby hack3rcon » 2020-12-26 12:00

CwF wrote:
hack3rcon wrote:I used "dd" and "PassMark OSForensics". The PassMark OSForensics has some options about create image and hash computing.

Very good hack3rcon, I admire your diligence.
p.H wrote:If the cloned partitions have the exact same sizes and contents as the original ones, they should have the same hashes.

You'd think, unless there is copy protection in place.

So hack3rcon's idea for the hex editor is correct, and where your going to end up.

I claim that qemu-img is forensically accurate - that is a deleted file before the image copy will be retrievable in the same way on the copy... Yes. But, the utilities are focused on data, not structure, so an intentional block of zeros are often discarded, sectors don't line up, yet all the 'data' is there. This is why I keep saying the magic is elsewhere - it's in the firmware! The data likely does have odd offsets designed to be ignored if copied. The firmware knows what sector has what data - that IS a relationship that is NOT relevant to 'preserving data' - that is preserving orientation.

So, spot check data alignment - yes with a hex editor! Divide the image up and check large blocks to find the offsets. You'll likely find the data is the same, what sector is not the same. The secret should be non-standard non-data at boundaries of data blocks that are themselves identical.

In the hexeditor you don't exactly do it 'by sight'. There is a search function ya' know! You can search content or by sector. The exercise here is to verify particular data at a particular sector

Again- get this point = the magic is the firmware of this non-standard device. The data structure on the disk is intentionally non-standard structure and gets 'corrected' by standard methods and the data is not 'changed'.

The simple theoretical compare to understand what is happening is Optical media copy protection. Do these image utilities make a perfect copy of the data, they DO! Do these CD/DVD checksums match? NO. The images don't work do they? Because the copies lost offset info, info deemed irrelevant to data integrity, info only the device firmware knows!

The other possibility is the firmware of the SSD itself. It can be altered from standard. There is no analog to disk geometry though it will emulate that info. That can be paired with the device firmware. Usually the filesystem is responsible for 'where is what' This device does NOT use the filesystem for it's security check - it reads sector 42 (whatever), and that is what is changed....indiscriminately and innocently changed by the copy utility to reside in sector 1.

It's called 'Copy-Protection'. And hack3rcon, you can crack it! And this thread is now off-topic.

Thank you.
How can I get the rid of copy protection?
The original SSD Drive HPA/DCO is: https://pasteboard.co/JGI7nmH.png
The cloned SSD Drive HPA/DCO is: https://pasteboard.co/JGI7E5w.png
If the cloned drive can't boot, then can it because of my cloned SSD Drive HPA/DCO? The DCO size of cloned SSD Drive is "N/A"!
When I plugged the cloned SSD Drive into the device then it halted at "0x6857c8" address:
Code: Select all
                            VxWorks System Boot


Copyright 1984-2002  Wind River Systems, Inc.





CPU: Mitel MMC-C PPC83XX F2500
Version: VxWorks5.5.2
BSP version: 3.1/10
Creation date: Aug  5 2011, 18:41:11




Press <SPACE><SPACE><SPACE> to stop auto-boot AFTER countdown starts...
<7><6><5><4><3><2><1><0>
auto-booting...


boot device          : ata=0
unit number          : 0
processor number     : 0
host name            : bootHost
file name            : /partition1/RTC8260
inet on ethernet (e) : 172.18.6.5:fffffff0
host inet (h)        : 192.168.137.10
gateway inet (g)     : 172.18.6.14
user (u)             : ftp
ftp password (pw)    : ftp
flags (f)            : 0x0
target name (tn)     : MyPhone
other (o)            : qefcc


Disk Configuration Started.
Creating block device for controller  0 drive 0... done.
Creating CBIO device for controller  0 drive 0... done.
0KB added to /partition1 partition
free disk space after partition 0 is 0KB
0KB added to /partition2 partition
free disk space after partition 1 is 0KB
0KB added to /partition3 partition
free disk space after partition 2 is 0KB
0KB added to /partition4 partition
free disk space after partition 3 is 0KB
Attaching to partition table for 4 partitions on controller 0 drive 0... done.
Creating Cache Layer for partition 0 (/partition1) on controller 0 drive 0... done.
Creating Cache Layer for partition 1 (/partition2) on controller 0 drive 0... done.
Creating Cache Layer for partition 2 (/partition3) on controller 0 drive 0... done.
Creating Cache Layer for partition 3 (/partition4) on controller 0 drive 0... done.
Creating Dos FS device for partition 0 (/partition1) on controller 0 drive 0... done.
Creating Dos FS device for partition 1 (/partition2) on controller 0 drive 0... done.
Creating Dos FS device for partition 2 (/partition3) on controller 0 drive 0... done.
Creating Dos FS device for partition 3 (/partition4) on controller 0 drive 0... done.
Disk Configuration Complete.
Loading /partition1/RTC8260...66125120
Starting at 0x6857c8...
hack3rcon
 
Posts: 507
Joined: 2015-02-16 09:54

Re: Clone an SSD drive.

Postby p.H » 2020-12-26 13:00

IIUC,
- HPA is disabled on both drives
- DCO is disabled on one drive and not available on the other
- both drives have the exact same usable capacity

Anyway neither HPA or DCO can be held responsible for differences in "cloned" data located in the user accessible area.
IMO, the drive was just not cloned properly.
p.H
 
Posts: 1609
Joined: 2017-09-17 07:12

Re: Clone an SSD drive.

Postby hack3rcon » 2020-12-26 13:50

p.H wrote:IIUC,
- HPA is disabled on both drives
- DCO is disabled on one drive and not available on the other
- both drives have the exact same usable capacity

Anyway neither HPA or DCO can be held responsible for differences in "cloned" data located in the user accessible area.
IMO, the drive was just not cloned properly.

In this kind of situation which tools you will use? How can I clone it properly?
hack3rcon
 
Posts: 507
Joined: 2015-02-16 09:54

Re: Clone an SSD drive.

Postby p.H » 2020-12-26 14:14

dd on the whole drives
Code: Select all
dd if=/dev/<sourcedrive> of=/dev/<destinationdrive> bs=1M

and check the result with
Code: Select all
cmp /dev/<sourcedrive> /dev/<destinationdrive>
p.H
 
Posts: 1609
Joined: 2017-09-17 07:12

Re: Clone an SSD drive.

Postby CwF » 2020-12-26 15:43

Interesting.

Exactly ONE sector short!
a 'standard' 120GB SSD is 120,034,123,776 bytes, that's one sector bigger!
We should have 23444648 sectors!

I've imaged to standard ssd's many times and would throw away the ADATA if it was actually one short, it's not - that is the copy. That's why it doesn't show an accurate MaxDisk LBA. I happen to have a stack of 120's here to check....

The MAGIC number is 23444648! Guaranteed! That R3SL120G has a magic sector!

Now you have to find it, attempt to replicate it. I already said, the hex editor won't see it, but will see data offset - by ONE sector! As I said "check the boundaries" and good luck!

Oh ya, the checksum is including the this magic sector on the original and it does not exist on the copy = hence the mismatch. And now we know the magic is in BOTH device and SSD, like I said...

Enjoy.
CwF
 
Posts: 872
Joined: 2018-06-20 15:16

Re: Clone an SSD drive.

Postby p.H » 2020-12-26 15:58

You are confusing the max LBA and the sector count. LBA start at 0, so max LBA = sector count - 1.
p.H
 
Posts: 1609
Joined: 2017-09-17 07:12

Re: Clone an SSD drive.

Postby CwF » 2020-12-26 16:09

maybe..
check after another attempt I suppose.
CwF
 
Posts: 872
Joined: 2018-06-20 15:16

Re: Clone an SSD drive.

Postby p.H » 2020-12-26 16:19

No doubt. Previous posts and the two screens shots show the correct sector count.
p.H
 
Posts: 1609
Joined: 2017-09-17 07:12

Re: Clone an SSD drive.

Postby andre@home » 2020-12-26 19:26

hack3rcon wrote:In this kind of situation which tools you will use? How can I clone it properly?
Try Foxclone.
https://forums.linuxmint.com/viewtopic. ... 2#p1784922
Tried it myself several times, works great.
Very easy to use.
andre@home
 
Posts: 397
Joined: 2011-10-02 08:00

Re: Clone an SSD drive.

Postby hack3rcon » 2020-12-27 11:05

p.H wrote:dd on the whole drives
Code: Select all
dd if=/dev/<sourcedrive> of=/dev/<destinationdrive> bs=1M

and check the result with
Code: Select all
cmp /dev/<sourcedrive> /dev/<destinationdrive>

I did it already and not worked.
hack3rcon
 
Posts: 507
Joined: 2015-02-16 09:54

Re: Clone an SSD drive.

Postby hack3rcon » 2020-12-27 11:08

CwF wrote:Interesting.

Exactly ONE sector short!
a 'standard' 120GB SSD is 120,034,123,776 bytes, that's one sector bigger!
We should have 23444648 sectors!

I've imaged to standard ssd's many times and would throw away the ADATA if it was actually one short, it's not - that is the copy. That's why it doesn't show an accurate MaxDisk LBA. I happen to have a stack of 120's here to check....

The MAGIC number is 23444648! Guaranteed! That R3SL120G has a magic sector!

Now you have to find it, attempt to replicate it. I already said, the hex editor won't see it, but will see data offset - by ONE sector! As I said "check the boundaries" and good luck!

Oh ya, the checksum is including the this magic sector on the original and it does not exist on the copy = hence the mismatch. And now we know the magic is in BOTH device and SSD, like I said...

Enjoy.

Excuse me, you mean is that the ADATA SSD Drive is something like FAKE drive, but "R3SL120G" is OK? My ADATA drive has fewer sector?
hack3rcon
 
Posts: 507
Joined: 2015-02-16 09:54

Re: Clone an SSD drive.

Postby hack3rcon » 2020-12-27 11:10

andre@home wrote:
hack3rcon wrote:In this kind of situation which tools you will use? How can I clone it properly?
Try Foxclone.
https://forums.linuxmint.com/viewtopic. ... 2#p1784922
Tried it myself several times, works great.
Very easy to use.

Is it better than "dd", "OSForensics", "Acronis", "Hex Editor Neo" and "WinHex" ?
hack3rcon
 
Posts: 507
Joined: 2015-02-16 09:54

Re: Clone an SSD drive.

Postby p.H » 2020-12-27 12:31

hack3rcon wrote:I did it already and not worked.

What did cmp show ?
p.H
 
Posts: 1609
Joined: 2017-09-17 07:12

Re: Clone an SSD drive.

Postby CwF » 2020-12-27 13:42

hack3rcon wrote:ADATA SSD Drive is something like FAKE drive

Nope, my bad. I saw that sector count and saw red, I'm used to that number, to distinguish between the odd 128GB models. Your Adata is fine. I'll also note it was old Win CE things that I found odd storage issues like this, so smaller, older. So, I have come across un-duplicatable things...so call the gadget manufacturer and ask! I said 'call', ha.
CwF
 
Posts: 872
Joined: 2018-06-20 15:16

PreviousNext

Return to Beginners Questions

Who is online

Users browsing this forum: No registered users and 16 guests

fashionable