search

orlikoski / CDQR

The Cold Disk Quick Response (CDQR) tool is a fast and easy to use forensic artifact parsing tool that works on disk images, mounted drives and extracted artifacts from Windows, Linux, MacOS, and Android devices
GNU General Public License v3.0
332 stars 51 forks source link

Process not completing #12

Closed tombytes closed 7 years ago

tombytes commented 7 years ago

Having trouble getting CDQR (v3.1.3) to complete its processing on some images/mounted devices. I was successful with a 16GB thumb drive (9 min) and with the 3GB nps-2008-jean.E01 test image (1h 27min).

I created a 3.5GB .E01 image using FTK Imager Lite v3.1.1.8 on a Windows 7, x86, VMware Virtual Machine. Image was located on an external HDD connected via USB 3.0. Forensic Machine was running an updated Kali Linux VM with 8GB RAM as used with the thumb drive and jean.E01 above. ./cdqr.py -p win --max_cpu /media/root/1TB_SSD/Evidence/FinalProject.E01 --export I force stopped CDQR after 16 hours. The logfile created during the process was over 90 MB in size, but most of it looks like below:

Identifier PID Status Sources Events File Main 12733 aborted 77245 (0) 1901267 (0) Worker_00 12741 running 40510 (0) 579900 (0) VSS2:TSK:/Windows/winsxs/Backup/x86_microsoft-windows-i..ltinstall.resources_31bf3856ad364e35_6.1.7600.16385_en-us_b0b31218d2ed84e5.manifest Worker_01 12747 running 35189 (0) 37180 (0) VSS2:TSK:/Windows/winsxs/Backup/x86_microsoft-windows-f..truetype-angsananew_31bf3856ad364e35_6.1.7600.16385_none_63cb9dea654e41ff.manifest Worker_02 12751 running 45059 (0) 71998 (0) VSS2:TSK:/Windows/winsxs/Backup/x86_microsoft-windows-feclient_31bf3856ad364e35_6.1.7600.16385_none_beb0674eb8e86a51.manifest Worker_03 12755 running 18853 (0) 1272473 (0) VSS2:TSK:/Windows/winsxs/Backup/x86_microsoft-windows-filtermanager-core_31bf3856ad364e35_6.1.7600.16385_none_10dfc9158c1fa6f6.manifest

I subsequently moved to a Dell XPS13 running Windows 10, 8GB RAM (no VM) and started CDQR. cdqr.py -p win --max_cpu G:\Evidence\FinalProject.E01 After 37 minutes it completed. But produced only two reports MFT and File System. Neither appeared to have collected the targeted information as compared to what was available in jean.E01.

I currently have the image mounted with CDQR pointed to F:. cdqr.py -p win --max_cpu F: It has been running for two hours, but has not yet started the reporting stage. Log file is empty and the tmp0g4cpp and tmpuldq_5 folders are also empty. This attempt may be a syntax error.

orlikoski commented 7 years ago

If CDQR doesn't stop with an error then it is working as expected. It can take a significant amount of time for file / artifact dense images. You can try to disable the hashing functionality to speed things up (--nohash) but then you lose the ability to search by hash at the end. The 90MB log file indicates that the image has a lot of files to process. You can verify how many parsers are running by the number of threads being used.

Typically the system will use every thread (when --max_cpu is used) until the longest running parser remains. At that point it will use one thread until that last parser has completed. The two longest running parsers are MFT, filestat, and hashing since they have to touch/ready every file in the image / artifact list.

orlikoski commented 7 years ago

Additionally, if you mounted the image with FTK imager then be aware that drive access can be limited to one thread at a time. This can significantly increase the amount of processing time required since it forces the process to being single threaded. It'll work in a pinch but not optimal.

Also keep in mind that it is possible to process .vmdk files directly without have to take images of them.

Hope this helps

tombytes commented 7 years ago

Mounting with FTK imager was just a troubleshooting method performed only during the last attempt. I had not expected there to be many files to process as the image was only ran for a few hours and used to trade about 20 emails, visit 30 URLs, and download a couple of photos. Its good to know that if it has not produced an error, it's working. Also, I will try the .vmdk route. Thanks for quick reply!