Announcement

Collapse
No announcement yet.

imageUSB

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • imageUSB

    Hello

    We were working with imageUSB 1.2.100 for a long time. Now we have been tracing a problem: after copying files to a 1GB stick - each file identical to its source by MD5 check - then creating a bin and afterwards writing this bin back to a stick (this time 8 GB), not all files are still identical to the source. This behaviour, the differences of the file, was reproducable. The MD5 check of the tool itself was all the time successful (identical) on both directions (to/from stick).
    Are/were there any known issues around these topics (resizing, version)?

    Now we updated to the latest version and are copying the original files to a 8GB stick directly like the target and then the process is every time successful. So, there is a solution and we are back in bussiness, but for documentary reasons we are interested if there are any reasonable explanations.
    Thank you in advance for any feedback.

    Best regards, mleb

  • #2
    ...after copying files to a 1GB stick - each file identical to its source by MD5 check - then creating a bin and afterwards writing this bin back to a stick (this time 8 GB), not all files are still identical to the source.
    imageUSB doesn't modify the contents of the files within an image, in fact imageUSB doesn't even know what files are inside an image itself. The duplication just reads bytes from the image and then write the same bytes out to the drive. Did you actually compare the contents of the files themselves to view what was modified?

    There were a couple of bugs that has seen be fixed since V1.2.100, that may of caused the imageUSB to report that the checksum was incorrect, but nothing that would of knowing modifying files itself.

    In V1.3.1002, Fixed a bug causing imageUSB to incorrectly fail a verification by reading more bytes than available on the destination image/drive.
    In V1.3.1001, Fixed a bug causing imageUSB to incorrectly write the header block back to the disk when image is not of even 1 MB chunks.

    Some of the above listed issues might of been introduced when we went from V1.2 to V1.3 (where we rewrote portions of the imageUSB code to handle physical drives vs only on drive letters), I can't remember for certain.There has been number of bug fixes/changes to imageUSB since V1.2.100, you can find a change log under the "Release History" section on the product page, https://www.osforensics.com/tools/write-usb-images.html

    Comment


    • #3
      Thank you for the feedback.

      As we suspected the resizing of the image and therefore the possibility of something cutted away we took a look a bit deeper and compared on byte level - see attachment. Click image for larger version

Name:	20190108150706-{F4DC9949-F3C8-4858-8379-EE1665FC5798}.png
Views:	538
Size:	579.5 KB
ID:	43734

      The content is noisy disturbed through the whole file. Not at the begin or end.
      Interesting is, that only two of about twenty files are affected. Perhaps the data storage had some problems - even the fact we tried different ones.

      Comment


      • #4
        A lot of those differences are single bit differences, which is characteristic of hardware failure (bad RAM or bad Flash memory).

        Comment

        Working...
        X