I'm looking for advice on implementing a driver under Vista and 7 which can hook and monitor arbitrary system functions for a userland process. My goal is to simply dump arguments for system functions called from ntdll, kernel32, etc. Coming from XP, SSDT modification and similar techniques were popular. On Vista+ there are filter drivers and notification routines. Are either of these meant for hooking native functions? The driver is for 32 and 64bit and has to play nice with Patch Guard. Any suggestions are welcomed.
ObCallback is similar to SSDT hooking.
Related
I really want to capture the packet on Windows 7
but i'm beginner of windows programming so I have no idea, how can I solve the
problem.
I know I can capture the packet by using DNIS but my computer is windows7 but
on the webpage there are only for windows 10 or windows 8.1
is there anyone let me know the information?
I know I can capture the packet by using DNIS
(Presumably "using NDIS".)
Yes, NDIS is the operating system mechanism that provides hooks for packet capture.
As you're asking on Stack Overflow, presumably you want to write a program to capture packets, rather than using an existing program.
You could write your own code to use NDIS (which works at least as far back as Windows NT 4.0, and probably earlier and, with different code, Windows 9x as well), but that's code that would run in the kernel, and that's a bit more difficult.
However, WinPcap and Npcap already have that kernel code, and a library that runs in user mode, providing the same API as libpcap on UN*X; the easiest way would probably be to install WinPcap or Npcap on your machine, along with the Software Development Kit for WinPcap or Npcap, and use that.
If you're programming in C or C++, you can use the API directly. In other languages, including .NET languages, there are wrappers for libpcap/WinPcap - see this list of wrappers, for example.
At Microsoft BUILD conference, I saw this figure.
I'm wondering whether the position of Win32 is correct or not. What is the role and position of Win32 API in modern Windows architecture?
My concept of Win32 API is a sort of assembly of all modern Windows architecture. Win32 API (or DDK) bridges "Windows Kernel Services" to the other technologies.
I thought that Internet Explorer/.NET/Silverlight are all build upon Win32 API. Even if a fancy new Metro Apps, I conjecture that Win32 is at the bottom place. However, this figure defies my knowledge.
As you can see, IE/.NET/SL/Metro are sitting horizontally with Win32.
Questions:
Does this figure necessarily mean that Win32 is not the framework of all other modern technologies?
What is "Windows Kernel Services"? How programmers can access them? Isn't it through Win32 API and DDK?
The diagram is wrong.
While there were originally other subsystems (e.g. POSIX) which accessed ntdll.dll (the "Kernel Services" gateway) without going through Win32 (kernel32.dll, user32.dll) these are all now defunct.
All modern application frameworks for Windows are built on Win32. The other subsytems are no longer supported. In some cases (drivers, and boot-time system utilities such as chkdsk) code is written directly against the native API, but these scenarios are very rare.
I'm not very familiar with WinRT, but I think Win32 fits underneath it as well (or it may use a combination of Win32 and direct ntdll.dll services).
According to Sasha Goldshtein,
Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – so they are not a replacement but rather a wrapper, an API flavor, on top of Win32. (Historical note: Windows used to have a feature called “environment subsystems”, which can be roughly described as API flavors. WinRT is not an environment subsystem – it is a library on top of the Win32 environment subsystem.)
The diagram is (presumably) correct, but only for Windows 8. Windows 8 has a significantly different architecture from previous versions.
I believe applications can make requests directly to the kernel, but the interface is mostly undocumented. Device drivers use the kernel directly.
I need to hijack all operating system calls of my own process. I cannot rewrite code as it is partly not my code (plug-ins). I need to be able to decide within my implementation of a specific system call, if I want to call the original implementation or not.
Operating systems will be at first windows xp and higher versions. Later os x 10.5 and higher will follow. Starting on windows with 32 bit versions, later for all operating systems also 64 bit versions.
I found a lot of documentation and tools about hooking other processes but I would hope my job is much simpler and I would hope for some source code.
Thanks a lot in advance, Bernd.
There are many hooking libraries that will let you do this, for example Detours or madCodeHook on Windows. No doubt there are similar libraries on OSX, I just don't know them!
It's very easy to hook a routine and replace it with your own implementation. It's less easy to retain the option of running the original routine in some circumstances, and that's where using a hooking library will take the pain away for you.
On Mac OS X, you can override functions with the DYLD_INTERPOSE macro (and DYLD_INSERT_LIBRARIES, if needed). This answer has an example: Ansi C patch using dlsym compiles OK under linux but fails on Mac Os X
For Windows, there is the open source alternative to Microsoft Detours called EasyHook:
CodePlex: EasyHook
Code Project: EasyHook - The reinvention of Windows API hooking
I am just trying to understand the differences to patching into the kernel and writing a driver.
It is my understanding that a kernel mode driver can do anything the kernel can do, and is similar in some ways to a linux module.
Why then, were AV makers so upset when Microsoft stopped them from patching into the Windows kernel?
What kind of stuff can you do through kernel patching that you can't do through a driver?
In this context patching the kernel means modifying its (undocumented?) internal structures in order to achieve some functionality, typically hooking various functions (e.g. opening a file). You are not supposed to go messing around with internal kernel structures that do not belong to you. In the past Microsoft did not provide official hooks for some things, so security companies reverse engineered the internals and hooked the kernel directly. Recently Microsoft has provided official hooks for some things, so the need to hook the kernel directly is not as strong.
It's true that a kernel-mode driver can do anything the kernel can do - after all, they both run in ring 0. The key question here is: how difficult is it? Patching things relies on internal details that may change between different kernel releases. For example, the system call number of NtTerminateProcess will change between versions, so a driver which hooks the SSDT will break between versions (although the system call number can be obtained through other means). Reading or modifying fields of internal structures such as EPROCESS or ETHREAD is risky as well, because again, these structures change between versions. None of this is impossible for a driver to do, but it's hard.
If an official interface is provided for hooking, Microsoft can guarantee compatibility between versions as well as being able to control who can do what (e.g. only signed drivers can use the object manager callbacks). However, Microsoft can't do this for everything, because some things are just implementation details that drivers shouldn't know about.
I was curious as to how does one go about finding undocumented APIs in Windows.
I know the risks involved in using them but this question is focused towards finding them and not whether to use them or not.
Use a tool to dump the export table from a shared library (for example, a .dll such as kernel32.dll). You'll see the named entry points and/or the ordinal entry points. Generally for windows the named entry points are unmangled (extern "C"). You will most likely need to do some peeking at the assembly code and derive the parameters (types, number, order, calling convention, etc) from the stack frame (if there is one) and register usage. If there is no stack frame it is a bit more difficult, but still doable. See the following links for references:
http://www.sf.org.cn/symbian/Tools/symbian_18245.html
http://msdn.microsoft.com/en-us/library/31d242h4.aspx
Check out tools such as dumpbin for investigating export sections.
There are also sites and books out there that try to keep an updated list of undocumented windows APIs:
The Undocumented Functions
A Primer of the Windows Architecture
How To Find Undocumented Constants Used by Windows API Functions
Undocumented Windows
Windows API
Edit:
These same principles work on a multitude of operating systems however, you will need to replace the tool you're using to dump the export table. For example, on Linux you could use nm to dump an object file and list its exports section (among other things). You could also use gdb to set breakpoints and step through the assembly code of an entry point to determine what the arguments should be.
IDA Pro is your best bet here, but please please double please don't actually use them for anything ever.
They're internal because they change; they can (and do) even change as a result of a Hotfix, so you're not even guaranteed your undocumented API will work for the specific OS version and Service Pack level you wrote it for. If you ship a product like that, you're living on borrowed time.
Everybody here so far is missing some substantial functionality that comprises hugely un-documented portions of the Windows OS RPC . RPC (think rpcrt4.dll, lsass.exe, csrss.exe, etc...) operations occur very frequently across all subsystems, via LPC ports or other interfaces, their functionality is buried in the mysticism incantations of various type/sub-type/struct-typedef's etc... which are substantially more difficult to debug, due to the asynchronous nature or the fact that they are destine for process's which if you were to debug via single stepping or what have you, you would find the entire system lockup due to blocking keyboard or other I/O from being passed ;)
ReactOS is probably the most expedient way to investigate undocumented API. They have a fairly mature kernel and other executive's built up. IDA is fairly time-intensive and it's unlikely you will find anything the ReactOS people have not already.
Here's a blurb from the linked page;
ReactOS® is a free, modern operating
system based on the design of Windows®
XP/2003. Written completely from
scratch, it aims to follow the
Windows® architecture designed by
Microsoft from the hardware level
right through to the application
level. This is not a Linux based
system, and shares none of the unix
architecture.
The main goal of the
ReactOS project is to provide an
operating system which is binary
compatible with Windows. This will
allow your Windows applications and
drivers to run as they would on your
Windows system. Additionally, the look
and feel of the Windows operating
system is used, such that people
accustomed to the familiar user
interface of Windows® would find using
ReactOS straightforward. The ultimate
goal of ReactOS is to allow you to
remove Windows® and install ReactOS
without the end user noticing the
change.
When I am investigating some rarely seen Windows construct, ReactOS is often the only credible reference.
Look at the system dlls and what functions they export. Every API function, whether documented or not, is exported in one of them (user, kernel, ...).
For user mode APIs you can open Kernel32.dll User32.dll Gdi32.dll, specially ntdll.dll in dependancy walker and find all the exported APIs. But you will not have the documentation offcourse.
Just found a good article on Native APIS by Mark Russinovich