Nytro

[h=1]zANTI 2.0 - Android Network Toolkit [/h] Lydecker Black on 3:14 PM zANTI is a mobile penetration testing toolkit that lets security managers assess the risk level of a network with the push of a button. This easy to use mobile toolkit enables IT Security Administrators to simulate an advanced attacker to identify the malicious techniques they use in the wild to compromise the corporate network. Scan Uncover authentication, backdoor, and brute-force attacks, DNS and protocol-specific attacks and rogue access points using a comprehensive range of full customizable network reconnaissance scans. Diagnose Enable Security Officers to easily evaluate an organization’s network and automatically diagnose vulnerabilities within mobile devices or web sites using a host of penetration tests including, man-in-the-Middle (MITM), password cracking and metasploit. Report Highlight security gaps in your existing network and mobile defenses and report the results with advanced cloud-based reporting through zConsole. zANTI mirrors the methods a cyber-attacker can use to identify security holes within your network. Dash-board reporting enables businesses to see the risks and take appropriate corrective actions to fix critical security issues. Download zANTI 2.0 Sursa: zANTI 2.0 - Android Network Toolkit | KitPloit - PenTest Tools for your Security Arsenal!

[h=1]AutoScan-Network - Automatically scan your network [/h] Lydecker Black on 11:26 PM AutoScan-Network is a network scanner (discovering and managing application). No configuration is required to scan your network. The main goal is to print the list of connected equipments in your network. System Requirements : •Mac OS X 10.5 or later •Microsoft Windows (XP, Vista) •GNU/Linux •Maemo 4 •Sun OpenSolaris Features: • Fast network scanner • Automatic network discovery • TCP/IP scanner • Wake on lan functionality • Multi-threaded Scanner • Port scanner • Low surcharge on the network • VNC Client • Telnet Client • SNMP scanner • Simultaneous subnetworks scans without human intervention • Realtime detection of any connected equipment • Supervision of any equipment (router, server, firewall...) • Supervision of any network service (smtp, http, pop, ...) • Automatic detection of known operatic system (brand and version), you can also add any unknown equipment to the database • The graphical interface can connect one or more scanner agents (local or remote) • Scanner agents could be deployed all over the network to scan through any type of equipment (router, NAT, etc) • Network Intruders detection (in intruders detection mode, all new equipments blacklisted) • Complete network tree can be saved in a XML file. • Privileged account is not required Download AutoScan-Network Sursa: AutoScan-Network - Automatically scan your network | KitPloit - PenTest Tools for your Security Arsenal!

[h=1]subdomain-bruteforcer (SubBrute)[/h] SubBrute is a community driven project with the goal of being the fastest, and most accurate subdomain enumeration tool. Some of the magic behind SubBrute is that it uses open revolvers as a kind of proxy to circumvent DNS rate-limiting (https://www.us-cert.gov/ncas/alerts/TA13-088A). This design also provides a bit of anonymity, as SubBrute does not send traffic directly to the target's name servers. Sursa: https://github.com/TheRook/subbrute/blob/master/README.md

Decrypt stored passwords from Firefox, Chrome and Internet Explorer with C# and .NET Mladen Stanisic, 28 Dec 2014 CPOL How to retrieve passwords stored in Firefox, Chrome and Internet Explorer programmatically in C# Introduction Modern internet browsers offer user to save user name/password while logging to sites. Some third party applications can be used to extract this information. These applications are written in C++, and the source code I ran into while searching for answer on how it's done is mostly in C++. Although I searched thoroughly for the answer on how to do this in C#, I didn't find complete solution for all the three. This article explains how to do this programmaticaly in C# with .NET 2.0 and for all three most popular browsers: Firefox, Chrome and IE. Background The way passwords are stored in browsers is thoroughly explained by Jordan Wright's excellent article in his blog on Raider Security which can be found here. His article also provide many usefull links for further insights. Especially useful are articles on password security SecurityXploaded site. For the purpose of this article it is enough to say that Google Chrome stores passwords in a file Login Data in %LOCALAPPDATA%\Google\Chrome\User Data\Default\ folder which is basically an SQLite database; Firefox stores login data in %APPDATA%\Mozilla\Firefox\Profiles\{profile name}\ folder in logins.json file, and older versions used to store data in signons.sqlite file, which is SQLite database and is not used anymore. Internet Explorer store its autocomplete passwords in Registry, in HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 key. Articol complet: Decrypt stored passwords from Firefox, Chrome and Internet Explorer with C# and .NET - CodeProject

Introduction to HTML5 WebSockets Vangos Pterneas, 27 Dec 2014 This blog post is based on my book “Getting Started with HTML5 WebSocket Programming“, published a few months ago. There’s a special holiday offer for you until the 6th of January. What is the HTML5 WebSocket protocol? In real life, handshaking is the act of gently grasping two peo This blog post is based on my book “Getting Started with HTML5 WebSocket Programming“, published a few months ago. There’s a special holiday offer for you until the 6th of January. What is the HTML5 WebSocket protocol? In real life, handshaking is the act of gently grasping two people’s hands, followed by a brief up and down movement. If you have ever greeted someone this way, then you already understand the basic concept of HTML5 WebSockets. WebSockets define a persistent two-way communication between web servers and web clients, meaning that both parties can exchange message data at the same time. WebSockets introduce true concurrency, they are optimized for high performance and result in much more responsive and rich web applications. The WebSocket protocol is all about speed: it aims to replace the traditional polling, long-polling and AJAX calls with a native mechanism. The WebSocket protocol is part of HTML5. HTML5 is a robust framework for developing and designing web applications. It is not just a new markup or some new styling selectors, neither it is a new programming language. HTML5 stands for a collection of technologies, programming languages and tools, each of which has a discrete role and all together accomplish a specific task: building rich web apps for any kind of device. The main HTML5 pillars include Markup, CSS3 and JavaScript APIs. Together. Unlike what its name implies, the WebSocket protocol is not only about the web! The specification has been implemented from the mainstream mobile and tablet operating systems, including iOS, Android, and Windows. That means you can use the power and speed of the WebSocket protocol into a native smartphone or tablet app. The core principles remain the same, regardless of whether you use JavaScript, Objective-C, or C#. Throughout this article, we are going to implement a simple chatting web app using WebSockets. No AJAX, no polling, no refresh, no waiting. Here’s the end-result: <iframe src="http://www.youtube.com/embed/MlbAWEwmQhA"></iframe> Download the source code from GitHub Articol complet: Introduction to HTML5 WebSockets - CodeProject

New challenges We added several new challenges: ls, radio heat, Rick, Roll, crackme, code_mess and cairo. Have fun! CTF is live! The CTF is live. More challenges will be added later on. We will announce those here and on IRC. Good luck and have fun! Registration Online Hi CTFers, we're happy to announce the 31C3 CTF, which StratumAuhuur will organize during the Chaos Communication Congress in Hamburg. This Jeopardy style CTF is open to everyone and can be played online. It will start on Dec. 27, 20:00 UTC and last 48h until Dec. 29, 20:00 UTC. As always, don't try to ruin other people's fun. IRC: #31c3ctf@hackint.eu Twitter: @stratumauhuur We hope to see you soon, StratumAuhuur Link: https://31c3ctf.aachen.ccc.de/announcements/

Vreti sa vedeti asta: Relive! – 31C3 Streaming Ca sa stiti despre ce e vorba: - cum se poate localiza un telefon avand doar numarul de telefon - cum se pot intercepta apeluri si mesaje (fara bruteforce pe cheile de encriptie) - cum se poate deconecta de la retea (denial of service) - cum se pot executa coduri USSD (stiti voi *100# ...) Prezentarea TREBUIE vazuta.

Relive: Relive! – 31C3 Streaming (prezentarile inregistrate) Nu uitati ca sunt prezentari si azi, maine si poimaine. Programul il aveti aici: https://events.ccc.de/congress/2014/Fahrplan/schedule/1.html

Keyloggers: Implementing keyloggers in Windows. Part Two By Nikolay Grebennikov on June 29, 2011. 12:15 pm Publications Keyloggers: How they work and how to detect them (Part 1) This article is a continuation of the previous report on keyloggers. It offers a detailed analysis of the technical aspects and inner workings of keyloggers. As was noted in the first article, keyloggers are essentially designed to be injected between any two links in the chain whereby a signal is transmitted from a key being pressed to symbols appearing on the screen. This article provides both an overview of which links exist in this chain, and how both software and hardware keyloggers work. This article is written for technical specialists and experienced users. Other users, who are not part of this target group, should simply be aware that Windows offers a multitude of ways in which data entered via the keyboard can be harvested, although the vast majority of keyloggers only use two of these methods (see: Designing keyloggers, the first part of the article). It should be stressed that this article does not include any keylogger source code; we do not share the opinion of some researchers who believe it is acceptable to publish such code. Instead, we focus on understanding how keyloggers work, so we can better implement effective protection against them. Processing data entered via the keyboard in Windows There are several basic technologies which can be used to intercept keystrokes and mouse events, and many keyloggers use these technologies. However, before examining specific types of keylogger, it's necessary to understand how data entered via the keyboard is processed by Windows. To describe the process - from a key being pressed on the keyboard to the keyboard system interrupt controller being activated and an active WM_KEYDOWN message appearing, three sources have been used: "Apparatnoe obeshpechenie IBM PC" by Alexander Frolov and Grigory Frolov, Volume 2, Book 1. Published by Dialog-MIFI, 1992. The second chapter, "The Keyboard" described how a keyboard functions, the ports used, and keyboard hardware interrupts; The section related to "HID / Human Input Devices" of the MSDN library, which describes the low-level (driver) part of the process by which keyboard input is processed; Jeffrey Richter's book 'Creating effective Win32 applications for 64-bit Windows". Chapter 27, "A model of hardware input and the local input condition" contains a description of the high level part of the process by which keyboard input is processed (in user mode). The keyboard as a physical device: how it works Today, the majority of keyboards are a separate device connected to the computer via a port - most frequently PS/2 or USB. There are two micro-controllers which support the processing of keyboard input data; one is part of the motherboard, the other is within the keyboard itself. Consequently, it could be said that a PC keyboard is itself a small computer system. It uses an 8042 microcontroller which constantly scans keys being pressed on the keyboard independently of central CPU activity. Each key on the keyboard has a specific number assigned to it; this is linked to keyboard matrix map and is not directly dependent on the value shown on the surface of the key itself. This number is called a "scan code" (the name highlights the fact that the computer scans the keyboard to search for keystrokes). Scan codes are random values which were selected by IBM back in the days when the company created the first keyboard for PCs. A scan code does not correspond to the ASCII code of a key; actually, a single key may correspond to several ASCII code values. A table of scan codes can be found in the twentieth chapter of "The Art of Assembly Language Programming". In actual fact, the keyboard generates two scan codes for each key: one for when the user presses the key, and another for when the user releases the key. The fact that there are two scan codes is important, as some keys only have a function when they are pressed and held (eg. Shift, Control or Alt). Fig. 1: The keyboard: a simplified scheme When the user presses a key on the keyboard, s/he closes an electrical circuit. As a result, when performing the next scan, the micro-controller detects that a specific key has been pressed, and sends the scan code of the key pressed to the central computer, together with an interrupt request. The same action is performed when the user releases the key that s/he has previously pressed. The second micro-controller receives the scan code, converts it, makes it accessible on the input/ output port 60h and then generates a central processor hardware interrupt. The handler which processes the interrupt can then get the scan code from the designated input/ output port. It should be noted that the keyboard contains an internal 16 byte buffer which it uses to exchange data with the computer. Low-level interaction with the keyboard via the input/ output port Interaction with the keyboard system controller takes place via the input/ output port 64h. Reading a byte from this port makes it possible to determine the status of the keyboard controller; writing a byte makes it possible to send a command to the controller. Interaction with the micro-controller within the keyboard itself takes places via the input/ output ports 60h and 64h. The 0 and 1 bits in the status byte (port 64h in read mode) make it possible to control the interaction: before writing data to these ports, bit 1 of port 64h should be 0. When data is read-accessible from port 60h, bit 1 of port 64h is equal to 1. The keyboard on/ off bits in the command byte (port 64h in write mode) determine whether or not the keyboard is active, and whether the keyboard controller will call a system interrupt when the user presses a key. Bytes written to port 60h are sent to the keyboard controller, while bytes written to port 64h are sent to the keyboard system controller. A list of permissible commands which can be sent to the keyboard controller can be found in, for example, "8042 Keyboard Controller IBM Technical Reference Manual" or in the twentieth chapter of "The Art of Assembly Language Programming". Bytes read from port 60h come from the keyboard. When reading, port 60h contains the scan code of the last key pressed, and in write mode this is used for extended management by the keyboard. When using port 60h in write mode, a program has the following additional options: Establishing a wait period before the keyboard goes into auto repeat mode Establishing the interval for generating scan codes in auto repeat mode Management of LEDs located on the outer surface of the keyboard - Scroll Lock, Num Lock, Caps Lock. To summarize, in order to read data entered via the keyboard, one only has to be able to read the values of input/ output port 60h and 64h. However, user-level applications in Windows are unable to work with ports; this function is fulfilled by operating system drivers. The architecture of "interactive input devices" So, what processes the hardware interrupts which are generated when data sent by the keyboard appears on port 60h? Clearly, it's done through the handler of the keyboard hardware interrupt IRQ 1. In Windows, this processing is conducted by the system driver i8042prt.sys. In contrast to MS DOS, when each system component was a law unto itself, as it were, in Windows all components are constructed in accordance with a clear architecture and work in accordance with strictly defined rules assigned by the program interface. So before examining i8042prt, let's take a look at the architecture of interactive input devices, within the confines of which all program components connected with the processing of keyboard (and 'mouse') input function. In Windows, devices which are used to manage operations on the computer are called 'interactive input devices'. A keyboard is one such device, together with the mouse, joysticks, trackballs, game controllers, wheels, virtual reality helmets etc. The architecture of interactive input devices is based on the USB Human Interface Device standard put forward by the USB Implementers Forum. However, this architecture is not limited to USB devices, and supports other input devices, such as Bluetooth keyboards, PS/2 keyboards and mice and devices connected to I/O port 201 (the gaming port). Later in this article we will examine how the driver stack and the device stack for a PS/2 keyboard are constructed (given that historically the PS/2 keyboard was the first type of device described above). USB keyboards use a range of elements which were introduced during the development of program support for PS/2 keyboards). Kernel mode drivers for PS/2 keyboards Driver stack for system input devices Regardless of how the keyboard is physically connected, keyboard drivers use keyboard class system drivers to process data. This happens regardless of the hardware used. Actually, these drivers are called class drivers because they support system requirements independent of the hardware requirements of a specific class of device. The corresponding functional driver (port driver) supports the execution of input/ output operations in correlation with the device being used. In x86 Windows this is implemented in a single system keyboard driver (i8042) and mouse driver. Fig 2.: Driver stack for system entry devices: keyboard and mouse Driver stack for Plug and Play PS/2 keyboards Fig 3. Driver stack for PS/2 keyboards The driver stack (from top to bottom): Kbdclass - high level filter driver, keyboard class; optional high level filter driver, keyboard class; i8042prt - functional keyboard driver root bus driver In Windows 2000 and older versions of Windows, the keyboard class driver is Kbdclass. The main tasks of this driver are: To support general and hardware-dependent operations of the device class To support Plug and Play, support power management and Windows Management Instrumentation (WMI) To support operations for legacy devices Simultaneous execution of operations from more than one device To implement the class service callback routine, which is called by the functional driver to transmit data from the device input buffer to the device driver data buffer. In Windows 2000 and older versions of Windows, the functional driver for input devices using the PS/2 port (keyboard and mouse) is the i8042prt driver. The main functions are as follows: To support hardware dependent simultaneous operations of PS/2 input devices (the keyboard and mouse share the input and output ports, but use different interrupts, Interrupt Service Routines (ISR) and procedures for terminating interrupt processing; To supporting Plug and Play, power management and Windows Management Instrumentation (WMI); To supporting operations for legacy devices; To call the class service callback routine for classes of keyboards and mice in order to transmit data from the input data buffer i8042prt to the device driver data buffer; To call a range of callback functions which can be implemented in high level driver filters for flexible management by a device Fig. 4: Hardware resources which use the i8042prt driver Figure 4 shows a list of the hardware resources which use the i8042prt driver. These can be viewed, for example, using DeviceTree (Downloads:DeviceTree), a utility developed by Open Systems Resources. If you've read the sections on 'The keyboard as a physical entity - how it works' and 'Low-level interaction with the keyboard via the input/ output ports" the values of the input/ output ports of 60h and 64h, and the hardware interrupt (IRQ) 1 will not come as any surprise. A new driver filter can be added above the keyboard class driver in the driver stack shown above in order to, for instance, perform specific processing of data entered via the keyboard. This driver should support the same processing of all types of input/ output requests and management commands (IOCTL) as the keyboard class driver. In such cases, before data is transmitted to the user mode subsystem, the data is passed for processing to this driver filter. Device stack for Plug and Play PS/2 keyboards Fig. 5: Configuration of device objects for Plug and Play PS/2 keyboards. Overall, the device stack (which more correctly should be called the device object stack) for a P/S2 keyboard is made up of: The physical device object (PDO), created by the driver bus (in this case, the PCI bus) - Device0000066; The functional device object (FDO), created and connected to the PDO by the i8042prt port - an unnamed object; Optional filter objects for the keyboard device, created by the keyboard driver filters, which are developed by third party developers; High level filter objects for the keyboard device class which are created by the Kbdclass class driver - DeviceKeyboardClass0. Processing keyboard input via applications Raw input thread (data received from the driver) The previous section gives examples of how keyboard stacks are constructed in kernel mode. This section takes a look at how data about keystrokes is transmitted by applications in user mode. The subsystem of Microsoft Win32 gets access to the keyboard by using the Raw Input Thread (RIT), part of the csrss.exe system process. On boot, the system creates the IRT and the system hardware input queue (SHIQ). The RIT opens the keyboard class device driver for exclusive use and uses the ZwReadFile function to send it an input/ output request (IRP) of the type IRP_MJ_READ. Having received the request, the Kbdclass driver flags it as pending, places it in the queue and returns a STATUS_PENDING code. The RIT has to wait until the IRP terminates, and in order to determine this it uses the Asynchronous Procedure Call or ACP. When the user presses or releases one of the keys, the keyboard system controller yields a hardware interrupt. The hardware interrupt processer calls a special procedure to process the IRQ 1 interrupt (the interrupt service routine, or ISR), which is registered in the system by the i8042prt driver. This procedure reads the data which has appeared from the internal keyboard controller queue. The processing of the hardware interrupt should be as quick as possible; because of this, the IRC places a Deferred Procedure Call (or DPC), l8042KeyboardlsrDpc and then terminates. As soon as is possible (the IRQL reverts to DISPATCH_LEVEL), the DPC is called by the system. At this moment the callback procedure KeyboardClassServiceCallback will be called, which is registered by the i8042 driver Kbdclass driver. KeyboardClassServiceCallback extracts the pending termination request (IRP) from its queue, completes the maximum amount of KEYBOARD_INPUT_DATA which provide all the information required about keys pressed and released and terminates the IRP. The raw input thread is activated again, processes the information received, and sends another IRP to the class driver, which will again be queued until the next key press/ release. This means that the keyboard stack always contains at least one pending termination request in the Kbdclass driver queue. Fig. 6: Sequence of requests from RIT to the keyboard driver Using a utility called IrpTracker, developed by the previously mentioned Open Systems Resources, it's possible to track the sequence of calls which takes place when keyboard input is processed. Fig. 7: Processing keyboard input in user mode How does RIT process incoming data? All incoming keyboard events are placed in the hardware input system queue, and are in turn transformed into Windows messages (e.g. WM_KEY*, WM_?BUTTON* or WM_MOUSEMOVE) and are then placed at the end of the virtualized input queue, or VIQ of the active thread. The key scan codes in the Windows messages are replaced by virtual key codes which correspond not to the location of keys on the keyboard but the action that this key performs (function that it fulfils). The mechanism for transforming codes depends on the current (active) keyboard layout, simultaneous pressing of keys (e.g. SHIFT) and other factors. When the user enters the system, the Windows Explorer process launches a thread which creates the task panel and the desktop (WinSta0_RIT). This thread binds to the RIT. If the user launches MS Word, then the MS WORD thread, having created a window, will immediately connect to the RIT. The Explorer process will then unhook from the RIT, as only one thread can be connected to RIT at any one time. When a key is pressed, the relevant element will appear in the SHIQ; this leads to the RIT becoming active, transforming the hardware input event into a message from the keyboard which will then be placed in the MS Word VIQ thread. Processing of messages by a specific window How does a thread process messages from the keyboard which have entered the thread's message queue? The standard message processing cycle usually looks like this: while(GetMessage(&msg, 0, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } Using the GetMessage function, keyboard events are extracted from the queue and redirected using the DispatchMessage function to the window procedure which processes messages for the window where input is currently focussed. The input focus is an attribute which can be assigned to a window created by an application or by Windows. If the window has an input focus, all keyboard messages from the system queue will reach the appropriate function of this window. An application can pass the input focus from one window to another, e.g. when another application is switched to using Alt+Tab. The TranslateMessage function is usually called prior to the DispatchMessage function. This function creates the 'symbolic' messages WM_CHAR, WM_SYSCHAR, WM_DEADCHAR and WM_SYSDEADCHAR using the WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, WM_SYSKEYUP messages as a base. These 'symbolic' messages are placed in the application message queue; however, it should be noted that the original keyboard messages are not deleted from this queue. Keyboard key status array One of the aims when developing the Windows hardware input model was to ensure resilience. Resilience is ensured by independent processing of input by threads; this prevents conflicts between threads. However, this is not enough to isolate threads from each other, and the system therefore supports an additional concept: local input status. Each thread has its own input condition, and information about this is stored in THREADINFO. The information includes data about the virtual queue thread, and a group of variables. This last contains management information about the input thread status. The following notifications are supported for the keyboard: which window is currently in the focus of the keyboard, which window is currently active, which keys are pressed and the status of the input cursor. Information about which keys are being pressed is saved to the synchronous status array of keys. This array is connected to the variables for the local input status of each thread. The array of asynchronous key status, which contains similar information, is shared by all threads. The arrays reflect the status of all keys at a given moment, and the GetAsyncKeyState function makes it possible to determine whether or not a specific key is being pressed at a given time. GetAsyncKeyState always returns 0 (i.e. not pressed) if it is called by a different thread (i.e. not the thread which created the window which is currently the focus of input status). The GetKeyState function differs from GetAsyncKeyState in that it returns the status of the keyboard at the moment when the most recent keyboard message is extracted from the thread queue. This function can be called at any time regardless of which window is currently in focus. Keyboard hooks The mechanism used to intercept events using specific functions (e.g. sending Windows messages, data input via the mouse or keyboard) in Microsoft Windows is called 'hooking'. This function can react to an event and, in certain cases, modify or delete events. Functions which receive notification of events are called filter functions; they differ from each other by which events they can intercept. In order for Windows to call a filter function, the function must be bound to a hook (for instance, to a keyboard hook). Binding one or more filter functions to a hook is called "setting a hook". An application can use the Win32 API SetWindowsHookEx and UnhookWindowsHookEx functions to set or remove filter functions. Some hooks can either be set across the system as a whole, or for a specific thread. To avoid conflicts if several filter functions are bound to a single hook, Windows implements a function queue; in such cases, the function most recently bound to the hook will be at the start of the queue, with the first function bound being at the end of the queue. The function filter queue (see figure 8) is managed by Windows itself, which simplifies the writing of filter functions and optimizes operating system productivity. The system also supports separate chains for each type of hook. A hook chain is a list of pointers to filter functions (specific callback functions determined by the application.) When an event linked to a particular type of hook takes place, the system consecutively sends the message for each type of filter function to the hook chain. The actions which filter functions may perform depend on the type of hook: some function can only track the appearance of an event, while others may modify message parameters or initiate message processing, by preventing the next filter function in the hook chain from being called, or the message processing function for the relevant window from being called. Figure 8. Filter function chain in Windows When one or more filter functions are bound to a hook and an event takes place which leads to the hook being activated, Windows calls the first function from the filter function queue. With this, its responsibility is over. The filter function is then responsible for calling the next function in the chain, and the Win32 API CallNextHookEx function is used to do this. The operating system supports several types of hooks, each of which provides access to one aspect of the Windows messaging process mechanism. Nearly all types of hooks are of potential interest to the creators of keyloggers: WH_KEYBOARD, WH_KEYBOARD_LL (hooking keyboard events when they are added to the thread event queue), WH_JOURNALRECORD and WH_JOURNALPLAYBACK (writing and producing keyboard and mouse events), WH_CBT (intercepting multiple events, including remote keyboard events from the system hardware input queue), WH_GETMESSAGE (intercepting an event from the thread event queue.) Processing Let's sum up all the information above on the procedure of keyboard input in a single algorithm: the algorithm of the passing of a signal from a key being pressed by the user to the appearance of symbols on the screen can be presented as follows: When starting, the operating system creates a raw input thread and a system hardware input queue in the csrss.exe process. The raw input thread cyclically sends read requests to the keyboard driver, which remains in a waiting condition until an event from the keyboard appears. When the user presses or releases a key on the keyboard, the keyboard micro-controller detects that a key has been pressed or released and sends both the scan code of the pressed/ released key to the central computer and an interrupt request. The keyboard system controller gets the scan code, processes it then makes it accessible on input/output port 60h and generates a central processor hardware interrupt. The interrupt controller signals the CPU to call the interrupt processing procedure for IRQ1 - ISR, which is registered in the system by the functional keyboard driver i8042prt. The ISR reads the data which has appeared from the internal keyboard controller queue, transforms the scan codes to virtual key codes (independent values which are determined by the system) and queues "I804KeyboardlsrDPC", a delayed procedure call. As soon as possible, the system calls the DPC which in turn executes the callback procedure KeyboardClassServiceCallback registered by the Kbdclass keyboard driver. The KeyboardClassServiceCallback procedure extracts a pending termination request from the raw input thread from its queue and returns it with information about the key pressed. The raw input thread saves the information to the system hardware input queue and uses it to create the basic Windows keyboard messages WM_KEYDOWN, WM_KEYUP, which are placed at the end of the VIQ virtual input queue of the active thread. The message processing cycle thread deletes the message from the queue and sends the corresponding window procedure for processing. When this happens, the system function TranslateMessage may be called, which uses basic keyboard messages to create the additional "symbol" messages WM_CHAR, WM_SYSCHAR, WM_DEADCHAR and WM_SYSDEADCHAR. Raw input model The keyboard input model described above has a number of shortcomings from the point of view of those who develop applications. In order to get input from a non-standard input device, the application has to perform a significant number of operations: mount the device, periodically query the device, consider the possibility of parallel use of the device by other applications etc. For this reason, later versions of Windows offer an alternative input model, called the raw input model, which simplifies the development of applications which use non-standard input devices (see Fig 3, DirectInput applications) The raw input model differs from the original Windows input model. In the latter, the application gets device independent input in the form of a message (such as (WM_CHAR), which is sent to application windows. In the raw input model, the application has to register the device it wants to receive data from. The application then receives user input via WM_INPUT messages. Two methods of data transmission are supported: a standard method and a buffering method. In order to interpret entered data, the application has to get information about the input device, which can be done using the GetRawInputDeviceInfo function. Implementing keyloggers: the variants Now we take a look at the main methods used by malware authors for implementing keyloggers, taking the model of processing keyboard input in Windows described above as a basis. Knowing how the model is structured makes it easier to understand which mechanisms can be used by keyloggers. Keyloggers can be injected at any stage in the processing sequence, intercepting data about keys pressed which is transmitted by one processing subsystem to another subsystem. The methods examined below for creating software keyloggers are divided into user mode methods and kernel mode methods. Figure 9 shows all the subsystems processing keyboard input and their interdependencies. Next to some of the subsystems are numbers in red circles, and these indicate the section of the article which describes how keyloggers which use or substitute the corresponding subsystem can be created. Fig 9: Overview of how Windows processes keyboard input This section will not look at creating hardware keyloggers. It is enough to note that there are three types of hardware keylogger: keyloggers incorporated into the keyboard itself; keyloggers incorporated into the cable connecting the keyboard to the system block; keyloggers incorporated into the computer's system block itself. The most common of these is the second type of hardware keylogger, and one of the best known examples of this type is the "KeyGhost USB Keylogger" (KeyGhost Keylogger - A hardware keylogger which captures all keystrokes to its internal memory chip. It is software free so it cannot be detected or disabled by software and installs in under 5 seconds!). Unfortunately, at the moment only afew antivirus solutions offer adequate protection against the potential threat posed by keyloggers. Such products are for instance Kaspersky Lab 6.0 products and newer. 1. User mode keyloggers User mode keyloggers are the easiest to create, but also the easiest to detect, as they use well known and well documented Win32 API functions to intercept data. 1.1. Setting hooks for keyboard messages This is the most common method used when creating keyloggers. Using SetWindowsHookEx, the keylogger sets a global hook for all keyboard events for all threads in the system (see the section on 'Keyboard hooks'). The hook filter function is located in a separate dynamic library which will be injected into all processes in the system. When any keyboard message thread is extracted from the message queue, the system calls the filter function installed. One of the advantages of this method of interception is its simplicity and the guaranteed interception of all pressed keys. As for disadvantages, it should be noted that it's necessary to have a separate dynamic library file, and it is also relatively easy to detect the keylogger due to the fact that it has been injected into all processes. Some keyloggers which use this approach are AdvancedKeyLogger, KeyGhost, Absolute Keylogger, Actual Keylogger, Actual Spy, Family Key Logger, GHOST SPY, Haxdoor, MyDoom and others. Kaspersky Internet Security proactively detects this type of Keylogger as 'invader (loader); the option 'Windows hooks' in the 'Application activity analyzer' subsystem in the PDM module of KIS should be enabled. 1.2. Using cyclical querying of the keyboard This is the second most common method used when implementing keyloggers. The GetAsyncnKeyState and GetKeyState are used to periodically query the status of all keys at rapid intervals. This function returns arrays of asynchronous or synchronous key status (see section Keyboard key status array); by analysing these it's possible to understand which keys have been pressed or released since the last query was carried out. The advantages of this method are that it is extremely easy to implement, there is no additional module (in contrast to the use of hooks); the disadvantages are that there is no guarantee that all keystrokes will be intercepted - some may be missed; and this method can easily be detected by looking for processes which query the keyboard with high frequency. This method is used in keyloggers such as Computer Monitor, Keyboard Guardian, PC Activity Monitor Pro, Power Spy, Powered Keylogger, Spytector, Stealth KeyLogger, Total Spy. Kaspersky Internet Security proactively detects this type of Keylogger as 'Keylogger'; the option 'Keylogger detection' in the 'Application activity analyzer' subsystem in the PDM module should be enabled. 1.3. Injection into processes and hooking message processing functions This method is used infrequently. The keylogger is injected into all processes and intercepts the GetMessage or PeekMessage functions from the user32.dll library. A range of methods can be used to do this: splicing (a method used to intercept API function calls; essentially, the method consists of substituting a few - normally five - of the first bytes of the JMP instruction function which passes control to the intercepting code), modifying the address table of IAT import functions, intercepting the GetProcAddress function which returns a function address from the library which has been loaded. A keylogger can be created either in the form of a DLL or by injecting the code directly into the target process. The result is as follows: when the application calls, for example, the GetMessage function in order to get the next message from the message queue, this call will be passed to the hook code. The hook calls the outgoing GetMessage function from user32.dll and analyses the results returned for message type objects. When a keyboard message is received, all information about it is extracted from the message parameters and logged by the keylogger. The advantages of this method are its effectiveness: due to the method being not very common, only a few programs are able to detect keyloggers of this type. Additionally, standard onscreen keyboards are useless against this type of keylogger, as the messages sent by them will also be intercepted. The disadvantages include the fact that modifying the IAT table does not guarantee interception, as the function address of user32.dll may have been saved prior to the keylogger being injected; splicing has certain difficulties connected with, for example, the need to rewrite the body of the function on the fly. Kaspersky Internet Security proactively detects this type of Keylogger as 'invader'; the option 'Intrusion into process (invaders)' in the 'Application activity analyzer' subsystem in the PDM module should be enabled. 1.4. Using the raw input model At the time of writing, there is only one known example of this method: a utility used to test how well protected the system is against keyloggers. Essentially the method uses the new Raw Input module (see the section "Raw Input model"), where the keylogger registers the keyboard as a device from which it wants to receive input. The keylogger then starts to get data about keys which have been pressed and released using the WM_INPUT message. The advantage is that this method is easy and effective to implement; in view of the fact that this method became well known only recently, almost none of today's protection software currently has the ability to combat such keyloggers. The disadvantage is that fact that such keyloggers are easy to detect due to the need for special registration in order for the application to get raw input (by default, no system processes do this). Kaspersky Internet Security 7.0 will proactively detect such keyloggers as 'Keylogger'; the option 'Keylogger detection' in the 'Application activity analyzer' subsystem in the PDM module should be enabled. 2. Kernel mode keyloggers In terms of both implementation and detection, kernel mode keyloggers are significantly more complex than user mode keyloggers. In order to write such keyloggers, higher knowledge is required, but this makes it possible to create keyloggers which will be completely unnoticed by all user mode applications. Both methods documented in the Microsoft Driver Development Kit and undocumented methods may be used for interception. 2.1. Using the keyboard driver filter Kbdclass The hook method is documented in the DDK (see the section "Driver stack for Plug and Play PS/2 keyboard"). Keyloggers which use this approach intercept requests to the keyboard by installing a filter above the device "DeviceKeyboardClass0", created by the Kbdclass driver (see Driver stack for Plub and Play PS/2 keyboards). Only IRP_MJ_READ requests need to be filtered as it is these which make it possible to get the codes of keys which have been pressed and released. The advantage is the guarantee that all keystrokes will be intercepted; such keyloggers cannot be detected without using a driver, and due to this, not all anti-keyloggers will detect them. The disadvantage is that the driver itself has to be installed. The best known keyloggers which use this approach are ELITE Keylogger and Invisible KeyLogger Stealth. Kaspersky Internet Security proactively detects such keyloggers as Keylogger by monitoring the keyboard device stack (the "Detect keyboard intercepts" option in the "Application activity analysis" option in the proactive detection module (PDM) should be enabled). 2.2. Using the filter driver of the i8042prt functional driver This method of interception is documented in the DDK. Keyloggers based on this method intercept requests to the keyboard by installing a filter on top of an unnamed device, created by the i8042prt driver for the DeviceKeyboardClass0 (see section "Device stack for Plug and Play PS/2 keyboards"). The i8042prt driver is a program interface for adding an additional IRQ1 (lsrRoutine) interrupt processing function, within with data received from the keyboard can be analysed. The advantages and disadvantages of this method are the same as those detailed in the previous point. However, there is an additional disadvantage - it is dependent on the type of keyboard. The i8042prt driver processes requests only from PS/2 keyboards, and because of this, this method is not suitable for intercepting data entered via a USB or wireless keyboard. Kaspersky Internet Security proactively detects such keyloggers as Keylogger by monitoring the keyboard device stack (the "Detect keyboard intercepts" option in the "Application activity analysis" option in the proactive detection module (PDM) should be enabled). 2.3. Modifying the dispatch table of the Kbdclass driver Keyloggers based on this principle intercept requests to the keyboard by changing the IRP_MJ_READ entry point in the dispatch table for the Kbdclass driver. This is functionally similar to the Kbdclass driver filter (see section "2.1 Driver filters for kbdclass driver".) The specifics are the same. Another variant hooks a different function for processing requests: IRP_MJ_DEVICECONTROL. In this case, the keylogger becomes a driver filter similar to the i8042 driver (see section "2.2 Using the filter driver of the i8042prt functional driver"). Kaspersky Internet Security proactively detects such keyloggers as Keylogger by monitoring the keyboard stack devices (the "Detect keyboard interception" in the "Application activity analysis" option in the proactive detection module (PDM) should be enabled.) 2.4. Modifying the system service table KeServiceDescriptorTableShadow This is a relatively common method for implementing keyloggers, which is similar to the user mode method described in section "1.3 Injection into processes and hooking message processing functions". Keyloggers which use this method intercept requests to the keyboard by patching the entry point for NtUserGetMessage/PeekMessage in the second table of system services (KeServiceDescriptorTableShadow of the win32k.sys driver. Information about keys pressed is transmitted to the keylogger when a call to the GetMessage or PeekMessage function is terminated within a thread. The advantage of this method is that it is difficult to detect. The disadvantage is that it is difficult to implement (searching for KeServiceDescriptorTableShadow is not an easy task; in addition to this, other drivers may already have patched the entry point in this table) and the need to install a separate driver. Kaspersky Internet security proactively detects such keyloggers as Keylogger by monitoring the keyboard stack devices (the "Detect keyboard interception" in the "Application activity analysis" option in the proactive detection module (PDM) should be enabled.) 2.5. Modifying the code of the NtUserGerMessage or NtUserPeekMessage function by splicing This is an extremely rare type of keylogger. Keyloggers which use this method intercept requests to the keyboard by modifying the code of the NtUserGetMessage or NtUserPeekMessage using splicing. These functions are implemented in the system kernel through the win32k.sys driver and are called by corresponding functions in the user32.dll library. As shown in section 1.3 "Injection into process and hooking message processing functions", these functions make it possible to filter all messages received by applications and get data about the pressing/ releasing of keys from keyboard messages. The advantage of this method is that it is difficult to detect. The disadvantage is that it is difficult to implement (it's necessary to rewrite the body of the function on the fly, and is dependent on the operating system version and software installed) and it's also necessary to install a driver. 2.6. Substituting a driver in the keyboard stack of drivers This method involves substituting a Kbdclass driver or a low-level keyboard driver with a driver expressly developed for the purpose. The clear disadvantage of this method is that it is difficult to implement, as it is impossible to know in advance which type of keyboard is being used. It is therefore relatively easy to detect driver substitution. As a consequence, this method is almost never used. 2.7. Implementing a handler driver for interrupt 1 (IRQ 1). This involves writing a kernel mode driver which will hook the keyboard interrupt (IRQ1) and which directly contacts the keyboard input/ output ports (60h, 64h), As this is difficult to implement, and due to the fact that it is not entirely clear how it interacts with the system processor for interrupt IRQ1 (i8042prt.sys), this method remains, at the moment, purely theoretical. Conclusion This article surveys the progression of data from a key being pressed by the user to the appearance of symbols on the screen; the links in the chain of processing the signal; and methods for implementing keyloggers which intercept keyboard input at specific stages of the process. The process of keyboard input in Windows is relatively complex, and it's possible to install a hook at any stage. Keyloggers have already been created for some of the stages, while for some they do not yet exist. There is a connection between how common a keylogger is and the difficulty of creating such a keylogger. For instance, the more common methods of interception - such as hooking input events and cyclical querying of the keyboard - are the simplest to implement. Even a person who has only been programming for a week would be able to write a keylogger which uses these methods. The majority of keyloggers currently in existence are relatively simple and can easily be used with malicious intent, with the main aim being to steal confidential information entered via the keyboard. Most important of all: Antivirus companies should protect their users against the threat posed by malicious keyloggers. As protection mechanisms become more sophisticated, the cybercriminals who create keyloggers will be forced to implement more complex methods using Windows kernel drivers - there are still many unexploited possibilities in this area. Keyloggers: How they work and how to detect them (Part 1) Sursa: https://securelist.com/analysis/36358/keyloggers-implementing-keyloggers-in-windows-part-two/

Keyloggers: How they work and how to detect them (Part 1) By Nikolay Grebennikov on March 29, 2007. 1:03 pm Publications Keyloggers: Implementing keyloggers in Windows. Part Two In February 2005, Joe Lopez, a businessman from Florida, filed a suit against Bank of America after unknown hackers stole $90,000 from his Bank of America account. The money had been transferred to Latvia. An investigation showed that Mr. Lopez's computer was infected with a malicious program, Backdoor.Coreflood, which records every keystroke and sends this information to malicious users via the Internet. This is how the hackers got hold of Joe Lopez's user name and password, since Mr. Lopez often used the Internet to manage his Bank of America account. However the court did not rule in favor of the plaintiff, saying that Mr. Lopez had neglected to take basic precautions when managing his bank account on the Internet: a signature for the malicious code that was found on his system had been added to nearly all antivirus product databases back in 2003. Joe Lopez's losses were caused by a combination of overall carelessness and an ordinary keylogging program. About Keyloggers The term 'keylogger' itself is neutral, and the word describes the program's function. Most sources define a keylogger as a software program designed to secretly monitor and log all keystrokes. This definition is not altogether correct, since a keylogger doesn't have to be software – it can also be a device. Keylogging devices are much rarer than keylogging software, but it is important to keep their existence in mind when thinking about information security. Legitimate programs may have a keylogging function which can be used to call certain program functions using "hotkeys," or to toggle between keyboard layouts (e.g. Keyboard Ninja). There is a lot of legitimate software which is designed to allow administrators to track what employees do throughout the day, or to allow users to track the activity of third parties on their computers. However, the ethical boundary between justified monitoring and espionage is a fine line. Legitimate software is often used deliberately to steal confidential user information such as passwords. Most modern keyloggers are considered to be legitimate software or hardware and are sold on the open market. Developers and vendors offer a long list of cases in which it would be legal and appropriate to use keyloggers, including: Parental control: parents can track what their children do on the Internet, and can opt to be notified if there are any attempts to access websites containing adult or otherwise inappropriate content; Jealous spouses or partners can use a keylogger to track the actions of their better half on the Internet if they suspect them of "virtual cheating"; Company security: tracking the use of computers for non-work-related purposes, or the use of workstations after hours; Company security: using keyloggers to track the input of key words and phrases associated with commercial information which could damage the company (materially or otherwise) if disclosed; Other security (e.g. law enforcement): using keylogger records to analyze and track incidents linked to the use of personal computers; Other reasons. However, the justifications listed above are more subjective than objective; the situations can all be resolved using other methods. Additionally, any legitimate keylogging program can still be used with malicious or criminal intent. Today, keyloggers are mainly used to steal user data relating to various online payment systems, and virus writers are constantly writing new keylogger Trojans for this very purpose. Furthermore, many keyloggers hide themselves in the system (i.e. they have rootkit functionality), which makes them fully-fledged Trojan programs. As such programs are extensively used by cyber criminals, detecting them is a priority for antivirus companies. Kaspersky Lab's malware classification system has a dedicated category for malicious programs with keylogging functionality: Trojan-Spy. Trojan-Spy programs, as the name suggests, track user activity, save the information to the user's hard disk and then forward it to the author or 'master' of the Trojan. The information collected includes keystrokes and screen-shots, used in the theft of banking data to support online fraud. Why keyloggers are a threat Unlike other types of malicious program, keyloggers present no threat to the system itself. Nevertheless, they can pose a serious threat to users, as they can be used to intercept passwords and other confidential information entered via the keyboard. As a result, cyber criminals can get PIN codes and account numbers for e-payment systems, passwords to online gaming accounts, email addresses, user names, email passwords etc. Once a cyber criminal has got hold of confidential user data, s/he can easily transfer money from the user's account or access the user's online gaming account. Unfortunately access to confidential data can sometimes have consequences which are far more serious than an individual's loss of a few dollars. Keyloggers can be used as tools in both industrial and political espionage, accessing data which may include proprietary commercial information and classified government material which could compromise the security of commercial and state-owned organizations (for example, by stealing private encryption keys). Keyloggers, phishing and social engineering (see 'Computers, Networks and Theft') are currently the main methods being used in cyber fraud. Users who are aware of security issues can easily protect themselves against phishing by ignoring phishing emails and by not entering any personal information on suspicious websites. It is more difficult, however, for users to combat keyloggers; the only possible method is to use an appropriate security solution, as it's usually impossible for a user to tell that a keylogger has been installed on his/ her machine. According to Cristine Hoepers, the manager of Brazil's Computer Emergency Response Team, which works under the aegis of the country's Internet Steering Committee, keyloggers have pushed phishing out of first place as the most-used method in the theft of confidential information. What's more, keyloggers are becoming more sophisticated – they track websites visited by the user and only log keystrokes entered on websites of particular interest to the cyber criminal. In recent years, we have seen a considerable increase in the number of different kinds of malicious programs which have keylogging functionality. No Internet user is immune to cyber criminals, no matter where in the world s/he is located and no matter what organization s/he works for. How cyber criminals use keyloggers One of the most publicized keylogging incidents recently was the theft of over $1million from client accounts at the major Scandinavian bank Nordea. In August 2006 Nordea clients started to receive emails, allegedly from the bank, suggesting that they install an antispam product, which was supposedly attached to the message. When a user opened the file and downloaded it to his/ her computer, the machine would be infected with a well known Trojan called Haxdoor. This would be activated when the victim registered at Nordea's online service, and the Trojan would display an error notification with a request to re-enter the registration information. The keylogger incorporated in the Trojan would record data entered by the bank's clients, and later send this data to the cyber criminals' server. This was how cyber criminals were able to access client accounts, and transfer money from them. According to Haxdoor's author, the Trojan has also been used in attacks against Australian banks and many others. On January 24, 2004 the notorious Mydoom worm caused a major epidemic. MyDoom broke the record previously set by Sobig, provoking the largest epidemic in Internet history to date. The worm used social engineering methods and organized a DoS attack on www.sco.com; the site was either unreachable or unstable for several months as a consequence. The worm left a Trojan on infected computers which was subsequently used to infect the victim machines with new modifications of the worm. The fact that MyDoom had a keylogging function to harvest credit card numbers was not widely publicized in the media. In early 2005 the London police prevented a serious attempt to steal banking data. After attacking a banking system, the cyber criminals had planned to steal $423 million from Sumitomo Mitsui's London-based offices. The main component of the Trojan used, which was created by the 32-year-old Yeron Bolondi, was a keylogger that allowed the criminals to track all the keystrokes entered when victims used the bank's client interface. In May 2005 in London the Israeli police arrested a married couple who were charged with developing malicious programs that were used by some Israeli companies in industrial espionage. The scale of the espionage was shocking: the companies named by the Israeli authorities in investigative reports included cellular providers like Cellcom and Pelephone, and satellite television provider YES. According to reports, the Trojan was used to access information relating to the PR agency Rani Rahav, whose clients included Partner Communications (Israel's second leading cellular services provider) and the HOT cable television group. The Mayer company, which imports Volvo and Honda cars to Israel, was suspected of committing industrial espionage against Champion Motors, which imports Audi and Volkswagen cars to the country. Ruth Brier-Haephrati, who sold the keylogging Trojan that her husband Michael Haephrati created, was sentenced to four years in jail, and Michael received a two-year sentence. In February 2006, the Brazilian police arrested 55 people involved in spreading malicious programs which were used to steal user information and passwords to banking systems. The keyloggers were activated when the users visited their banks' websites, and secretly tracked and subsequently sent all data entered on these pages to cyber criminals. The total amount of money stolen from 200 client accounts at six of the country's banks totaled $4.7million. At approximately the same time, a similar criminal grouping made up of young (20 – 30 year old) Russians and Ukrainians was arrested. In late 2004, the group began sending banking clients in France and a number of other countries email messages that contained a malicious program – namely, a keylogger. Furthermore, these spy programs were placed on specially created websites; users were lured to these sites using classic social engineering methods. In the same way as in the cases described above, the program was activated when users visited their banks' websites, and the keylogger harvested all the information entered by the user and sent it to the cyber criminals. In the course of eleven months over one million dollars was stolen. There are many more examples of cyber criminals using keyloggers – most financial cybercrime is committed using keyloggers, since these programs are the most comprehensive and reliable tool for tracking electronic information. Increased use of keyloggers by cyber criminals The fact that cyber criminals choose to use keyloggers time and again is confirmed by IT security companies. One of VeriSign's recent reports notes that in recent years, the company has seen a rapid growth in the number of malicious programs that have keylogging functionality. Source: iDefense, a VeriSign Company One report issued by Symantec shows that almost 50% of malicious programs detected by the company's analysts during the past year do not pose a direct threat to computers, but instead are used by cyber criminals to harvest personal user data. According to research conducted by John Bambenek, an analyst at the SANS Institute, approximately 10 million computers in the US alone are currently infected with a malicious program which has a keylogging function. Using these figures, together with the total number of American users of e-payment systems, possible losses are estimated to be $24.3 million. Kaspersky Lab is constantly detecting new malicious programs which have a keylogging function. One of the first virus alerts on Securelist - Information about Viruses, Hackers and Spam, Kaspersky Lab's dedicated malware information site, was published on 15th June 2001. The warning related to TROJ_LATINUS.SVR, a Trojan with a keylogging function. Since then, there has been a steady stream of new keyloggers and new modifications. Kaspersky antivirus database currently contain records for more than 300 families of keyloggers. This number does not include keyloggers that are part of complex threats (i.e. in which the spy component provides additional functionality). Most modern malicious programs are hybrids which implement many different technologies. Due to this, any category of malicious program may include programs with keylogger (sub)functionality. The number of spy programs detected by Kaspersky Lab each month is on the increase, and most of these programs use keylogging technology. Keylogger construction The main idea behind keyloggers is to get in between any two links in the chain of events between when a key is pressed and when information about that keystroke is displayed on the monitor. This can be achieved using video surveillance, a hardware bug in the keyboard, wiring or the computer itself, intercepting input/ output, substituting the keyboard driver, the filter driver in the keyboard stack, intercepting kernel functions by any means possible (substituting addresses in system tables, splicing function code, etc.), intercepting DLL functions in user mode, and, finally, requesting information from the keyboard using standard documented methods. Experience shows that the more complex the approach, the less likely it is to be used in common Trojan programs and the more likely it is to be used in specially designed Trojan programs which are designed to steal financial data from a specific company. Keyloggers can be divided into two categories: keylogging devices and keylogging software. Keyloggers which fall into the first category are usually small devices that can be fixed to the keyboard, or placed within a cable or the computer itself. The keylogging software category is made up of dedicated programs designed to track and log keystrokes. The most common methods used to construct keylogging software are as follows: a system hook which intercepts notification that a key has been pressed (installed using WinAPI SetWindowsHook for messages sent by the window procedure. It is most often written in C); a cyclical information keyboard request from the keyboard (using WinAPI Get(Async)KeyState or GetKeyboardState – most often written in Visual Basic, sometimes in Borland Delphi); using a filter driver (requires specialized knowledge and is written in C). We will provide a detailed explanation of the different ways keyloggers are constructed in the second half of this article (to be published in the near future). But first, here are some statistics. A rough breakdown of the different types of keyloggers is shown in the pie chart below: Recently, keyloggers that disguise their files to keep them from being found manually or by an antivirus program have become more numerous. These stealth techniques are called rootkit technologies. There are two main rootkit technologies used by keyloggers: masking in user mode; masking in kernel mode. A rough breakdown of the techniques used by keyloggers to mask their activity is shown in the pie chart below: How keyloggers spread Keyloggers spread in much the same way that other malicious programs spread. Excluding cases where keyloggers are purchased and installed by a jealous spouse or partner, and the use of keyloggers by security services, keyloggers are mostly spread using the following methods): a keylogger can be installed when a user opens a file attached to an email; a keylogger can be installed when a file is launched from an open-access directory on a P2P network; a keylogger can be installed via a web page script which exploits a browser vulnerability. The program will automatically be launched when a user visits a infected site; a keylogger can be installed by another malicious program already present on the victim machine, if the program is capable of downloading and installing other malware to the system. How to protect yourself from keyloggers Most antivirus companies have already added known keyloggers to their databases, making protecting against keyloggers no different from protecting against other types of malicious program: install an antivirus product and keep its database up to date. However, since most antivirus products classify keyloggers as potentially malicious, or potentially undesirable programs, users should ensure that their antivirus product will, with default settings, detect this type of malware. If not, then the product should be configured accordingly, to ensure protection against most common keyloggers. Let's take a closer look at the methods that can be used to protect against unknown keyloggers or a keylogger designed to target a specific system. Since the chief purpose of keyloggers is to get confidential data (bank card numbers, passwords, etc.), the most logical ways to protect against unknown keyloggers are as follows: using one-time passwords or two-step authentication, using a system with proactive protection designed to detect keylogging software, using a virtual keyboard. Using a one-time password can help minimize losses if the password you enter is intercepted, as the password generated can be used one time only, and the period of time during which the password can be used is limited. Even if a one-time password is intercepted, a cyber criminal will not be able to use it in order to obtain access to confidential information. In order to get one-time passwords, you can use a special device such as: a USB key (such as Aladdin eToken NG OTP): a 'calculator' (such as RSA SecurID 900 Signing Token): In order to generate one-time passwords, you can also use mobile phone text messaging systems that are registered with the banking system and receive a PIN-code as a reply. The PIN is then used together with the personal code for authentication. If either of the above devices is used to generate passwords, the procedure is as described below: the user connects to the Internet and opens a dialogue box where personal data should be entered; the user then presses a button on the device to generate a one-time password, and a password will appear on the device's LCD display for 15 seconds; the user enters his user name, personal PIN code and the generated one-time password in the dialogue box (usually the PIN code and the key are entered one after the other in a single pass code field); the codes that are entered are verified by the server, and a decision is made whether or not the user may access confidential data. When using a calculator device to generate a password, the user will enter his PIN code on the device 'keyboard' and press the ">" button. One-time password generators are widely used by banking systems in Europe, Asia, the US and Australia. For example, Lloyds TSB, a leading bank, decided to use password generators back in November 2005. In this case, however, the company has to spend a considerable amount of money as it had to acquire and distribute password generators to its clients, and develop/ purchase the accompanying software. A more cost efficient solution is proactive protection on the client side, which can warn a user if an attempt is made to install or activate keylogging software. Proactive protection against keyloggers in Kaspersky Internet Security The main drawback of this method is that the user is actively involved and has to decide what action should be taken. If a user is not very technically experienced, s/he might make the wrong decision, resulting in a keylogger being allowed to bypass the antivirus solution. However, if developers minimize user involvement, then keyloggers will be able to evade detection due to an insufficiently rigorous security policy. However, if settings are too stringent, then other, useful programs which contain legitimate keylogging functions might also be blocked. The final method which can be used to protect against both keylogging software and hardware is using a virtual keyboard. A virtual keyboard is a program that shows a keyboard on the screen, and the keys can be 'pressed' by using a mouse. The idea of an on-screen keyboard is nothing new - the Windows operating system has a built-in on-screen keyboard that can be launched as follows: Start > Programs > Accessories > Accessibility > On-Screen Keyboard. An example of the Windows on-screen keyboard However, on-screen keyboards aren't a very popular method of outsmarting keyloggers. They were not designed to protect against cyber threats, but as an accessibility tool for disabled users. Information entered using an on-screen keyboard can easily be intercepted by a malicious program. In order to be used to protect against keyloggers, on-screen keyboards have to be specially designed in order to ensure that information entered or transmitted via the on-screen keyboard cannot be intercepted. Conclusions This article has provided an overview of how keyloggers – both keylogging software and hardware - function and are used. Even though keylogger developers market their products as legitimate software, most keyloggers can be used to steal personal user data and in political and industrial espionage. At present, keyloggers – together with phishing and social engineering methods – are one of the most commonly used methods of cyber fraud. IT security companies have recorded a steady increase in the number of malicious programs that have keylogging functionality. Reports show that there is an increased tendency to use rootkit technologies in keylogging software, to help the keylogger evade manual detection and detection by antivirus solutions. Only dedicated protection can detect that a keylogger is being used for spy purposes. The following measures can be taken to protect against keyloggers: use a standard antivirus that can be adjusted to detect potentially malicious software (default settings for many products); proactive protection will protect the system against new ,modifications of existing keyloggers; use a virtual keyboard or a system to generate one-time passwords to protect against keylogging software and hardware. Keyloggers: Implementing keyloggers in Windows. Part Two Sursa: Keyloggers: How they work and how to detect them (Part 1) - Securelist

Cello is a library that introduces higher level programming to C. Interfaces allow for structured design Duck Typing allows for generic functions Exceptions control error handling Constructors/Destructors aid memory management Syntactic Sugar increases readability C Library means excellent performance and integration /* Example libCello Program */ #include "Cello.h" int main(int argc, char** argv) { /* Stack objects are created using "$" */ var int_item = $(Int, 5); var float_item = $(Real, 2.4); var string_item = $(String, "Hello"); /* Heap objects are created using "new" */ var items = new(List, int_item, float_item, string_item); /* Collections can be looped over */ foreach (item in items) { /* Types are also objects */ var type = type_of(item); print("Object %$ has type %$\n", item, type); } /* Heap objects destroyed with "delete" */ delete(items); } [h=2]Quickstart[/h] For more examples please take a look at the quickstart documentation section: Containers and Collections Type and Classes Exceptions First Class Functions Memory Management Or some articles about the creation: Hacking C to its limits Cello vs C++ vs ObjC Sursa: Cello • High Level Programming C

Def Con 22 Touring The Darkside Of The Internet. An Introduction To Tor, Darknets, And Bitcoin Description: This is an introduction level talk. The talk itself will cover the basics of Tor, Darknets, Darknet Market places, and Bitcoin. I will start by giving the audience an overview of Tor and how it works. I will cover entry nodes, exit nodes, as well as hidden services. I will then show how you connect to Tor on both Linux/OSX and Windows and demo it off. Once we are connected to Tor, I am going to show how to find Tor hidden services and then demo off browsing around some marketplaces. Once the audience has a solid grasp on what the market places offer, I am going to start dealing the process of purchasing something off of it. I will cover bitcoin and bitcoin mining. After we know about how bitcoin works, we will cover purchasing items. I will cover purchasing PO Box's and the pickup of packages. Finally I will finish up with some concerns you may want to be aware of and my recommendations to help make the use of TOR, Bitcoin, and Marketplaces more secure. As a infosec professional by day, Metacortex much prefers his hacker by night persona. Most of his free time time is spent helping run both DC801 and the Salt Lake City based HackerSpace 801 Labs. He loves talking about anything hacking related and does everything he can to help promote and build the northern Utah hacking community. Twitter: @MeTacortex Grifter has been a DEF CON Goon for 14 years. He is currently the Senior Goon in charge of DEF CON Evening Event space and the DEF CON Villages. In previous lives he served as a Security, Vendor, and Skybox Goon, Coordinator of the DEF CON Movie Channel, former Organizer of the Scavenger Hunt, and Administrator of the DEF CON Forums. He birthed the idea of the DEF CON Villages and DC Groups into the world, and he's not sorry about it. Grifter has spoken at DEF CON numerous times, as well as related Hacker, Security, and Industry conferences. He has co-authored several books on various information security topics, and has somehow found a way to convince people to give him money for what he keeps inside his head.(The technical stuff, not the dirty stuff…yet.) He uses this money to provide food and shelter for his family in Salt Lake City, Utah, where he is an active part of DC801, and a founding member of the 801 Labs hackerspace. For More Information please visit:- https://www.defcon.org/html/defcon-22/dc-22-index.html Sursa: Def Con 22 Touring The Darkside Of The Internet. An Introduction To Tor, Darknets, And Bitcoin

[h=3]Cell Phone Tapping: How It Is Done and Will Anybody Protect Subscribers[/h] You probably have read on various news websites about surveillance programs led by security services in different countries that reach phone and Internet communications of ordinary citizens. We have already wrote about possible threats to mobile telecommunication networks and today we want to put more emphasis on one of the attack vectors against mobile subscribers. In short, the outline is like this. The attacker penetrates into the SS7 (Signaling System's No. 7) network and sends a Send Routing Info For SM (SRI4SM) service message to the network channel, specifying the phone number of an attacked subscriber A as a parameter. The subscriber's A home network sends the following technical information as a response: IMSI (International Mobile Subscriber Identity) and address of the MSC currently providing services to the subscriber. After that, the attacker changes the billing system address in the subscriber's profile to the address of his own pseudo-billing system and injects the updated profile into VLR database via Insert Subscriber Data (ISD) message. When the attacked subscriber makes an outgoing call, his switch addresses the attacker's system instead of the actual billing system. The attacker's system sends the switch a directive allowing one to redirect a call to a third party controlled by the attacker. At a third-party location, a conference call with three subscribers is set up, two of them are real (the caller A and the called while the third is introduced by the attacker illegally and is able to listen and record the conversation. I would say to skeptics straight off: this plan is not a fantasy, as you can see, and it could be practically realized. On the stage of development, the SS7 system was not provided with defense mechanisms against such attacks. It was meant that SS7 network itself is private enough and an "outsider" cannot access it. However, times are changing and we become witnesses of using telephony technologies with malicious intent. Unfortunately, one does not simply enable external SS7 message filtering, as far as it may affect the availability of mobile services in roaming. There is no mobile network operator who wants to lose its money. The work of an operator providing services to a large number of subscribers always treads a fine line between Information Security and availability of services. The problem is especially acute for mobile network operators: The range of services is broad, it is different for different operators; at the same time, providing services both to their subscribers and subscribers from other networks within the operator's network is desirable, and in such a manner that subscribers do not face the limitations of mobile network services when traveling abroad. What you can do It would be good to fix the so-called "vulnerabilities" in the SS7 protocol stack, but any expert will tell you that it is impossible. A classic example of the "it's not a bug, it's a feature" thing. Instead of being philosophical about mobile network architecture we must take action. We can do the following, for example: Perform a penetration test in the SS7 network. Set up monitoring of warning messages at the operator's network perimeter by all available means. Analyze the received information and take steps to minimize the risks. Penetration Tests Let's talk a bit about the benefits of penetration tests. As for operator's network, these tests play a role not only in the detection of vulnerabilities, but also in solving operational tasks. For instance, you need to perform dozens of tests considering the specifics of each particular network in order to find out the impact of enabling either one feature or the other. When testing SS7 warning messages, we consider 10 basic types of attacks on a network and mobile subscribers. Check for the disclosure of confidential technical parameters: subscriber's IMSI; MSC address where the subscriber is registered; HLR database address, where the subscriber's profile is stored. An attacker can conduct more complicated attacks using these parameters. Check for the disclosure of subscriber's cell data. An attacker can detect subscriber's location using the cell ID. In cities the location can be determined with an accuracy of about 10 meters (Positive Research Center: Search and Neutralize. How to Determine Subscriber’s Location). Check for possible violation of subscriber's availability for incoming calls (DoS against the subscriber). In case of a successful attack, the victim subscriber no longer receives incoming calls and SMS. At the same time victim's mobile phone indicates the network availability. The victim subscriber will stay in this state until he/she makes an outgoing call, goes to the other switch service area or reboots the phone. Check for private SMS conversations disclosure. This attack is a consequence of the attack number 3. In case of a successful attack, incoming SMS messages are intercepted by the attacker's devices, so it will not be difficult to read them. To prevent the following delivery to the recipient, the attacker sends an SMS delivery notification to the SMS Center. Check for USSD commands manipulations. In case of a successful attack, the attacker is able to send USSD commands on behalf of the subscriber. The possible damage will be assessed with regard to USSD services provided by the operator (e.g, if the money transfer between accounts via USSD commands is available or not). Check for spoofing subscriber's profile in VLR. In case of a successful attack, the attacker is able to use his equipment as an intelligent platform in order to extend the capabilities of voice calls and manipulate the tariffing of mobile services. Check for possible outgoing calls redirection. This attack is a continuation of the attack number 6. In case of a successful attack, the attacker is able to redirect outgoing calls from the victim subscriber. Additionally, this attack allows an attacker to make an unauthorized conference call, cutting in the conversation. Check for possible incoming calls redirection. In case of a successful attack, the attacker is able to redirect incoming calls to the victim subscriber. Moreover, calls to high-tariff regions may be not tariffed or call charges will be billed to the victim subscriber. Checking the switch stability and resistance to DoS attacks. In case of a successful attack, the switch no longer handles incoming calls to subscribers located in its service area. Check for possible direct direct manipulations in billing. In case of a successful attack, the attacker is able to empty the subscriber's personal account, so that the subscriber becomes deprived of the opportunity to make calls. How to Protect Users Our research revealed that the overwhelming majority of attacks against SS7 networks begin with obtaining technical data about the subscriber (IMSI, MSC and HLR database addresses). These parameters can be obtained from the response to the SRI4SM message mentioned in the beginning of this article. One of security solutions is SMS Home Routing procedure provided by 3GPP in 2007. It is sometimes called the SMS Firewall or SMS Filter. An additional host, providing filtering of malware SRI4SM messages, is implemented to the operator's network. It works is as follows. When a SRI4SM message is received to the operator's network from another network, it is re-routed to the new filtering host. This host sends a correct response replacing MSC and HLR database addresses with its own address and IMSI with false data. If the SRI4SM message was generated by the attacker, he will not receive any useful data in the response and his attack will be interrupted in the very beginning. If the SRI4SM message was used for the authorized transaction, to send an SMS, the originator's network will send this message to the filtering host, which will deliver the message to the recipient within the home network. It's been 7 years since this recommendation was issued, but, so far as we can see, few operators had launched this solution. By the way, SRI4SM message is not the only way to obtain the sunscriber's IMSI. Mobile operator's network is potentially vulnerable, just like any other network. Due to the specificity of mobile networks, these attacks can be more sophisticated than the Internet attacks. We recommend that operators take measures to protect such networks using the traditional scenario: penetration tests to discover potential vulnerabilities, security audit with the recommended settings and cyclic check of security settings against a template. This minimum amount of work helps you to improve the level of your network security just above the average, still it is enough for the first step. So subscribers got nothing to worry about. P. S. In the course of the Positive Hack Days IV, we made a report about possible attacks in mobile operators' network, where tapping into phone conversations from almost any place on earth was discussed. Video: PHDays ?????????-??? Authors: Sergey Puzankov, Dmitry Kurbatov ?????: Positive Research ?? 11:07 PM Sursa: Positive Research Center: Cell Phone Tapping: How It Is Done and Will Anybody Protect Subscribers

4MRecover 11.0 Beta OS Can Help Users Recover Lost Files By Silviu Stahie 27 Dec 2014, 15:18 GMT This is the first edition of this Linux distro 4MRecover 11.0 Beta, a new distribution based on 4MLinux that is designed to be used specifically for file recovery, is now available for download and testing. The 4MLinux developer is branching out and this is the second distro in a week that is made available and that follows a similar trend. The previous one is called 4MParted and it helps users to partition their systems more easily from outside the other OSes. Now, 4MRecover is using TestDisk and PhotoRec to allow users to recover lost files from the available partitions. The developer says that "this initial release is based on 4MLinux 11.0 and TestDisk 6.14. PhotoRec (tool to recover lost files) is started automatically. Just close PhotoRec, and Midnight Commander will be opened so that you can manage your files. You can also execute 'testdisk' (in Midnight Commander's shell prompt) if you are going to try to recover lost partitions." Even if PhotoRec might sound like something designed only for images, that's not the case. It works with any kind of file formats and it's very efficient. You can download 4MRecover 11.0 Beta from Softpedia and give it a go. Please keep in mind that it's still a Beta release and some problems might still linger. Sursa: 4MRecover 11.0 Beta OS Can Help Users Recover Lost Files - Softpedia

THC-IPV6 Last update 2014-12-27 Current public version: v2.7 For german speaking people: In the german C't magazine 11/13 and the iX IPv6 Kompakt (4/13) are articles on how to use the thc-ipv6 toolkit to comprehensively test IPv6 firewalls. Next Trainings: CanSecWest 2015, Vancouver, 16-17 March 2015, "Professional Pentesting IPv6 Networks" (now bookable) A complete tool set to attack the inherent protocol weaknesses of IPV6 and ICMP6, and includes an easy to use packet factory library. [0x00] News and Changelog Please note that public versions do not include all tools available! Only those who send in comprehensive patches and new tools for thc-ipv6 get the private versions which are released more often, include unreleased tools and more! If you want to participate, here is a list of tools that would be interesting: * Enhancing the library so it works on FreeBSD and OSX too * Create a tool which tests an ipv6 address if it is an endpoint for various tunnel protocols * Adding more exploit tests to exploit6 (I can supply a long list of exploit files) * Add a dhcp6 client fuzzer If you want to work on a topic on the list, email me, so not multiple people are working on the same tool. Contact: vh(at)thc(dot)org and put "antispam" in the subject line. CHANGELOG: ########## v2.7 - PUBLIC (31C3) * All flood_* tools: - changed destination so that targets can be remote. Yes this should not work, but sometimes it does * New tool: fuzz_dhcpc6 - DHCPv6 client fuzzer, submitted by Darrell Ambro, thanks a lot! * Added new script: six2four.sh - send an IPv6 packet via a 6to4 gateway * Added new script: grep6.pl - extracts an IPv6 in all possible notations from a file (from Eric Vyncke) * alive6: - setting -C twice increases the common address search space significantly - fixed from-to definition implementation - added "-y step" option, to define the step range when performing from-to scans (e.g. 2001:1::0-ff), default step range is of course 1, max is 256 - selects the source IPv6 address for every new target now; waiting, if no fitting IPv6 address is present on the interface until one is - if you use -s for alive scanning, the new "one packet fingerprinting" functionality is automatically used, courtesy of warlord @ nologin from his poison tool - error message if a packet can not be send for >50ms, and waiting for 60 seconds - cleaned up help output and add -hh more help/options output * thcsyn6: - added -m dstmac option (good for DOSing local, esp. hot standby addresses) - added -d dst hdr option - documented -a hbh-ra option * denial6: - added five more test cases with HBH-RA and AH headers * flood_router26 - added -a hopbyhop with router alert option - changed a default so the attacks do not show up in Snort IDS * flood_redir6 - added -a hopbyhop with router alert option * flood_solicitate6 - added query address parameter option - added -a hopbyhop with router alert option * fuzz_ip6: - fixes for HBH and DST EH fuzzing * thcping6: - added -x flood option - added -e ethertype option - added -V IP version option - added -L payload length option - added -N next header option - now prints fragID of fragmented replies * implementation6: - a few more test cases and fixes * dump_dhcp6 - more option decoding, better solicitate packet - added sending information request packet * four2six: - support for source port and ping ID (required for AFTR) * trace6: - support for MTU sizes > 2500 added * implementation6 - fixed to test cases where the wrong fragment nxt header was set (thanks to Gabriel Bertram for reporting) * inverse_lookup6 - fixed to display only the IPv6 addresses (and not interpret other data as such) * thc-ipv6-lib - global addresses are now prefered over unique local if no destination is set - fixed a bug in IPv4 CRC calculation function * cppcheck and Coverity issues checked and fixed * added spelling fixes by Debian maintainers [0x01] Introduction Welcome to the mini website of the THC IPV6 project. This code was inspired when I got into touch with IPv6, learned more and more about it - and then found no tools to play (read: "hack") around with. First I tried to implement things with libnet, but then found out that the ipv6 implementation is only partial - and sucks. I tried to add the missing code, but well, it was not so easy, hence I saved my time and quickly wrote my own library. (That was 2005 though, today libnet and other packet creation libraries have full IPv6 support.) [0x02] Disclaimer 1. This tool is for legal purposes only! 2. The AGPLv3 applies to this code. [0x03] Some Of The Included Tools - parasite6: icmp neighbor solitication/advertisement spoofer, puts you as man-in-the-middle, same as ARP mitm (and parasite) - alive6: an effective alive scanng, which will detect all systems listening to this address - dnsdict6: parallized dns ipv6 dictionary bruteforcer - fake_router6: announce yourself as a router on the network, with the highest priority - redir6: redirect traffic to you intelligently (man-in-the-middle) with a clever icmp6 redirect spoofer - toobig6: mtu decreaser with the same intelligence as redir6 - detect-new-ip6: detect new ip6 devices which join the network, you can run a script to automatically scan these systems etc. - dos-new-ip6: detect new ip6 devices and tell them that their chosen IP collides on the network (DOS). - trace6: very fast traceroute6 with supports ICMP6 echo request and TCP-SYN - flood_router6: flood a target with random router advertisements - flood_advertise6: flood a target with random neighbor advertisements - exploit6: known ipv6 vulnerabilities to test against a target - denial6: a collection of denial-of-service tests againsts a target - fuzz_ip6: fuzzer for ipv6 - implementation6: performs various implementation checks on ipv6 - implementation6d: listen daemon for implementation6 to check behind a fw - fake_mld6: announce yourself in a multicast group of your choice on the net - fake_mld26: same but for MLDv2 - fake_mldrouter6: fake MLD router messages - fake_mipv6: steal a mobile IP to yours if IPSEC is not needed for authentication - fake_advertiser6: announce yourself on the network - smurf6: local smurfer - rsmurf6: remote smurfer, known to work only against linux at the moment - sendpees6: a tool by willdamn(ad)gmail.com, which generates a neighbor solicitation requests with a lot of CGAs (crypto stuff ;-) to keep the CPU busy. nice. - thcping6: sends a hand crafted ping6 packet [and about 30 more tools for you to discover!] [0x04] Installation THC-IPV6 requires libpcap development files being installed, also the libopenssl development files are a good idea. For Debian/Ubunut, you can install them by: $ sudo apt-get install libpcap-dev libssl-dev To compile simply type $ make All tools are installed to /usr/local/bin if you type $ sudo make install [0x05] Documentation THC-IPV6 comes with a rather long README file that describes the details about the usage and library interface. [0x06] Development & Contributions Your contributions are more than welcomed! If you find bugs, coded enhancements or wrote a new attack tool please send them to vh (at) thc (dot) org - and add the word "antispam" to the subject line. [0x07] The Art of Downloading: Source and Binaries The source code of THC-IPV6: thc-ipv6-2.7.tar.gz (Note: Linux only) Comments and suggestions are welcome. Yours sincerly, van Hauser The Hackers Choice http://www.thc.org Sursa: https://www.thc.org/thc-ipv6/

Descriere SnoopSnitch collects and analyzes mobile radio data to make you aware of your mobile network security and to warn you about threats like fake base stations (IMSI catchers), user tracking and over-the-air updates.To use SnoopSnitch, a rooted device with a Qualcomm chipset running stock Android 4.1 or higher is required. Unfortunately, custom ROMs are unsupported at the moment as they lack necessary proprietary drivers. This application uses data contributed by other users. By choosing to upload your measurement results or security events, you can help improve this data base and support future research. SnoopSnitch will ask for confirmation whenever any of your information is uploaded to our servers. All uploads are encrypted. Note that uploaded radio traces may contain private information as a side-effect. The following permissions are required: - ACCESS_SUPERUSER: Open Qualcomm diagnosis interface to capture radio data - CALL_PHONE, READ_PHONE_STATE, SEND_SMS, RECEIVE_SMS: Generate mobile network traffic recorded in active tests - GET_TASKS: Retrieve state of helper processes interacting with diagnosis interface - WAKE_LOCK: Acquire CPU for long-running analysis steps - ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION: record location of IMSI catchers and security events if configured - INTERNET: Download new data from gsmmap.org, upload radio traces and debug logs upon request - ACCESS_NETWORK_STATE: Postpone uploads until network is available SnoopSnitch is open-source software released under the GPL version 3. Visit our project website for source code and further information: https://opensource.srlabs.de/projects/snoopsnitch PGP fingerprint: 9728 A7F9 D457 1FBB 746F 5381 D52C AC10 634A 9561 Sursa: https://play.google.com/store/apps/details?id=de.srlabs.snoopsnitch

Bytecode Viewer is an Advanced Lightweight Java Bytecode Viewer, GUI Procyon Java Decompiler, GUI CFR Java Decompiler, GUI FernFlower Java Decompiler, GUI Jar-Jar, Hex Viewer, Code Searcher, Debugger and more. It's written completely in Java, and it's open sourced. It's currently being maintained and developed by Konloch. There is also a plugin system that will allow you to interact with the loaded classfiles, for example you can write a String deobfuscator, a malicious code searcher, or something else you can think of. You can either use one of the pre-written plugins, or write your own. It supports groovy, python and ruby scripting. Once a plugin is activated, it will execute the plugin with a ClassNode ArrayList of every single class loaded in BCV, this allows the user to handle it completely using ASM. Code from various projects has been used, including but not limited to: J-RET by WaterWolf JHexPane by Sam Koivu RSynaxPane by Robert Futrell Commons IO by Apache ASM by OW2 FernFlower by Stiver Procyon by Mstrobel CFR by Lee Benfield CFIDE by Bibl Contributors: Konloch Bibl Fluke Righteous sahitya-pavurala priav03 Afffsdd If I missed you, please feel free to contact me @konloch or konloch@gmail.com Contribution Guide Lines: Packages must start with the.bytecode.club.bytecodeviewer If code you write can throw an exception, handle it using new the.bytecode.club.bytecodeviewer.ExceptionUI(exception) Video: 2014-11-03_17-17-25 Source Code: https://github.com/konloch/bytecode-viewer Bin/Archive: https://github.com/konloch/bytecode-viewer/releases Java Docs: https://the.bytecode.club/docs/bytecode-viewer/ License (Copyleft): https://raw.githubusercontent.com/Konloch/bytecode-viewer/master/LICENSE Report Bugs (or below): https://github.com/Konloch/bytecode-viewer/issues Discussion Forum: https://the.bytecode.club/forumdisplay.php?fid=69 Key Features: Java Decompiler - It uses a modified version of FernFlower, Procyon and CFR. Bytecode Decompiler - A modified version of CFIDE's. Hex Viewer - Powered by JHexPane. Each Decompiler/Viewer is toggleable. Fully Featured Search System. A Plugin System With Built In Plugins. (Show All Strings, Malicious Code Scanner, String Decrypters, etc) Fully Featured Scripting System That Supports Groovy, Python And Ruby. Recent Files & Recent Plugins. EZ-Inject - Graphically insert hooks and debugging code, invoke main and start the program. And more! Give it a try for yourself! Sursa: https://github.com/Konloch/bytecode-viewer

Prezentare acum la 18:15: SS7: Locate. Track. Manipulate. http://streaming.media.ccc.de/saal1/ Inainte a fost o prezentare despre securitatea cardurilor cu EMV (chip and PIN). Merita vazuta conferinta.

Si eu sunt fan Mozilla si mi l-am umflat cu addon-uri pana a inceput sa mearga ca curul. Apoi am inceput sa mai scot din ele si nu am realizat nimic. Cu Ghostery am avut ceva probleme cu anumite site-uri si l-am scos, am Disconnect. Adblock Plus nu e lipsit.

De vazut: http://streaming.media.ccc.de/

Cica "most secure browser" si e un Chrome cu cateva extensii...

O vazusem si eu acum ceva timp, e misto

TorCoin The power of distributed consensus on the Blockchain leveraged for Tor 1. Abstract 2. Introduction 3. Background 3.1. Tor Scaling Challenges 3.2. Leveraging the Blockchain 3.2.1. Distributed Consensus 3.2.2. Proof of Work 4. Design of TorCoin 4.1. Defining the Transaction 4.2. Validating the Transaction 4.4. Feasibility 5. Security of TorCoin 5.1. 51% Attack 5.2. Denial of Service 5.2.1. Tor DoS Vectors 5.2.2. Blockchain DoS Vectors 5.3. Timejacking 5.4 Sybil Attack 6. Further Work 6.1. P2P Voting 6.2. Hidden Services 6.3. Limited Network Knowledge 7. Conclusions 8. Acknowledgements 9. References 10. Our Code 1. Abstract In this paper we introduce TorCoin, a distributed consensus protocol based on the Bitcoin block chain. This protocol will be used to establish new nodes on the network, and to determine node validity and bandwidth. TorCoin will run in collaboration with TorFlow, an existing code designed to determine bandwidth and monitor node behavior, using an RPC interface. To handle the computational costs of mining, we propose to partially outsource these costs to the Bitcoin network using the existing work sharing protocol. We discuss our implementation and provide an analysis of security concerns. Finally, we provide proof of concept, along with potential directions for future work. Download: http://css.csail.mit.edu/6.858/2014/projects/bchrobot-ynnad19-dereklax.pdf

The Windows User mode heap and the DNS resolver cache. Memory analysis has come a long way in the last few years. There has been a large focus on analysing popular operating system kernels such as Windows, Linux and OSX. We have been able to reconstruct important system information, such as processes, threads, mutexes etc. However, progress has been slower with analysis of applications. Some applications contain a wealth of forensically relevant information, such as recent URLs visited, encryption keys etc. Analyzing applications, however, is difficult because most of the time these are not documented, and debugging symbols are not available or incomplete. Virtually all applications use the heap to allocate memory (e.g. using malloc()/free()). Typically applications request the exact size they need from the heap allocator to accommodate the intended purpose of the memory. By enumerating all heap allocations we can sometimes get a good idea of their purpose. Unlike scanning techniques, heap enumeration allows us to see the memory layouts of structs at the application intends (i.e. we know where the structs begins in memory and how large it is). This blog post explains Rekall’s new heap inspection plugin. In particular I wanted to demonstrate how heap inspection can be used to help reverse engineer some important application, such as the DNS resolver. In windows, DNS requests are typically cached by the DNS resolver service (which is running inside one of the svchost.exe processes). This information is very important from an incident response perspective since it can reveal recently accesses command and control (C&C) connections. However, the DNS resolver is a largely undocumented application, making it an excellent demonstration for heap based analysis. 1. What is a heap? The kernel provides a single mechanism for an application to allocate memory - VirtualAlloc. By calling VirtualAlloc, the process is able to map new pages into its address space. The kernel will set up additional VAD regions and manipulate page tables to ensure this new region may be mapped by physical memory so that the application can use the memory as it pleases. However, in practice, most applications do not need to allocate page sized memory (4kb), rather they need to rapidly allocate and free small allocations (e.g. 20 bytes) to store structs, strings etc. VirtualAlloc is kind of a sledgehammer - its quite slow since it needs to set up page tables, flush TLB etc. Therefore the application uses a heap library. The library is a set of routines in the user process which divides up the large page-sized allocation the kernel can provide into manageable, small allocations the application needs. From the kernel’s point of view, the heap area is a contiguous region of process pages (marked with a VAD). But from the application’s point of view the heap represents a set of arbitrarily sized allocations (obtained via e.g. malloc()). In the following discussion I examine how the heap looks like in a real process. In order to test this I wrote a quick c program which uses malloc() to allocate known strings: [B]#include[/B] [COLOR=red]"Windows.h"[/COLOR] [COLOR=#009900]int[/COLOR] [B][COLOR=black]_tmain[/COLOR][/B][COLOR=#990000]([/COLOR][COLOR=#009900]int[/COLOR] argc[COLOR=#990000],[/COLOR] _TCHAR[COLOR=#990000]*[/COLOR] argv[COLOR=#990000][])[/COLOR] [COLOR=red]{[/COLOR] [COLOR=#009900]int[/COLOR] i[COLOR=#990000];[/COLOR] [COLOR=#009900]char[/COLOR] pattern[COLOR=#990000][][/COLOR] [COLOR=#990000]=[/COLOR] [COLOR=#990000]([/COLOR] [COLOR=red]" "[/COLOR] [I][COLOR=#9a1900]// First byte for the size of allocation.[/COLOR][/I] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR] [COLOR=red]"The quick brown fox jumped over the lazy dog!"[/COLOR][COLOR=#990000]);[/COLOR] [B][COLOR=blue]for[/COLOR][/B][COLOR=#990000]([/COLOR]i[COLOR=#990000]=[/COLOR][COLOR=#993399]0[/COLOR][COLOR=#990000];[/COLOR] i[COLOR=#990000]<[/COLOR][COLOR=#993399]255[/COLOR][COLOR=#990000];[/COLOR] i[COLOR=#990000]++)[/COLOR] [COLOR=red]{[/COLOR] [COLOR=#009900]char[/COLOR] [COLOR=#990000]*[/COLOR]buff [COLOR=#990000]=[/COLOR] [COLOR=#990000]([/COLOR][COLOR=#009900]char[/COLOR] [COLOR=#990000]*)[/COLOR][B][COLOR=black]malloc[/COLOR][/B][COLOR=#990000]([/COLOR]i[COLOR=#990000]+[/COLOR][COLOR=#993399]1[/COLOR][COLOR=#990000]);[/COLOR] [B][COLOR=black]memcpy[/COLOR][/B][COLOR=#990000]([/COLOR]buff[COLOR=#990000],[/COLOR] pattern[COLOR=#990000],[/COLOR] i[COLOR=#990000]);[/COLOR] buff[COLOR=#990000][[/COLOR][COLOR=#993399]0[/COLOR][COLOR=#990000]][/COLOR] [COLOR=#990000]=[/COLOR] i[COLOR=#990000];[/COLOR] [I][COLOR=#9a1900]// Mark the size of allocation in the first byte.[/COLOR][/I] [B][COLOR=blue]if[/COLOR][/B][COLOR=#990000](([/COLOR]i [COLOR=#990000]%[/COLOR] [COLOR=#993399]3[/COLOR][COLOR=#990000])[/COLOR] [COLOR=#990000]==[/COLOR] [COLOR=#993399]0[/COLOR][COLOR=#990000])[/COLOR] [COLOR=red]{[/COLOR] [B][COLOR=black]free[/COLOR][/B][COLOR=#990000]([/COLOR]buff[COLOR=#990000]);[/COLOR] [COLOR=red]}[/COLOR][COLOR=#990000];[/COLOR] [COLOR=red]}[/COLOR][COLOR=#990000];[/COLOR] [B][COLOR=black]Sleep[/COLOR][/B][COLOR=#990000]([/COLOR][COLOR=#993399]100000[/COLOR][COLOR=#990000]);[/COLOR] [B][COLOR=blue]return[/COLOR][/B] [COLOR=#993399]0[/COLOR][COLOR=#990000];[/COLOR] [COLOR=red]}[/COLOR] This program simply allocates a string of increasing length and marks the length of the string in the first byte. The program also frees every third string. Finally the program simply sleeps, allowing us to either examine the live system memory, or acquire a memory image capturing the process memory. I just ran the ewfacquire plugin to write an EWF format image called output.E01 from within the Rekall interactive shell. [TABLE=width: 100%] [TR] [TD=class: icon][/TD] [TD=class: content] When compiling the test program one should select the Release mode rather than the Debug mode. Compiling in Debug mode creates different heap structures which are larger and contain a lot of debugging information. It might be useful for Rekall to also support debugging heaps but currently we only support release heaps.[/TD] [/TR] [/TABLE] 2. The windows HEAP implementation. Implementing an efficient heap is actually a very complex task, since it needs to be very fast, use memory efficiently, and reduce memory fragmentation. Additionally heaps need to defend themselves from exploitation by being resilient to heap overflows. The Microsoft default heap implementation is implemented in ntdll.dll and is therefore available by default in all processes. Although it is possible for an application to use a different heap implementation, this is rarely done - most applications use the standard heap library. The Microsoft heap has been studied extensively by the security community. The seminal references are: Understanding the LFH Windows 8 Heap Internals Understanding the Windows Allocator: A Redux These documents are very detailed and cover the heap operation algorithms with a general focus on exploitation. For our purposes, the information is too detailed, since we are only interested in enumerating all heap allocations and care less about how the heap actually works. I will therefore explain at a high level how the heap looks in memory and skip all the gory details of how the heap actually works. The Microsoft heap implementation is divided into two parts - the Front End Allocator and the Back End Allocator. The Back End allocator is the one which actually requests memory from the kernel, managing relatively large blocks of memory. The Front End allocator is a fine grained allocator which further divides large memory regions (obtained from the backend allocator) into efficiently managed small allocations. In Windows 7 there is only one type of front end allocator named the Low Fragmentation Heap (LFH). Another important point to make is that a single process may have multiple heaps for different purposes. This helps to keep related data together. We can see all the heaps that a process contains by examining the _EPROCESS.Peb.ProcessHeaps array in the Rekall interactive shell: [1] output.E01 09:37:11> pslist proc_regex="heap" _EPROCESS Name PID PPID Thds Hnds Sess Wow64 Start Exit -------------- -------------------- ----- ------ ------ -------- ------ ------ ------------------------ ------------------------ 0xfa8002c04060 heap.exe 2628 2956 1 7 1 False 2014-12-16 10:25:29+0000 - [1] output.E01 09:47:37> task = session.profile._EPROCESS(0xfa8002c04060) [1] output.E01 09:48:06> for heap in task.Peb.ProcessHeaps: print repr(heap) <_HEAP Pointer to [0x00060000] (ProcessHeaps[0] )> <_HEAP Pointer to [0x00010000] (ProcessHeaps[1] )> <_HEAP Pointer to [0x00020000] (ProcessHeaps[2] )> <_HEAP Pointer to [0x003C0000] (ProcessHeaps[3] )> So there are 4 process heaps in this process. Note that each of these heaps exists in a VAD region: [1] output.E01 09:51:48> vad pid=2628 ************************************************** Pid: 2628 heap.exe VAD lev Start Addr End Addr com ------- ------ Protect Filename -------------- --- -------------- -------------- ---- -------------------- -------- 0xfa8002eec850 1 0x000000210000 0x00000030ffff 5 Private READWRITE 0xfa8001e30ed0 2 0x000000050000 0x000000050fff 1 Private READWRITE 0xfa8000df2ba0 3 0x000000030000 0x000000033fff 0 Mapped READONLY 0xfa8001754a10 4 0x000000010000 0x00000001ffff 0 Mapped READWRITE <----- Heap 0xfa8001c0e480 5 0x000000020000 0x00000002ffff 0 Mapped READWRITE <----- Heap 0xfa8000e83230 4 0x000000040000 0x000000040fff 0 Mapped READONLY 0xfa80010d7c00 3 0x000000060000 0x00000015ffff 25 Private READWRITE <----- Heap 0xfa8002acd1b0 4 0x000000160000 0x0000001c6fff 0 Mapped READONLY \Windows\System32\locale.nls 0xfa8000e12990 2 0x00007ffe0000 0x00007ffeffff -1 Private READONLY 0xfa8002ec2ad0 3 0x000076fc0000 0x000077168fff 12 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\ntdll.dll 0xfa8001645580 4 0x00006da20000 0x00006daf1fff 10 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\msvcr100.dll 0xfa8000df4e60 5 0x0000003c0000 0x0000003cffff 16 Private READWRITE <----- Heap 0xfa8002e460d0 6 0x0000003d0000 0x0000004cffff 17 Private READWRITE 0xfa8001bbc680 5 0x000076ea0000 0x000076fbefff 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\kernel32.dll 0xfa8001737160 4 0x00007f0e0000 0x00007ffdffff 0 Private READONLY 0xfa8001dee1b0 5 0x00007efe0000 0x00007f0dffff 0 Mapped READONLY 0xfa8002ec2d60 3 0x07fffffb0000 0x07fffffd2fff 0 Mapped READONLY 0xfa80010d06d0 4 0x07fefcdf0000 0x07fefce5bfff 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\KernelBase.dll 0xfa8002e1f8d0 5 0x00013f350000 0x00013f356fff 2 Mapped Exe EXECUTE_WRITECOPY \Users\mic\Documents\Visual Studio 2010\Projects\heap\x64\Release\heap.exe 0xfa8000e39010 5 0x07feff2e0000 0x07feff2e0fff 0 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\apisetschema.dll 0xfa80011eb200 4 0x07fffffdd000 0x07fffffddfff 1 Private READWRITE 0xfa800148da10 5 0x07fffffde000 0x07fffffdffff 2 Private READWRITE 2.1. The Back End allocator. The Back End allocator uses VirtualAlloc system calls to carve out large regions of contiguous memory. The memory is divided into regions called Segments. Each segment has a_HEAP_SEGMENT struct at its start. Segments form a linked list headed at the _HEAP.SegmentListEntry (Note that _HEAP is also a _HEAP_SEGMENT and therefore the first segment is the _HEAPstruct itself). [1] output.E01 10:02:20> for seg in heap.SegmentListEntry.list_of_type("_HEAP_SEGMENT", "SegmentListEntry"): |..> print repr(seg) [_HEAP_SEGMENT _HEAP_SEGMENT] @ 0x003D0000 [_HEAP_SEGMENT _HEAP_SEGMENT] @ 0x003C0110 The Back End allocator further subdivides the Segments into smaller allocations to service user (and Front End) requests. Each of these user allocations is preceded with a _HEAP_ENTRY struct. On 64 bits Windows 7 this is: [1] output.E01 10:10:07> dt "_HEAP_ENTRY" [_HEAP_ENTRY _HEAP_ENTRY] @ 0x000000 Offset Field Content -------------------- ------------------------------ ------- 0x0 PreviousBlockPrivateData <Void Pointer to [0x00000000] (PreviousBlockPrivateData)> 0x0 Reserved <Void Pointer to [0x00000000] (Reserved)> 0x0 ReservedForAlignment <Void Pointer to [0x00000000] (ReservedForAlignment)> 0x8 AgregateCode [unsigned long long:AgregateCode]: 0x00000000 0x8 Code1 [unsigned long:Code1]: 0x00000000 0x8 CompactHeader [unsigned long long:CompactHeader]: 0x00000000 0x8 FunctionIndex [unsigned short:FunctionIndex]: 0x00000000 0x8 InterceptorValue [unsigned long:InterceptorValue]: 0x00000000 0x8 Size [unsigned short:Size]: 0x00000000 0xa ContextValue [unsigned short:ContextValue]: 0x00000000 0xa Flags [Flags:Flags]: 0x00000000 () 0xb SmallTagIndex [unsigned char:SmallTagIndex]: 0x00000000 0xc Code2 [unsigned short:Code2]: 0x00000000 0xc PreviousSize [unsigned short:PreviousSize]: 0x00000000 0xc UnusedBytesLength [unsigned short:UnusedBytesLength]: 0x00000000 0xe Code3 [unsigned char:Code3]: 0x00000000 0xe EntryOffset [unsigned char:EntryOffset]: 0x00000000 0xe LFHFlags [unsigned char:LFHFlags]: 0x00000000 0xe SegmentOffset [unsigned char:SegmentOffset]: 0x00000000 0xf Code4 [unsigned char:Code4]: 0x00000000 0xf ExtendedBlockSignature [unsigned char:ExtendedBlockSignature]: 0x00000000 0xf UnusedBytes [unsigned char:UnusedBytes]: 0x00000000 For now I will point out the Size and PreviousSize members of the header (Both are expressed in terms of allocation blocks - 16 bytes on AMD64). This means that it is possible to follow_HEAP_ENTRY structs along the Segment from start to end. In fact one can notice that many heap structs (e.g. _HEAP, _HEAP_SEGMENT) start with a _HEAP_ENTRY. One can start at the start of the segment and walk the entries to the end of the segment. Most of the smarts in the Back End allocator is about managing allocated and freed entries. The backend always maintains the property that _HEAP_ENTRYs can be walked over to enumerate them all. Since we only really care about enumerating all user allocations we don’t particularly care about the specific algorithms the heap uses to manage its free lists, only where the final chunks are to be found. There is a small trick though. In order to prevent traditional heap overflow attacks, the _HEAP_ENTRY is encoded by XORing it with a unique heap specific key. Therefore before we can read the_HEAP_ENTRY we must XOR it with _HEAP.Encoding. I have written a plugin that can be used to visualize these allocations. For each heap it lists the segment and then enumerates the heap entries (after decoding them with the heap key) and displays the first few bytes of each allocation. In our case only the last heap is interesting: [1] output.E01 10:25:02> inspect_heap proc_regex="heap", heaps=[4] DEBUG:root:Switching to process context: heap.exe (Pid 2628@0xfa8002c04060) ************************************************** [_EPROCESS _EPROCESS] @ 0xFA8002C04060 (pid=2628) Heap 4: 0x3c0000 (LOW_FRAG) Backend Info: Segment End Length Data --------------- -------------- ---------- ---- . 0x3c0040 0x3d0000 65472 .. 0x3c0a80 0x3c12e0 2128 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 ................ .. 0x3c12e0 0x3c15b0 704 50 03 00 00 00 00 00 00 ff ff ff ff ff ff ff ff P............... .. 0x3c15b0 0x3c20c0 2816 03 00 00 00 00 00 00 00 c1 0a 00 00 01 00 00 00 ................ .. 0x3c20c0 0x3c28c0 2032 30 c5 3d 00 00 00 00 00 20 9a 3c 00 00 00 00 00 0.=.......<..... .. 0x3c28c0 0x3c2900 48 46 00 72 00 61 00 6d 00 65 00 77 00 6f 00 72 00 F.r.a.m.e.w.o.r. .. 0x3c2900 0x3c2ad0 448 49 00 4e 00 43 00 4c 00 55 00 44 00 45 00 3d 00 I.N.C.L.U.D.E.=. .. 0x3c2ad0 0x3c2c00 288 4c 00 49 00 42 00 3d 00 63 00 3a 00 5c 00 50 00 L.I.B.=.c.:.\.P. .. 0x3c2c00 0x3c2c60 80 4c 00 4f 00 43 00 41 00 4c 00 41 00 50 00 50 00 L.O.C.A.L.A.P.P. .. 0x3c2c60 0x3c2ca0 48 4e 00 55 00 4d 00 42 00 45 00 52 00 5f 00 4f 00 N.U.M.B.E.R._.O. .. 0x3c2ca0 0x3c2d30 128 50 00 41 00 54 00 48 00 45 00 58 00 54 00 3d 00 P.A.T.H.E.X.T.=. .... .. 0x3c7700 0x3c7f00 2032 00 c5 3d 00 00 00 00 00 58 01 3c 00 00 00 00 00 ..=.....X.<..... .... .. 0x3c8fd0 0x3c9020 64 38 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 8The.quick.brown .. 0x3c9020 0x3c9070 64 3a 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e :The.quick.brown .. 0x3c9070 0x3c90c0 64 3b 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e ;The.quick.brown .. 0x3c90c0 0x3c9120 80 49 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e IThe.quick.brown .. 0x3c9120 0x3c9180 80 4a 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e JThe.quick.brown .. 0x3c9180 0x3c91e0 80 4c 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e LThe.quick.brown .. 0x3c91e0 0x3c9240 80 4d 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e MThe.quick.brown .. 0x3c9240 0x3c92a0 80 4f 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e OThe.quick.brown .. 0x3c92a0 0x3c9300 80 50 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e PThe.quick.brown .. 0x3c9300 0x3c9360 80 52 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e RThe.quick.brown ... .. 0x3caba0 0x3cbba0 4080 60 c5 3d 00 00 00 00 00 e0 8f 3c 00 00 00 00 00 `.=.......<..... .. 0x3cbba0 0x3ccba0 4080 90 c5 3d 00 00 00 00 00 d0 90 3c 00 00 00 00 00 ..=.......<..... .. 0x3ccba0 0x3cdba0 4080 c0 c5 3d 00 00 00 00 00 90 94 3c 00 00 00 00 00 ..=.......<..... .. 0x3cdba0 0x3cdc10 96 65 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e eThe.quick.brown We can see some of the allocations that our program made in the output, but closely examining the data shows that not all allocations are found. 2.2. The Front End Allocator. On Windows 7 the only Front End Allocator available is the Low Fragmentation Heap (LFH) front end. The front end is set for a particular heap in the _HEAP.FrontEndHeapType enumeration which can be 0 (backend only) or 2 (LFH). The _LFH_HEAP struct contains the low fragmentation heap and is set in _HEAP.FrontEndHeap if it is used. In the following discussion is skip over some of the low level details so please take a look at the source code for the inspect_heap plugin for the gory details. The heap starts off with only a backend allocator active. If the heap heuristics detect that the application might benefit from a low fragmentation heap, the LFH is created and added to the heap. Note that LFH is only used for smallish allocations. Larger allocations still end up going to the backend directly. The LFH claims sub-segments from the backend allocator. Each subsegment starts with a _HEAP_USERDATA_HEADER and it is followed by an array of allocations of the same size. Each such allocation has a _HEAP_ENTRY at the start. To the backend allocator the subsegments simply look like largish opaque allocations (and are therefore also contained in a backend _HEAP_ENTRY ). The LFH reuses the _HEAP_ENTRY struct (again encoded with the heap’s key) to describe each allocation, but since all entries in a subsegments are the same size, there is no need to use Size andPreviousSize to track them. The _HEAP_ENTRY.UnusedBytes member describes how many bytes are unused in the allocation (e.g. if the allocation is 20 bytes but the user only wanted 18 bytes there are 2 bytes unused), and also contains flags to indicate if the entry is BUSY or FREE. We can see the LFH allocations for our example (output just follows the previous command): Low Fragmentation Front End Information: Entry Alloc Length Data -------------- ------ ------ ---- 0x3c7730 32 21 54 41 52 47 45 54 5f 50 4c 41 54 46 4f 52 4d 3d TARGET_PLATFORM= 57 49 4e 37 00 WIN7. 0x3c7750 32 17 54 6f 6f 6c 73 56 65 72 73 69 6f 6e 3d 34 2e 30 ToolsVersion=4.0 00 . 0x3c7770 32 15 55 53 45 52 44 4f 4d 41 49 4e 3d 64 65 76 00 USERDOMAIN=dev. 0x3c7790 32 13 55 53 45 52 4e 41 4d 45 3d 6d 69 63 00 USERNAME=mic. 0x3c77b0 32 18 77 69 6e 64 69 72 3d 43 3a 5c 57 69 6e 64 6f 77 windir=C:\Window 73 00 s. 0x3c77d0 32 24 e0 16 ab 6d 00 00 00 00 98 9a ab 6d 00 00 00 00 ...m.......m.... 00 00 00 00 00 00 00 00 ........ 0x3c77f0 32 22 41 00 50 00 50 00 56 00 45 00 52 00 3d 00 36 00 A.P.P.V.E.R.=.6. 2e 00 31 00 00 00 ..1... 0x3c7810 32 24 50 00 52 00 4f 00 4d 00 50 00 54 00 3d 00 24 00 P.R.O.M.P.T.=.$. 50 00 24 00 47 00 00 00 P.$.G... 0x3c7830 32 9 08 54 68 65 20 71 75 69 00 .The.qui. 0x3c7850 32 11 0a 54 68 65 20 71 75 69 63 6b 00 .The.quick. 0x3c7870 32 12 0b 54 68 65 20 71 75 69 63 6b 20 00 .The.quick.. 0x3c7890 32 14 0d 54 68 65 20 71 75 69 63 6b 20 62 72 00 .The.quick.br. 0x3c78b0 32 15 0e 54 68 65 20 71 75 69 63 6b 20 62 72 6f 00 .The.quick.bro. 0x3c78d0 32 17 10 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 00 . 0x3c78f0 32 18 11 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 00 .. 0x3c7910 32 20 13 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 00 .fo. 0x3c7930 32 21 14 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 78 00 .fox. 0x3c7950 32 23 16 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 78 20 6a 00 .fox.j. 0x3c7970 32 24 17 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 78 20 6a 75 00 .fox.ju. .... 0x3c2390 48 26 19 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 78 20 6a 75 6d 70 69 .fox.jumpi 0x3c23c0 48 27 1a 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 78 20 6a 75 6d 70 65 5c .fox.jumpe\ 0x3c23f0 48 29 1c 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 78 20 6a 75 6d 70 65 64 20 74 .fox.jumped.t 0x3c2420 48 30 1d 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 78 20 6a 75 6d 70 65 64 20 6f 63 .fox.jumped.oc 0x3c2450 48 32 1f 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 78 20 6a 75 6d 70 65 64 20 6f 76 65 4c .fox.jumped.oveL 0x3c2480 48 33 20 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 20 66 6f 78 20 6a 75 6d 70 65 64 20 6f 76 65 72 .fox.jumped.over 2e . 0x3c24b0 48 35 22 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e "The.quick.brown 20 66 6f 78 20 6a 75 6d 70 65 64 20 6f 76 65 72 .fox.jumped.over 20 74 31 .t1 ..... We can see a series of allocations of size 0x20 which can hold strings up to size 24 (8 bytes must be reserved for the _HEAP_ENTRY header). Further allocations must skip to the next sub-segment which contains allocations of size 48. Note also that as far as the backend is concerned each of the sub-segments are unique opaque allocations in their own right (they appear in the previous listing too) but the backend does not see inside the subsegments to enumerate the smaller allocations. Note that the allocation of size 25 is missing since it was freed (i=24 and 24 % 3 == 0) and then probably reused for allocation of size 26. You can verify that all the allocated strings can be enumerated by a combination of front end and back end enumerations. It is instructive to see the allocations using the regular Rekall dump plugin to view a hexdump of the allocations (We must remember to switch to the correct process context first using the cc plugin so we can read the process address space): [1] output.E01 11:09:06> cc proc_regex="heap" Switching to process context: heap.exe (Pid 2628@0xfa8002c04060) [1] output.E01 11:30:06> dump 0x3c7950 Offset Hex Data -------------- ------------------------------------------------ ---------------- 0x3c7950 20 66 6f 78 00 00 00 00 80 f9 a4 45 19 00 00 89 .fox.......E.... 0x3c7960 16 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 0x3c7970 20 66 6f 78 20 6a 00 00 82 f9 a4 45 19 00 00 88 .fox.j.....E.... 0x3c7980 17 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e .The.quick.brown 0x3c7990 20 66 6f 78 20 6a 75 00 8c f9 a4 45 19 00 00 80 .fox.ju....E.... 0x3c79a0 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *............... The inspect_heap plugin indicates that the entry at offset 0x3c7950 is an allocation of length 23 bytes. This offset contains an _HEAP_ENTRY struct, but we can see a weird effect - the first 8 bytes appear to belong to the previous allocation. This is a weird implementation detail of the Microsoft heap. The first 8 bytes of the _HEAP_ENTRY struct (which is normally 16 bytes long) are actually reserved for the previous allocation and named _HEAP_ENTRY.PreviousBlockPrivateData. An allocation is allowed to overflow up to 8 bytes into the next _HEAP_ENTRY. Therefore for an allocation of size 32 bytes, there are 24 user usable bytes. It is useful to recognize this effect when looking at the hexdump of raw memory. This effect only occurs on 64 bit systems. The next 4 bytes belong to the _HEAP_ENTRY but before we read them we need to decode the entry using the heap key. The final byte (0x89) is the UnusedBytes field which is not encoded. In the LFH this field can be ANDed with 0x38 to determine if the allocation is BUSY or FREE. Subtracting 0x88 gives the number of unused bytes in the allocation (in the above case 1 byte unused). 3. The Windows DNS Resolver. So now we have the ability to enumerate all application heap allocations. So what can we use this for? As an example I chose to examine the windows DNS resolver service. This is implemented as an in-process service (i.e. it is running as a thread in a shared process with other services). The resolver is implemented using dnsrslvr.dll which is linked into one of the svchost.exe shared service hosting processes. To test this I used Chrome to browse to a bunch of websites and then ensured that the DNS cache was populated, and obtained a memory image. You can check the DNS cache using the ipconfig /displaydns command: C:\Program Files\Rekall>ipconfig /displaydns Windows IP Configuration clients4.google.com ---------------------------------------- Record Name . . . . . : clients4.google.com Record Type . . . . . : 5 Time To Live . . . . : 3566 Data Length . . . . . : 8 Section . . . . . . . : Answer CNAME Record . . . . : clients.l.google.com code.jquery.com ---------------------------------------- Record Name . . . . . : code.jquery.com Record Type . . . . . : 5 Time To Live . . . . : 3577 Data Length . . . . . : 8 Section . . . . . . . : Answer CNAME Record . . . . : code.jquery.netdna-cdn.com apis.google.com ---------------------------------------- Record Name . . . . . : apis.google.com Record Type . . . . . : 5 Time To Live . . . . : 3571 Data Length . . . . . : 8 Section . . . . . . . : Answer CNAME Record . . . . : plus.l.google.com [URL="http://www.google.com"]Google[/URL] ---------------------------------------- Record Name . . . . . : [URL="http://www.google.com"]Google[/URL] Record Type . . . . . : 1 Time To Live . . . . : 3539 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 173.194.72.147 Record Name . . . . . : [URL="http://www.google.com"]Google[/URL] Record Type . . . . . : 1 Time To Live . . . . : 3539 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 173.194.72.99 At this stage we have zero knowledge of how the resolver cache works, but we know it stores DNS records, hostnames and IP addresses. We can imagine that it stores these on the heap and probably has some data structures it uses to maintain these details. Usually before an application creates a new data structure it must allocate the memory from the heap - normally the exact size of the allocation depends on the data structure (so it can fit in the allocated memory). So examining the allocation of the resolver cache might give us a clue as to how it organizes its own data. The first step is to find the process where the resolver is running in. We use the vad plugin to locate the svchost process which hosts the dnsrslvr.dll (filter by both process name and VAD filename): [1] output.E01 11:46:45> vad proc_regex="svchost", regex="dnsrslvr.dll" .... [uninteresting output omitted] Pid: 1076 svchost.exe VAD lev Start Addr End Addr com Protect Filename -------------- --- -------------- -------------- ---- ------- ------ -------------------- -------- 0xfa800271fb80 4 0x07fef9a20000 0x07fef9a4ffff 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\dnsrslvr.dll Ok great. This tells us the process we care about has a pid of 1076 and that the DLL is mapped in the range 0x07fef9a20000-0x07fef9a4ffff. Lets inspect its heaps. There is a lot of output here - the process has 12 heaps with a lot of allocations. However, we can immediately recognize some of the hostnames we are looking for in heap number 4: [1] output.E01 12:08:26> inspect_heap pid=1076, heaps=[4] DEBUG:root:Switching to process context: svchost.exe (Pid 1076@0xfa800271c630) ************************************************** [_EPROCESS _EPROCESS] @ 0xFA800271C630 (pid=1076) Heap 4: 0x11a0000 (BACKEND) Backend Info: Segment End Length Data --------------- -------------- ---------- ---- . 0x11a0040 0x1220000 524224 .. 0x11a0a80 0x11a12f0 2144 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 ................ .. 0x11a12f0 0x11a1500 512 00 13 1a 01 00 00 00 00 00 13 1a 01 00 00 00 00 ................ .. 0x11a1500 0x11a2240 3376 10 15 1a 01 00 00 00 00 10 15 1a 01 00 00 00 00 ................ .. 0x11a2240 0x11a2280 48 d0 22 1a 01 00 00 00 00 40 93 a4 f9 fe 07 00 00 ."..... @[URL="https://rstforums.com/forum/member.php?u=84839"].......[/URL] .. 0x11a2280 0x11a22c0 48 d0 22 1a 01 00 00 00 00 50 22 1a 01 00 00 00 00 ."......P"...... .. 0x11a22c0 0x11a2300 48 10 23 1a 01 00 00 00 00 50 22 1a 01 00 00 00 00 .#......P"...... .. 0x11a2300 0x11a2340 48 50 23 1a 01 00 00 00 00 d0 22 1a 01 00 00 00 00 P#......."...... .. 0x11a2340 0x11a2380 48 90 23 1a 01 00 00 00 00 10 23 1a 01 00 00 00 00 .#.......#...... .. 0x11a2380 0x11a23c0 48 40 32 1a 01 00 00 00 00 50 23 1a 01 00 00 00 00 @2......P#...... .. 0x11a23c0 0x11a23f0 32 07 00 00 00 30 75 00 00 60 ea 00 00 c0 d4 01 00 ....0u..`....... .. 0x11a23f0 0x11a2410 16 64 00 65 00 76 00 00 00 58 01 1a 01 00 00 00 00 d.e.v...X....... .. 0x11a2410 0x11a24a0 128 02 00 78 00 05 00 00 00 00 00 14 00 00 00 00 10 ..x............. .. 0x11a24a0 0x11a24e0 48 01 00 04 00 00 00 00 00 c0 d3 51 00 00 00 00 00 ..........Q..... .. 0x11a24e0 0x11a25e0 240 00 00 00 00 00 00 00 00 f0 25 1a 01 00 00 00 00 .........%...... .. 0x11a25e0 0x11a2600 16 64 00 65 00 76 00 00 00 58 01 1a 01 00 00 00 00 d.e.v...X....... .. 0x11a2600 0x11a2620 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11a2620 0x11a2680 80 7b 00 32 00 31 00 43 00 35 00 30 00 31 00 36 00 {.2.1.C.5.0.1.6. .. 0x11a2680 0x11a26c0 48 4c 00 6f 00 63 00 61 00 6c 00 20 00 41 00 72 00 L.o.c.a.l...A.r. .. 0x11a26c0 0x11a2770 160 02 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11a2770 0x11a27e0 96 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11a27e0 0x11a2840 80 7b 00 31 00 41 00 38 00 34 00 44 00 37 00 44 00 {.1.A.8.4.D.7.D. .. 0x11a2840 0x11a28a0 80 54 00 65 00 72 00 65 00 64 00 6f 00 20 00 54 00 T.e.r.e.d.o...T. .. 0x11a28a0 0x11a28d0 32 ac 02 00 00 00 00 00 00 50 05 00 00 00 00 00 00 ........P....... .. 0x11a28d0 0x11a2900 32 10 2b 1a 01 00 00 00 00 c0 3b 1c 01 00 00 00 00 .+.......;...... .. 0x11a2900 0x11a2920 16 64 00 65 00 76 00 00 00 58 01 1a 01 00 00 00 00 d.e.v...X....... .. 0x11a2920 0x11a2980 80 90 2a 1a 01 00 00 00 00 10 37 1c 01 00 00 00 00 .*.......7...... .. 0x11a2980 0x11a29d0 64 4c 00 6f 00 63 00 61 00 6c 00 20 00 41 00 72 00 L.o.c.a.l...A.r. .. 0x11a29d0 0x11a2a10 48 b0 6b 1f 01 00 00 00 00 60 2a 1a 01 00 00 00 00 .k......`*...... .. 0x11a2a10 0x11a2a50 48 70 00 79 00 74 00 68 00 6f 00 6e 00 2e 00 6d 00 p.y.t.h.o.n...m. .. 0x11a2a50 0x11a2a80 32 77 00 77 00 77 00 2e 00 70 00 79 00 74 00 68 00 w.w.w...p.y.t.h. .. 0x11a2a80 0x11a2ae0 80 40 2c 1a 01 00 00 00 00 30 29 1a 01 00 00 00 00 @,......0)...... .. 0x11a2ae0 0x11a2b00 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11a2b00 0x11a2b30 32 60 56 1f 01 00 00 00 00 e0 28 1a 01 00 00 00 00 `V.......(...... .. 0x11a2b30 0x11a2b70 48 00 2c 1a 01 00 00 00 00 c0 2b 1a 01 00 00 00 00 .,.......+...... .. 0x11a2b70 0x11a2bb0 48 63 00 6c 00 69 00 65 00 6e 00 74 00 73 00 2e 00 c.l.i.e.n.t.s... .. 0x11a2bb0 0x11a2bf0 48 63 00 6c 00 69 00 65 00 6e 00 74 00 73 00 34 00 c.l.i.e.n.t.s.4. .. 0x11a2bf0 0x11a2c30 48 d0 35 1c 01 00 00 00 00 90 35 1c 01 00 00 00 00 .5.......5...... .. 0x11a2c30 0x11a2cd0 144 c0 69 1f 01 00 00 00 00 90 2a 1a 01 00 00 00 00 .i.......*...... .. 0x11a2cd0 0x11a2cf0 16 64 00 65 00 76 00 00 00 58 01 1a 01 00 00 00 00 d.e.v...X....... .. 0x11a2cf0 0x11a2d10 16 20 32 1a 01 00 00 00 00 58 01 1a 01 00 00 00 00 .2......X....... .. 0x11a2d10 0x11a2dc0 160 02 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11a2dc0 0x11a2ec0 240 02 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11a2ec0 0x11a2f00 48 67 00 6f 00 6f 00 67 00 6c 00 65 00 61 00 70 00 g.o.o.g.l.e.a.p. .. 0x11a2f00 0x11a2f50 64 74 00 72 00 61 00 6e 00 73 00 6c 00 61 00 74 00 t.r.a.n.s.l.a.t. .. 0x11a2f50 0x11a2f90 48 20 30 1a 01 00 00 00 00 e0 2f 1a 01 00 00 00 00 .0......./...... .. 0x11a2f90 0x11a2fd0 48 63 00 6c 00 69 00 65 00 6e 00 74 00 73 00 2e 00 c.l.i.e.n.t.s... .. 0x11a2fd0 0x11a3010 48 63 00 6c 00 69 00 65 00 6e 00 74 00 73 00 31 00 c.l.i.e.n.t.s.1. .. 0x11a3010 0x11a3050 48 a0 30 1a 01 00 00 00 00 60 30 1a 01 00 00 00 00 .0......`0...... .. 0x11a3050 0x11a3090 48 63 00 6c 00 69 00 65 00 6e 00 74 00 73 00 2e 00 c.l.i.e.n.t.s... .. 0x11a3090 0x11a30d0 48 e0 30 1a 01 00 00 00 00 00 00 00 00 00 00 00 00 .0.............. .. 0x11a30d0 0x11a3120 64 d0 5f 1f 01 00 00 00 00 00 00 00 00 00 00 00 00 ._.............. .. 0x11a3120 0x11a3160 48 90 36 1c 01 00 00 00 00 10 2f 1a 01 00 00 00 00 .6......./...... .. 0x11a3160 0x11a31a0 48 e0 31 1a 01 00 00 00 00 b0 31 1a 01 00 00 00 00 .1.......1...... .. 0x11a31a0 0x11a31d0 32 77 00 77 00 77 00 2e 00 67 00 6f 00 6f 00 67 00 w.w.w...g.o.o.g. .. 0x11a31d0 0x11a3210 48 e0 3b 1c 01 00 00 00 00 00 00 00 00 00 00 00 00 .;.............. .. 0x11a3210 0x11a3230 16 d0 37 1c 01 00 00 00 00 00 2d 1a 01 00 00 00 00 .7.......-...... .. 0x11a3230 0x11a3270 48 40 93 a4 f9 fe 07 00 00 90 23 1a 01 00 00 00 00 @[URL="https://rstforums.com/forum/member.php?u=84839"].......[/URL].#...... .. 0x11a3270 0x11b33a0 65824 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11b33a0 0x11c34d0 65824 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11c34d0 0x11c3580 160 f0 65 1f 01 00 00 00 00 40 2c 1a 01 00 00 00 00 .e......@,...... .. 0x11c3580 0x11c35c0 48 63 00 6c 00 69 00 65 00 6e 00 74 00 73 00 2e 00 c.l.i.e.n.t.s... .. 0x11c35c0 0x11c3600 48 10 36 1c 01 00 00 00 00 00 00 00 00 00 00 00 00 .6.............. .. 0x11c3600 0x11c3640 48 50 36 1c 01 00 00 00 00 00 00 00 00 00 00 00 00 P6.............. .. 0x11c3640 0x11c3680 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11c3680 0x11c36c0 48 00 00 00 00 00 00 00 00 d0 36 1c 01 00 00 00 00 .........6...... .. 0x11c36c0 0x11c3700 48 67 00 6f 00 6f 00 67 00 6c 00 65 00 61 00 70 00 g.o.o.g.l.e.a.p. .. 0x11c3700 0x11c3760 80 30 29 1a 01 00 00 00 00 60 56 1f 01 00 00 00 00 0)......`V...... .. 0x11c3760 0x11c37c0 80 7b 00 32 00 31 00 43 00 35 00 30 00 31 00 36 00 {.2.1.C.5.0.1.6. .. 0x11c37c0 0x11c37e0 16 f0 39 1c 01 00 00 00 00 20 32 1a 01 00 00 00 00 .9.......2...... .. 0x11c37e0 0x11c3830 64 63 00 6f 00 64 00 65 00 2e 00 6a 00 71 00 75 00 c.o.d.e...j.q.u. .. 0x11c3830 0x11c3870 48 d0 38 1c 01 00 00 00 00 80 38 1c 01 00 00 00 00 .8.......8...... .. 0x11c3870 0x11c38c0 64 63 00 6f 00 64 00 65 00 2e 00 6a 00 71 00 75 00 c.o.d.e...j.q.u. .. 0x11c38c0 0x11c3900 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11c3900 0x11c3930 32 64 00 65 00 76 00 00 00 58 01 1a 01 00 00 00 00 d.e.v...X....... .. 0x11c3930 0x11c3970 48 b0 39 1c 01 00 00 00 00 80 39 1c 01 00 00 00 00 .9.......9...... .. 0x11c3970 0x11c39a0 32 73 00 73 00 6c 00 2e 00 67 00 73 00 74 00 61 00 s.s.l...g.s.t.a. .. 0x11c39a0 0x11c39e0 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x11c39e0 0x11c3a00 16 c0 3b 1c 01 00 00 00 00 d0 37 1c 01 00 00 00 00 .;.......7...... .. 0x11c3a00 0x11c3a40 48 e0 3a 1c 01 00 00 00 00 a0 3a 1c 01 00 00 00 00 .:.......:...... .. 0x11c3a40 0x11c3a90 64 65 00 31 00 30 00 30 00 38 00 38 00 2e 00 64 00 e.1.0.0.8.8...d. .. 0x11c3a90 0x11c3ad0 48 77 00 77 00 77 00 2e 00 6d 00 69 00 63 00 72 00 w.w.w...m.i.c.r. .. 0x11c3ad0 0x11c3b10 48 60 3c 1c 01 00 00 00 00 70 3b 1c 01 00 00 00 00 `<......p;...... .. 0x11c3b10 0x11c3b60 64 74 00 6f 00 67 00 67 00 6c 00 65 00 2e 00 77 00 t.o.g.g.l.e...w. ..... [TABLE=width: 100%] [TR] [TD=class: icon][/TD] [TD=class: content] Windows can have many heaps in each process. Sometimes an application can deliberately create multiple heaps to keep similar data together for some reason. Often data within the same heap is somehow related - as in this case - all the data in this heap involves the DNS resolver. This makes it easier to make sense of data since its more likely that the data we are looking for exist in this heap.[/TD] [/TR] [/TABLE] We can see some host names allocated in this heap. This makes sense - the application must have data structures to maintain state and these should have pointers to the allocated strings from the heap. For example consider the string "www.google.com" at allocation offset 0x11a31a0. There should be a pointer somewhere pointing to this string (Note that 0x11a31a0 is the offset to the_HEAP_ENTRY - the user allocation is 16 bytes later). We can use the grep plugin to find this pointer. We first assume it is located in this heap so we start the search from the heap’s starting address 0x11a0040: [1] output.E01 12:33:03> cc 1076 Switching to process context: svchost.exe (Pid 1076@0xfa800271c630) [1] output.E01 12:33:21> grep 0x11a0040, keyword="\xb0\x31\x1a\x01" Offset Hex Data -------------- ------------------------------------------------------------ -------------------- 0x11a3164 00 00 00 00 e1 42 36 20 30 a1 00 1c e0 31 1a 01 00 00 00 00 .....B6.0....1...... 0x11a3178 b0 31 1a 01 00 00 00 00 01 00 04 00 09 20 03 00 4a 20 01 00 .1..............J... We can see a pointer to this string located at offset 0x11a3178 which exists inside an allocation of size 48 at heap entry 0x11a3160 (Struct starts at 0x11a3170): [1] output.E01 12:36:04> dump 0x11a3170 Offset Hex Data -------------- ------------------------------------------------ ---------------- 0x11a3170 e0 31 1a 01 00 00 00 00 b0 31 1a 01 00 00 00 00 .1.......1...... 0x11a3180 01 00 04 00 09 20 03 00 4a 20 01 00 01 00 00 00 ........J....... 0x11a3190 ad c2 48 93 2e 00 63 00 6f 00 6d 00 00 00 00 00 ..H...c.o.m..... [1] output.E01 12:55:25> dump 0x11a31e0 Offset Hex Data -------------- ------------------------------------------------ ---------------- 0x11a31e0 e0 3b 1c 01 00 00 00 00 00 00 00 00 00 00 00 00 .;.............. 0x11a31f0 01 00 04 00 09 00 00 00 4a 20 01 00 01 00 00 00 ........J....... 0x11a3200 ad c2 48 63 6c 00 64 00 6c 00 2e 00 77 00 69 00 ..Hcl.d.l...w.i. [1] output.E01 13:00:44> dump 0x11c3be0 Offset Hex Data -------------- ------------------------------------------------ ---------------- 0x11c3be0 20 3c 1c 01 00 00 00 00 00 00 00 00 00 00 00 00 .<.............. 0x11c3bf0 01 00 04 00 09 00 00 00 4a 20 01 00 01 00 00 00 ........J....... 0x11c3c00 ad c2 48 68 0a 00 02 03 00 00 00 00 00 00 00 00 ..Hh............ [1] output.E01 13:03:36> dump 0x11c3c20 Offset Hex Data -------------- ------------------------------------------------ ---------------- 0x11c3c20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x11c3c30 01 00 04 00 09 00 00 00 4a 20 01 00 01 00 00 00 ........J....... 0x11c3c40 ad c2 48 6a 00 00 00 00 00 00 00 00 00 00 00 00 ..Hj............ The struct itself starts at offset 0x11a3170. There are two pointers back to this heap, the first points at 0x11a31e0, the second back at the string "www.google.com". We also see a short integer of value 1 - comparing to the output of ipconfig, this is the type. The next short integer is of size 4 (Data length). We see the data at offset 0x11a3190 representing the IPv4 address (173.194.72.147). If we dump the contents at the first pointer we can see a very similar struct. We can repeat to see a series of very similar structs all containing the different IPv4 addresses for Google. Lets name this the DNS_RECORD struct. Examining other similar structs gives examples for ones with Type = 5: [1] output.E01 13:08:33> dump 0x11c3c60 Offset Hex Data -------------- ------------------------------------------------ ---------------- 0x11c3c60 40 3d 1c 01 00 00 00 00 f0 3c 1c 01 00 00 00 00 @=.......<...... 0x11c3c70 05 00 08 00 09 30 00 00 60 20 01 00 01 00 00 00 .....0..`....... 0x11c3c80 a0 3c 1c 01 00 00 00 00 00 00 00 00 00 00 00 00 .<.............. [1] output.E01 13:08:38> dump 0x11c3ca0 Offset Hex Data -------------- ------------------------------------------------ ---------------- 0x11c3ca0 77 00 77 00 77 00 2e 00 6d 00 69 00 63 00 72 00 w.w.w...m.i.c.r. 0x11c3cb0 6f 00 73 00 6f 00 66 00 74 00 2e 00 63 00 6f 00 o.s.o.f.t...c.o. 0x11c3cc0 6d 00 2e 00 65 00 64 00 67 00 65 00 6b 00 65 00 m...e.d.g.e.k.e. 0x11c3cd0 79 00 2e 00 6e 00 65 00 74 00 00 00 00 00 00 00 y...n.e.t....... In this case we can see that the data field is a pointer to a string containing the CNAME record. We can already write its definition like: [I][COLOR=#9a1900]# Most common DNS types.[/COLOR][/I] DNS_TYPES [COLOR=#990000]=[/COLOR] [COLOR=#990000]{[/COLOR] [COLOR=#993399]1[/COLOR][COLOR=#990000]:[/COLOR] [COLOR=red]"A"[/COLOR][COLOR=#990000],[/COLOR] [COLOR=#993399]5[/COLOR][COLOR=#990000]:[/COLOR] [COLOR=red]"CNAME"[/COLOR][COLOR=#990000],[/COLOR] [COLOR=#993399]28[/COLOR][COLOR=#990000]:[/COLOR] [COLOR=red]"AAAA"[/COLOR][COLOR=#990000],[/COLOR] [COLOR=#990000]}[/COLOR] types [COLOR=#990000]=[/COLOR] [COLOR=#990000]{[/COLOR] [COLOR=red]"DNS_RECORD"[/COLOR][COLOR=#990000]:[/COLOR] [COLOR=#990000][[/COLOR]None[COLOR=#990000],[/COLOR] [COLOR=#990000]{[/COLOR] [COLOR=red]"Next"[/COLOR][COLOR=#990000]:[/COLOR] [COLOR=#990000][[/COLOR][COLOR=#993399]0[/COLOR][COLOR=#990000],[/COLOR] [COLOR=#990000][[/COLOR][COLOR=red]"Pointer"[/COLOR][COLOR=#990000],[/COLOR] [B][COLOR=black]dict[/COLOR][/B][COLOR=#990000]([/COLOR] target[COLOR=#990000]=[/COLOR][COLOR=red]"DNS_RECORD"[/COLOR] [COLOR=#990000])]],[/COLOR] [COLOR=red]"Name"[/COLOR][COLOR=#990000]:[/COLOR] [COLOR=#990000][[/COLOR][COLOR=#993399]8[/COLOR][COLOR=#990000],[/COLOR] [COLOR=#990000][[/COLOR][COLOR=red]"Pointer"[/COLOR][COLOR=#990000],[/COLOR] [B][COLOR=black]dict[/COLOR][/B][COLOR=#990000]([/COLOR] target[COLOR=#990000]=[/COLOR][COLOR=red]"UnicodeString"[/COLOR] [COLOR=#990000])]],[/COLOR] [COLOR=red]"Type"[/COLOR][COLOR=#990000]:[/COLOR] [COLOR=#990000][[/COLOR][COLOR=#993399]16[/COLOR][COLOR=#990000],[/COLOR] [COLOR=#990000][[/COLOR][COLOR=red]"Enumeration"[/COLOR][COLOR=#990000],[/COLOR] [B][COLOR=black]dict[/COLOR][/B][COLOR=#990000]([/COLOR] choices[COLOR=#990000]=[/COLOR]DNS_TYPES[COLOR=#990000],[/COLOR] target[COLOR=#990000]=[/COLOR][COLOR=red]"unsigned short"[/COLOR] [COLOR=#990000])]],[/COLOR] [COLOR=red]"DataLength"[/COLOR][COLOR=#990000]:[/COLOR] [COLOR=#990000][[/COLOR][COLOR=#993399]18[/COLOR][COLOR=#990000],[/COLOR] [COLOR=#990000][[/COLOR][COLOR=red]'unsigned short'[/COLOR][COLOR=#990000]]],[/COLOR] [COLOR=red]"Data"[/COLOR][COLOR=#990000]:[/COLOR] [COLOR=#990000][[/COLOR][COLOR=#993399]0x20[/COLOR][COLOR=#990000],[/COLOR] [COLOR=#990000][[/COLOR][COLOR=red]'char'[/COLOR][COLOR=#990000]]],[/COLOR] [COLOR=#990000]}],[/COLOR] [COLOR=#990000]}[/COLOR] [B][COLOR=blue]class[/COLOR][/B] [B][COLOR=black]DNS_RECORD[/COLOR][/B][COLOR=#990000]([/COLOR]obj[COLOR=#990000].[/COLOR]Struct[COLOR=#990000]):[/COLOR] @[URL="https://rstforums.com/forum/member.php?u=74209"]pro[/URL]perty [B][COLOR=blue]def[/COLOR][/B] [B][COLOR=black]Data[/COLOR][/B][COLOR=#990000]([/COLOR]self[COLOR=#990000]):[/COLOR] [B][COLOR=blue]if[/COLOR][/B] self[COLOR=#990000].[/COLOR]Type [COLOR=#990000]==[/COLOR] [COLOR=red]"CNAME"[/COLOR][COLOR=#990000]:[/COLOR] [B][COLOR=blue]return[/COLOR][/B] self[COLOR=#990000].[/COLOR][B][COLOR=black]m[/COLOR][/B][COLOR=#990000]([/COLOR][COLOR=red]"Data"[/COLOR][COLOR=#990000]).[/COLOR][B][COLOR=black]cast[/COLOR][/B][COLOR=#990000]([/COLOR] [COLOR=red]"Pointer"[/COLOR][COLOR=#990000],[/COLOR] target[COLOR=#990000]=[/COLOR][COLOR=red]"UnicodeString"[/COLOR][COLOR=#990000]).[/COLOR][B][COLOR=black]deref[/COLOR][/B][COLOR=#990000]()[/COLOR] [B][COLOR=blue]elif[/COLOR][/B] self[COLOR=#990000].[/COLOR]Type [COLOR=#990000]==[/COLOR] [COLOR=red]"A"[/COLOR][COLOR=#990000]:[/COLOR] [B][COLOR=blue]return[/COLOR][/B] utils[COLOR=#990000].[/COLOR][B][COLOR=black]inet_ntop[/COLOR][/B][COLOR=#990000]([/COLOR] socket[COLOR=#990000].[/COLOR]AF_INET[COLOR=#990000],[/COLOR] self[COLOR=#990000].[/COLOR]obj_vm[COLOR=#990000].[/COLOR][B][COLOR=black]read[/COLOR][/B][COLOR=#990000]([/COLOR]self[COLOR=#990000].[/COLOR][B][COLOR=black]m[/COLOR][/B][COLOR=#990000]([/COLOR][COLOR=red]"Data"[/COLOR][COLOR=#990000]).[/COLOR]obj_offset[COLOR=#990000],[/COLOR] [COLOR=#993399]4[/COLOR][COLOR=#990000]))[/COLOR] Just like we followed the Next pointer before we can also try to follow this list in reverse using the grep plugin to see where each struct is referenced from. [1] output.E01 13:13:28> grep 0x11a0040, keyword="\x70\x31\x1a\x01" Offset Hex Data -------------- ------------------------------------------------------------ -------------------- [1] output.E01 13:15:17> grep 0x20f0000, keyword="\x70\x31\x1a\x01" -----------------------> grep(0x20f0000, keyword="\x70\x31\x1a\x01") Offset Hex Data -------------- ------------------------------------------------------------ -------------------- 0x20f1c84 00 00 00 00 b0 1c 0f 02 00 00 00 00 00 00 00 00 03 00 00 00 .................... 0x20f1c98 70 31 1a 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 p1.................. [1] output.E01 13:15:14> inspect_heap pid=1076, heaps=[12] [_EPROCESS _EPROCESS] @ 0xFA800271C630 (pid=1076) Heap 12: 0x20f0000 (BACKEND) Backend Info: Segment End Length Data --------------- -------------- ---------- ---- . 0x20f0040 0x2100000 65472 .. 0x20f0a80 0x20f12e0 2128 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 ................ .. 0x20f12e0 0x20f1980 1680 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .. 0x20f1980 0x20f19f0 96 00 00 00 00 00 00 00 00 c0 19 0f 02 00 00 00 00 ................ .. 0x20f19f0 0x20f1a70 112 00 00 00 00 00 00 00 00 30 1a 0f 02 00 00 00 00 ........0....... .. 0x20f1a70 0x20f1ae0 96 00 00 00 00 00 00 00 00 b0 1a 0f 02 00 00 00 00 ................ .. 0x20f1ae0 0x20f1b50 96 00 00 00 00 00 00 00 00 20 1b 0f 02 00 00 00 00 ................ .. 0x20f1b50 0x20f1bb0 80 00 00 00 00 00 00 00 00 90 1b 0f 02 00 00 00 00 ................ .. 0x20f1bb0 0x20f1c10 80 00 00 00 00 00 00 00 00 f0 1b 0f 02 00 00 00 00 ................ .. 0x20f1c10 0x20f1c70 80 00 00 00 00 00 00 00 00 50 1c 0f 02 00 00 00 00 ........P....... .. 0x20f1c70 0x20f1cd0 80 00 00 00 00 00 00 00 00 b0 1c 0f 02 00 00 00 00 ................ .. 0x20f1cd0 0x20f1d30 80 00 00 00 00 00 00 00 00 10 1d 0f 02 00 00 00 00 ................ .. 0x20f1d30 0x20f1d90 80 00 00 00 00 00 00 00 00 70 1d 0f 02 00 00 00 00 ........p....... .. 0x20f1d90 0x20f1df0 80 00 00 00 00 00 00 00 00 d0 1d 0f 02 00 00 00 00 ................ .. 0x20f1df0 0x20f1e60 96 00 00 00 00 00 00 00 00 30 1e 0f 02 00 00 00 00 ........0....... .. 0x20f1e60 0x20f1ec0 80 00 00 00 00 00 00 00 00 a0 1e 0f 02 00 00 00 00 ................ .. 0x20f1ec0 0x20f1f20 80 00 00 00 00 00 00 00 00 00 1f 0f 02 00 00 00 00 ................ .. 0x20f1f20 0x20f1f80 80 00 00 00 00 00 00 00 00 60 1f 0f 02 00 00 00 00 ........`....... .. 0x20f1f80 0x20f1fe0 80 00 00 00 00 00 00 00 00 c0 1f 0f 02 00 00 00 00 ................ .. 0x20f1fe0 0x20f2040 80 00 00 00 00 00 00 00 00 20 20 0f 02 00 00 00 00 ................ .. 0x20f2040 0x20f20b0 96 00 00 00 00 00 00 00 00 80 20 0f 02 00 00 00 00 ................ .. 0x20f20b0 0x20f2120 96 00 00 00 00 00 00 00 00 f0 20 0f 02 00 00 00 00 ................ .. 0x20f2120 0x20f2180 80 00 00 00 00 00 00 00 00 60 21 0f 02 00 00 00 00 ........`!...... .. 0x20f2180 0x20f21e0 80 00 00 00 00 00 00 00 00 c0 21 0f 02 00 00 00 00 .........!...... .. 0x20f21e0 0x20f2230 64 00 00 00 00 00 00 00 00 20 22 0f 02 00 00 00 00 ........."...... .. 0x20f2230 0x20f2290 80 00 00 00 00 00 00 00 00 70 22 0f 02 00 00 00 00 ........p"...... .. 0x20f2290 0x20f22f0 80 00 00 00 00 00 00 00 00 d0 22 0f 02 00 00 00 00 ........."...... .. 0x20f22f0 0x20f2350 80 00 00 00 00 00 00 00 00 30 23 0f 02 00 00 00 00 ........0#...... .. 0x20f2350 0x20f3fc0 7264 58 01 0f 02 00 00 00 00 58 01 0f 02 00 00 00 00 X.......X....... .. 0x20f3fc0 0x20f4000 48 f8 00 0f 02 00 00 00 00 f8 00 0f 02 00 00 00 00 ................ .. 0x20f4000 0x2100000 49136 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [1] output.E01 13:15:26> dump 0x20f1c70 Offset Hex Data -------------- ------------------------------------------------ ---------------- 0x20f1c70 63 00 6f 00 6d 00 00 00 bd 11 f0 6c 22 43 00 12 c.o.m......l"C.. 0x20f1c80 00 00 00 00 00 00 00 00 b0 1c 0f 02 00 00 00 00 ................ 0x20f1c90 00 00 00 00 03 00 00 00 70 31 1a 01 00 00 00 00 ........p1...... 0x20f1ca0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f1cb0 77 00 77 00 77 00 2e 00 67 00 6f 00 6f 00 67 00 w.w.w...g.o.o.g. 0x20f1cc0 6c 00 65 00 2e 00 63 00 6f 00 6d 00 00 00 00 00 l.e...c.o.m..... The references to the first DNS_RECORD in the linked list actually come from a different heap (Heap 12). The struct in that heap starts at 0x20f1c80 and appears to be a different struct. The pointer at offset 8 is the string, while the pointer to the DNS_RECORD is at offset 24. What is referring to this struct? [1] output.E01 13:17:56> grep 0x20f0000, keyword="\x80\x1c\x0f\x02" Offset Hex Data -------------- ------------------------------------------------------------ -------------------- 0x20f14cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .................... 0x20f14e0 80 1c 0f 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .................... # Go back to the start of the allocation and dump it out (This is a large # allocation 1680 bytes): [1] output.E01 13:21:32> dump 0x20f12f0 Offset Hex Data -------------- ------------------------------------------------ ---------------- 0x20f12f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f1300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f1310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f1320 00 00 00 00 00 00 00 00 a0 1d 0f 02 00 00 00 00 ................ 0x20f1330 00 00 00 00 00 00 00 00 60 1b 0f 02 00 00 00 00 ........`....... 0x20f1340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f1350 00 00 00 00 00 00 00 00 c0 1b 0f 02 00 00 00 00 ................ 0x20f1360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f1370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f1380 00 00 00 00 00 00 00 00 30 21 0f 02 00 00 00 00 ........0!...... 0x20f1390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f13a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f13b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f13c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f13d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f13e0 90 1f 0f 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f13f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x20f1400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ We see that the allocation at offset 0x20f12f0 seems to have lots of 0’s and randomly occurring pointers. If one dumps these pointers they all appear very similar to the allocation at 0x20f1c70. This looks very much like a hash table but we are not quite sure at this stage. If an application allocated this memory, it must have a pointer to it somewhere (if not the memory will be leaked!). We can search for who holds a reference to this 1680 byte allocation. The reference is not found within this heap but actually inside the mapped DLL itself (If you really have no idea where the reference might be, try vaddump to dump all the memory regions of the process and then use a hex editor to search them, alternatively you can use yarascan too): [1] output.E01 13:28:24> grep 0x07fef9a20000, keyword="\xf0\x12\x0f\x02" Offset Hex Data Comment -------------- ------------------------------------------------------------ -------------------- ---------------------------------------- 0x7fef9a49254 00 00 00 00 f0 24 1a 01 00 00 00 00 00 00 0f 02 00 00 00 00 .....$.............. \Windows\System32\dnsrslvr.dll+0x55DF 0x7fef9a49268 f0 12 0f 02 00 00 00 00 14 01 00 00 00 00 00 00 28 01 00 00 ................(... \Windows\System32\dnsrslvr.dll+0x55DF Note that Rekall knows this offset falls within the mapped region of dnsrslvr.dll - in fact 0x55DF bytes into it. I wonder if we can obtain debugging information for this dll from Microsoft? [1] output.E01 13:34:58> peinfo 0x07fef9a20000 Attribute Value ------------------------------ ------------------------------------------------------------ Machine IMAGE_FILE_MACHINE_AMD64 TimeDateStamp 2011-03-03 06:11:04+0000 Characteristics IMAGE_FILE_DLL, IMAGE_FILE_EXECUTABLE_IMAGE, IMAGE_FILE_LARGE_ADDRESS_AWARE GUID/Age - PDB - MajorOperatingSystemVersion 6 MinorOperatingSystemVersion 1 MajorImageVersion 6 MinorImageVersion 1 MajorSubsystemVersion 6 MinorSubsystemVersion 1 Sections (Relative to 0x7FEF9A20000): Perm Name VMA Size ---- -------- -------------- -------------- xr- .text 0x000000001000 0x00000001d400 -r- .rdata 0x00000001f000 0x000000009e00 -rw .data 0x000000029000 0x000000002600 -r- .pdata 0x00000002c000 0x000000002000 -r- .rsrc 0x00000002e000 0x000000000600 -r- .reloc 0x00000002f000 0x000000000600 Data Directories: ---------------------------------------- VMA Size -------------- -------------- IMAGE_DIRECTORY_ENTRY_EXPORT 0x07fef9a43c2c 0x0000000000a9 IMAGE_DIRECTORY_ENTRY_IMPORT 0x07fef9a45ebc 0x000000000230 IMAGE_DIRECTORY_ENTRY_RESOURCE 0x07fef9a4e000 0x000000000528 IMAGE_DIRECTORY_ENTRY_EXCEPTION 0x07fef9a4c000 0x000000001ecc IMAGE_DIRECTORY_ENTRY_SECURITY 0x000000000000 0x000000000000 IMAGE_DIRECTORY_ENTRY_BASERELOC 0x07fef9a4f000 0x0000000004e4 IMAGE_DIRECTORY_ENTRY_DEBUG 0x07fef9a3e31c 0x000000000038 IMAGE_DIRECTORY_ENTRY_COPYRIGHT 0x000000000000 0x000000000000 IMAGE_DIRECTORY_ENTRY_GLOBALPTR 0x000000000000 0x000000000000 IMAGE_DIRECTORY_ENTRY_TLS 0x000000000000 0x000000000000 IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 0x000000000000 0x000000000000 IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT 0x07fef9a202d8 0x00000000041c IMAGE_DIRECTORY_ENTRY_IAT 0x07fef9a3f000 0x000000000788 IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT 0x07fef9a45d2c 0x000000000080 IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 0x000000000000 0x000000000000 IMAGE_DIRECTORY_ENTRY_RESERVED 0x000000000000 0x000000000000 Import Directory (Original): Name Mapped Function Ord -------------------------------------------------- ------------------------------------------------------------ ----- Export Directory: Entry Stat Ord Name -------------- ---- ----- ---- 0x07fef9a2bf14 M 0 dnsrslvr.dll!LoadGPExtension (dnsrslvr!LoadGPExtension) 0x07fef9a28350 M 1 dnsrslvr.dll!Reg_DoRegisterAdapter (dnsrslvr!Reg_DoRegisterAdapter) 0x07fef9a2c5f8 M 2 dnsrslvr.dll!ServiceMain (dnsrslvr!ServiceMain) 0x07fef9a2c5e8 M 3 dnsrslvr.dll!SvchostPushServiceGlobals (dnsrslvr!SvchostPushServiceGlobals) 0x07fef9a43c89 M 4 dnsrslvr.dll! (\Windows\System32\dnsrslvr.dll) Version Information: key value -------------------- ----- Unfortunately in this case the RSDS section is not mapped in. We will have to read it from the file on disk: [1] pmem 12:17:18> peinfo executable="c:/Windows/System32/dnsrslvr.dll" Attribute Value -------------------- -------------------------------------------------------- Machine IMAGE_FILE_MACHINE_AMD64 TimeDateStamp 2011-03-03 06:11:04+0000 Characteristics IMAGE_FILE_DLL, IMAGE_FILE_EXECUTABLE_IMAGE, IMAGE_FILE_LARGE_ADDRESS_AWARE GUID/Age D5736592F1A64779989D409FCC6BA4952 PDB dnsrslvr.pdb ..... We can download an parse the PDB for this dll: [1] output.E01 13:38:32> fetch_pdb guid="D5736592F1A64779989D409FCC6BA4952", pdb_filename="dnsrslvr.pdb" Trying to fetch Symbol information [1] output.E01 13:39:02> parse_pdb "dnsrslvr.pdb", output="/tmp/dnsrslvr.json" Unfortunately the public symbol server does not have information for structs, but it does have information for global constants. We can search for the name of the constant at offset 0x7fef9a49268 (168552 relative to the start of the PE image). We see that this symbol is in fact the hash table: "g_HashTable": 168552, "g_HashTableSize": 168304, The other interesting thing we notice is that most of the allocations in heap 12 seems to be related to the hash table and its records. In fact it appears as though the entire heap is dedicated to the DNS resolver itself. We can check this by searching for a reference to the heap from the DLL: [1] output.E01 14:52:07> grep 0x07fef9a20000, keyword="\x00\x00\x0f\x02\x00\x00" Offset Hex Data Comment -------------- ------------------------------------------------------------ -------------------- ---------------------------------------- 0x7fef9a4924c 00 00 00 00 ac 02 00 00 00 00 00 00 f0 24 1a 01 00 00 00 00 .............$...... \Windows\System32\dnsrslvr.dll+0x55D7 0x7fef9a49260 00 00 0f 02 00 00 00 00 f0 12 0f 02 00 00 00 00 14 01 00 00 .................... \Windows\System32\dnsrslvr.dll+0x55D7 [1] output.E01 14:52:34> 0x7fef9a49260 - 0x07fef9a20000 Out > 168544 [1] output.E01 14:53:08> !grep 168544 /tmp/dnsrslvr.json "g_CacheHeap": 168544, 3.1. Putting it all together So now we can summarize how the DNS cache looks: There is a global symbol in dnsrslvr.dll pointing to a private heap (named g_CacheHeap). The heap has a allocation for a hash table. The allocation contains pointers to DNS_HASHTABLE_ENTRY records. Each DNS_HASHTABLE_ENTRY has a reference to a head of a singly linked list of DNS_RECORD structs relating to the name. Each DNS_RECORD struct contains either an A record (IP Address) or a CNAME record anther name. We can now put it all together in a plugin: [1] output.E01 14:54:08> dns_cache DEBUG:root:Switching to process context: svchost.exe (Pid 1076@0xfa800271c630) INFO:root:Loaded profile ntdll/GUID/9D04EB0AA387494FBD81ED062072B99C2 from Directory:/home/scudette/projects/rekall-profiles/v1.0 Name Record Type Data --------------------------------------------- -------------- ------ ---- clients4.google.com 0x0000020f1da0 HTABLE . clients4.google.com 0x0000011a2b40 CNAME clients.l.google.com . clients.l.google.com 0x0000011a2c00 A 64.233.187.102 . clients.l.google.com 0x0000011c35d0 A 64.233.187.139 . clients.l.google.com 0x0000011c3610 A 64.233.187.100 . clients.l.google.com 0x0000011c3650 A 64.233.187.101 tools.google.com 0x0000020f1b60 HTABLE crl.microsoft.com 0x0000020f1bc0 HTABLE code.jquery.com 0x0000020f2130 HTABLE . code.jquery.com 0x0000011f56a0 CNAME code.jquery.netdna-cdn.com . code.jquery.netdna-cdn.com 0x0000011c3840 A 94.31.29.53 . code.jquery.netdna-cdn.com 0x0000011c38d0 A 94.31.29.230 apis.google.com 0x0000020f1f90 HTABLE . apis.google.com 0x0000011f5950 CNAME plus.l.google.com . plus.l.google.com 0x0000011f59d0 A 173.194.72.101 . plus.l.google.com 0x0000011f5a50 A 173.194.72.113 . plus.l.google.com 0x0000011f5a90 A 173.194.72.138 . plus.l.google.com 0x0000011f5ad0 A 173.194.72.102 [URL="http://www.google.com"]Google[/URL] 0x0000020f1c80 HTABLE . [URL="http://www.google.com"]Google[/URL] 0x0000011a3170 A 173.194.72.147 . [URL="http://www.google.com"]Google[/URL] 0x0000011a31e0 A 173.194.72.99 . [URL="http://www.google.com"]Google[/URL] 0x0000011c3be0 A 173.194.72.104 . [URL="http://www.google.com"]Google[/URL] 0x0000011c3c20 A 173.194.72.106 en.wikipedia.org 0x0000020f2190 HTABLE . en.wikipedia.org 0x0000011f6570 A 198.35.26.96 fe2.update.microsoft.com 0x0000020f1af0 HTABLE [URL="http://www.rekall-forensic.com"]Rekall Memory Forensic Framework[/URL] 0x0000020f2050 HTABLE . [URL="http://www.rekall-forensic.com"]Rekall Memory Forensic Framework[/URL] 0x0000011f5c50 CNAME github.map.fastly.net . github.map.fastly.net 0x0000011f5d10 CNAME google.github.io . google.github.io 0x0000011f5dd0 A 103.245.222.133 mscrl.microsoft.com 0x0000020f1c20 HTABLE github.com 0x0000020f21f0 HTABLE . github.com 0x0000011f6950 A 192.30.252.129 clients1.google.com 0x0000020f2300 HTABLE . clients1.google.com 0x0000011a2f60 CNAME clients.l.google.com . clients.l.google.com 0x0000011a3020 A 173.194.72.101 . clients.l.google.com 0x0000011a30a0 A 173.194.72.100 . clients.l.google.com 0x0000011a30e0 A 173.194.72.102 . clients.l.google.com 0x0000011f5fd0 A 173.194.72.139 [URL="http://www.google.de"]Google[/URL] 0x0000020f1d40 HTABLE . [URL="http://www.google.de"]Google[/URL] 0x0000011f55f0 A 216.58.220.99 translate.googleapis.com 0x0000020f1e00 HTABLE . translate.googleapis.com 0x0000011a3130 CNAME googleapis.l.google.com . googleapis.l.google.com 0x0000011c3690 A 74.125.204.95 ctldl.windowsupdate.com 0x0000020f1990 HTABLE [URL="http://www.python.org"]www.python.org[/URL] 0x0000020f22a0 HTABLE . [URL="http://www.python.org"]www.python.org[/URL] 0x0000011a29e0 CNAME python.map.fastly.net . python.map.fastly.net 0x0000011f6bb0 A 103.245.222.223 plusvic.github.io 0x0000020f2240 HTABLE . plusvic.github.io 0x0000011f6a70 CNAME github.map.fastly.net . github.map.fastly.net 0x0000011f6b30 A 103.245.222.133 [URL="http://www.gstatic.com"]www.gstatic.com[/URL] 0x0000020f1ed0 HTABLE . [URL="http://www.gstatic.com"]www.gstatic.com[/URL] 0x0000011c3f40 A 173.194.72.94 . [URL="http://www.gstatic.com"]www.gstatic.com[/URL] 0x0000011f5710 A 173.194.72.120 rekall-forensic.com 0x0000020f1ff0 HTABLE . rekall-forensic.com 0x0000011f5b10 A 216.239.32.21 . rekall-forensic.com 0x0000011f5b90 A 216.239.34.21 . rekall-forensic.com 0x0000011f5bd0 A 216.239.36.21 . rekall-forensic.com 0x0000011f5c10 A 216.239.38.21 download.microsoft.com 0x0000020f1a80 HTABLE ds.download.windowsupdate.com 0x0000020f1a00 HTABLE netdna.bootstrapcdn.com 0x0000020f20c0 HTABLE . netdna.bootstrapcdn.com 0x0000011f5e50 CNAME bootstrapcdn.jdorfman.netdna-cdn.com . bootstrapcdn.jdorfman.netdna-cdn.com 0x0000011f5f30 A 94.31.29.154 clients3.google.com 0x0000020f1f30 HTABLE . clients3.google.com 0x0000011f5750 CNAME clients.l.google.com . clients.l.google.com 0x0000011f5810 A 173.194.72.139 . clients.l.google.com 0x0000011f5890 A 173.194.72.101 . clients.l.google.com 0x0000011f58d0 A 173.194.72.138 . clients.l.google.com 0x0000011f5910 A 173.194.72.100 ssl.gstatic.com 0x0000020f1e70 HTABLE . ssl.gstatic.com 0x0000011c3940 A 173.194.72.94 . ssl.gstatic.com 0x0000011c39b0 A 173.194.72.120 [URL="http://www.microsoft.com"]Microsoft Home Page | Devices and Services[/URL] 0x0000020f1ce0 HTABLE . [URL="http://www.microsoft.com"]Microsoft Home Page | Devices and Services[/URL] 0x0000011c3a10 CNAME e10088.dscb.akamaiedge.net . e10088.dscb.akamaiedge.net 0x0000011c3ae0 CNAME toggle.[URL="http://www.ms.akadns.net"]www.ms.akadns.net[/URL] . toggle.[URL="http://www.ms.akadns.net"]www.ms.akadns.net[/URL] 0x0000011c3c60 CNAME [URL="http://www.microsoft.com.edgekey.net"]www.microsoft.com.edgekey.net[/URL] . [URL="http://www.microsoft.com.edgekey.net"]www.microsoft.com.edgekey.net[/URL] 0x0000011c3d40 A 23.53.152.151 - 0x434e6df011bc HTABLE Posted by Michael at 12:46 AM Sursa: Rekall Memory Forensics blog: The Windows User mode heap and the DNS resolver cache.

Ireland sides with Microsoft in email privacy case The country files a friend-of-the-court brief asking the US to respect its sovereignty and not go over its head by seizing emails stored on Microsoft servers in Ireland. by Don Reisinger @donreisinger December 24, 2014 11:52 AM PST Ireland waded into an email privacy case Tuesday by filing a friend-of-the-court brief supporting Microsoft's opposition to turning over emails in a criminal case that are stored on servers in Dublin. The Irish government filed the motion in the US Court of Appeals for the Second Circuit in New York asking the US to respect its sovereignty. "Ireland does not accept any implication that it is required to intervene into foreign court proceedings to protect its sovereignty," the brief read. But the Irish government also said it would consider allowing access to data in its country. "As minister for data protection, I have given detailed consideration, from an Irish perspective, to the issues raised in this complex case," Ireland's Dara Murphy said Tuesday in a statement. "There are important principles of public policy at play. Having engaged in detailed consultation with my colleagues in government, it was agreed that Ireland should submit an amicus curiae brief to the US court that focuses on the principles involved in this case and that points to the existing process for mutual legal assistance in criminal matters." The brief notes that the US and Ireland signed a treaty in 2001 that allows them to transfer case evidence to assist in law enforcement activities. The brief has pleased Microsoft, which has called on Ireland to chime in on the issue before any decisions are made by US courts. The US and Microsoft have for the last year been waging a legal war over whether the software company can and should hand over emails from users involved in the narcotics case. Last December, a New York judge said that Microsoft would be required to provide the US government with user emails in connection with a criminal investigation. Microsoft discovered that the emails were residing on one of its servers in Dublin and subsequently refused the request, saying that the US doesn't have the right to obtain private emails without the "knowledge or consent of the subscriber or the relevant foreign government where the data is stored." Microsoft says that the stored communications provisions of the Electronic Communications Privacy Act (ECPA) do not apply outside of the United States. Despite Microsoft's concerns, a court ruled in July that Microsoft must hand over the emails. Microsoft again refused, saying that the US doesn't have the right to access email communications from people who are not living in the country. While Microsoft General Counsel Brad Smith stopped short of going that far with his statement on the matter on Tuesday, he did write in a blog post on the issue that "the Irish government's engagement underscores that an international dialogue on this issue is not only necessary but possible." Smith went on to say that Microsoft has long desired collaboration between governments and not for one to "exercise" any "authority" over another. Microsoft declined to provide additional comment beyond what Smith wrote in his blog post. Sursa: Ireland sides with Microsoft in email privacy case - CNET