Finding undocumented APIs in Windows

A

5

55

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.

Alcantara answered 28/5, 2009 at 3:32 Comment(2)

-1 bad question: it is never a good idea to use undocumented APIs; they are undocumented for a reason, and the risks are not to you but rather to your OS vendor (if they care about app compat at all). – Coprophilous 28/5, 2009 at 17:29

+1 not a bad question. There is nothing wrong with poking around the internals of your OS or anything else. Curiosity is a good thing. Just don't rely on undocumented behavior. – Surfing 4/2, 2011 at 13:5

D

40

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:

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:

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.

Dextrad answered 28/5, 2009 at 3:43 Comment(0)

A

10

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.

Automate answered 28/5, 2009 at 6:25 Comment(3)

And then if you're someone with influence, Microsoft has to maintain them forever because if they don't, Crap Inc's software will break and the misguided user will scream about how Microsoft sucks and Apple is great. – Clemmie 28/5, 2009 at 6:28

You don't even have to be that influential - crack open the AppCompat shim database one day, we've got apps like Disney Timon & Puumba Learn to Type in there – Automate 28/5, 2009 at 6:32

Yes. I use the undocumented SetConsoleFont successfully on windows xp, and windows 7, but it fails on windows 7 sp1. – Israelite 24/12, 2014 at 15:54

R

10

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.

Reorder answered 2/7, 2009 at 9:20 Comment(1)

Oh, so if you do attempt to manually reverse engineer the OS, you should investigate the utility of IDL and how to locate IDL's embeded in DLL's, extract the location of the implementation methods. Also, refer to en.wikipedia.org/wiki/MSRPC for some more decent starting points. – Reorder 2/7, 2009 at 9:25

M

1

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, ...).

Mcqueen answered 28/5, 2009 at 3:40 Comment(0)

E

1

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

Emotional answered 28/5, 2009 at 3:43 Comment(0)

Recommended topics

Hot tags