Hot answers tagged

25

To extend the answer of perror: Perhaps you should take a look into a recently published whitepaper named Breaking the x86 ISA, by Christopher Domas. It was published on blackhat17 and describes an approach for digging into x86 chips and extracting hidden machine instructions. Title: Breaking the x86 ISA Abstract: A processor is not a ...


16

Most vulnerabilities in closed-source products are found via fuzzing and static reverse engineering. reversing it and hoping to find a buffer overflow this way seems rather hopeless to me, considering how much work this is Typically you don't need to analyze the entire program, but only the entrypoints for user-input. Yes, it's still a lot of work, but ...


14

Here is the list of few decompilation tools / resources that you may find useful. IDA Pro + Hex-Rays decompiler Hopper disassembler (has a decompiler) ODA (Online Disassembler) Retargetable Decompiler


14

Injecting payload and hexadecimal addresses through program inputs depends on the type of input you get. Here is a list of all the possible inputs and the way to do it with both a pure shell environment and from within gdb. Getting inputs from char *argv[] In this case, the arguments are read from the initial command line, so the most convenient thing is: ...


13

If you look at the disassembly of authorize() I'm sure you'll find that the compiler is pushing and restoring more registers than just EBP or aligning the stack. I would recommend that you always look at the disassemly when dealing with overflows of various kinds. The compiler and decompiler, if you use one, hides a lot of details. The disassembly never lies ...


12

First of all, I have bad news for you ! Doug Lea's malloc is almost no more used in any C library implementation (even if understanding dlmalloc can help a lot to understand new ones). The new implementation that is most widely used is ptmalloc2 and the best way to learn about it is... to read the code... So, if you are using a Debian(-like) distribution, ...


12

It largely depends on what kind of vulnerability. This particular one you mentione is in SecurityManager, and you could have found it relatively easily by analyzing the Java source code. To get some idea of how that process is done, take a look at this and this articles by Esteban Guillardoy of Immunity. Jduck has also published some research on memory ...


11

Why does the return address have to point to the shellcode in the same buffer? It doesn't, but generally, both the shellcode and the return address are delivered at the same time, so they are stuck together for that reason. If your exploit allows you to deliver them separately, then they can be separated. However, they are by necessity both local to the ...


9

In fact, the CPU are much more checked and verified than programs. It is very unlikely to find a (significant) bug in a CPU. Even though it happens from time to time. Therefore, it is much more interesting to look at software bugs (because they are more likely) than hardware bugs. Yet, you have a few occurrences of hardware bugs that led to disclosure of ...


8

Well I myself am an exploit developer. The methods of attack/research are: Reversing the input values. Files, network protocols etc etc. Building a Fuzzer with this information Fuzz till crash Analyse the crash Build exploit Another method I commonly use is to reverse points of interests (eg SingleSignOne modules, other login methods, database connections (...


7

You might be interested in the Dr. Gadget IDAPython script (screenshots here, code here). This little IDAPython plugin helps in writing and analyzing return oriented payloads. It uses IDA's custom viewers in order to display an array of DWORDs called 'items', where an item can be either a pointer to a gadget or a simple 'value'.


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

Any such functionality is dependent on the player or viewer used. I know of no image formats that require any kind of interaction from the viewer, but some video formats do (or, rather, did) use it. In addition to Quicktime mentioned by 0xea, the Windows Media/ASF format allows embedding of script commands, and one of them is opening an URL: http://support....


6

This comes down to the type of bug you are exploiting. If your payload cant contain null bytes (a vulnerable strcpy), this can become an issue, however not all bugs have this constraint. Take for example a bug in how a filetype is parsed, which allows null bytes. Also there is the possibility of a series of bugs to be used, for example, the idea of heap ...


5

This is a continuation of non-return based gadgets. A ROP-gadget in itself is a segment of code that you can use to manipulate data, and get some desired effect, while maintaining control of execution. Here is a paper about Jump Oriented Programming. Also, Return Oriented Programming without Returns. They went through libc-2.7 (/lib/i686/cmov/libc-2.7.so of ...


5

What you ask for would be very near remote code execution, which is usually a security no-no. Tho there are some formats that allow similar things. As far as i remember MOV file format allows you to embed urls or aliases in it for alternative versions of the movie. I think it's usually used for streaming purposes, so that a player can request a higher or ...


5

In fact, the memory layout within gdb and outside of it differs of a few bytes. There have been recently a question about this here. You can read: How to predict address space layout differences between real and gdb-controlled executions? In your case, you may just have to adjust your address by adding/subtracting 96 bytes. I can, also, give you a few ...


5

this is how a BSTR represented in memory: Length Data string Terminator so an attacker will try to get an aligned heapspray and then trigger a vulnerability that will modify the Length part of a BSTR, it can be: a heap overflow. a use after free that crashes on instructions that can modify a controlled memory address (eg AND 0xFFFFFFFF, edi) where edi is ...


5

If you can patch the program's image, you don't actually need to hardcode the address. you can simply add another import entry to the already existing import tables and have it patched in automatically by the loader. See Iczelion's tutorial on import tables to guide you further. Of course, if you're trying to do that from shellcode, you'll need to walk the ...


5

Because the operating system is initializing ESP always at the same value (and that the execution of the program you look at are deterministic). The way the ASLR (Address-Space Layout Randomization) works for stack randomization is very simple. At program start, the operating system, when initializing the ESP register, will add a random value to it. When ...


5

Why is it not working. This example is basically from an older book I'm reading. But theoretically it should work so I think.... It's because you're overwriting the return address on the stack with 0xffffd2ec instead of 0x0804852f (the latter is the address for secret()). If you thus use '{print "A"x24; print "\x2f\85\04\08"; }' instead, it should work. ...


5

Regarding your original question: Upon ntdll.dll loading each PE image, the list of exception handler addresses in the PE image is parsed and each address is inserted into a sorted list that ntdll.dll internally uses. When an exception hits, ntdll.dll!KiUserExceptionDispatcher will try to figure out which exception in the SEH chain to use. In turn, each ...


5

The only idea I have is to compare the dumps. The places that are same in all dumps are code or read only data. The places that are changing from dump to dump are either stack or section like .bss. After finding places that are not changing I'd try to disassemble these places in order to divide between code and data. I think that the places with the code ...


4

Lots of Java exploits revolve around bypassing the Java sandbox, the Security Manager in Java parlance. Sami Koivu published a lot of interesting work around Java security and exploits, notably his 3 parts introduction to Java security. http://slightlyrandombrokenthoughts.blogspot.ca/2009/02/java-se-security-part-i_25.html http://...


4

Try to set a catchpoint on fork if you are want to both the parent and the child. set-follow-fork-mode ask catch fork Concerning your second point, I have this macro in my .gdbinit (I believe ultimately originating from Tavis Ormandy). It is imminently useful in many cases, your own included. define assemble # dont enter routine again if user hits ...


4

If I'm understanding your first question correctly, I think there was a disconnect between you and whoever told you that. There is no restriction based on the buffer(s) being in the same process, at least not with respect to return values. You could absolutely have the return address point to the start of the shellcode. It's entirely up to you. The better ...


4

Yes, all the opcodes ending by a ret can be considered as a gadget. But, consider also the fact that not only legal instructions can be considered as gadget, also 'starting in the middle of an instruction' or 'using the static arguments of an instruction' can be considered as a potential gadget. In fact, the only limitation (apart from the fact that it must ...


4

if you want to develop exploits in Python, this book may help: http://my.safaribooksonline.com/book/-/9781597497299/chapter-9-exploitation-scripting/building_exploits_with_python If you need to generate big chunks of asm PeachPy might help: PeachPy https://github.com/Maratyszcza/PeachPy You can also compile python to C, and use a C compiler to get ...


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

Some things you will inevitably have to know at some degree to be able to reverse engineer Game Consoles: Learn a lower level language such as C or C++. Most, if not all, Console games, modern and old, use these two languages for the bulk of the game (AKA, the Engine). This is important for my next point, which is: Learn about the architecture of game ...


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