In UNIX environment(linux/solaris/AIX) my application crashing. Please help to me get environment variable from the core dump
Running strings -a core should produce an obvious-looking block of strings like HOME=..., HOSTNAME=..., etc.
You can also examine initial environment by looking at the 3rd argument to main, which is a envp[] -- a NULL-terminated array of pointers to the environment strings.
Finally, current environment block is pointed at by __environ or similar variable.
Related
This question already has answers here:
where command line arguments are stored?
(4 answers)
Closed 6 years ago.
I know that the command line arguments are character arrays and that they are stored on the stack. But, I want to know actual memory allocation for of each argument. e.g. suppose I passed the directory name "/tmp" as a command line argument. This will be stored in argv[1]. But as I tested, it is allowed to change argv[1] to "/tmp/log/" (size increased) in the program. How is this possible ?
To answer your question, the total maximum size available to argument strings and the passed environment can be obtained with:
getconf ARG_MAX
from the command line or the syconf equivalent from C (see http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html for more information).
(On my Linux box, the limit is 2097152).
Your example happens to work because the arguments and the environment are realistically stored contiguously, so appending to a string will overwrite what comes after it (following arguments, or the environment).
And that's why it's a bad idea to try and expand the argv strings like that. If you want to modify them, either edit them or shrink them, but trying to expand them is a call for trouble.
On Linux, parameters are populated by create_elf_tables. For this specific platform at least, you are correct that the values are stored on the stack.
Linux only uses exactly as much memory as is necessary to store arguments and (initial) environment variables on the stack; if you try to use more than what is already there, you're overwriting something else (or crashing).
The standard states that the argv can be modified since it is a special internal.
177 — The parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program, and retain their last-stored values between program startup and program termination, so it is allocated only what you need at the assignment or replacement.
Standard text:
http://c0x.coding-guidelines.com/5.1.2.2.1.html
I am trying to debug using gdb. I got that if you want output in string you have to use "x/s Ptr". It works fine some time. But many times I am getting either Null value i.e. " " or some random numeric values. My file has 10000 lines of codes. :-p Please find some gdb output. For e.g.
krb5_get_credentials_for_user (context=0x59c00eb0, options=4, ccache=0x5a001d40, in_creds=0x5ab022a8, subject_cert=0x0,
out_creds=0x5ab02378) at test_abc.c:696
(gdb) x/s 0x59c00eb0
0x59c00eb0: "$\247\016\227"
(gdb) x/s 0x5ab022a8
0x5ab022a8: ""
Could someone please tell me how I can solve this prob? Thanks in advance!
But many times I am getting either Null value i.e. " " or some random numeric values.
There is nothing wrong with what you show. It's just that the memory location you are examining isn't pointing to a string (0x59c00eb0) or is pointing to an empty string (0x5ab022a8).
You didn't present any evidence that these locations should be pointing to a string, and in fact, as (now deleted) comment showed context points to struct _krb5_context, which contains magic number as the first member. Therefore, you should use x/w to examine it.
... fine some times. But many times I am getting either Null value i.e. " "
or some random numeric...
Been there, done that. Allow me to encourage you to be creative.
I sometimes create a function (call it foo? bar? show? dump?), that is not used by the program being debugged. The function is often c-style (because gdb seems to understand that better, and simpler to invoke), global scope, simple. The temporary install of this function close (in the same file?) to what you want to improve the visibility of sometimes helps.
I can then invoke this function using the gdb p command, such as
gdb> p foo
it is possible to pass parameters to foo, but if I'm touching the code to debug something, I usually make foo more capable ... when no parameters it does one thing. Or perhaps use an int parameter (bar(7)) that switches to show more or differently.
Experiment.
This is not typical, and I suspect better knowledge of gdb might be worth the effort, if I could remember it to the next time I need it. Sometimes gdb just doesn't understand, and I can't figure out why. Other times, I get away with adding a pointer and trying to print that:
gdb> p *foobar
I am doing some debugging of an application that uses boost::spirit. This means that backtraces are very deep and that many of the intermediate layers have function names that take several pages to print. The length of the function names makes examining the backtrace difficult. How can I have gdb limit the length of a function name to 1 or 2 lines? I'd still like the see the full path to the file and line number, but I don't need four pages of template parameters!
I don't think it can be done directly right now. I think it would be a reasonable feature.
However, you can write your own implementation of "bt" in Python and then apply whatever transforms you like. This isn't actually very hard.
I have a dll (ansi c) that has some string litarals defined.
__declspec(dllexport) char* GetSomeString()
{
return "This is a test string from TestLib.dll";
}
When compiled this string is still visible in "notepad" for example. I'm fairly new to C, so I was wondering, is there a way to safely store string literals?
Should I do it with a resx file (for example), that has some encrypted values, or what would be the best way?
Thanks
EDIT 1:
The scenario is basically the following in pseudo code:
if(hostname)
return hostname
else
return "Literal String"';
It's this "literal string" that I would like to see "secured" in some way..
Don't put your secrets on anyone else's computer if you want them to stay secret.
See my related answer, The #1 Law of Software Licensing
And Eric Lippert's similar answer
First of all, since your executable1 needs to decode that literal in memory, any attacker determined enough will be able to do the same; often it's just as easy as freezing the process after startup (or after it needed to use the string we want), creating a memory dump and use utilities like string over it. There are methods to mitigate the issue (e.g. zeroing the memory used by a sensitive string immediately after using it), but since your code is on a machine where the potential attacker has all the privileges, you can only put roadblocks: in the end your executable is completely in the attacker's hands.
That being said, if your concern is just "not leaving important strings en plein air" you may just run an executable packer/encrypter over your whole dll. This is as easy as adding a post-build step in your solution, the packer will compress/encrypt the whole executable image and build an executable that when launched will decrypt and run it in memory.
This method has the great advantage of not requiring any change to your code: you just run upx over the compiled dll and you get your compressed dll, no XORs or weird literals spread across your code are needed.
Of course, this is quite weak security (basically it will just protect from snooping around in the executable with notepad or a hex editor), but again, storing critical "secrets" in an executable that is going to be distributed is a bad idea in first place.
In the whole answer I "executable" is to be intended in the wide meaning - i.e. also dlls are included.
You probably want to store hardcoded passwords in the library, right? You can XOR the string with some value, and store it, then read it and XOR again. It's the simplest way, but it doesn't protect your string from any kind of disassembling/reverse engineering.
Similar question to Linux equivalent of GetCommandLine and CommandLineToArgv
Is it possible to get the raw command line in linux? The file /proc/self/cmdline is destroyd.
./a.out files="file 1","file 2" param="2"
prints
./a.outfiles=file 1,file 2param=2
which is junk
Escaping command line does work for all arguments but the first.
./a.out files=\"fil 1\",\"fil 2\"\ param=\"2\"
prints
./a.outfiles="fil1","fil2" param="2"
You can't do that. The command line arguments are actually passed to the new process as individual strings. See the linux kernel source:
kernel_execve
Note that kernel_execve(...) takes a const char *argv[] - so there is no such thing as a long string commandline in Linux - it's the layer above that needs to split the arguments into separate components.
Edit: actually, the system call is here:
excve system call
But the statement above still applies. The parameter for argv is already split by the time the kernel gets it from the C-library call to exec.
It is the responsibility of the "starter of the program" (typically a shell, but doesn't have to be) to produce the argv[] array. It will do the "globbing" (expansion of wildcard filenames to the actual files that it matches) and stripping of quotations, variable replacement and so on.
I would also point out that although there are several variants of "exec" in the C library, there is only one way into the kernel. All variants end up in the execve system call that I linked to above. The other variants are simply because the caller may not fancy splitting arguments into invdividual elements, so the C library "helps out" by doing that for the programmer. Similarly for passing an environment array to the new program - if the programmer don't need specific environment, he/she can just call the variant that automatically take the parent process env.