Tag Info

Hot answers tagged

28

The Linux kernel can be viewed as a kind of ultimate shell code, since it is "injected" on a raw machine (which only has the BIOS code at that point) and then provides a lot of functionality. That kernel is written in C. If you write shell code in C or C++, you will run into trouble with library calls and linking, which are two facets of the same issue. ...


18

It is perfectly valid to write shellcode in any language that gets compiled down to machine code instructions. Provided no external libraries that are not linked by the victim program are required for its operation. However, it is almost never the case that directly compiled code (even from just C) is a valid, injectable shellcode. The most common reason ...


13

You're very much getting into the realm of "Here be dragons" when you look into hardware manipulation like this. I don't know of any research or in-the-wild attack that has done any practical experimentation with this, so my answer will be purely academic. First, it's probably best if I explain a bit about how microcode works. If you're already clued up on ...


11

Although modern x86 processors allow for runtime microcode upload, the format is model-specific, undocumented, and controlled by checksums and possibly signatures. Also, the scope of microcode is somewhat limited nowadays, because most instructions are hardwired. See this answer for some details. Modern operating systems upload microcode blocks upon boot, ...


11

On 32-bit x86 processors, with the ELF format in use on Linux systems, the function call convention states (page 3-12) that: A function that returns an integral or pointer value places its result in register %eax. In your program, the last element of main() is a call to strcpy(). That function returns a copy of its first argument, here a pointer to the ...


8

First of all, the paper you are reading is more than a decade old and is no longer applicable to modern systems. The problem you are facing is that in the latest version of GCC, the main no longer "returns" like a normal function, its just exits. If you want a pointer to the return address int *ret; then you need to declare another function, and call ...


6

There are two "unknowns" that the attacker has to contend with. First, the attacker is overflowing a buffer, supposedly on the stack, and among the bytes which follow the buffer in RAM are the bytes which store the "return address" where execution jumps after the current function is finished. The attacker wants to overwrite these bytes with another address, ...


5

Ultimately, any code will be reduced to machine code / opcodes. The result is the same, but lets discuss both distributing source code and compiled/machine code: If you are using something like PHP where you have the sourcecode, you could add more loops and constructs, but someone can just load a debugger and trace through your code anyway to strip away the ...


3

Your problem is ASLR randomly choosing where your program is loaded. You can turn off ASLR in Linux using sudo sysctl -w kernel.randomiz_va_space=0. Here's my program. I'm using RAX instead of EAX, and an unsigned long * rather than an int *. #include <stdio.h> #include <stdlib.h> unsigned long *get_stack_ptr(void) { __asm__( "mov ...


3

Yes, it's possible although not quite the way some think. I've proposed a few ideas on Schneier's blog along these lines. There are a few ways of doing this: Your own microcode that starts with a processor that will not change. This can be accomplished using an open core, for instance, and freezing the internal design. Then you (and other users) do custom ...


3

Corelan has a couple of good articles on taking a fuzzing crash through to exploitation : https://www.corelan.be/index.php/2013/02/26/root-cause-analysis-memory-corruption-vulnerabilities/ and https://www.corelan.be/index.php/2013/07/02/root-cause-analysis-integer-overflows/ Their methodology appears to be a case of looking at the original seed file that ...


2

Rather that cite definitions of the terms I'd like to give my personal view of what these things are. Reverse Engineering is the process of taking an output and and figuring out what the input was. It also means tracing the steps that a piece of information took from it being inputted up until it is outputted. Think of this as figuring out things work ...


2

The question is not very clear to me, but I'll try to answer as I understand it, Yes, disassemblers do detect standard functions which is possibly loaded as dynamically linkable library (dll) into memory when you execute the binary. The standard library functions (esp. those that belong to stdio/iostream/stdlib etc) are generally part of most operating ...


2

There's a good way to solve problems (2) and (3) in the described manual binding process but I'm reluctant to publish good and elaborated public tutorial about designing shellcode here on StackExchange. ^_^ So, there's a hint for you of using crcs for (2) and indirect calls for (3) - you seem familiar enough with the manual binding process to deduce the ...


2

I don't think that changing the microcode of x86 is possible but running an emulator on top with different microcode is possible and being used. This emulator can be built to start at boot time similar to CPU bootstrapping (yes, CPUs need to bootstrap too). Obfuscating opcodes is being used in PE protectors which will generate an unique set of opcodes and ...


2

you can use scdbg with the raw binary shellcode file to get a runtime log of all of the api it uses. Execution is done in the libemu emulation envirnoment. The -d option will create a dump of the memory once finished if it detects any memory modifications (self decoding). The tool also supports locating shellcode start offsets (in case of ROP prefix), and an ...


2

libemu. Is free. For Linux but is able to analyze win32 shellcode. miasm. Implemented in Python, looks very interesting.


2

Yes, but be warned: All function gets its parameters in the stack, or sometimes in registers. Probably you don't know, which params and where will it get. Maybe you will need a little bit play if you won't and early crash at the begin. The return of a function is on the stack, but sometimes they are in registers. It is very sure, that the process will die ...


2

This is a fundamental problem with using a system you don't control. You don't control it and cannot force it to behave. You hinted at one solution in your question. Send a single request to multiple remote systems and compare the results. If they are different, one of them is wrong. It doesn't matter if it's compromised or buggy. As long as you have ...


2

Alright, I've gotten some answers from asking in the IRC channel. When you use -b, the shellcode is encoded to avoid the bytes specified. The decoder is attached to the beginning, and that code is actually readable and makes sense. This specific decoder apparently does something with XORing bytes in the shellcode, which explains why the shellcode looks like ...


2

In most (if not all) modern operating systems that run on x86 hardware, segments are ignored. The segment registers are set to begin at address 0 and to extend for the whole 32-bit address space; thus, offsets computed relatively to one segment are valid for all segments, since they all start at the same place and exactly overlap each other. In practice, ...


1

In your interpretation of the message, you're performing a step that a computer wouldn't: you're assuming the output of the base64 decoding process is ASCII-encoded hexadecimal and converting it to binary before performing the disassembly process. The first few bytes of the message are (note: there's a newline before the 5 571266161278423 with hex values ...


1

This is a great question! Never thought about this until you asked. Firstly, code running inside a secure enclave runs in ring 3. So all restrictions that apply to untrusted non enclave ring 3 code apply. So an enclave cannot write to MSR's. Next, the specs don't explicitly mention anything about MSR's but it does tell you about interaction with IA32 ...


1

The links posted by others here on obfuscation are worth a read. As you note yourself, a single point of testing can be easily patched to knock out tests. There may be mileage in utilising side effects that cause unrelated code breaking further on unless important code has run and left particular values lying around, and also for code to break if such values ...


1

What you are looking for is obfuscation. And for your specific example control flow obfuscation. For example, you could add needless ifs and goto statements: if (!this_is_always_true_and_defined_somewhere_else) { goto some_label; } else { if (delta > 0) { // code is fine } else { // code is tampered } } You can also make ...


1

It allows you for one to understand what is happening at the lowest possible level of the operating system. Second of all it allows you to change code at byte level which means you have a lot of control over the code. This is, for instance nescessary when exploiting buffer or stack overflows. When doing either attack you will essentially inject byte code ...


1

If you want to write a crypter, usually you take a certain shellcode and then load it into a script which generates another shellcode which contains an encrypted form of your shellcode. At runtime the shellcode will then be decrypted and run. To generate this encrypted form you will need to either use an existing crypter or create your own. In your python ...



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