According to this article the executable part is in .text, According to this article the executable part is in .text and .rodata, is it possible to grab the bytes in .text and convert them to a shellcode then injecting it into a process
pe = pefile.PE(sys.argv[1])
def grab_executable_code():
ops = ""
for section in pe.sections:
print (section.Name.decode('utf-8'), hex(section.VirtualAddress),
hex(section.Misc_VirtualSize),section.SizeOfRawData)
if section.Name == b'.text\x00\x00\x00':
for i,item in enumerate(bytearray(section.get_data())):
if len(hex(item)) < 4:
ops += f"\\x0{hex(item)[2:]}"
else:
ops += f"\\{hex(item)[1:]}"
return ops
something like this, but when I try to inject the resulting shellcode I do not get any results but in windbg preview I don't see any errors
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
ModLoad: 00000000`00400000 00000000`00414000 image00000000`00400000
ModLoad: 00007ffa`0a230000 00007ffa`0a425000 ntdll.dll
ModLoad: 00007ffa`094d0000 00007ffa`0958e000 C:\Windows\System32\KERNEL32.DLL
ModLoad: 00007ffa`07d50000 00007ffa`08019000 C:\Windows\System32\KERNELBASE.dll
ModLoad: 00007ffa`09720000 00007ffa`097be000 C:\Windows\System32\msvcrt.dll
ModLoad: 00000000`6fc40000 00000000`6fda4000 C:\Program Files\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0\mingw64\bin\libstdc++-6.dll
ModLoad: 00007ffa`08a50000 00007ffa`08bf1000 C:\Windows\System32\USER32.dll
ModLoad: 00007ffa`07a10000 00007ffa`07a32000 C:\Windows\System32\win32u.dll
ModLoad: 00007ffa`095a0000 00007ffa`095cb000 C:\Windows\System32\GDI32.dll
ModLoad: 00007ffa`07af0000 00007ffa`07bfb000 C:\Windows\System32\gdi32full.dll
ModLoad: 00007ffa`081e0000 00007ffa`0827d000 C:\Windows\System32\msvcp_win.dll
ModLoad: 00007ffa`07c50000 00007ffa`07d50000 C:\Windows\System32\ucrtbase.dll
ModLoad: 00000000`61440000 00000000`6145b000 C:\Program Files\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0\mingw64\bin\libgcc_s_seh-1.dll
(17f0.a4c): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffa`0a3006b0 cc int 3
0:000> g
ModLoad: 00007ffa`08a20000 00007ffa`08a50000 C:\Windows\System32\IMM32.DLL
ntdll!RtlUserThreadStart:
00007ffa`0a282630 4883ec78 sub rsp,78h
The exe I am using is a compiled "hello world" program written in c++ and compiled with g++
The injection method is obtained from ired.team (Virtualalloc) and I tested it with a shellcode generated from msfvenom and works fine but not with the shellcode from the python script
My best guess is that the entry point for the executable code is not specified therefore the shellcode does not run but I could be wrong
Related
I'm new to assembly languages. I installed NASM and GoLink on Windows 10 and put their folder paths into Environment Variables in the advanced PC properties tab. I have a simple asm file with this program:
global _start
_start:
mov eax, 1
mov ebx, 42
int 0x80
I run Command Prompt from the file folder and input following command:
nasm -f win32 test.asm -o test.obj
It successfully creates obj file in the same folder. Then I input this command:
golink /entry:_start /console kernel32.dll user32.dll test.obj
And I get the following error:
Error!
The following symbol was not defined in the object file or files:-
_start
You may be trying to link object files or lib code with decorated symbols -
If so, you could try using the /mix switch
Output file not made
I read that /entry appends a "_" to the name of the entry point but even with no underscore I get the same error.
How can I fix this?
As commentators mentioned, section .text is required when compiling in Windows 10. Also, I used int 0x80 which is system call used on Linux systems so the program wouldn't work anyway.
My plan to debug eBPF code using the latest gdb support. however the simulator crash after I run . so i tried regular "hello world" c code compiled with -g option (gcc -g hello_wold.c) got the same issue.
gdb version : GNU gdb (GDB) 12.0.50.20211105-git
Reading symbols from /root/hello_program/a.out...
(gdb) target sim
Connected to the simulator.
(gdb) sim memory-size 4Mb
(gdb) load
Loading section .interp, size 0x1c lma 238
Loading section .note.ABI-tag, size 0x20 lma 254
Loading section .note.gnu.build-id, size 0x24 lma 274
Loading section .gnu.hash, size 0x1c lma 298
Loading section .dynsym, size 0xc0 lma 2b8
Loading section .dynstr, size 0x96 lma 378
Loading section .gnu.version, size 0x10 lma 40e
Loading section .gnu.version_r, size 0x20 lma 420
Loading section .rela.dyn, size 0xd8 lma 440
Loading section .rela.plt, size 0x18 lma 518
Loading section .init, size 0x17 lma 530
Loading section .plt, size 0x20 lma 550
Loading section .plt.got, size 0x8 lma 570
Loading section .text, size 0x1c2 lma 580
Loading section .fini, size 0x9 lma 744
Loading section .rodata, size 0x10 lma 750
Loading section .eh_frame_hdr, size 0x3c lma 760
Loading section .eh_frame, size 0x10c lma 7a0
Loading section .init_array, size 0x8 lma 200dd8
Loading section .fini_array, size 0x8 lma 200de0
Loading section .jcr, size 0x8 lma 200de8
Loading section .dynamic, size 0x1e0 lma 200df0
Loading section .got, size 0x30 lma 200fd0
Loading section .got.plt, size 0x20 lma 201000
Loading section .data, size 0x10 lma 201020
Start address 580
Transfer rate: 17760 bits in <1 sec.
(gdb) run
Starting program: /root/hello_program/a.out
Fatal signal: Aborted
----- Backtrace -----
0x55ffda5588a7 gdb_internal_backtrace_1
/root/binutils-gdb/gdb/bt-utils.c:121
0x55ffda5588a7 _Z22gdb_internal_backtracev
/root/binutils-gdb/gdb/bt-utils.c:164
0x55ffda6506cd handle_fatal_signal
/root/binutils-gdb/gdb/event-top.c:896
0x7f89e035905f ???
/build/glibc-77giwP/glibc-2.24/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f89e0358fff __GI_raise
../sysdeps/unix/sysv/linux/raise.c:51
0x7f89e035a429 __GI_abort
/build/glibc-77giwP/glibc-2.24/stdlib/abort.c:89
0x55ffda8e2728 sim_engine_invalid_insn
/root/binutils-gdb/sim/bpf/traps.c:37
0x55ffda8da83d execute
/root/binutils-gdb/sim/bpf/mloop-le.c:119
for bpf code i compiled with ( clang -target bpf -g -O2 -c hello_world.c)
hello world bpf code
#include <linux/bpf.h>
#include "bpf_helpers.h"
#include <stdlib.h>
#include <stdio.h>
int bpf_prog(void *ctx) {
char buf[] = "Hello World!\n";
bpf_trace_printk(buf, sizeof(buf));
bpf_trace_printk(buf, sizeof(buf));
bpf_trace_printk(buf, sizeof(buf));
bpf_trace_printk(buf, sizeof(buf));
return 0;
}
Error
Type "apropos word" to search for commands related to "word"...
Reading symbols from /root/ebpf_test/hello_world.o...
(No debugging symbols found in /root/ebpf_test/hello_world.o)
(gdb) target sim
Connected to the simulator.
(gdb) sim memory-size 4Mb
(gdb) load
Loading section .text, size 0x28 lma 0
Loading section .rodata.str1.1, size 0xd lma 0
Start address 0
Transfer rate: 424 bits in <1 sec.
(gdb) run
Starting program: /root/ebpf_test/hello_world.o
Fatal signal: Aborted
----- Backtrace -----
0x562154f4a63b gdb_internal_backtrace_1
/root/binutils-gdb/gdb/bt-utils.c:121
0x562154f4a63b _Z22gdb_internal_backtracev
/root/binutils-gdb/gdb/bt-utils.c:164
0x56215504d2ba handle_fatal_signal
/root/binutils-gdb/gdb/event-top.c:896
0x7f6f1a85503f ???
0x7f6f1a854fb7 ???
0x7f6f1a856920 ???
0x5621552fb9f8 sim_engine_invalid_insn
/root/binutils-gdb/sim/bpf/traps.c:37
0x5621552f3aaa execute
/root/binutils-gdb/sim/bpf/mloop-le.c:119
0x5621552f3aaa bpfbf_ebpfle_engine_run_full
/root/binutils-gdb/sim/bpf/mloop-le.c:222
0x5621552ddee4 engine_run_1
same happen when i try to debug an ebpf program. any help is appreciated to understand where to begin fixing the issue.
thanks
Looking at the number of sections that GDB loaded, I don't believe your object file was compiled as eBPF bytecode. Was gcc -g hello_world.c the command you used to produce it? This will compile instructions from your host architecture, likely x86_64.
Compiling to eBPF
To compile to eBPF instructions instead, most people use clang rather than gcc. There is a gcc backend for eBPF now, but I don't know what its status is, I'm just aware that its eBPF support is not quite as complete as clang/LLVM. With clang, you can run:
$ clang -target bpf -g -O2 -c hello_world.c
This will produce an object file containing eBPF instructions. Note that I'd usually add -Wall and -o hello_world.o to display potential warnings and to name the output file. The resulting object file should work in gdb, provided you have a recent version with support for eBPF (see here otherwise).
If you care about a specific eBPF instruction set (if you're getting started, you probably don't), you can specify it by compiling in two steps instead, and passing the relevant option via the -mcpu option for llc:
$ clang -g -O2 -Wall -emit-llvm -c hello_world.c -o - | \
llc -march=bpf -mcpu=probe -filetype=obj -o hello_world.o
See also this resource for details and compiling into and from assembly.
hi i have attached crash dump for an exe and symbols also.but i am getting this error:
Unable to verify checksum for abc.exe.
What would be the reason for this?
Unable to verify checksum is emitted when the checksum in the PE header isn't verifiable.
This can happen if the exe in question was compiled and linked without using /RELEASE linker option.
Normal project based compile linker sets this option. nmake or batch file based compilation can omit this switch and can lead to this output.
A simple hello world compiled and linked with and without /RELEASE linker option (PDB not generated for simpilicity and diffed to show the difference in timestamp and checksum). Loaded in WinDbg and checksum warning is generated only for the exe with no checksum in PE header.
simple hello world.cpp contents
testrelease:\>dir /b & type testrelease.cpp
testrelease.cpp
#include <stdio.h>
int main (void) {
printf("hello my relase\n");
return 0;
}
compiling without /RELEASE
testrelease:\>cl /nologo testrelease.cpp
testrelease.cpp
renaming the exe and compiling the same source with with /RELEASE
testrelease:\>ren testrelease.exe testrelease_norel.exe
testrelease:\>cl /nologo testrelease.cpp /link /release
testrelease.cpp
comparing both exes
testrelease:\>fc /b testrelease.exe testrelease_norel.exe
Comparing files testrelease.exe and TESTRELEASE_NOREL.EXE
000000E0: D6 CE
00000130: A3 00
00000131: 95 00
00000132: 01 00
analysing output of the comparison
testrelease:\>xxd -s +0x3c -l 1 testrelease.exe
000003c: d8 .
testrelease:\>xxd -s +0x3c -l 1 testrelease_norel.exe
000003c: d8 .
testrelease:\>echo d8 = NT_HEADER so e0 = TimeDateStamp and 130 = CheckSum
d8 = NT_HEADER so e0 = TimeDateStamp and 130 = CheckSum
loading both exes in windbg warning generated for only one exe without checksum
testrelease:\>cdb -c ".reload /f ; q" testrelease.exe
.*** ERROR: Module load completed but symbols could not be loaded for image00400
testrelease:\>cdb -c ".reload /f ; q" testrelease_norel.exe
.*** WARNING: Unable to verify checksum for image00400000
*** ERROR: Module load completed but symbols could not be loaded for image004000
no symbol header available error means the exe was compiled without debug information.
You can't do much about it unless you have a lot of expertise in recreating debug information from scratch.
Both the executables that are compiled above will generate the error because iIhave intentionally not created the debug information.
DBGHELP: image00400000 missing debug info. Searching for pdb anyway
DBGHELP: Can't use symbol server for image00400000.pdb - no header information available
I'm looking at the disassembly of some x86_64 code with Apple's otool. Here's a sample of the disassembly, as outputted by otool:
0000000100055de4 movq $0x00000000,%rax
Only the last 4 bytes in that offset, the 00055de4, represent the file address of that instruction. I can open a hex editor and navigate to 0x55de4 and the movq instruction is there.
However, I noticed that gdb only works when I include all 8 bytes in the address, including the mysterious 1. break *0x0000000100055de4 works as expected, while break *0x00055de4 never triggers.
Every 64-bit binary I have analyzed with otool shows this pattern. It obviously doesn't apply to 32-bit addresses.
So, if 0x55de4 is the actual address, why do otool and gdb use 0x0000000100055de4?
__PAGEZERO, the first load command in a 64 bit Mach-O binary, specifies a segment size of 0x100000000 in virtual memory.
$ otool -lV binary
command 0
cmd LC_SEGMENT_64
cmdsize 72
segname __PAGEZERO
vmaddr 0x0000000000000000
vmsize 0x0000000100000000
When you do break *0x00055de4 your breakpoint ends up in this segment of zeros, which explains why it's never hit. 0x0000000100055de4 is the address of the instruction (found at 0x55de4 in the binary) when loaded into virtual memory.
For 32 bit binaries the __PAGEZERO size is 0x1000, which explains why the pattern does not apply.
I'll admit to being completely new to Windbg so hopefully this is a noobish question that I couldn't find the answer for on the internet.
Anyways, here is my symbol path: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
I have a small command line program that I made, so I go to File -> Open Executable
I select the .exe and give it the two arguments from that screen. I then go to the Command window and press 'g' to run my program. I get the following output.
CommandLine: C:\Users\me\devcode\folder\program\myprogram.exe input1 outputdir
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 01320000 01367000 image01320000
ModLoad: 779b0000 77b30000 ntdll.dll
ModLoad: 76e30000 76f40000 C:\Windows\syswow64\kernel32.dll
ModLoad: 76790000 767d7000 C:\Windows\syswow64\KERNELBASE.dll
(19a8.1cf0): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=cb5b0000 edx=0026ddf8 esi=fffffffe edi=00000000
eip=77a50fab esp=001af830 ebp=001af85c iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrpDoDebuggerBreak+0x2c:
77a50fab cc int 3
0:000> g
(19a8.1cf0): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Module load completed but symbols could not be loaded for image01320000
eax=008872a8 ebx=7efde000 ecx=008872a8 edx=00887e60 esi=00000000 edi=00000000
eip=01327076 esp=000b2fe4 ebp=000b3028 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
image01320000+0x7076:
01327076 53 push ebx
I am most concerned about the line that reads:
*** ERROR: Module load completed but symbols could not be loaded for image01320000
Where does image01320000 come from? Shouldn't this be the name of my executable? I do have .pdb files that were created.
Yes, my program is built in debug mode. I'm just trying to get a stacktrace so I can find the source of the stack overflow it is reporting.
Thank you!