I have a memory dump (unmanaged process) .
How can I extract (using windbg) one of the dlls loaded into the process ? I mean actually saving the dll file into the disk
You can use the sos.dll inside windbg directory.
First, load the sos.dll in windbg:
.load clr10\sos.dll
Then use !sam OR !SaveAllModule to extract the modules on specific disk location:
!sam c:\notepad
To extract a DLL without using SOS, use the .writemem extension as follows:
discover the module start and end addresses using lmvm dllname
example output for ieframe:
start end module name
61370000 61fb8000 ieframe
calculate the length = end-start: ? 61fb8000 - 61370000
output: Evaluate expression: 12877823 = 00c48000
then save the DLL as follows:
.writemem C:\tmp\mydll.dll 61370000 L?00c48000
This is unlikely to give you the exact DLL as it was loaded from disk, fixing this up is non-trivial.
(Partly based on this article)
Yes, it's true. calc.exe will also pull up its multi user language interface information and attach it in memory, as will a lot of Windows programs like mspaint, photoviewer, etc.
Related
I'm using preaty old Matlab (version 7.1.0.246 (R14) Service Pack 3) :(
I have some toolbox I was provided which I'd like to use. When I try to execute the function, I'm getting Undefined command/function 'test' (my function is test and stored in test.m and the file located in my current working directory).
If I place the file in C:\Temp\ and execute which test, I'm getting the complete file path (C:\Temp\test.m).
If I place the file in C:\Temp\MyMap\ and execute which test, I'm getting the complete file path('C:\Temp\MyMap\test.m') and additional comment %Has no license available.
If I use following one
if exist('test')
test(...)
end
It solves the issue. However, as mentioned previously, its a toolbox and contains many functions. I don't have time (and want to) apply the workaround on all the files/functions.
Any suggestion how this could be solved?
I need to strictly bind every core file generated by system to certain bin version of crashed application. I can specify core-name pattern in sysctl.conf:kernel.core_pattern, but there is no way to put bin version here.
How can I put the version of crashed program into core file (revision number) or any other way to determine version of crashed bin?
I'm using qmake VERSION variable in .pro file, which contains revision number from SVN. Its available by QCoreApplication::applicationVersion(), in my every bin by flag --version.
Assuming your app can get far enough to print out its version number without a core dump, you can write a small program (python would probably be easiest) that is invoked by a core dump. The program would read stdin, dump it to a file, then rename the file based on the version number.
From man 5 core:
Piping core dumps to a program
Since kernel 2.6.19, Linux supports an alternate syntax for the
/proc/sys/kernel/core_pattern file. If the first character of this
file is a pipe symbol (|), then the remainder of the line is inter‐
preted as a program to be executed. Instead of being written to a disk
file, the core dump is given as standard input to the program. Note
the following points:
* The program must be specified using an absolute pathname (or a path‐
name relative to the root directory, /), and must immediately follow
the '|' character.
* The process created to run the program runs as user and group root.
* Command-line arguments can be supplied to the program (since Linux
2.6.24), delimited by white space (up to a total line length of 128
bytes).
* The command-line arguments can include any of the % specifiers
listed above. For example, to pass the PID of the process that is
being dumped, specify %p in an argument.
If you call your script /usr/local/bin/dumper, then
echo "| /usr/local/bin/dumper %E" > /proc/sys/kernel/core_pattern
The dumper should copy stdin to a file, then try to run the program named on its command line to extract a version number and use that to rename the file.
Something like this might work (I haven't tried it, so use at extreme risk:)
#!/usr/bin/python
import sys,os,subprocess
from subprocess import check_output
CORE_FNAME="/tmp/core"
with open(CORE_FNAME,"f") as f:
while buf=sys.stdin.read(10000):
f.write(buf)
pname=sys.argv[1].replace('!','/')
out=subprocess.check_output([pname, "--version"])
version=out.split('\n')[0].split()[-1]
os.rename(CORE_FNAME, CORE_FNAME+version)
The really big risk of doing this is recursive core dumps that may crash your system. Be sure to use ulimit to only allow core dumps from processes that can print out their own versions without core dumping.
It would be a good idea to change the script to re-run the program to get the version info only if it is the program you are expecting.
Problem outline:
need allow upload ZIP files (and tgz and more compressed directory trees) via web-from
the zip files should be extracted for their content handling
planning to use Archive::Extract for the extracting
here are things like ZIP BOMBS and like...
From the manual
Archive::Extract can use either pure perl modules or command line
programs under the hood. Some of the pure perl modules (like
Archive::Tar and Compress::unLZMA) take the entire contents of the
archive into memory, which may not be feasible on your system.
Consider setting the global variable $Archive::Extract::PREFER_BIN to
1 , which will prefer the use of command line programs and won't
consume so much memory.
The questions are:
When I set the $Archive::Extract::PREFER_BIN = 1 - i'm enough protected againist ZIP-BOMB like things?
$Archive::Extract::PREFER_BIN protect me againist much memory usage - but, the standard unzip, tar -z unrar binaries are safe againist zip bomb like attacks?
If not - how to handle safely uploaded compressed directory tree? (so here is not only one file inside the e.g zip archive).
$Archive::Extract::PREFER_BIN = 1 doesn't protect you against zip bombs, you are passing the problem to the binary unzip tool of your system.
This SO question may helps you. I like the idea of running a second process with ulimit.
I'm debugging a module for which I have only the .exe and a .pdb without private symbols.
During the debug session I need to inspect an internal struct. Obviously this struct does not appear in the PDB since it's private - but fortunately I have an .h file where this struct is defined. Therefore I can build some dummy module that uses this struct and obtain a PDB file that contains this struct.
Now I have an unloaded module with the struct symbols, and I would like to load its symbols in order to cast some memory to that struct. (without unloading the original .exe I'm debugging, of course)
The problem: it seems that WinDbg only allows loading symbols for loaded modules...
My question is: Is there a simple way I could load my symbols from the unloaded module?
I've tried .reload /i /f MyDll.dll but I always get ...MyDll.dll - unmatched.
Setting the sympath did not help.
Any ideas?
A better way is .reload /unl MyDll.dll
Unloaded module list contains timestamp (for image/pdb matching) and image base address. Using /unl tells WinDBG to use that information.
You can force windbg to load symbols at a specific address e.g.
0:000> .reload /f /i MyDll.dll=77777777
c:\sym\MyDll.pdb - unmatched
0:000> lm
start end module name
00000000`55555555 00000000`55555555 notepad (no symbols)
00000000`77530000 00000000`7762a000 USER32 (deferred)
00000000`77777777 00000000`77777777 MyDll_77777777 (private pdb symbols) c:\sym\MyDll.pdb
The unmatched warning here is because windbg cannot tell that the symbols match the correct version of the module since it can find no timestamp or checksum.
While creating a file, you provide the name of a file to operating system and
it creates file and returns you the handle.
I am curious to know how it is created.
Does the operating system do some kind of hashing on file name to create a unique file handle
or does it increase count of created files and return it as a file handle?
No, it's an index into an array inside the OS kernel, unique to that one process. File handles are usually just small integers.
File handles are only unique within one process at a given time. On Linux I think that it is a simple counter that is incremented. I think that Windows returns the memory address to an information block about the file (the information block's structure is internal to the operating system, so it's not possible to deal with it directly).
The file handle (file descriptor) is just a number which is unique for that particular process. For instance, standard input, output and error has fds (0, 1, 2). In linux you can check the process' file descriptor in /proc/PID/fd where PID is process id.
Here is an example:
$ pidof executable
4711
$ ls -l /proc/4711/fd
...
$ # Use 'lsof' to show file descriptor opened by this process:
$ lsof -p 4711
...