Clone an SSD drive.

[hack3rcon]

Device running VxWorks operating system.
I compared the original drive partitions hashes with cloned drive and they are not same :/

Code: Select all

Original:

Partition 0:
Size: 1.10 GB

SHA-1: 20f9d5196736771e6bffb0c12052e996d35e8df3
MD5: dd5a5ffb08d35d7758a77c9dacba3874


Partition 1:
Size: 6.58 GB

SHA-1: 8018ce32f313cabfd8ebf9fb7f14a1d79988a1b0
MD5: d5277242c62bde2ec3932049d65229ab



Partition 2:
Size: 14.09 GB

SHA-1: 1a3385d06f9ce95af80669b1af29d6d3a9e436ce
MD5: 7845181ea5c5467a7219ed714d97b09c


Partition 3:
Size: 1.10 GB

SHA-1: 77216106ff98a77479a81b95abd10b4a4a5cc46f
MD5: 032e997221da902b884ce23b26c6d0e9


Partition 4:
Size: 6.59 GB

SHA-1: 507276ebc81fdadd4dcd36b9ac2c024f7d52ddc9
MD5: 7cf0951a2fd6c4e9bbd101688b719ddb


Partition 5:
Size: 82.33 GB

SHA-1: c3d0cf989c17cc8fae518ab8729df3d4f9599eb5
MD5: b779439080a8a19c6f38f99883d86d9a

And:

Code: Select all

Cloned:

Partition 0:
Size: 1.10 GB

SHA-1: 88b4f781a66f8407326bde847c16114e40b7aacf
MD5: 8e67ea69b7d17bf867760175b6697d11


Partition 1:
Size: 6.58 GB

SHA-1: 6f623c54386e4346fd72cb09ea4539b38543575b
MD5: 2f3ad684cac91559646242764e984355



Partition 2:
Size: 14.09 GB

SHA-1: a91ad5962611ca36746283de9bc6c3d28921aeb0
MD5: dfbd62f46af3d3d4c6a2989f0a0c12a3


Partition 3:
Size: 1.10 GB

SHA-1: 6dab8007bed89608bca5bd026c0aee9c45dbd48b
MD5: c5779f6cb8b00106799cbd08d468ca79


Partition 4:
Size: 6.59 GB

SHA-1: 980908929ee34d2ca09e15dab1a7bc474b00e587
MD5: ab7e328be37708cbc1a597a4e115782e


Partition 5:
Size: 82.33 GB

SHA-1: a22fa1ba60062cf4981c23d0b8cbee807679cc82
MD5: 1685d0acb10c0d4e4d2ef8b419c0c588

Why? Is it normal?
MITEL can't boot with cloned drive:

Code: Select all

MITEL SYSTEM ROM R3.1/10 Aug 5 2011 (83 - POWER_ON_RESET)

CCA Number : 76009581 Ra.4
System Model : 00620001 F2500
CPU Model : 8360 R80480021
Reset Config Low : 0804008c
Reset Config High : b4500006
Coherent System Bus Clock (MHz) : 266
CPM Clock (MHz) : 399
Core Clock (MHz) : 533
DDR Clock (MHz) : 133
Local Bus Clock (MHz) : 66
Input Clock (MHz) : 33
Internal Memory Map : f0000000
Main Memory (MB) : 512
Local Memory (MB) : 0
Flash Memory (MB) : 4
MAC Address : 08000f640a40
POST Bypass : 0
Watchdog Bypass : 0
Slot Id : 0

Starting POST...

SDRAM CS1 Data Bit Walk 1................... PASSED
SDRAM CS1 Data Bit Walk 0................... PASSED
SDRAM CS1 Address Walk 1................... PASSED
SDRAM CS1 Address Walk 0................... PASSED
SDRAM CS1 March Test........................ PASSED

Starting vxWorks...

Decompressing FPGA image...615412 bytes decompressed successfully

Programming the FPGA image...OK

FPGA version 0002:6123 loaded

SATA RAID Controller Not Present.











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...

https://www.udrop.com/Koc/image_3303.png

[p.H]

How did you compute the partition hashes ?
Can you remind us how exactly you cloned the drive ? This thread has been quite long, and I am reluctant to re-read it all.
If the cloned partitions have the exact same sizes and contents as the original ones, they should have the same hashes.

[hack3rcon]

How did you compute the partition hashes ?
Can you remind us how exactly you cloned the drive ? This thread has been quite long, and I am reluctant to re-read it all.
If the cloned partitions have the exact same sizes and contents as the original ones, they should have the same hashes.

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

[CwF]

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.

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.

[p.H]

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 ?

[CwF]

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...

[hack3rcon]

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.

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...

[p.H]

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.

[hack3rcon]

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?

[p.H]

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>

[CwF]

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.

[p.H]

You are confusing the max LBA and the sector count. LBA start at 0, so max LBA = sector count - 1.

[CwF]

maybe..
check after another attempt I suppose.

[p.H]

No doubt. Previous posts and the two screens shots show the correct sector count.

[andre@home]

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.

[hack3rcon]

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]

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]

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" ?

[p.H]

I did it already and not worked.

What did cmp show ?

[CwF]

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.