Recently while working on the malware-traffic-analysis.net exercise “2016-02-06 – TRAFFIC ANALYSIS EXERCISE – NETWORK ALERTS AT CUPID’S ARROW ONLINE”
I ran into a problem where when you loaded any file into the hex editor or just open it on its own it would push 1 core to 100% or use 25% of the CPU power.
David Solomon coined the phrase and Mark Russinovich passes it along.
“When in doubt run process monitor” . So that is what I did.
Here is what I seen.
When we look at this it show us the last thing it did before going out to lunch was to create a mount point.
From the time we started the program until the thread exits is a little more that 10 minuets, at which point the program finally shows up but the core is still pegged.
So I got to wondering what it was I had done last. After looking in the registry at the key referenced for the mount points, one of the mount points reminded me that the last thing I had done was install some “unnamed popular” software, which also created a mount point. So I quickly jumped on that scenario opened the command prompt as admin and ran mountvol /R which removes old mount points that are no longer used and can sometimes correct problems involved with mounted volumes.
But to my dismay, after restarting the system , that did not work.
Neither did uninstalling and then reinstalling the program.
So back to process monitor.
While scrolling thru the log file looking for anything of interest I ran across this.
Before the hang, the hex editor was looking for the .ini file to load some settings.
I didn’t think to take a screen shot of it, but what I found was one of the item paths in the file was duplicated several hundred time for 1 path entry. Here is what it should look like when it is working.
So the .ini file got corrupted most likely when I copied pasted from a VM straight to the hex editor. Strange things happen when running this VM in the background so I have to restart my system after every use with its services set to start in manual instead of automatic.
After deleting the current .ini file and allowing the program to recreate it the problem was solved.
So how did I know that was the problem ? I didn’t, but after seeing that many lines where there shouldn’t have been it was a more reasonable conclusion than the mount point idea.
I hope this helps someone else that has had the same problem.