将 Shellcode 输出定向到文件 - C
Directing Shellcode Output to a File - C
我正在使用这里的代码:Read and Execute Shellcode from a .txt File
#include <stdio.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <stdlib.h>
int main(void)
{
FILE *file = fopen("text.txt", "r");
unsigned char *buf;
int length = 0;
struct stat st;
int v;
// get file size and allocate. We're going to convert to bytes
// from text, so this allocation will be safely large enough
fstat(fileno(file), &st);
buf = valloc(st.st_size);
while (fscanf(file, "\x%02x", &v) == 1)
{
buf[length++] = v;
}
fclose(file);
mprotect(buf, length, PROT_EXEC);
int (*ret)() = (int (*)())buf;
ret();
return 0;
}
我正在编译:gcc -fno-stack-protector -z execstack testshell.c -o testshell
它运行得很好,但它执行的 shellcode 会写入终端,但我想以某种方式将其重定向到一个文件。
我试过了:
./testshell > output.txt
但似乎也无法捕获 shellcode 的结果。
我如何捕获它运行的任何 shellcode 的输出,并在可能的情况下将其重定向到文件?
更新: 我正在使用的 shellcode,它通过 sys_write 系统调用输出到文件描述符(它进行计算并打印到屏幕) -
\xeb\x4d\x5e\x66\x83\xec\x0c\x48\x89\xe0\x48\x31\xc9\x68\x33\x09\x00\x7c\x48\x89\xcf\x80\xc1\x0c\x40\x8a\x3e\x40\xf6\xd7\x40\x88\x38\x48\xff\xc6\x68\x16\x96\xd0\xd9\x48\xff\xc0\xe2\xea\x2c\x0c\x48\x89\xc6\x68\xf2\xf5\x44\x48\x48\x31\xc0\x48\x89\xc7\x04\x01\x48\x89\xc2\x80\xc2\x0b\x0f\x05\x48\x31\xc0\x04\x3c\x0f\x05\xe8\xae\xff\xff\xff\x85\xa7\xaa\xc7\x9e\x87\xa5\xa5\x8e\xb7\x87\xba\x31\x80\xe0\x55\xef\xa1\x93\x0c\x4e\x1c\xdc\x34\x53\xb3\x8b\x43\x48\x68\x30\x1d\x4b\x65\x5b\x52\x41\x4e\x44\x53\x54\x52\x32\x5d
将评论转化为答案,在信用到期时给予信用。
Deanie 说:
This should work if the shellcode is writing to stdout and not stderr. Try:
./testshell > output.txt 1>&2
OP 对此 user2059300 回复:
No dice on the 1>&2
, the output still occurs in the terminal and not in output.txt
I think he meant ./testshell > output.txt 2>&1
to redirect both stdout & stderr to output.txt.
但是user2059300表示:
Still a no-go on that, … I provided the shellcode I'm testing.
然后我问:
- shell代码是怎么写的?它在做什么?我不会为你剖析它; shell 代码往往是非常特定于平台的,您还没有确定您使用的是哪个系统。当然,很容易猜到您在 Intel 机器上使用 Linux,但它可能是 32 位或 64 位 Linux,以及 shell 代码的作用仍然需要了解如何重定向其输出。例如,如果它打开终端并写入,你将很难避免输出出现在终端上。
并且user2059300表示:
It's a sys_write
syscall output to a file descriptor.
提示我提问:
- 哪个文件描述符? 0、1、2 还是其他?
David C. Rankin 备注:
That's still up in the air. Dumping to assembly shows a call to fprintf
, but redirecting both stderr
and stdout
does nothing. It's almost like a kernel printf is being used.
我反驳说:
- 这就是为什么我将 0 列为候选文件描述符的原因。 文件描述符 0 通常是文件描述符 1 和 2 的副本,因此您既可以写入 0(标准输入),也可以从 1 和 2(标准输出和标准错误)读取。 的当然,这样做是完全不受支持且不可移植的(并且您不能通过文件流
stdin
、stdout
、stderr
),但是 shell 代码一般是不可携带的。
这似乎是关键。 David C. Rankin 确认:
Hah! You nailed it. ./testshell > output.txt 0>&1
worked just fine. Learning has occurred… Thanks. That is the first, and hopefully the last time, I'll run across that. I'm too old to be learning those tricks.
user2059300也是如此:
Thank you guys so much. Learning has indeed occurred. ./testshell > output.txt 0>&1
显然,我不知道这会是解决方案,但是当标准输出和标准错误的 I/O 重定向失败时,它成为了可能。这种行为有很长的历史(第 7 版 Unix,也可能在此之前),尽管很少有明确记录。
我正在使用这里的代码:Read and Execute Shellcode from a .txt File
#include <stdio.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <stdlib.h>
int main(void)
{
FILE *file = fopen("text.txt", "r");
unsigned char *buf;
int length = 0;
struct stat st;
int v;
// get file size and allocate. We're going to convert to bytes
// from text, so this allocation will be safely large enough
fstat(fileno(file), &st);
buf = valloc(st.st_size);
while (fscanf(file, "\x%02x", &v) == 1)
{
buf[length++] = v;
}
fclose(file);
mprotect(buf, length, PROT_EXEC);
int (*ret)() = (int (*)())buf;
ret();
return 0;
}
我正在编译:gcc -fno-stack-protector -z execstack testshell.c -o testshell
它运行得很好,但它执行的 shellcode 会写入终端,但我想以某种方式将其重定向到一个文件。
我试过了:
./testshell > output.txt
但似乎也无法捕获 shellcode 的结果。
我如何捕获它运行的任何 shellcode 的输出,并在可能的情况下将其重定向到文件?
更新: 我正在使用的 shellcode,它通过 sys_write 系统调用输出到文件描述符(它进行计算并打印到屏幕) -
\xeb\x4d\x5e\x66\x83\xec\x0c\x48\x89\xe0\x48\x31\xc9\x68\x33\x09\x00\x7c\x48\x89\xcf\x80\xc1\x0c\x40\x8a\x3e\x40\xf6\xd7\x40\x88\x38\x48\xff\xc6\x68\x16\x96\xd0\xd9\x48\xff\xc0\xe2\xea\x2c\x0c\x48\x89\xc6\x68\xf2\xf5\x44\x48\x48\x31\xc0\x48\x89\xc7\x04\x01\x48\x89\xc2\x80\xc2\x0b\x0f\x05\x48\x31\xc0\x04\x3c\x0f\x05\xe8\xae\xff\xff\xff\x85\xa7\xaa\xc7\x9e\x87\xa5\xa5\x8e\xb7\x87\xba\x31\x80\xe0\x55\xef\xa1\x93\x0c\x4e\x1c\xdc\x34\x53\xb3\x8b\x43\x48\x68\x30\x1d\x4b\x65\x5b\x52\x41\x4e\x44\x53\x54\x52\x32\x5d
将评论转化为答案,在信用到期时给予信用。
Deanie 说:
This should work if the shellcode is writing to stdout and not stderr. Try:
./testshell > output.txt 1>&2
OP 对此 user2059300 回复:
No dice on the
1>&2
, the output still occurs in the terminal and not in output.txt
I think he meant
./testshell > output.txt 2>&1
to redirect both stdout & stderr to output.txt.
但是user2059300表示:
Still a no-go on that, … I provided the shellcode I'm testing.
然后我问:
- shell代码是怎么写的?它在做什么?我不会为你剖析它; shell 代码往往是非常特定于平台的,您还没有确定您使用的是哪个系统。当然,很容易猜到您在 Intel 机器上使用 Linux,但它可能是 32 位或 64 位 Linux,以及 shell 代码的作用仍然需要了解如何重定向其输出。例如,如果它打开终端并写入,你将很难避免输出出现在终端上。
并且user2059300表示:
It's a
sys_write
syscall output to a file descriptor.
提示我提问:
- 哪个文件描述符? 0、1、2 还是其他?
David C. Rankin 备注:
That's still up in the air. Dumping to assembly shows a call to
fprintf
, but redirecting bothstderr
andstdout
does nothing. It's almost like a kernel printf is being used.
我反驳说:
- 这就是为什么我将 0 列为候选文件描述符的原因。 文件描述符 0 通常是文件描述符 1 和 2 的副本,因此您既可以写入 0(标准输入),也可以从 1 和 2(标准输出和标准错误)读取。 的当然,这样做是完全不受支持且不可移植的(并且您不能通过文件流
stdin
、stdout
、stderr
),但是 shell 代码一般是不可携带的。
这似乎是关键。 David C. Rankin 确认:
Hah! You nailed it.
./testshell > output.txt 0>&1
worked just fine. Learning has occurred… Thanks. That is the first, and hopefully the last time, I'll run across that. I'm too old to be learning those tricks.
user2059300也是如此:
Thank you guys so much. Learning has indeed occurred.
./testshell > output.txt 0>&1
显然,我不知道这会是解决方案,但是当标准输出和标准错误的 I/O 重定向失败时,它成为了可能。这种行为有很长的历史(第 7 版 Unix,也可能在此之前),尽管很少有明确记录。