-
Posts
18712 -
Joined
-
Last visited
-
Days Won
701
Everything posted by Nytro
-
Get your root access here By Dan Goodin in San Francisco 15th September 2010 18:21 GMT The Linux kernel has been purged of a bug that gave root access to untrusted users – again. The vulnerability in a component of the operating system that translates values from 64 bits to 32 bits (and vice versa) was fixed once before – in 2007 with the release of version 2.6.22.7. But several months later, developers inadvertently rolled back the change, once again leaving the OS open to attacks that allow unprivileged users to gain full root access. The bug was originally discovered by the late hacker Wojciech "cliph" Purczynski. But Ben Hawkes, the researcher who discovered the kernel regression bug, said here that he grew suspicious when he recently began tinkering under the hood of the open-source OS and saw signs the flaw was still active. “I showed this to my friend Robert Swiecki who had written an exploit for the original bug in 2007, and he immediately said something along the lines of 'well this is interesting,'” Hawkes wrote. “We pulled up his old exploit from 2007, and with a few minor modifications to the privilege escalation code, we had a root shell.” No doubt, Linux fans will be quick to point out that the bug can be exploited only by those with a valid account on a targeted machine in the first place. This is true, but the existence of vulnerabilities like these are a big deal in corporate, government and educational environments, where Linux is a mainstay has a large following. Add privilege escalation to the mix and things like protected mode, integrity levels, and chroot – often the very reason the OS was chosen in the first place – are largely wiped out. The oversight means that untrusted users with, say, limited SSH access have a trivial means to gain unfettered access to pretty much any 64-bit installation. Consider, too, that the bug has been allowed to fester in the kernel for years and was already fixed once before and we think a measured WTF is in order. It was one of two privilege-elevation vulnerabilities Hawkes disclosed on Wednesday in the Linux 32-bit compatibility mode. The official updates are here, here and here. ®
-
Probabil o sa apara si acest patch in cine stie ce versiune urmatoare de kernel: --- a/fs/xfs/xfs_dir2_data.h 2010-09-02 11:13:11.632007536 +0300 +++ b/fs/xfs/xfs_dir2_data.h 2010-09-02 11:13:28.080006488 +0300 @@ -87,7 +87,7 @@ typedef struct xfs_dir2_data_entry { __be64 inumber; /* inode number */ __u8 namelen; /* name length */ - __u8 name[1]; /* name bytes, no null */ + __u8 name[2]; /* name bytes, no null */ /* variable offset */ __be16 tag; /* starting offset of us */ } xfs_dir2_data_entry_t; E vorba de un vector cu un singur element, dar se folosesc doua elemente, si apare o eroare urata. Se foloseste name[1] cand nu exista decat name[0]. Si acum discut cu cu Alex Elder, maintainer-ul, despre un alt patch dar pe acela nu l-am trimis cum trebuia. Edit: Va fi reparat si celalalt bug, e cam prostie avertismentul generat: fs/xfs/xfs_alloc.c: In function ‘xfs_alloc_ag_vextent_near’: fs/xfs/xfs_alloc.c:694:15: warning: ‘ltlena’ may be used uninitialized in this function fs/xfs/xfs_alloc.c:683:15: warning: ‘gtlena’ may be used uninitialized in this function Acele variabile sunt initializate in niste expresii conditionate, de aceea apare acel avertisment, insa in practica nu e nici o problema. Dar e urat sa apara astfel de erori la compilarea kernelului. Rezolvarea e banala, initializarea acelor variabile cu 0.
-
Daca stiti C++ cea mai buna solutie e sa aruncati o privire peste libpurple.
-
Uite ca exista si oameni care nu cer bani pentru orice. Mutat la Stuff tools, aici o sa "dispara" repede.
-
De vreo 5 luni folosesc si eu aproape numai Linux (am folosit Windows cat am scris articolul despre Winsock API). Si imi place libertatea oferita. Bine, mai opresc eu servicii fara sa ma interesez ce rost au si mai stric cate ceva, dar am invatat cum sta treaba. Oricum, nu place Gnome deloc la mine, KDE rullz.
-
How To Crack WEP and WPA Wireless Networks Autor: Habar n-am With the popularity of wireless networks and mobile computing, an overall understanding of common security issues has become not only relevant, but very necessary for both home/SOHO users and IT professionals alike. This article is aimed at illustrating current security flaws in WEP/WPA/WPA2. Successfully cracking a wireless network assumes some basic familiarity with networking principles and terminology, as well as working with command-line tools. A basic familiarity with Linux can be helpful as well. Disclaimer: Attempting to access a network other than your own, or one you have permission to use is illegal insome U.S. jurisdictions. Speed Guide, Inc. are not to be held liable for any damages resulting from the use or misuse of the information in this article. To successfully crack WEP/WPA, you first need to be able to set your wireless network card in "monitor" mode to passively capture packets without being associated with a network. This NIC mode is driver-dependent, and only a relatively small number of network cards support this mode under Windows. One of the best free utilities for monitoring wireless traffic and cracking WEP/WPA-PSK keys is the aircrack-ng suite, which we will use throughout this article. It has both Linux and Windows versions (provided your network card is supported under Windows). The aircrack-ng site has a comprehensive list of supported network cards available here: NIC chipset compatability list. If your network card is not supported under Windows, one can use a free Linux Live CD to boot the system. BackTrack 3 is probably the most commonly used distribution, since it runs from a Live CD, and has aircrack-ng and a number of related tools already installed. For this article, I am using aircrack-ng version 1.0 on a Linux partition (Fedora Core 10, 2.6 32-bit kernel) on my Sony Vaio SZ-680 laptop, using the built-in Intel 4965agn network card. If you're using the BackTrack 3 CD aircrack-ng is already installed, with my version of linux it was as simple as finding it with: yum search aircrack-ng yum install aircrack-ng The aircrack-ng suite is a collection of command-line programs aimed at WEP and WPA-PSK key cracking. The ones we will be using are: airmon-ng - script used for switching the wireless network card to monitor mode airodump-ng - for WLAN monitoring and capturing network packets aireplay-ng - used to generate additional traffic on the wireless network aircrack-ng - used to recover the WEP key, or launch a dictionary attack on WPA-PSK using the captured data. 1. Setup (airmon-ng) As mentioned above, to capture network traffic wihtout being associated with an access point, we need to set the wireless network card in monitor mode. To do that under linux, in a terminal window (logged in as root), type: iwconfig (to find all wireless network interfaces and their status) airmon-ng start wlan0 (to set in monitor mode, you may have to substitute wlan0 for your own interface name) Note: You can use the su command to switch to a root account. Other related Linux commands: ifconfig (to list available network interfaces, my network card is listed as wlan0) ifconfig wlan0 down (to stop the specified network card) ifconfig wlan0 hw ether 00:11:22:33:44:55 (change the MAC address of a NIC - can even simulate the MAC of an associated client. NIC should be stopped before chaning MAC address) iwconfig wlan0 mode monitor (to set the network card in monitor mode) ifconfig wlan0 up (to start the network card) iwconfig - similar to ifconfig, but dedicated to the wireless interfaces. 2. Recon Stage (airodump-ng) This step assumes you've already set your wireless network interface in monitor mode. It can be checked by executing the iwconfig command. Next step is finding available wireless networks, and choosing your target: airodump-ng mon0 - monitors all channels, listing available access points and associated clients within range. It is best to select a target network with strong signal (PWR column), more traffic (Beacons/Data columns) and associated clients (listed below all access points). Once you've selected a target, note its Channel and BSSID (MAC address). Also note any STATION associated with the same BSSID (client MAC addresses). running airodump-ng displays all wireless access points and associated clients in range, as well as MAC addresses, SSIDs, signal levels and other information about them. WEP is much easier to crack than WPA-PSK, as it only requires data capturing (between 20k and 40k packets), while WPA-PSK needs a dictionary attack on a captured handshake between the access point and an associated client which may or may not work. 3. Capture Data (airodump-ng) To capture data into a file, we use the airodump-ng tool again, with some additional switches to target a specific AP and channel. Most importantly, you should restrict monitoring to a single channel to speed up data collection, otherwise the wireless card has to alternate between all channels. Assuming our wireless card is mon0, and we want to capture packets on channel 6 into a text file called data: airodump-ng -c 6 bssid 00:0F:CC:7D:5A:74 -w data mon0 (-c6 switch would capture data on channel 6, bssid 00:0F:CC:7D:5A:74 is the MAC address of our target access point, -w data specifies that we want to save captured packets into a file called "data" in the current directory, mon0 is our wireless network adapter) Running airodump-ng on a single channel targeting a specific access point Notes: You typically need between 20,000 and 40,000 data packets to successfully recover a WEP key. One can also use the "--ivs" switch with the airodump-ng command to capture only IVs, instead of whole packets, reducing the required disk space. However, this switch can only be used if targeting a WEP network, and renders some types of attacks useless. 4. Increase Traffic (aireplay-ng) - optional step for WEP cracking An active network can usually be penetrated within a few minutes. However, slow networks can take hours, even days to collect enough data for recovering the WEP key. This optional step allows a compatible network interface to inject/generate packets to increase traffic on the wireless network, therefore greatly reducing the time required for capturing data. The aireplay-ng command should be executed in a separate terminal window, concurrent to airodump-ng. It requires a compatible network card and driver that allows for injection mode. Assuming your network card is capable of injecting packets, in a separate terminal window try: aireplay-ng -3 -b 00:0F:CC:7D:5A:74 -h 00:14:A5:2F:A7:DE -x 50 wlan0 -3 --> this specifies the type of attack, in our case ARP-request replay -b ..... --> MAC address of access point -h ..... --> MAC address of associated client from airodump -x 50 --> limit to sending 50 packets per second wlan0 --> our wireless network interface aireplay-ng allows for injecting packets to greatly reduce the time required to recover a WEP key Notes: To test whether your nic is able to inject packets, you may want to try: aireplay-ng -9 wlan0. You may also want to read the information available -here-. To see all available replay attacks, type just: aireplay-ng 5. Crack WEP (aircrack-ng) WEP cracking is a simple process, only requiring collection of enough data to then extract the key and connect to the network. You can crack the WEP key while capturing data. In fact, aircrack-ng will re-attempt cracking the key after every 5000 packets. To attempt recovering the WEP key, in a new terminal window, type: aircrack-ng data*.cap (assuming your capture file is called data...cap, and is located in the same directory) aircrack-ng can successfully recover a WEP key with 10-40k captured packets. The retreived key is in hexadecimal, and can be entered directly into a wireless client omitting the ":" separators Notes: If your data file contains ivs/packets from different access points, you may be presented with a list to choose which one to recover. Usually, between 20k and 40k packets are needed to successfully crack a WEP key. It may sometimes work with as few as 10,000 packets with short keys. 6. Crack WPA or WPA2 PSK (aircrack-ng) WPA, unlike WEP rotates the network key on a per-packet basis, rendering the WEP method of penetration useless. Cracking a WPA-PSK/WPA2-PSK key requires a dictionary attack on a handshake between an access point and a client. What this means is, you need to wait until a wireless client associates with the network (or deassociate an already connected client so they automatically reconnect). All that needs to be captured is the initial "four-way-handshake" association between the access point and a client. Essentially, the weakness of WPA-PSK comes down to the passphrase. A short/weak passphrase makes it vulnerable to dictionary attacks. To successfully crack a WPA-PSK network, you first need a capture file containing handshake data. This can be obtained using the same technique as with WEP in step 3 above, using airodump-ng. You may also try to deauthenticate an associated client to speed up this process of capturing a handshake, using: aireplay-ng --deauth 3 -a MAC_AP -c MAC_Client mon0 (where MAC_IP is the MAC address of the access point, MAC_Client is the MAC address of an associated client, mon0 is your wireless NIC). Once you have captured a four-way handshake, you also need a large/relevant dictinary file (commonly known as wordlists) with common passphrases. See related links below for some wordlist links. You can, then execute the following command in a linux terminal window (assuming both the dictionary file and captured data file are in the same directory): aircrack-ng -w wordlist capture_file (where wordlist is your dictionary file, and capture_file is a .cap file with a valid WPA handshake) Additional Notes: Cracking WPA-PSK and WPA2-PSK only needs 4 packets of data from the network (a handshake). After that, an offline dictionary attack on that handshake takes much longer, and will only succeed with weak passphrases and good dictionary files. A good size wordlist should be 20+ Megabytes in size, cracking a strong passphrase will take hours and is CPU intensive. Cracking WPA/WPA2 usually takes many hours, testing tens of millions of possible keys for the chance to stumble on a combination of common numerals or dictionary words. Still, a weak/short/common/human-readable passphrase can be broken within a few minutes using an offline dictionary attack. My record time was less than a minute on an all-caps 10-character passphrase using common words with less than 11,000 tested keys! A modern laptop can process over 10 Million possible keys in less than 3 hours. WPA hashes the network key using the wireless access point's SSID as salt. This prevents the statistical key-grabbing techniques that broke WEP, and makes hash precomputation more dificult because the specific SSID needs to be added as salt for the hash. There are some tools like coWPAtty that can use precomputed hash files to speed up dictionary attacks. Those hash files can be very effective (sicne they're much less CPU intensive and therefore faster), but quite big in size. The Church of WiFi has computed hash tables for the 1000 most common SSIDs against a million common passphrases that are 7Gb and 33Gb in size...
-
Eu aveam ceva incredere in femei, dar de ceva (mai mult) timp nu mai am. Nu merita decat muie majoritatea. De fapt, nu pentru asta sunt ele facute?
-
Trebuie sa implementezi protocolul YMSG. Si faci asta pe un server care ruleaza non-stop. Creezi un ID, il loghezi, si in functie de mesajele primite, faci anumite lucruri. De exemplu, daca zice cineva botului tau "vreme Cluj", cauti vremea in Cluj pe un site (CURL daca faci botul in PHP de exemplu) si trimiti vremea. Asta e ideea de baza.
-
Romania are si parti bune si parti rele. Sa prezinte si partile bune. Intre timp sa le dam la muie. Ce domenii (top level) au elvetienii astia? Edit: .ch
-
Eu fac sala, si muschii de la picioare se vad binisor, se vede destul de bine forma lor, si nu cred ca e necesar sa ma rad pentru a se vedea asta. Nu neaparat ca e "gay", dar parul e ceva barbatesc, la multi e singurul element care inseamna masculinitate, ca muschi nema, par nema, isi mai lasa si parul lung, si mai sunt si care se dau cu lac pe unchii sau alte rahaturi. Legat de ce spun fetele, 90% din cele pe care le cunosc, nu numai ca nu plac, dar nu suporta baietii care se rad pe picioare sau fac alte lucruri pe care le fac fetele. Cu alte cuvinte, astia care se rad pe picioare sau altceva, incet, incet o sa faca din ce in ce mai multe lucruri pe care le fac decat fetele, ajung sa se fardeze, si da, aveti dreptate, nu o sa fie gay ci travestiti. Unor fete le place, dar le place acelor fete carora le plac persoanele mai feminine, care le plac fetele mai mult decat normal ca sa spun asa. Am vazut multi care s-au ras, si sa fim seriosi, arata ca pula. Si asta nu ar fi singura problema. Baietii din ziua de azi se penseaza ca fetele, sprancene subtiri si nu numai. Unde o sa ajunga lumea asta? Daca vad picioarele cuiva si nu vad par pe ele cum imi dau seama daca e fata sau baiat? O sa inceapa sa se rada si pe maini si o sa ajungem o natie numai de "femei". Na, fiecare cu opinia lui, e o tara libera.
-
Florin Salam - V-am facut-o
-
Nu e Windows, e un alt sistem de operare. Si nu, in nici un caz nu e prentru jocuri. Nici pentru multimedia nu prea e.
-
Tu te razi pe picioare? Mie mi se pare gay, dar am vazut multi care au inceput sa se rada. Vreau doar sa vad daca mai mult de jumatate din cei care voteaza o fac.
-
Se vede acolo. Oricum, nu cred ca va ajuta cu ceva acum ca stiti in ce limbaj e scris.
-
Eu nu stiu ce sa mai cred despre ce zic "cercetatorii" astia. Rar se intampla cum "prevestesc" ei, mai bine ma duc la o ghicitoare si o intreb cat de frig o sa fie.
-
Cred ca s-a ajuns la 10 milioane. Da, contribuie foarte multi. Si cum spunea si el, Ubuntu nu contribuie mai cu nimic. Deci _|_ Ubuntu. RedHat si SUSE se implica mult, de asemenea si Intel si nu numai. La fel, Google nu sunt prea interesati, desi Android-ul "lor" e bazat pe acest kernel. Deci _|_ Google. Si lista poate continua.
-
Securitate in domeniul IT, nu ma intereseaza pe mine ca ninge cu 2 zile mai mult. Edit: Nu numai securitate, orice nou si interesant din domeniul IT.
-
Greg Kroah Hartman on the Linux Kernel L-am vazut si eu astazi, e interesant, multe lucruri bine de stiut despre kernel, cum se dezvolta, statistici si multe altele. Youtube: http://www.youtube.com/watch?v=L2SED6sewRw
-
Sursa: ApriorIT Wednesday, 17 March 2010 16:31 This article includes description of simple unhooker that restores original System Service Table hooked by unknown rootkits, which hide some services and processes. 1. SST: references 2. Algorithm 3. Memory mapped files 4. Implementation 5. Demonstration 6. How to build Written by: Victor Milokum, Development Leader of Network Security Team. 1. SST: references This article is a logical continuation to the article "Driver to Hide Processes and Files" by Ivan Romananko. You can find all necessary information about System Service Table (SST) and its hooking in it. In this article I would like to present how to write your own unhooker that will restore original SST hooked by drivers like Ivan's one. 2. Algorithm My goal is to write a simple driver for SST hooking detection and removing purposes. This means that our driver should not use various Zw-functions and SST table because I suppose that SST table is corrupted by unknown rootkits. I do not care about filter drivers and function code splicers for now, but maybe I will come back to them in future. The simplest way to detect and remove hooks is to compare SST that is placed in memory with the initial SST from ntoskernel.exe file. So the goal is: 1. to find ntoskernel module in memory; 2. to find the section of ntoskernel where SST is placed and to calculate relative offset of SST in the section; 3. to find this section in the ntoskernel.exe file; 4. to calculate real address of SST in the file; 5. to read values from the file and to compare them with SST. But before the implementation I would like to present some additional information. 3. Memory mapped files in kernel mode "A memory-mapped file is a segment of virtual memory which has been assigned a direct byte-for-byte correlation with some portion of a file or file-like resource". © Wiki Yeah, we want to parse the PE file and memory mapped files are very useful for this task. And it is easy enough to use mapped files API from the kernel mode, because it is very similar to Win32 API. Instead of CreateFileMapping and MapViewOfSection functions in kernel mode driver should access NTSTATUS ZwCreateSection( OUT PHANDLE SectionHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL, IN PLARGE_INTEGER MaximumSize OPTIONAL, IN ULONG SectionPageProtection, IN ULONG AllocationAttributes, IN HANDLE FileHandle OPTIONAL ); and NTSTATUS ZwMapViewOfSection( IN HANDLE SectionHandle, IN HANDLE ProcessHandle, IN OUT PVOID *BaseAddress, IN ULONG_PTR ZeroBits, IN SIZE_T CommitSize, IN OUT PLARGE_INTEGER SectionOffset OPTIONAL, IN OUT PSIZE_T ViewSize, IN SECTION_INHERIT InheritDisposition, IN ULONG AllocationType, IN ULONG Win32Protect ); functions. But if we use these functions we will break our own rule not to use SST. Also, it is good for antirootkit to use extremely low level functions in the hope of being invisible to the possible rootkits. With regard to this we can use undocumented functions of Memory Manager (Mm), of course at our own risk: NTSTATUS MmCreateSection ( OUT PVOID *SectionObject, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL, IN PLARGE_INTEGER MaximumSize, IN ULONG SectionPageProtection, IN ULONG AllocationAttributes, IN HANDLE FileHandle OPTIONAL, IN PFILE_OBJECT File OPTIONAL ); NTSTATUS MmMapViewOfSection( IN PVOID SectionToMap, IN PEPROCESS Process, IN OUT PVOID *CapturedBase, IN ULONG_PTR ZeroBits, IN SIZE_T CommitSize, IN OUT PLARGE_INTEGER SectionOffset, IN OUT PSIZE_T CapturedViewSize, IN SECTION_INHERIT InheritDisposition, IN ULONG AllocationType, IN ULONG Protect ); NTSTATUS MmUnmapViewOfSection( IN PEPROCESS Process, IN PVOID BaseAddress ); NTSTATUS drv_MapAllFileEx(HANDLE hFile OPTIONAL, drv_MappedFile * pMappedFile, LARGE_INTEGER * pFileSize, ULONG Protect) { NTSTATUS status = STATUS_SUCCESS; PVOID section = 0; PCHAR pData=0; LARGE_INTEGER offset; offset.QuadPart = 0; // check zero results if (!pFileSize->QuadPart) goto calc_exit; status = MmCreateSection (§ion, SECTION_MAP_READ, 0, // OBJECT ATTRIBUTES pFileSize, // MAXIMUM SIZE Protect, 0x8000000, hFile, 0 ); if (status!= STATUS_SUCCESS) goto calc_exit; status = MmMapViewOfSection(section, PsGetCurrentProcess(), (PVOID*)&pData, 0, 0, &offset, &pFileSize->LowPart, ViewUnmap, 0, Protect); if (status!= STATUS_SUCCESS) goto calc_exit; calc_exit: if (NT_SUCCESS(status)) { pMappedFile->fileSize.QuadPart = pFileSize->QuadPart; pMappedFile->pData = pData; pMappedFile->section = section; } else { if (pData) MmUnmapViewOfSection(PsGetCurrentProcess(), pData); if (section) { ObMakeTemporaryObject(section); ObDereferenceObject(section); } } return status; } This example demonstrates an alternative approach to the usage of mapped files through MmCreateSection/MmMapViewOfSection functions. The presented approach is pretty good because it doesn’t utilize Zw* functions and even handles at all, but it has one restriction. If you start this sample from DriverEntry it will work fine, but if you start it from the IRP_MJ_DEVICE_CONTROL handler you will see that MmCreateSection function fails with STATUS_ACCESS_DENIED. Why? The answer is: Zw* functions do one good thing - they set previous mode to KernelMode and this allows to utilize kernel mode pointers and handles as parameters for them (for more information see Nt vs. Zw - Clearing Confusion On The Native API article) So, the presented above function can be called only from DriverEntry or from the system thread. 4. Algorithm implementation I designed the following structure to save all ntoskernel parsing results: #define IMAGE_SIZEOF_SHORT_NAME 8 typedef struct _Drv_VirginityContext { drv_MappedFile m_mapped; HANDLE m_hFile; UCHAR m_SectionName[IMAGE_SIZEOF_SHORT_NAME+1]; ULONG m_sstOffsetInSection; char * m_mappedSST; ULONG m_imageBase; char * m_pSectionStart; char * m_pMappedSectionStart; char * m_pLoadedNtAddress; }Drv_VirginityContext; And I implemented the chosen algorithm as follows: static NTSTATUS ResolveSST(Drv_VirginityContext * pContext, SYSTEM_MODULE * pNtOsInfo) { PIMAGE_SECTION_HEADER pSection = 0; PIMAGE_SECTION_HEADER pMappedSection = 0; NTSTATUS status = 0; PNTPROC pStartSST = KeServiceDescriptorTable->ntoskrnl.ServiceTable; char * pSectionStart = 0; char * pMappedSectionStart = 0; // Drv_ResolveSectionAddress function detects // to which section pStartSST belongs // pSection will contain the section of ntoskernel.exe that contains SST pContext->m_pLoadedNtAddress = (char*)pNtOsInfo->pAddress; status = Drv_ResolveSectionAddress(pNtOsInfo->pAddress, pStartSST, &pSection); if (!NT_SUCCESS(status)) goto clean; // save section name to context memcpy(pContext->m_SectionName, pSection->Name, IMAGE_SIZEOF_SHORT_NAME); // calculate m_sstOffsetInSection - offset of SST in section pSectionStart = (char *)pNtOsInfo->pAddress + pSection->VirtualAddress; pContext->m_sstOffsetInSection = (char*)pStartSST - pSectionStart; // find section in mapped file - on disk! status = Drv_FindSection(pContext->m_mapped.pData, pSection->Name, &pMappedSection); if (!NT_SUCCESS(status)) goto clean; pMappedSectionStart = (char *)pContext->m_mapped.pData + pMappedSection->PointerToRawData; pContext->m_mappedSST = pMappedSectionStart + pContext->m_sstOffsetInSection; { // don´t forget to save ImageBase PIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)pContext->m_mapped.pData; PIMAGE_NT_HEADERS pNTHeader = (PIMAGE_NT_HEADERS)((char*)dosHeader + dosHeader->e_lfanew); pContext->m_imageBase = pNTHeader->OptionalHeader.ImageBase; } pContext->m_pSectionStart = pSectionStart; pContext->m_pMappedSectionStart = pMappedSectionStart; clean: return status; } And here is the function that returns real value of SST: void Drv_GetRealSSTValue(Drv_VirginityContext * pContext, long index, void ** ppValue) { char * pSST = pContext->m_mappedSST; ULONG * pValue = ((ULONG *) pSST) + index; // now pValue points to the mapped SST entry // but entry contains offset from the beginning of ntoskernel file, // so correct it *ppValue = (void*)(*pValue + (ULONG)pContext->m_pLoadedNtAddress – pContext->m_imageBase); } After that it is quite simple to implement main functionality: virtual NTSTATUS ExecuteReal() { CAutoVirginity initer; NT_CHECK(initer.Init(&m_virginityContext)); // now we are ready to scan for(int i = 0, sstSize = Drv_GetSizeOfNtosSST(); i < sstSize; ++i) { void ** pCurrentHandler = Drv_GetNtosSSTEntry(i); void * pRealHandler = 0; Drv_GetRealSSTValue(&m_virginityContext, i, &pRealHandler); if (pRealHandler != *pCurrentHandler) { // oops, we found the difference! // unhook this entry Drv_HookSST(pCurrentHandler, pRealHandler); } } return NT_OK; } This tiny cycle completely removes all SST hooks and brings SST to its initial state. 6. Demonstration For testing purposes I developed simple console utility named unhooker.exe. This utility can be started without parameters; in this case it shows information about its abilities: 1. “stat” command shows statistics about SST hooking; 2. “unhook” command cleans SST; This sample demonstrates how to use utility to detect and erase hooks: Have fun! 6. How to build Build steps are the same as in the “Hide Driver” article. They are: 1. Install Windows Driver Developer Kit 2003 - Windows Server 2003 DDK 2. Set global environment variable "BASEDIR" to path of installed DDK. Go here: Computer -> Properties -> Advanced -> Environment variables ->System Variables -> New And set it like this: BASEDIR -> c:\winddk\3790 (You have to restart your computer after this.) If you choose Visual Studio 2003, then you can simply open UnhookerMain.sln and build all. Download: http://www.apriorit.com/downloads/unhook/release.zip http://www.apriorit.com/downloads/unhook/src.zip
-
Si eu pateam asa, dar de la un timp merge.
-
Despre ce fel de baza de date e vorba?
-
Exista optiunea: "Disable smilies in text"
-
Cel mai jegos site posibil. Astia copiau exploituri de pe milw0rm (sa nu mai spun ca au folosit un script asemanator) si ziceau ca sunt gasite de ei. Ratati. Abyssesc astia sunt chiar buni. In fiecare zi cate 2 buguri in aplicatii mari, cunoscute. Bine, am testat si eu cateva exploituri ale lor si nu au mers, si am inteles ca nu sunt singurul caruia nu ii merg.
-
Mai bine: http://www.exploit-db.com/archive.tar.bz2