I have a problem with Cuckoo Sandbox and its memory dump it should generate in order to be able to analyse it with Volatility.
My issue is:
Cuckoo's log files telling me that a memory dump has successfully been generated but it can not access them because they can not be found. Manually looking for them in the directory confirms that they do not exist. Cuckoo tells me to enable memory_dump in cuckoo.conf which is enabled.
My Cuckoo version and operating system are:
Cuckoo: 2.0.6
Host: Ubuntu 18.04.1 LTS
Guest: Win7 Ultimate, Service Pack 1, 32-bit
Those are my config files:
cuckoo.conf
memory_dump = yes
memory.conf
guest_profile = Win7SP1x86
delete_memdump = no
processing.conf
[memory]
enabled = yes
This is the output of the cuckoo.log:
INFO: Successfully generated memory dump for virtual machine with label Win7 to path /home/test/.cuckoo/storage/analyses/1/memory.dmp
[...]
ERROR: VM memory dump not found: to create VM memory dumps you have to enable memory_dump in cuckoo.conf!
Any kind of help is appreciated. If you need any more information from me please let me know
Edit: Only memory dump of full machine is not being generated. If malware is injected in a new process then memory dump is generated as shown in the report.json
INFO: injected into process with pid 3844 and name 'iexplorer.exe'
INFO: memory dump of process with pid 3844 completed
and I can also find the 3844-1.dmp file in the directory
I had a similar issue some time back where the memory dump creation was a little inconsistent. However that was with a older version of the cuckoo sandbox.
In processing.conf, check to see if you have set
[procmemory]
enabled = yes
I do remember that I had issues where I would sometimes get full memory dumps if I submitted a sample via the web GUI but I would not get memory dumps if I submitted a sample via commandline or vice versa. Sometimes I would only get memory dumps after the first sample failed. I found that a good place to start was with with something like a 32 bit putty.exe. Once the memory dumps started to work though I never had a issue after that. So I never documented what I done. I do remember playing around with the memory settings, so it may be worth playing around with processing.conf settings, turn them on and off to see what works.
[memory]
enabled = yes
[procmemory]
enabled = yes
and cuckoo.conf
memory_dump = yes
I know it may sound odd but I sometimes seen different functionality when submitting samples through both terminal or webgui mode. I no longer have my setup so I have nothing to compare it to.
[Edit]
Also make sure you have the correct dependencies installed
https://github.com/volatilityfoundation/volatility/wiki/Linux
Related
I'm developing a program running on embedded Linux (Debian Buster), and I found the program sometimes has performance issues. After some debugging process, I doubt the issue might not be in my program. Instead, somehow the OS start doing memory swap and my program was swapped to the file system.
Therefore, I use the code here to verify. And it turns out my program occupied much less physical memory after about 500 seconds, and it matches the hypothesis.
Now I want to find which process suddenly takes lots of memory at that point, but I don't know how.
Is there anyway to keep monitoring memory usage of all processes (or the top 10) of the system and dump to a log file? Any tools or commands would be good.
Thanks.
I'm developing a program running on embedded Linux
It will be helpful, if you could specify which embedded Linux you are working on.
Based on that, there are tools that someone could suggest.
For Linux, I would say, you could use:
top -p [PID]
you can get PID by:
ps [options]
I am not sure if there is a problem while using the command line?
dump to a log file
I think you could use grep to dump the terminal output to a log file you can create using touch command.
I am running QEmu on Linux and the virtualized OS is Windows XP. I would like to have either the 1st or the 2nd possibility:
to apply a command in QEmu which creates a dump that can be opened with WinDbg
to apply a command in QEmu which creates a dump of a particular type and then use another utility to make it readable with WinDbg
I know about QEmu's "dump-guest-memory" (creates an ELF-dump), rekall's raw2dmp plugin and Volatility's raw2dmp plugin. The output can be scanned by WinDbg, but in fact you face the problem of a bad header - probably, the most important part of a dump, which is good for nothing when the dump was created using tools/plugins mentioned above. Many fields are lacking in correct details. Comparing to a normal dump created by Windows OS itself (for example, when crashing), which contains information which is full and correct.
I am a student and I got the task to resolve this problem. I think it is reasonable to ensure that it has not been completed yet by anybody so doing it does make sense.
if Qemu Monitor commands are acceptable set the crashonctrlscroll registry key in the guest os
set the dump creation parameters in SystemApplet
Mycomputer->properties->Advanced->Startup and Recovery->Settings->Complete memory dump)
path , no overwrite , uncheck automatically restart
and from Qemu monitor shell use sendkeys ctrl_r-scroll_lock-scroll_lock
that will generate a dump that will be windbg compatible
manually initiated_crash bugcheck code 0xe2
screen shot of a 700 mb ram xp64 guest os running inside qemu on a 32 bit xp32 os
I have followed all the suggestions I can find.
I am running the current version on redis on windows 2008
I can run fin from command line
I can install the service but it doesnt run
I do...
redis-server --service-install redis.windows.conf
and get "redis successfully installed as a service"
Then I try to start the service doing...
redis-server --service-start redis.windows.conf --loglevel verbose
and get Redis service failed to start
I have made sure I have the .net framework 4.5.2 installed, I have tried with the firewall off and have played with security on the folder.
Anyone have any ideas?
(Merry Christmas all)
Start redis server from the command line instead of as a service and it will display a more useful error message. If you are just using the default configuration it is most likely a problem with the maxmemory/maxheap configuration.
C:\redis>redis-server.exe redis.windows.conf
[1576] 04 Feb 10:32:54.172 #
The Windows version of Redis allocates a memory mapped heap for sharing with
the forked process used for persistence operations. In order to share this
memory, Windows allocates from the system paging file a portion equal to the
size of the Redis heap. At this time there is insufficient contiguous free
space available in the system paging file for this operation (Windows error
0x5AF). To work around this you may either increase the size of the system
paging file, or decrease the size of the Redis heap with the --maxheap flag.
Sometimes a reboot will defragment the system paging file sufficiently for
this operation to complete successfully.
Please see the documentation included with the binary distributions for more
details on the --maxheap flag.
Redis can not continue. Exiting.
In my case the default commandline config did not have logging enabled and the service one did. And no place where it complains about that.
Try creating the directory ./Logs.
Old question, but I came across it while trying to get a Win7x64 install working using binaries Redis-x64-2.8.2101. Couldn't get it to start despite fiddling with various options, no meaningful error given when run with the config, and only an apparently spurious disk space error when run natively.
There appears to be a issue on the github related, linked here for future benefit: https://github.com/MSOpenTech/redis/issues/267
I'm getting a lovely BSOD on bootup (STOP: 0x0000007E) from a driver I'm writing, and would like to load up the memory dump for analysis. However, it's not getting dumped anywhere. Everything is setup correctly in the Startup and Recovery settings, but I get no dump file, and nothing in the event log stating a dump has taken place. It looks like a dump is not even occurring...
I know the exact line of code causing it (a call to IoAttachDevice()), but am not sure why, and would like to view the DbgPrint output to see where exactly it's failing. Could Windows possibly be crashing before the dumping functionality is set up? If so, how do I get access to the state of the machine when the failure occurs?
UPDATE: Other possibly useful information: I'm running Windows XP through VirtualBox on a Linux host.
I don't know why you're not getting a dump file, but if you have ready access to the machine, attach a kernel debugger to it an repro the error - you'll be left with the machine sitting in the debugger, ready to go (you can have the debugger produce the dumpfile for you if you want to debug offline as well).
Right-click on "my computer" select "Advanced", under "startup and recovery" click "settings". select "kernel memory dump" or "complete memory dump".
What's the start setting of your driver? If it starts too early in the boot order, the filesystem might not be remounted read-write yet, and therefore there's no place for a dump to go.
Drivers under development shouldn't generally be set to auto-start until you've gotten the driver stable when loaded later. Of course you eventually need to set it to auto-start so you can verify it works correctly, but that comes later.
On Linux, FreeBSD and other systems I have valgrind for checking for memory errors like invalid reads and similar. I really love valgrind. Now I have to test code on Solaris/OpenSolaris and can't find a way to get information on invalid reads/writes in an as nice way (or better ;-)) as valgrind there.
When searching for this on the net I find references to libumem, but I get only reports about memory leaks there, not invalid access. What am I missing?
The dbx included with the Sun Studio compilers includes memory access checking support in its "Run Time Checking" feature (the check subcommand). See:
Solaris Studio 12.4 dbx manual: Chapter 9: Using Runtime Checking
Debugging Applications with Sun Studio dbx, dbxtool, and the Thread Analyzer
Leonard Li's Weblog: Runtime Memory Checking
The related "Sun Memory Error Discovery Tool" is also available from
http://cooltools.sunsource.net/discover/
Since version 3.11.0, Valgrind does run on Solaris.
See Release Notes and Supported Platforms.
More precisely, x86/Solaris and amd64/Solaris is now supported.
Support for sparc/Solaris is still in works.
watchmalloc is a quite useful library that can be dynamically loaded for your program (usually no need for recompiling) and then sets watchpoints at all the usually problematic memory locations, like freed areas or after an allocated memory block.
If your program accesses one of these invalid areas it gets a signal and you can inspect it in the debugger.
Depending on the configuration problematic areas can be watched for writes only, or also for reads.