Hot answers tagged

15

What the Instructions Are Doing What are the first three instructions before push %ebp doing? Namely, 804841b: 8d 4c 24 04 lea 0x4(%esp),%ecx <- 1 804841f: 83 e4 f0 and $0xfffffff0,%esp <- 2 8048422: ff 71 fc pushl -0x4(%ecx) <- 3 This is easy to see if gdb (or some other ...


6

What does this do? These three statements serve to move the stackframe of main, beginning with its return address, to the next 16-byte-aligned address. lea 0x4(%esp),%ecx # save address of arguments and $0xfffffff0,%esp # align stack pushl -0x4(%ecx) # move return address ... # continue normal preamble At the same ...


6

if I pass an argument to an function it should be translated in assembly language into push something That's true for some 32-bit calling conventions, but your program is a 64-bit program and thus follows the System V Application Binary Interface for AMD64. From https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI: The calling ...


6

I can think of 2 cases where a VMT is not in the first word of an object: using multiple inheritance when the an object has a member variable which has virtual methods multiple inheritance struct base1 { uint32_t x[12]; virtual void m1() { } }; struct base2 { virtual void m2() { } }; struct cls : base1, base2 { }; now the VMT of base2 is at ...


4

It seems like the functions are defined like this: int quotearg_n(int a, int b) { return quotearg_n_options(a, b, -1, "some_string"); } int quotearg(int a) { return quotearg_n(0, a); } (the ints might as well be pointers, can't tell this from your snippets, and the "some string" might be a pointer to a pre-initialized structure) These functions ...


4

Given that you didn't specify any optimization flag and used -m32, GCC performed no optimization on your code. The -m32 flag specifies the generation of a 32 bit code for a compiler configured to generate 64 bit code by default. In 32 bit mode, even with optimizations activated, GCC will generate a sub-optimal code given that the only way to do floating ...


4

My best guess : memory alignment. An integer in C is 4 bytes and a char 1 byte. Therefore, your declarations go like this : 4B & 1x10=10B & 4B. This order means that the 10B won't be aligned on a power of two memory boundary without wasting space. Data accesses are faster on x86 machines when arrays are aligned on 16B/32B/64B - BTW 64B is the size ...


4

These are object virtual table entries used to implement multiple inheritance. The short story is, the sub instruction is to do with offsetting the correct derived class object size to the virtual table; but the following (long) article does a much better job of explaining than I could fit here : http://thomas-sanchez.net/computer-sciences/2011/08/15/what-...


4

you're looking the wrong way. look in the functions before running main and you will find the decryption function. when you're using the decrypt function, you get a key for the archive: 1n1T_4nD_F1n1_4rR4Ys_4r3_S0_34sY!! and flag: {FLG:4#hfoU98Y5(ButYou'llNeverKnowIt)} EZ part 1 = [2, 93, 2, 103, 108, 7, 93, 119, 108, 117, 2, 93, 2, 108, 7, 65, 97, 7, ...


3

Since another question was based on the same binary and the accepted answer doesn't go into detail on how to find the function responsible, here's a writeup. Usual stuff $ r2 wysiNwyg; aaa have a look at the list of functions(afl) [0x080484a0]> afl 0x080483bc 3 35 fcn.080483bc 0x080483f0 1 6 sym.imp.strcmp 0x08048400 1 6 ...


3

A runtime function does not necessarily convert to a C++ function. For example, on a processor that has no floating point hardware, a simple statement like a=b+c; with a, b and c being floats, will probably be converted to a function call that takes b and c as parameters and returns the results. The user is not supposed to call that function directly. In ...


3

Shot in the dark: Maybe this text (or the whole binary image) is compressed. Think something like LZSS. The fact that there is a mystery byte containing eight 1 bits, followed by eight literal and correct bytes, indicates that maybe the mystery bytes are actually flags that use each bit position to differentiate uncompressed data bytes from pointers to ...


2

The code to detect and print virtual function table pointers is: int isIdentifier(const char* s) { // true if points to [0-9a-zA-Z_]*\x00 if(!isValidPtr(s,0x10)) { return 0; } if(!s[0]) { return 0; } int i; for (i=0; s[i] && i<512; i++) { if( i/0x10 && i%0x10 == 0 && !isValidPtr(s,0x10)) { return 0; } ...


2

You are executing code on a little-endian machine. This means that this code: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 e4 f0 and $0xfffffff0,%esp 6: e8 00 00 00 00 call b <_main+0xb> Would be expressed as 32-bit unsigned hex integers as: 0x83e58955 ...


2

Information about symbols resolved at link time, including the symbol name and memory address, can be acquired by by executing ld with the -M option plus the name of the object file to be linked: $ ld -M <OBJECT FILE> This will result in a link map being printed to STDOUT. Of course, this output can also be redirected to a file: $ ld -M <OBJECT ...


2

This behavior is totally normal. The way functions are handled is usually described in what's called an ABI (Application Binary Interface). It defines calling conventions which detail how a call is made in assembly code and how parameters are passed to a function using specific registers. I would recommend Agner Fog's C++ Optimization Manual. It contains ...


2

The stack is for data storage, not code I figured it out. It looks like the sub statement is allocating space for the entire program rounded to the nearest qword. Program 1 requires only 0x17 bytes 23 bytes of code while program 2 requires 0x28 or 40 bytes of space. This is not correct: space on the stack is not allocated for a function's code (or any ...


2

.eh_header is probably not executable but editing the section table won't help. You need to edit the segment (Program header) corresponding to this section. you can find out the segment using e.g. readelf -a: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align ...


2

The .eh_frame section is not a code section. Therefore, it is not an executable section and the memory allocated for it is non-executable memory. You can read it, but the CPU won't execute it. One solution is to change the permissions for that section in the ELF header (in the sections listing). Another would be to find another code cave (that's how regions ...


2

I believe the best thing to do would be to learn about compilation in general and code generation in particular. The dragon book would be a good start. Then you can check Engineering a Compiler by Cooper & co. About common compiler patterns, this would require a bit of extensive reverse engineering which, I believe, few people in the research and ...


2

The "problem" with your example is that the structure is too small (four bytes), so it fits in a register and is not actually passed on the stack. From the Itanium C++ ABI (used by most GCC implementations): A type is considered non-trivial for the purposes of calls if: it has a non-trivial copy constructor, move constructor, or destructor, or ...


2

It's not add in the first opcode. It's and. So it will clear the lower nibble for the last byte in the address. This is how the alignment is done and not by adding anything. Only later you sub 16 to have room for the local variables. Why do we need to modify the value of EBP? We use EBP to store the initial ESP value. EBP is pointing to the current stack ...


2

Additional to PE detection tools (like PEiD, Detect it easy ,Etc) there is some especial code patterns for GCC and MSVC for example GCC use MOVinst instead of PUSH inst for pushing a value on stack.


2

It seems to be %rip (the address of the ud2): #include <signal.h> #include <stdio.h> #include <ucontext.h> void handler(int signo, siginfo_t *info, void *context) { ucontext_t *uc = (ucontext_t*)context; printf("%llx\n", uc->uc_mcontext.gregs[REG_RIP]); } compiles to: handler(int, siginfo_t*, void*): movq 168(%rdx),...


1

I think your shellcode is missing the specifier for the bit-ness of the shellcode. You're compiling the shells in 32 bits, but for the nasm (I'm assuming you're using that) doesn't have anything. I'm assuming you're compiling in bin mode and if you check the documentation ...the bin output format defaults to 16-bit mode in anticipation of it being used ...


1

The best heuristic would be code. I would create a hello world test file and compile it with the compilers I was interested in identifying. Load them in the free version of IDA (or Pro if you've got it), and then examine the instructions at the entry point. Matching on compiler code at the entry point is a sure fire was of getting it right. You may have to ...


1

Yes, there is a very good book (as in, it covers tons of patterns) at https://beginners.re/ - https://beginners.re/RE4B-EN.pdf You can spend 5-10 years studying general theory of compilation, which will go forward during that time anyway, but if you need a reasonably quick compendium of current patterns for reference / quick training, use that book.


1

"Qualcomm Hexagon" is not a compiler, its an architecture by Qualcomm Inc. The internet has a few resources which might be helpful in your endeavors. A third party IDA processor module An SDK provided by Qualcomm. A few other tools and documents provided by Qualcomm. Although these do not explain the reason for the empty sections table, I assume going ...


1

If you want assembly code without the use of push instruction from a C code, there is always the C prototype #inline.


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