Menu ▾ ▴

Home Log in to Edit

guy Narayan

Guymager Wiki

Welcome to the Guymager Wiki. Guymager is a fast and most user friendly forensic imager. See it's homepage for details.

Interesting pages:

Click here for a list of all pages in the Guymager Wiki.

Related

Wiki: New features in Guymager 0.8.x

Discussion

1 2 > >> (Page 1 of 2)

  • vincenzo

    vincenzo - 2016-10-29

    SCENARIO:
    I tried to use Guymager to make a clone of a usb stick with 8 gigabytes on a hard disk drive of 120 gigabytes, previously filled with data for approximately 40% (I know that the combination 8 - 120 is disproportionate, but I did it the same).
    Obviously all the data in the hard disk disappeared and remained only the cloned partition.

    I used Guymager to detect the image (in order to recover data from the hard disk with the usual forensic tools) .
    As a target for the image I used a second hard drive of 500 gigabytes, formatted NTFS.

    WHAT APPENED:
    Guymager started and after an hour's work found 700 bad sectors hard disk clone, reduced its speed to 0.5 Mb / s and told me that it took about 144 hours to finish the copy and that he had just copied 2.6 GB up to that point.

    My question is: why Guymager slows and incredibly increases the time for copying?

    Tips are welcome.

    Thanks in advance

    Best Regards.

    Vincenzo.

     

  • L Barrera

    L Barrera - 2017-10-16

    I used Guymager to image HD of several computers (Exx type images). In about 30% of cases, the info file (the plain text file that stores data about the image) was unreadable (it appears as chinese characters). Since there was no change in the procedure, I am wondering what could cause guymager to do this in three cases out of ten?. (the other seven info files were perfect and all ten images were perfect, inlcuding the three were info file is unreadable). Having used guymager for several year, this is the first time this happens. Any hint?

     

  • L Barrera

    L Barrera - 2018-09-02

    Is there a command line version of Guymager, that allows to run the program several times from within a bash script file? If so, where are the command line instructions?

     

    • guy

      guy - 2018-09-02

      Hello,
      no, there is currently no command line version. It has been asked several times but I did find yet the time for doing it.
      Greetings
      Guy

       

      Last edit: guy 2018-09-18
      alternate

      • L Barrera

        L Barrera - 2018-09-02

        Thanks Guy, I very much appreciate your prompt reply.

        Now, is there a way to parse programmatically the fields required to Guymager to run ? I meant a way to fill the corresponding text box automatically somehow?

        Best,

        Lautaro Barrera

        Lautaro Barrera B.
        www.e-forensicsinc.comhttp://www.e-forensicsinc.com

         

        Last edit: guy 2018-09-18
        alternate

        • guy

          guy - 2018-09-02

          Yes, that's possible. Two ways of doing it:

          1) The hard way: You read /etc/guymager/guymager.cfg where everything is documented

          2) The easy way: You tell me what you need and I'll provide you with a personal cfg file for you that you may refine afterwards

          BTW: Guymager 0.8.9 will be released in 3-4 weeks.

          Guy

           

          Last edit: guy 2018-09-18
          alternate

          • L Barrera

            L Barrera - 2018-09-02

            Thank you Guy!!

            What I need is to fill all the fields in the Guymager screen taken the data from a text file.

            We normally take 5-10 images and some of the corresponding fields are the same for various or all images and others (like the image name) are unique... so it would ideal to run some sort of script that starts Guymager, fill all fields in the starting screen with the appropriate values and then start the image (of course after choosing E01 or DD) ...

            I hope have properly explained what I need, but please let me know about any further clarification you may need

            I very -very- much appreciate your help and goodwill. It makes evident you professionalism that is otherwise notable on the quality of your product: Guymager

            Best,

            Lautaro Barrera B.
            www.e-forensicsinc.comhttp://www.e-forensicsinc.com

             

            Last edit: guy 2018-09-18
            alternate

  • guy

    guy - 2018-09-18

    Lautaro, I tried several times to join you. I replied to your questions as usual by email, but somehow, SF didn't put my latest responses here. It's only now, after logging to SF that I see this. (SF starts to become more and more annoying...)

    I also contactet you directly by email... didn't that work?

    Here's my answer (sent on 4. Sept. 2018):

    Copy the attached file to /etc/guymager/local.cfg (root rights needed). Then launch Guymager and start an acquisition. You'll see that many fields have changed. Have a look into the attached file and you'll see how easy it is.

    Some fields even have disappeared. Look at the hash selection fields: You may no longer select the hash algorithm; it has been configured to do always MD5 and the user may no longer choose. That's the effect of 'Hide' in the second column of the table.

    You now should be able to do your own changes.

    If you really need different settings on every launch of Guymager then you may write a script that generates the contents of local.cfg before Guymager is being launched.

    The configuration also knows special tokens, as for example %size% (will be replaced by the size of the device being acquired) or %serial% (the serial number of the device). For a list of all tokens please open /etc/guymager/guymager.cfg and search for "Special tokens".

    Guymager has many more configuration options. They are listed and documented in /etc/guymager/guymager.cfg. Please do not do any changes in guymager.cfg directly. Only copy those parameters you like to change into local.cfg. If you change directly in guymager.cfg then all your changes will be lost on the next Guymager update.

    Guy

     
    local.cfg

    • L Barrera

      L Barrera - 2018-09-18

      Guy,

      Thank you very much for your help.

      This is the first e-mail I received from you in days. In fact, I was missing your normal promptness in replying, but I thought that was due to your holidays.

      I really appreciate this information and your courtesy in making this available. I will let you know the outcome,

      Best wishes,

      Lautaro Barrera

       

      Last edit: guy 2018-09-19
      alternate

  • Eddy Colloton

    Eddy Colloton - 2018-09-18

    Guy,

    I'm a bit new to this, so forgive me if the answers to these questions is reproduced elsewhere. The other applications I have used to create EWF/E01 disk images have often prompted me for a "compression level." Does your application compress the E01s it creates?

    There also seems to be many verisons of this format (https://www.forensicswiki.org/wiki/Encase_image_file_format) which version does guymager create?

    Eddy

     

  • guy

    guy - 2018-09-19

    Concerning compression
    According to my experience, when it comes to compression level, people always have the same philosophy: Max, none, only compress if all zeroes, ...

    That's why I didn't add it to the acquisition dialogue. I do not want to add GUI elements that need to be adjusted again and again.

    Instead, use the configuration file for setting your preferred compression level. The default value used by Guymager is "fast". Let's suppose you want to change it to "best". You do it this way: Create file /etc/guymager/local.cfg (root rights required) and put this line into it:
    EwfCompression = BEST
    For further reading: Have a look into /etc/guymager/guymager.cfg and search for "Compression".

    PS: It is also possible to modifiy /etc/guymager/guymager.cfg directly, but all your changes will be lost on the next Guymager update. That's why you should put your changes into /etc/guymager/local.cfg.

    PPS: Guymager logs all configuration settings in its log file, see /var/log/guymager.log. So, if ever you wonder what was a certain setting 3 weeks ago you may look it up here.

    Concerning EWF formats
    Short history: The EWF format never was seriously documented - it's the old stupid problem we know from many commercial SW developers...

    Fortunately, there's a guy named Joachim Metz (one of the best developers in forensics on this planet) who reverse engineers almost any format. One the first things he did was documenting the EWF file format and writing his famous libewf for working with EWF files. See the doc on github.

    He revealed that different programs generate slightly different EWF files. However, those changes aren't really too important (except very early EWF versions and the switch made for generating big EWF files). It's merely a question of how sections are ordered or if certain sections are repeated redundanly. Every software should be able to handle any of these subtle differences.

    In the beginning, Guymager was entirely based on Joachim's libewf. Joachim even was so kind to add some parallelising extensions based on my comments, because I wanted Guymager to run as fast as possible (later on, others also added parallelised compression).

    Some time later, I wrote my own EWF functions, optimised for Guymager's architecture (I was unhappy with libewf's RAM consumption). These internal EWF functions are used nowadays by default. The EWF files generated by Guymager can be read by any software (just as other imagers also generate files readable anywhere).

    Guymager still is able to run with libewf. Have a look into /etc/guymager/guymager.cfg, search for parameter EwfFormat. The parameter is set by default to "Guymager", meaning that Guymager's own EWF functions are to be used. If you want for example generate the format that is most close to what Encase 6 did then open (or create) /etc/guymager/local.cfg and add this line:
    EwfFormat = Encase6
    See /etc/guyager/guymager.cfg for a list of all possible settings.
    Attention: When settings EwfFormat to seomthing different than "Guymager" then Guymager uses libewf instead of its own functions. I do not recommend doing so, as you might run out of RAM with libewf when imaging several big HDDs in parallel! Recommendation:
    EwfFormat = Guymager

    Guy

     

    Last edit: guy 2018-09-19

    • Eddy Colloton

      Eddy Colloton - 2018-09-20

      Thanks for all of this info Guy! I really appreciate your thorough and prompt reply! Another question: Do you think the subtle differences between the Guymager format and other EWF versions will be documented publically in the same way Metz has so thoroughly documented the subtle differences between EnCase1 and EnCase6, for example?

       

    • Eddy Colloton

      Eddy Colloton - 2018-12-13

      I've done a few tests compairing the size of ewf disk images with compression=empty vs compression=fast. I've been surprised that the 2 flash drives I have imaged with compression=empty have ended up equal size to a raw disk image (despite often having lots of empty space). See results below:

      32gb flash drive:
      EWFCompression=Fast: 23.2 GB, 00:49:43
      EWFCompression=Empty: 32.1 GB, 00:49:40

      4gb flash drive:
      EWFCompression=Fast: 2.2 GB, 00:03:40
      EWFCompression=Empty: 4 GB, 00:03:40

      I had assumed that due to the space available on the 4 gb drive (about 2.8 gb avail) that the resulting empty compression ewf disk image would be around 2.2gb (like the fast is). This is clearly not the case. Is the "availbale" space on a drive not technically "empty"? Or is something else going on?

      -Eddy

       

      • guy

        guy - 2018-12-13

        Eddy, I think you already found the solution yourself: "not technically empty".

        I added the compression option "empty" for systems with poor CPU performance. For example, when imaging many PCs in a company, where I then use the PCs themselves for doing the images (booted from Linux live sticks). Those office PCs often are low cost systems with cheap Intel CPUs.

        For "empty" to work there must be whole chunks filled with only zeroes. A chunk is the block size used in EWF, it very often is 32K. So, only if there is a block with 32768 zero bytes then the "empty" compression jumps in and replaces that chunk by a precomputed z-compressed-zero-chunk.

        Try this to see the effect:
        1. Put your drive/stick into a Linux system and mount it
        2. Open a shell, change to the directory of the stick you just mounted and run
        dd if=/dev/zero of=./big_and_zero bs=1M
        3. Wait until dd returns with the "no more space" error.
        4. Remove the file
        rm ./big_and_zero
        5. Unmount the device

        Now, try to image that device again with compression set to "empty" and see what the resulting image size will be.

        Of course, there is no sense in waiting a long time to fill the empty spaces with zeros before starting the image. It's just for showing the effect.

        SSDs and sticks are generally problematic for the "empty" setting, as even brand new devices often are not initialised with zeros (unlike HDDs).

        My recommendation: The setting "empty" is for HDDs images done on slow CPUs.

         

        Last edit: guy 2018-12-13

        • Eddy Colloton

          Eddy Colloton - 2018-12-20

          Wow! The volume that created a 4gb disk image with ewfcompression=empty,
          created a disk image of only 1.1gb after running the scripts you recommend.

          I think your point is well taken that the uninitialized SSDs are not a good
          fit for this setting, but thank you so much for helping me problem solve.

          Best,
          Eddy

          On Thu, Dec 13, 2018 at 12:50 PM guy gvoncken@users.sourceforge.net wrote:

          Eddy, I think you already found the solution yourself: "not technically
          empty".

          I added the compression option "empty" for systems with poor CPU
          performance. For example, when imaging many PCs in a company, where I then
          use the PCs themselves for doing the images (booted from Linux live
          sticks). Those office PCs often are low cost systems with cheap Intel CPUs.

          For "empty" to work there must be whole chunks filled with only zeroes. A
          chunk is the block size used in EWF, it very often is 32K. So, only if
          there is a block of 32K fully made up of zeroes then the "empty"
          compression jumps in and replaces that chunk by a precomputed
          z-compressed-zero-chunk.

          Try this to see the effect:
          1. Put your drive/stick into a Linux system and mount it
          2. Open a shell, change the directory to the stick you just mounted and run
          dd if=/dev/zero of=./big_and_zero bs=1M
          3. Wait until dd returns with the "no more space" error.
          4. Remove the file
          rm ./big_and_zero
          5. Unmount the device

          Now, try to image that device again with compression set to "empty" and
          see what the resulting image size will be.

          Of course, there is no sense in waiting a long time to fill the empty
          spaces with zeros before starting the image. It's just for showing the
          effect.

          SSDs and Stick are generally problematic for the "empty" setting, as even
          brand new devices often are not initialised with zeros (unlike HDDs).

          My recommendation: The setting "empty" is for HDDs images done on slow
          CPUs.

          Sent from sourceforge.net because you indicated interest in
          https://sourceforge.net/p/guymager/wiki/Home/

          To unsubscribe from further messages, please visit
          https://sourceforge.net/auth/subscriptions/

          --
          Eddy Colloton
          309-830-3306
          eddy.colloton@gmail.com

           
          alternate

  • guy

    guy - 2018-09-20

    I would guess: No, Guymager's EWF files won't be described separately.

    I think there's no sense in doing so. Other imagers are missing as well - and Joachim surely has other things to do than re-running every imager with every version update ; )

    BTW: if you need a tool for accessing EWF files under Linux then have a look at xmount.

     

    • Eddy Colloton

      Eddy Colloton - 2018-09-21

      Thanks again Guy! Yeah, makes sense lots of imagers out there. I've used xmount a little, I'm more familiar with ewfmount from libewf. Both seem to work well!

       

  • ridgedale

    ridgedale - 2018-11-15

    I must be doing something wrong. When I try to mount the .E01 file on another system I get the following error:

    Unable to open input image file 'xmount': The specified input file(s) are not valid EWF files!

    I made sure the write blocker tool had set the source internal drive of the computer was set to read only before I created the image and the target drive (4Tb USB3 G-Tech mobile external drive) was set to read/write. I used Guymager via a CAINE 10 bootable flash drive (*Note: I had to reformat the 4Tb drive to NTFS in order to get it be recognised)* to create the .E01 image file written directly to the 4Tb external drive. No bad sectors were encountered during the acquisition. The MD5 hash and MD5 hash verified image recorded in the .info file match exactly.

    I've got 3 copies of the 1Tb image file inluding the original image file on the 4Tb external drive. I subsequently copied the the .E01 (single image file) and .info files to two other computers: MacOS Sierra (on external GTech 8Tb thunderbolt drive - FS = Mac OS Extended (Journaled)) and Windows 10 64-bit (internal hard drive - FS = NTFS). The only way I was able to transfer the file from the 4Tb drive to the 8Tb drive was to install Lubuntu under VMware Fusion. Neither of the md5 hashes for those .E01 files match the original md5 hash generated by Guymager at the time of the image completion.

    The file sizes by getting the information from the file properties were 105,670,052,583 bytes (105.67 GB on disk - Mac (on 8Tb drive)), 98.4Gb (105,670,052,583 bytes) but showing as 103,193,411kb in Windows Explorer (on internal hard drive) - Windows 10. The size of the original file on the 4Tb drive matches the details of the file on the Windows 10 internal hard drive and matches the byte count of the file copied to the 8Tb external drive.

    When I connect the 4Tb drive to the Windows 10 PC and run an md5 check against the original image file it matches the hashes of the both the copied files! It does not match the hash generated by Guymager upon completion of the imaging. The original file has not been touched other than being copied as detailed.

    Any ideas what I have done wrong?

     

  • guy

    guy - 2018-11-15

    You wrote:

    Neither of the md5 hashes for those .E01 files match the original md5 hash generated by Guymager at the time of the image completion.

    and

    It does not match the hash generated by Guymager upon completion of the imaging

    The MD5 hash calculated by Guymager (and by any other imager that exists) is always the hash of the original source data packed into the E01 file. As the E01 file also includes its own EWF structures and some meta data it's just normal that the MD5 of the whole E01 file is different from the MD5 of the imaged data it contains.

    In order to check the consistency and the imaged data hash of an EWF file you should use ewfverify.

    You may instruct Guymager to not only compute the hash of the imaged data but also the hashes of the generated Exx files. AFAIK, that option is switched off by default in CAINE. To enable it you may run Guymager from the command line like this:
    sudo guymager CalcImageFileMD5=on
    You'll find the hashes computed that way in a table at the end of the info file, for every Exx file there's a hash.

    I cannot tell you what your problems are on MacOS/Windows or why you would have to use Vmware. Guymager simply created a file on an NTFS drive. No matter what file Guymager or any other program wrote to that drive and no matter what it contains: A file is a file and can be copied. Nobody needs Vmware for copying files. Or else there must be a problem with the system that does the copy. Does your Mac support NTFS?

    Concerning your xmount problem: On which system do you run it? What's the exact command line you're using?

     

  • ridgedale

    ridgedale - 2018-11-19

    Thanks for your reply, Guy.

    I've learnt a lot over the past weekend. I re-ran the check using ewfverify as advised and the md5 checksum matches, which is good to know. I also ran some md5sum tests on some small text files and then compressed them using .7z that confirmed your point that the checksum of the "container" file will always be different from the source file.

    As regards the xmount error, if I remember correctly, I was using the gui interface. Using the commandline resolved that issue. ;)

    I'm beginning to realise it would be better going forward to run any forensic tools from the commandline to ensure control and integrity of the process being launched. I'll remember to use the CalcImageFileMD5=on switch in future.

    My Mac is currently running Lion and Sierra which should support opening NTFS at least read-only out of the box. I'm not too bothered at this stage as I found a workround albeit convoluted by launching a Lubuntu VM. I'll be replacing the MacBookPro internal hard drive shortly, once I've imaged all the boot partitions and backed up the data to the server. So I'll check out mounting cross-platform volumes as soon as I have a vanilla OS installed.

    Thanks again for your help and patience.

     

    • guy

      guy - 2018-11-19

      You always may contact me directly by email via
      develop at faert point net
      if you like. It's easier than using a wiki (and more adequate as well).

       
      alternate
1 2 > >> (Page 1 of 2)

Log in to post a comment.