i have a shellcode and i want to inject my shellcode into a PE file (a simple compiled c program that prints Hello World on the screen) .
My shellcode size is 0x2a1 and the .text section of my pe file has enough space to hold it .
So i opened my PE file in PE-Bear and find the .text section RawOffset in file .
.text section RawOffset in PE-Bear
then i patch .text section bytes using HxD .
I set AddressOfEntryPoint in OptionalHeader to start of .text section where my shellcode is :
AddressOfEntryPoint in PE-Bear
So now execution must be started from my shellcode bytes . but i ran pe file and got error :
ERROR
I open PE file using OllyDbg and execution isn't at position that i expected .
OllyDbg
AddressOfEntryPoint was 1000 . it's RVA so the execution must be started at 0x00401000 since the ImageBase is 0x00401000 (PE file is not dynamic base) but it isn't that and we got Access Violation .
i use Windows XP .
what is going on ? why does this happen ?
(sorry ! i couldn't add images . click on links to see them )
Related
I have a memory crash dump, and I can list processes with !process 0 0
What I want to do is find the Image Base Address of calc.exe and get its contents from the memory. Potentially saving it into a file.
what do I need to do to achieve that?
Edit: the type of dump I have is "automatic dump" but I would like to know the technique for other types such as full core dump
a dump can be of several types
what is the type of dump is it user mode or kernel mode ?
it is mindump of full dump ?
in many cases the pages may not be present either being paged out or intentionally discarded init section of modules
anyway
if user mode try !vadump or !address to locate the module of interest find its start address and end address and try dumping in page size increments (0x1000 bytes )using .writemem
in kmode use !vad
and follow both commands by lm or !dh to get the module information in both user mode and kernelmode
here is an user mode dump !address info
F:\caldump>cdb -c "!address calculator;q" -z calc.dmp | awk "/Reading/,/quit/"
0:023> cdb: Reading initial command '!address calculator;q'
Usage: Image
Base Address: 00007ff7`04a30000
End Address: 00007ff7`04a31000
Region Size: 00000000`00001000 ( 4.000 kB)
State: 00001000 MEM_COMMIT
Protect: 00000002 PAGE_READONLY
Type: 01000000 MEM_IMAGE
Allocation Base: 00007ff7`04a30000
Allocation Protect: 00000080 PAGE_EXECUTE_WRITECOPY
Image Path: C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.1906.55.0_x64__8wekyb3d8bbwe\Calculator.exe
Module Name: Calculator
Loaded Image Name:
Mapped Image Name:
More info: lmv m Calculator
More info: !lmi Calculator
More info: ln 0x7ff704a30000
More info: !dh 0x7ff704a30000
Since !process 0 0 works then it's a kernel dump. Try inspecting the peb
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/-peb
Attaching to DLL as memory dump with WinDbg looks like (for example)
cdb -z %__appdir__%kernel32.dll
It works fine, now I can read NT_IMAGE_HEADER structure
!dh kernel32 -f
For reading export table I use next technique
dd kernel32+262c; * example of an export table RVA;
The is number of exported functions in second column of second row and offset to the start of the export table in first column of third row. Check it
dd kernel32+353c; * example of offset;
...; * take the first address in output;
da kernel32+4ba5
7c804ba5 "ActivateActCtx"
Bingo! Now we can use da again and again to see other exported functions but it's awful way. So it's better to use next trick
? (kernel32+353c); * get hexadecimal address of first exported function;
r? #$t0 = (int *)0x7c80353c; * set the pointer on that address into pseudo-register;
.for (r #$t1 = 0; #$t1 < 3ba; r #$t1 = #$t1 + 1) {da kernel32+(##c++(#$t0[#$t1]));}
What's my problem? At present moment I'm trying to read imported functions but when I type
dps kernel32+1000
where 1000 is RVA to the Import Address Table Directory I've got only part of addresses of names, not names. So, how can I get list of all names of the imported functions? Is there a simplest way or should I write a cycle again? How should be cycle look like?
cdb -z is used for loading dump files
using them for loading binaries have several side effects
and may include not loading pages that belong to import table
import table fill up needs interaction by loader to resolve imported address
when you load a binary as a dumpfile no other modules are loaded along with it
but dump file has information about other dlls needed in the module stream
so when you try to read some data from unloaded memory region
you are presented with ??? (question marks)
actually windbg has three bang commands that you can use for the purpose
they are
!showexports { address / mod }
!showimports { address / mod }
!showresources { address / mod }
the !showimports command also will not work on binary files loaded as dump
(cdb may hang trying to ReadARange and iirc i sent off a mail to windbg team long ago
(during 6.0 or xp era ) but the same hang appears in 17763 windbg which is latest as on the date of post
your efforts to read imports the way you describe will work better if you load an actual dump instead of binary file as dump
to confirm you can use !vadump command and you will see cdb has mapped
pages after the size of import table
C:\>cdb -c "!dh kernel32;q" -z c:\Windows\System32\kernel32.dll | grep -i "Import.*Address"
1000 [ DFC] address [size] of Import Address Table Directory
C:\>cdb -c "dd kernel32+1df0;q" -z c:\Windows\System32\kernel32.dll
Microsoft (R) Windows Debugger Version 10.0.16299.15 X86
Loading Dump File [c:\Windows\System32\kernel32.dll]
0:000> cdb: Reading initial command 'dd kernel32+1df0;q'
77de1df0 ???????? ???????? ???????? 90909090 <<<<<<<<<<<<<
77de1e00 90909090 90909090 90909090 90909090
quit:
C:\>cdb -c "!vadump;q" -z c:\Windows\System32\kernel32.dll
Microsoft (R) Windows Debugger Version 10.0.16299.15 X86
Loading Dump File [c:\Windows\System32\kernel32.dll]
0:000> cdb: Reading initial command '!vadump;q'
BaseAddress: 77de0000
RegionSize: 00001000
BaseAddress: 77de1dfc <<<<<<<<<<<<<<<
RegionSize: 000c4204
BaseAddress: 77ea6000
RegionSize: 00001000
BaseAddress: 77ea7000
RegionSize: 00001000
BaseAddress: 77ea8000
RegionSize: 0000c000
quit:
I have a single DLL or EXE file and I'd like to acquire the symbols (PDB file) for it, i.e. download from the symbol server.
Note: The DLL is not a module which is part of a crash dump, so opening the dump and doing .symfix and .reload is not possible.
I have tried
symchk /os /if "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll"
/su "SRV*e:\debug\symbols*http://msdl.microsoft.com/download/symbols"
but it just says
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
and there are no symbols in my symbol folder.
You have used /if which sounds plausible, but actually it needs to be /id for a dump file:
symchk /os /id "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll"
/su "SRV*e:\debug\symbols*http://msdl.microsoft.com/download/symbols"
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
The output is the same, but the symbol folder contains the PDBs now.
It is similar in WinDbg:
choose File | Open Crash Dump ... or press Ctrl+D
for the file name filter, instead of Crash Dump Files select All files
choose the DLL or EXE of your interest. WinDbg will e.g. say
Loading Dump File [C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll]
although it is not really a dump file
issue the typical commands .symfix and .reload. If symbols are present on the symbol server, they will be downloaded.
Looking at what you're "debugging", you'll see that it's the DLL:
0:000> |
. 0 id: f0f0f0f0 examine name: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
0:000> ||
. 0 Image file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
0:000> lm
start end module name
00000001`80000000 00000001`80988000 clr (pdb symbols) e:\debug\symbols\clr.pdb\5706A2AA257A45FDAC5776EDDC7BBA542\clr.pdb
And also some other commands work:
0:000> x clr!*
00000001`80123e28 clr!SafeHandle::Init (<no parameter info>)
00000001`808f5e80 clr!HillClimbingLogSize = <no type information>
00000001`80064af0 clr!IsTimerSpecialThread (<no parameter info>)
...
0:000> u clr!SafeHandle::Init
clr!SafeHandle::Init:
00000001`80123e28 4883ec28 sub rsp,28h
00000001`80123e2c 488b059d4b7c00 mov rax,qword ptr [clr!g_Mscorlib+0x10 (00000001`808e89d0)]
00000001`80123e33 488b80e0070000 mov rax,qword ptr [rax+7E0h]
00000001`80123e3a 4885c0 test rax,rax
...
I am disassembling instructions by passing their offset to DisassembleWide() function while writing an extension for Windbg. However, with the disassembled instruction, it adds the address of the instruction + hex opcode for that instruction.
I was able to remove the opcode by specifying DEBUG_ASMOPT_NO_CODE_BYTES flag in SetAssemblyOptions(). However I can't seem to get rid of the instruction offset. Neither DEBUG_ASMOPT_DEFAULT | DEBUG_ASMOPT_NO_CODE_BYTES, nor (DEBUG_ASMOPT_DEFAULT | DEBUG_ASMOPT_NO_CODE_BYTES) & ~DEBUG_ASMOPT_VERBOSE seem to work.
Am I missing something? Is there a way I can cleanly remove the offset from the instruction, or will I have to do it the manual way?
no Address will always be printed you have to parse it out yourself
if you are on a windbg session you can achieve this with .shell and awk
0:000> .asm no_code_bytes
Assembly options: no_code_bytes
0:000> .shell -ci "u #eip l4" awk "{$1=\"\";print $0}"
int 3
ret
mov edi,edi
int 3
.shell: Process exited
I am trying to understand why lseek() is used in this image creator. Why 5 bytes away from start of file? If I changed that number, the OS won't boot.
The image creator creates a .img file with the bootloader.bin inside.
/* modify the sector count */
total_sector_number = file_size / 512
lseek(disk_image_fd, 5, SEEK_SET);
write(disk_image_fd, &total_sector_number, 2);
write(disk_image_fd, &kernel_32_sector_number, 2);
//printf("%d\n", lawl);
printf("TOTAL_SECTOR_NUMBER : %d\n", total_sector_number);
printf("KERNEL_32_SECTOR_NUMBER : %d\n", kernel_32_sector_number);
The source code (image maker):
http://pastebin.com/raw.php?i=MuDpYP3Y
Bootloader:
http://pastebin.com/raw.php?i=kzw2ZaU1
The hexdump with lseek() and writing umber of sectors to byte at offset 5:
Without lseek() OS does not boot correctly.
I only figured this out because of your previous post Bootloader memory location which contained different source code for the bootloader.
You mentioned the two unknown variables TOTALSECTORCOUNT and KERNEL32SECTORCOUNT. These variables were near the beginning of the file, and I guess when assembled they sit 5 bytes into the binary. Calling lseek with the SEEK_SET parameter moves the file pointer to 5 bytes after the beginning of the file. It then writes the two values which will overwrite the ones in the bootloader code.
When you remove the lseek it will instead append the two values to the end of the file. If you changed the offset parameter of lseek to zero it would overwrite the jmp command of the bootloader instead.
Notice in your hexdump.
00000000 00eb b8fa 02c0 0000 c000 e08e e88e 00b8
^ ^- kernel_32_sector_number is never initialized.
|-total_sector_number which was calculated in code before the write.