SuperImager by medi...
 
Notifications
Clear all

SuperImager by mediaclone Issues

13 Posts
6 Users
0 Likes
1,161 Views
(@seanharold)
Posts: 2
New Member
Topic starter
 

Hello,

Recently I started testing with the SuperImager by mediaclone. This device is supposed to work faster than the Tableau TD2 forensic duplicator. However, I'm running into a lot of problems simply trying to benchmark this tool. Im comparing times of how long it takes to do a disk to file full physical image.

I've completed times between 500 GB and 1 TB. Whats giving me the problem are the 2 TB drives.
Now I'm using a 2 TB drive as the suspect and capturing onto a 2 TB drive. I enabled compression so this should fit with no problem.

So far some of the problems are

Not enough space
The SuperImager tries to capture 3.6 TB (yes the drives are in the appropriate slots - 1 in suspect drive and the other in evidence drive)
I've also had various detecting of drives problems but thats besides the point.

Has anyone used/dealt with the SuperImager and ran into the same problems I've had. Does anyone have any suggestions to avoid these problems?

thanks,

 
Posted : 20/06/2014 7:42 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Wild guess 😯 , but it could be connected with 512 bytes sectors vs. 4 Kb sectors or AF disks.

jaclaz

 
Posted : 20/06/2014 7:59 pm
Bulldawg
(@bulldawg)
Posts: 190
Estimable Member
 

Wild guess 😯 , but it could be connected with 512 bytes sectors vs. 4 Kb sectors or AF disks.

jaclaz

Based on your description, this is no doubt the issue. I'm not familiar with this duplicator, so check but check for a firmware update. There is no excuse for not handling 4K sectors in 2014.

 
Posted : 23/06/2014 5:08 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Based on your description, this is no doubt the issue. I'm not familiar with this duplicator, so check but check for a firmware update. There is no excuse for not handling 4K sectors in 2014.

Well, since (like it happened, it is happening and will happen with EFI/UEFI) everyone has managed to invent (or read in a different way) standards, the whole AF (Advanced Format) and particularly the 512b/512e vs "Native 4K" has been maaged in the most possible confusing way by WD and Seagate and Toshiba (with the help of MS, but this should be less relevant here).

See also the can of worms that was opened here
http//www.forensicfocus.com/Forums/viewtopic/t=11431/

jaclaz

 
Posted : 23/06/2014 7:23 pm
(@ekohavi)
Posts: 4
New Member
 

For speed please use SHA-1 and not MD5
For detection please insert the hard drives all the way into the drive bay and make sure the HDD are well connected to SAS/SATA socket.
E01/DD Destination HDD need to be to accommodate the OS and the audit trail info.
format with 4k Support is in process, it need an update to the hdd driver.

 
Posted : 26/06/2014 12:04 pm
(@mscotgrove)
Posts: 938
Prominent Member
 

Was the sample 2TB drive originally part of a 3.6TB RAID-0. If so, the 3.6TB may be the logical size found for the RAID, ie twice the physical drive. The software in this case would be using a EFI header rather than physical value for the drive size. To me this is more likely to be problem than a possible 0x200 / 0x1000 byte sector size. This would give error of 8 times rather than the twice found.

@ekohavi
I don't understand the comment 'for speed use SHA-1 not MD5' Are you saying you want a speed comparison for SHA-1 rather than MD5, or are you saying that SHA-1 is a faster routine?

 
Posted : 26/06/2014 4:39 pm
(@ekohavi)
Posts: 4
New Member
 

Hi
yes u are right.
Capture data or run HASH verify when user select to run with MD5 HASH on does slowdown the data capture speed, and that is because of the algorithm routing and the implementation in the SI unit.
Also MD5 is an old and breakable algorithm, and replaced by SHA-1 long time ago.
To achieve a high capture speed with this unit use the SHA-1, SHA-2 algorithm. (for example run HASH verify SHA-1 on SanDisk ExtremeII 128GB measured 31.3 GB/min or run HASH verify on 1TB WD Blue measured 10.1GB/min. If you run HASH verify on those hard drives with MD5, you will get half of this speed).
thx

 
Posted : 27/06/2014 9:54 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Also MD5 is an old and breakable algorithm, and replaced by SHA-1 long time ago.

Oh, noes, not again. (

It is possible to create a MD5 collision.

As such MD5 is not "secure".

But how probable it is that a MD5 collision happens "by chance"?

So low that the Heart of Gold could travel to end of universe and back with it fed to the improbability drive.

The fact that finding a collision is possible does not mean that is not a good validating hash for an image.

To achieve a high capture speed with this unit use the SHA-1, SHA-2 algorithm. (for example run HASH verify SHA-1 on SanDisk ExtremeII 128GB measured 31.3 GB/min or run HASH verify on 1TB WD Blue measured 10.1GB/min. If you run HASH verify on those hard drives with MD5, you will get half of this speed).

That should be an issue with the way the algorithms are implemented specifically, as tests around tend to result in MD5 being faster, either only slightly or much.

jaclaz

 
Posted : 27/06/2014 1:02 pm
(@ekohavi)
Posts: 4
New Member
 

u are right.
MD5 can still be used as authentication.
thank u

 
Posted : 27/06/2014 7:04 pm
Bulldawg
(@bulldawg)
Posts: 190
Estimable Member
 

I'm guessing here, but it's possible there's a co-processor dedicated to SHA-1 hashing, and an MD5 hash has to use the general-purpose processor in the device. If you've got one of these, it sounds like you should hash with SHA-1.

Ditto on MD5 being perfectly acceptable for this purpose.

 
Posted : 27/06/2014 7:08 pm
Page 1 / 2
Share: