How do I run gdb with environment variables set such as in the example below?
gdb (env -i SHELLCODE="`cat ~/shellcode.bin`" ./vulnerable)
In general, you can use the set environment command before starting the program you want to debug:
set environment MYVAR abc
However, from your question it looks like you want to get the content of the environment variable from a file, and there's no way to do that from the GDB shell. You can however just start GDB with the variable already set, and it will be kept when starting the program to debug. You can verify this with the show environment command.
$ MYVAR="$(cat x.txt)" gdb ./vulnerable
or:
$ export MYVAR="$(cat x.txt)"
$ gdb ./vulnerable
or even using env:
$ env -i MYVAR="$(cat x.txt)" gdb ./vulnerable
Then:
(gdb) show environment MYVAR
MYVAR=...
(gdb) run
You might want to check that your shellcode does not contain \x00 bytes though, as that can cause some problems (not 100% sure since I didn't test it).
Related
XCode has functionality to set breakpoint, then run lldb command and “Automatically continue after evaluating”.
How to setup same functionality via --source ? Found --command quote in the manual, but no examples and no reference in sub-command help
By default, the breakpoint command add command takes lldb command line commands. You can also specify this explicitly by passing the "--command" option.
Syntax: command <sub-command> [<sub-command-options>] <breakpoint-id>
I'm not entirely clear what you are asking.
But if you want to put commands in a text file somewhere which will add set a breakpoint and add commands to it you want something like:
> cat /tmp/cmds.lldb
break set -F main
break command add
frame var
continue
DONE
> lldb -s /tmp/cmds.lldb myBinary
Or if you want to do this in Xcode, just use:
(lldb) command source /tmp/cmds.lldb
once you are in the Xcode debugging session.
This relies on one trick, the "breakpoint command add" command operates on the last breakpoint set, which was why I didn't have to specify the breakpoint number.
I think you are asking about auto-continue with lldb?
I used the modify command to add auto-continue..
(lldb) b CCCryptorCreate
Breakpoint 1: where = libcommonCrypto.dylib`CCCryptorCreate, address = 0x000000011047e1b7
(lldb) breakpoint modify --auto-continue true 1
(lldb) br list
Current breakpoints:
1: name = 'CCCryptorCreate', locations = 1, resolved = 1, hit count = 0 Options: enabled auto-continue
1.1: where = libcommonCrypto.dylib`CCCryptorCreate, address = 0x000000011047e1b7, resolved, hit count = 0
then to add some commands I used..
(lldb) breakpoint command add -s python 1
Enter your Python command(s). Type 'DONE' to end.
print "Hit this breakpoint!"
DONE
The help has some good examples (lldb) help breakpoint command add
help breakpoint command add reveals it is called --one-liner, --command must be a typo?
-o <one-line-command> ( --one-liner <one-line-command> )
Specify a one-line breakpoint command inline.
Question is actual, how to automatically continue when --source is used
I used to have a server running CentOS, and I used to execute shell files this way:
sudo sh /folder/script.sh
Now I have an Ubuntu server. When I'm executing the same command line, I now have the following error message:
/folder/script.sh: ID[0]=ID: not found
I had a look on the internet and it says I need to use:
sudo /bin/bash /folder/script.sh
But when I do so I got the same error message.
The first line of my script is:
ID[0]="ID"
/bin/sh is often a POSIX shell, which does not support arrays.
I suggest you install another shell which does support them, like mksh (disclaimer: I’m its developer), ksh93, zsh, or just use GNU bash instead, and call your script with, for example, sudo mksh /folder/script.sh instead. This will give you more consistent behaviour across systems, too (note that to behave consistent on all platforms is actually an mksh design goal).
Hm… this works for me:
$ cat >x
#!/bin/bash
ID[0]="ID"
echo works for me
$ mksh x
works for me
Do you have any weird characters in your script, like embedded Carriage Return (^M)? Check with: cat -v /folder/script.sh
I am working on remote computer. The shell is tcsh with no root privileges. I have no control on the server.
I have a script script.pl. When running it:
perl script.pl
gives the correct results
but when I'm trying to send this output to some program I got an error "Illegal variable name."
./vuln $(perl script.pl)
Illegal variable name.
When i'm working on gdb, the error of course repeats
(gdb) r $(perl script.pl)
Starting program: /vuln $(perl script.pl)
Illegal variable name.
How to send the output of the script to the program either on shell and gdb?
tcsh does not understand this substitution syntax $(...)
You need to use backticks for portable shell scripts:
./vuln `perl script.pl`
I'm using lldb inside Xcode, and one of my variables contains a huge chunk of JSON data. Using po myVar isn't much helpful to analyse this data, as it will output in the tiny Xcode debug console.
Is there a way to redirect lldb output to a file ?
I saw here that such a feature seems to be available on gdb as :
(gdb) set logging on
(gdb) set logging file /tmp/mem.txt
(gdb) x/512bx 0xbffff3c0
(gdb) set logging off
and is "translated" in lldb as :
(lldb) memory read --outfile /tmp/mem.txt --count 512 0xbffff3c0
(lldb) me r -o/tmp/mem.txt -c512 0xbffff3c0
(lldb) x/512bx -o/tmp/mem.txt 0xbffff3c0
However, the memory read command will not help in my case, and apparently, --outfile is not available for the print command.
You can use a Python script to do so (and much more), as explained here:
LLDB Python scripting in Xcode
Create a file named po.py in a directory of your choice (for example "~/.lldb"):
import lldb
def print_to_file(debugger, command, result, dict):
#Change the output file to a path/name of your choice
f=open("/Users/user/temp.txt","w")
debugger.SetOutputFileHandle(f,True);
#Change command to the command you want the output of
command = "po self"
debugger.HandleCommand(command)
def __lldb_init_module (debugger, dict):
debugger.HandleCommand('command script add -f po.print_to_file print_to_file ')
Then in lldb write:
command script import ~/.lldb/po.py
print_to_file
I found session save <filename> to be a much better, easier option than those listed here. It's not quite the same as you can't use it (to my knowledge selectively) but for generating logs, it's quite handy.
Here is a slight modification incorporating some of the comments from above:
def toFile(debugger, command, result, dict):
f=open("/Users/user/temp.txt","w")
debugger.SetOutputFileHandle(f,True);
debugger.HandleCommand(command)
f.close()
debugger.SetOutputFileHandle(sys.stdout, True)
This allows the command to be supplied as an argument, and reverts the output file handle to stdout after the command is run.
Assuming that you have a variable named jsonData (which has a Data type) you can save it to a file with this command:
expr jsonData.write(to: URL(fileURLWithPath: "/tmp/datadump.bin"))
Alternatively instead of above command you could dump memory used by this variable to a file as in the example below:
(lldb) po jsonData
▿ Optional<Data>
▿ some : 32547 bytes
- count : 32547
▿ pointer : 0x00007fe8b69bb410
- pointerValue : 140637472797712
(lldb) memory read --force --binary --outfile /tmp/datadump.bin --count 32547 0x00007fe8b69bb410
32547 bytes written to '/tmp/datadump.bin'
I have a program in c/gtk which is opened with gksu. The problem is that when I get the environment variable $HOME with getenv("HOME") it returns "root" obviously. I would like to know if there is a way to know who was the user that executed the gksu or the way to get his environmental variables.
Thanks in advance!
See the man page. Use gksu -k command... to preserve the environment (in particular, PATH and HOME).
Or, like Lewis Richard Phillip C indicated, you can use gksu env PATH="$PATH" HOME="$HOME" command... to reset the environment variables for the command. (The logic is that the parent shell, the one run with user privileges, substitutes the variables, and env re-sets them when superuser privileges have been attained.)
If your application should only be run with root privileges, you can write a launcher script -- just like many other applications do. The script itself is basically
#!/bin/sh
exec gksu -k /path/to/your/application "$#"
or
#!/bin/sh
exec gksu env PATH="$PATH" HOME="$HOME" /path/to/your/application "$#"
The script is installed in /usr/bin, and your application as /usr/bin/yourapp-bin or /usr/lib/yourapp/yourapp. The exec means that the command replaces the shell; i.e. nothing after the exec command will ever be executed (unless the application or command cannot be executed at all) -- and most importantly, there will not be an extra shell in memory while your application is begin executed.
While Linux and other POSIX-like systems do have a notion of effective identity (defining the operations an application may do) and real identity (defining the user that is doing the operation), gksu modifies all identities. In particular, while getuid() returns the real user ID for example for set-UID binaries, it will return zero ("root") when gksu is used.
Therefore, the above launch script is the recommended method to solve your problem. It is also a common one; run
file -L /usr/bin/* /usr/sbin/* | sed -ne '/shell/ s|:.*$||p' | xargs -r grep -lie launcher -e '^exec /'
to see which commands are (or declare themselves to be) launcher scripts on your system, or
file -L /bin/* /sbin/* /usr/bin/* /usr/sbin/* | sed -ne '/shell/ s|:.*$||p' | xargs -r grep -lie gksu
to see which ones use gksu explicitly. There is no harm in adopting a known good approach.. ;)
you could assign the values of these environment vars to standard variables, then execute gksu exporting the vars after gkSU... By defining these after the gkSU using && to bind together your executions, so that you essentially execute using cloned environment variables...
A better question is why do this at all? I realize you are wanting to keep some folders, but am not sure why as any files created as root, would have to be globally writable, probably using umask, or you would have to manually revise permissions or change ownership... This is such a bad Idea!
Please check out https://superuser.com/questions/232231/how-do-i-make-sudo-preserve-my-environment-variables , http://www.cyberciti.biz/faq/linux-unix-shell-export-command/ & https://serverfault.com/questions/62178/how-to-specify-roots-environment-variable