10

Slightly modified version from pydasm's README.txt import pydasm import binascii # Open, and read 200 bytes out of the file, # while converting buffer to hex string with open('file.bin','r') as f: buffer = binascii.hexlify(f.read(200)) # Iterate through the buffer and disassemble offset = 0 while offset < len(buffer): i = pydasm.get_instruction(...


10

The shellcode is unicode escaped. You can convert it to its hex representation using a simple python script. from binascii import unhexlify as unhx encoded = open('encoded.txt').read() # The shellcode dump out = open('shellcode.bin', 'wb') for s in encoded.split('%'): if len(s) == 5: HI_BYTE = s[3:] LO_BYTE = s[1:3] out.write(...


9

It's not run in the example. It's a shellcode, it has to be somehow injected (for example using a buffer overflow vulnerability). To understand how it works, let's first put some addresses on the strings: 00000045 "/bin/sh" 0000004D "-c" 0000004F "cp -p /bin/sh /tmp/.beyond; chmod 4755 /tmp/.beyond;" Let's look at the disassembly piece by piece. ...


9

The structures for the PEB are _PEB and PEB_LDR_DATA. You need to have the ntapi type library loaded, you can add it by going in the Type Libraries view (Shift+F11) and then press Ins.


8

It looks like you have two issues. 1) You are overwriting your input buffer with those push-es so that why you have some junk on the stack and that's why our application crashes. See those two pictures that show your assembly before and after executing the second push for the /bin/sh Before After You can clearly see odd das and bound opcodes instead of ...


7

The diagram you linked to seems to be wrong. The size of the previous chunk is stored in the current chunk iff, the previous chunk is free. This image is more appropriate of what an allocated heap chunk looks like. Source: https://sploitfun.wordpress.com/2015/02/10/understanding-glibc-malloc/ Lets take the following code to demonstrate this. #include <...


6

The problem with you shellcode and the why it differs if you run from C program or not is the initial values. The registers that are used when executing execv (second page) are: eax = 0x0b ebx = ptr to filename ecx = ptr to argv edx = ptr to environment variables But actually the important one are only ebx and eax and the two other we can nullify. If you ...


6

Try using IDC function StartDebugger. You can pass a C-style string (e.g. "\x55\x89\xe5")for program arguments: *********************************************** ** Launch the debugger arguments: path - path to the executable file. args - command line arguments sdir - initial directory for the process for all args: if empty, the ...


5

if you are using IDA FREE then this and several other type libraries are not available and if you intend to create them yourself and export them somehow (would have to figure out how). this walk through provides few hints on how to accomplish it os winxp sp3 vm (all opaque structures like EPROCESS can vary from os to os / hotfix to hotfix patch ...


5

Alphanumeric shellcode expects the location of the shellcode to be stored in a register, since the usual technique of call/pop can't be performed with the limited character set. In your example above this is set using BufferRegister=ECX, your C program doesn't take this into account though, which is why it crashes. Taking out the BufferRegister directive ...


4

Copy/pasted from the online disassembler: .data :00000000 e0522002 subs r2, r2, r2 .data :00000004 e92d0104 push {r2, r8} .data :00000008 e8bd0101 pop {r0, r8} Or, in thumb mode (the push/pop instructions are actually the same, seemingly being byte-swapped due to endianness): .data :00000000 1a92 subs r2, r2, r2 .data :00000002 0104e92d stmdb ...


4

68 A bytes - 23 shellcode bytes: 45 NOPs. NOP is the mnemonic that stands for No OPeration which is the byte \x90, meaning that you'll have to change the A's (\x41) for NOPs (\x90), because \x41 by itself it's not a valid ASM instruction in the x86 processor hence making your program crash. Taking this into account, first part goes like: python -c 'print ...


4

We have two major stack protection for buffer overflows: Stack canaries Non-executable stack You land on nopsled but, you get segmentation fault. Because your operating system marked program stack as non-executable and processor raises the exception when program counter addresses that segment. But, even we use executable stack (for GCC use -z execstack) ...


4

There are several online tools providing a disassembling service. Here is a (non-exhaustive) list: ODAweb (probably the most known); Pym's online disassembler; PVPHP; Udis86; Defuse online x86 assembler (a bit out-of-topic, but we never know).


4

This execute-from-array method is used to test shellcodes in bytes format, which is often the way shellcodes are provided (see http://shell-storm.org/shellcode/). It also emulates the usual way shellcodes are being used in an exploit. Inline assembly is compiler dependent and shellcode developers might use assemblers directly such as nasm or MASM. However ...


4

First thing that comes to mind when you have non-executable stack is Return-oriented programming which, as the name implies, uses return to execute a code you want. When using ROP, you will want to use the program's executable and dlls (or .so files for linux) and rely as little as you can on system dlls as they change with the OS version. The idea is that ...


3

I suppose you should check this part of the ARM documentation, and this description of svc and its parameters. By cross referencing the two links you'll find an answer to your question. From the links above you'll be able to understand what the parameter of the svc instruction represents. It is supposed to be ignored by the CPU but the exception handler can ...


3

If user32.dll is already loaded in the process's address space (and I assume it is given that you said it's a Windows GUI application), you can walk the PEB_LDR_DATA structure in order to find the base address of user32.dll: KERNEL32 image base address on Windows Seven Understanding the PEB Loader Data Structure Where is ntdll.dll?


3

Okay, so according to gdb the shellcode does run, so it's probably placed into .text. You should try to step through the shellcode (e.g. using stepi) to see on what instruction it faults.


3

With the shellcode given I was not able to get a shell. If you strace the binary when getting input from the stack execve("/bin//sh", ["/bin//sh"], [/* 0 vars */]) = -1 EFAULT (Bad address) char *const envp[] is passed in edx register which is not properly set. To patch this I changed shellcode to this 0: 31 c0 xor eax, eax 2: ...


3

Put a INT3 (F2) breakpoint on the recv function (To jump to that function, hit CTRL+G then type recv to the textbox which just appeared, and then hit enter) within Immunity Debugger, and observe the stack (lower right corner) for the socket ID when the breakpoint is hit.


3

In WinDbg: 0:000> dt ntdll!_TEB -y ProcessEnvironmentBlock->Ldr->InM +0x030 ProcessEnvironmentBlock : +0x00c Ldr : +0x014 InMemoryOrderModuleList : _LIST_ENTRY the list entry->Flink is a pointer to _LDR_DATA_TABLE_ENTRY-> InMemoryOrderLinks so if you take the Flink subtract -8 ...


2

I don't see that option in golink linker but if you use i.e. link.exe (Microsoft (R) Incremental Linker Version 14.11.25506.0) then you can use /SECTION parameter to specify that. link /SUBSYSTEM:CONSOLE /ENTRY:start xor.obj /SECTION:.text,RWE After that if you display memory map in xdbg you'll see the change: After that, you encoder can modify the code ...


2

There are few issues with your code. 1st is what Igor mentioned - .text section is RO. This was solved in this answer. The 2nd is that you did not copy correctly the bytes or lost some of them in other way. Your shellcode has 260 bytes, but if I compile the example for the link that you've provided then I get 262. I run them by a short python script to xor ...


2

I think the problem is that the executable code is not writeable by default on Windows, so it fails when xor tries to modify the code. You should look into how to modify .text section permissions, either at assembly/link time or at runtime. Another solution could be to copy the shellcode to writeable memory before decryption, however this may lead to the ...


2

It seems bp $exentry should set breakpoint on the entrypoint, then you can continue (g) until you hit it.


2

Okay, so I will try to answer to all your questions and add a few remarks. Do not disable ASLR system-wide, prefer to disable it within the current process. In fact, echoing 0 in randomize_va_space will totally shutdown the ASLR for your whole system leaving it vulnerable to external attack. If you are under Linux, the best way to disable locally the ASLR ...


2

iirc you cant go from a constant hash to name but hash an exported name compare the generated hash with the constant you can see a discussion and an implementation here a ripped python implementation using the discussion as follows :\>cat foo.py def rol32(val, amt): return ( (val << amt) & 0xffffffff ) | ( ( val >> (32 - amt) )...


2

relative address can be forward or backward from end of current instruction or start of next instruction that e8 00 00 00 00 will be call to the next immediate instruction forward can be e8 ( 00 00 00 00 .... 7f ff ff ff ) backward can be e8 ( ff ff ff ff .... 80 00 00 00 ) so your immediate here is 0xfffffe6b that is == -0x195 ...


2

The instruction that causes the SIGSEGV is trying to store a '\0' after the 'h' in "/bin/shJAAAABBBB". All your code/data is in the .text section which is probably read-only. Run objdump -h on the resulting binary, and you should see something like the following in the output: 5 .text 00000031 00001000 00001000 00001000 2**4 ...


Only top voted, non community-wiki answers of a minimum length are eligible