@perplex_files

Tags:

#exploit #ebook #reversing #programming #emulation #cpp #roadmap #comp_arch #comp_theory #math #c #assembly #misc #crypto #rootkit #malware #hardware #arduino #learning #tool #bsd #quantum #embedded #lisp #channel #notes #linux #my #windows #book #graphics #info_theory #ic #privacy #android #ios #physics #playlist #philosophy #electronics
#sat

Telegram Channels:

https://t.iss.one/p_file/60

Twitter Channels:

https://t.iss.one/p_file/343

Links for Articles:

https://t.iss.one/p_file/299

Book/links recommendations:

Information Theory

Computer Science and Programming

Physics and Math

Philosophy

Books for free:

zlibrary.onion

Github Awesome Links:

https://t.iss.one/p_file/195

Youtube Channels:

Programming and Hacking

Hardware

Math

Useful Links:

Playlists

Undergrad Courses

A Corelan tutorial about Heap Spraying, from the simple way (to older browsers) to simple bypasses of common mitigations of this technique (chunk randomization, different variable names and so on). I think it is a pretty interesting post.

https://www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heap-spraying-demystified/

Cache & Plunger technique – oleaut32.dll

Every time a chunk gets freed, the heap manager will try to place the pointer to that freed chunk on the cache (there are a few conditions that need to be met for that to happen, but those conditions are not that important right now). These pointers could point anywhere in the heap, so everything that is placed on the cache may appear somewhat random. When a new allocation happens, the cache system will see if it has a chunk of the requested size and can return it directly. This improves performance and also prevents further fragmentation to a certain extent.

Blocks larger than 32767 bytes are never cached and always freed directly.

The cache management table is structured based on chunk sizes. Each “bin” in the cache list can hold freed blocks of a given size. There are 4 bins :

Allocating chunks that are returned by the cache manager could be located anywhere in the heap, the address would not be reliable.

Since the cache can only hold up to 6 blocks per bin

This is the Intel Software Developer's Manual. Here you will learn about the functioning of the Intel's CPUs, from the basic environment (Data types, types of procedure calls, instruction sets and general instructions/registers) to the memory management, paging, protection system of the CPU (rings, memory protection, paging protection), task management, etc. Basically you will learn beyond assembly, you will learn how the CPU manages all the memory/environment and how it is performed. This can be useful for driver development, system management, VM purposes, rootkits, to know more about any assembly instruction and its particularity, or just for knowing more about what happens behind an application and its instructions. It is divided in 4 chapters, the information about the CPU's behavior are located in chapters 1 (the introduction to the architecture) and 3 (the system programming guide, with all the information of the Intel's CPU behavior). Chapter 2 has the Instruction Set Reference of all the assembly instructions (from A-Z, and every instruction has a detailed description), and chapter 4 it is about MSR (Model Specific Registers).

https://xenproject.org/2012/06/13/the-intel-sysret-privilege-escalation/

What is the SYSRET Intel Vulnerability?

This vulnerability is found on Intel's CPUs, and it is caused by a flaw in the SYSRET instruction, in which is used to fastly execute code of a different access right (with a higher required privilege).

How can the vulnerability be exploited? Basically by generating a #GP exception while in hypervision code execution (in this example of the link above), as known, generating a exception can lead you to overwrite the stack frame with your own values (in this case), and then control the RIP using the same privileges as the hypervision mode. To generate the exception, the RCX needs to be changed to a non-canonical value (in 64 bit mode, addresses are not completely made in 64 bit format, but 48 bit, that is, a canonical address), the SYSRET does not check if the address provided by RCX is a valid address (canonical), and then the exception is generated before the access right is changed to the guest mode privileges (on AMD processors, the #GP exception is generated after the privilege changed), making it possible to change the stack frame and execute your code in hypervision mode. This vulnerability is useful to make rootkits to escalate privileges to NT SYSTEM, like in the following technique, where it shows how to change the token pointers of a program to the SYSTEM token (pid 4).

https://mcdermottcybersecurity.com/articles/x64-kernel-privilege-escalation


Here is a POC of SYSRET:

https://github.com/shahriyarj/sysret

The Feng Shui and Plunger techniques are, as written here, methods to allocate all the buffers freed in the garbage collector, making sure the next heaps will come from the system heap. The article below shows an interesting exploit, using not only this technique, but the lookaside-list to make a fake vtable and get code execution through a virtual function call.

https://www.phreedom.org/research/heap-feng-shui/heap-feng-shui.html

A simple technique against SEHOP mitigation. This Microsoft mitigation some additional verifications in order to avoid SEH corruption and SEH-based exploits, but under certain conditions, it can be bypassed. As this article explains, you need to create a fake SEH to bypass the verification (made by RtlIsValidHandler), so you will need to recreate the chain , putting a 0xFFFFFFFF and a pointer to ntdll!FinalExceptionHandler in the last exception handler (EH), otherwise the exploit will fail, since you made all the chain, you will need to find a pointer to the last EH (containing the 0xFFFFFFFF etc), this pointer needs to be a valid instruction too, because since we need to point to the next handler, the pop pop ret will return exactly to this pointer, making it executable, fortunately we are free to put any value in the 2 last bytes of this pointer, so we can make a conditional JMP (0xFF74 in the POC) to another JMP (before the pointer, this one will lead us to another JMP next to the shellcode and before the last EH), and lastly this JMP will fall in the shellcode . The first JMP is necessary to making our first pointer simple and easy to adjust, and because you probably could not use this pointer to jump directly to the shellcode or to the next handler of the last EH, since this JMP aka pointer is limited, we use another JMP before the pointer and it leads to another JMP (i don't know if this one is necessary, if the first one can jump into the shellcode, you won't need the second one). The real problem about this article is the pointer to the ntdll!FinalExceptionHandler, Windows has ASLR and you can't simple guess this function address, so this technique would be suitable under these conditions (i think):

- You don't need to full overwrite the stack to make an exception, this way you can put the shellcode before the last EH (since you can set the displacement between the first and the last EH) and make a JMP into it;
- You can somehow get the address of ntdll!FinalExceptionHandler and put it in the last EH.

https://index-of.es/EBooks/sehop_en.pdf

A post about flink and blink structures. This is not related to exploits or hacking, since the site focuses on kernel structures and Windows, but it can be useful for hacking (eg: heap exploitation). Basically it is a list where the flink points to the next entry, and blink points to the entry backwards, if the structure is empty, the blink and flink will point to themselves. Often used in drivers to store data.

https://bsodtutorials.blogspot.com/2013/10/linked-lists-flink-and-blink.html?m=1

Another post about linked lists.

https://www.osronline.com/article.cfm%5Earticle=499.htm

How a group of hackers (FIN7) used SHIM databases to inject a malicious DLL in services.exe. I really liked this method, the SHIM implementation and SHIM databases made by Microsoft patch executables through in-memory patches, when the .exe is loaded into memory (the same for drivers), this malware uses a SDB file with the 2nd stage code inside, and modifies the registry keys that store the SDB path for an application, this way when services.exe is loaded, Windows checks if there is any .sdb file for it, if so, the application is patched with the code inside it, in this case the code patched is ScRegisterTCPEndpoint function, when the function is called, the program decompresses and reads the shellcode stored in the registry HKLM\SOFTWARE\Microsoft\DRM, then it sleeps for 4 minutes and loads a new process named svchost.exe with the malware's DLL.

https://www.fireeye.com/blog/threat-research/2017/05/fin7-shim-databases-persistence.html