[ACCEPTED]-Finding undocumented APIs in Windows-winapi

Use a tool to dump the export table from 25 a shared library (for example, a .dll such 24 as kernel32.dll). You'll see the named 23 entry points and/or the ordinal entry points. Generally 22 for windows the named entry points are unmangled 21 (extern "C"). You will most likely 20 need to do some peeking at the assembly 19 code and derive the parameters (types, number, order, calling 18 convention, etc) from the stack frame (if 17 there is one) and register usage. If there 16 is no stack frame it is a bit more difficult, but 15 still doable. See the following links for 14 references:

1. http://www.sf.org.cn/symbian/Tools/symbian_18245.html
2. http://msdn.microsoft.com/en-us/library/31d242h4.aspx

Check out tools such as dumpbin for 13 investigating export sections.

There are 12 also sites and books out there that try 11 to keep an updated list of undocumented 10 windows APIs:

1. The Undocumented Functions
2. A Primer of the Windows Architecture
3. How To Find Undocumented Constants Used by Windows API Functions
4. Undocumented Windows
5. Windows API

Edit: These same principles work 9 on a multitude of operating systems however, you 8 will need to replace the tool you're using 7 to dump the export table. For example, on 6 Linux you could use nm to dump an object file 5 and list its exports section (among other 4 things). You could also use gdb to set breakpoints 3 and step through the assembly code of an 2 entry point to determine what the arguments 1 should be.

Everybody here so far is missing some substantial 42 functionality that comprises hugely un-documented 41 portions of the Windows OS RPC . RPC (think 40 rpcrt4.dll, lsass.exe, csrss.exe, etc...) operations 39 occur very frequently across all subsystems, via 38 LPC ports or other interfaces, their functionality 37 is buried in the mysticism incantations 36 of various type/sub-type/struct-typedef's 35 etc... which are substantially more difficult 34 to debug, due to the asynchronous nature 33 or the fact that they are destine for process's 32 which if you were to debug via single stepping 31 or what have you, you would find the entire 30 system lockup due to blocking keyboard or 29 other I/O from being passed ;)

ReactOS is probably 28 the most expedient way to investigate undocumented 27 API. They have a fairly mature kernel and 26 other executive's built up. IDA is fairly 25 time-intensive and it's unlikely you will 24 find anything the ReactOS people have not 23 already.

Here's a blurb from the linked page;

ReactOS® is 22 a free, modern operating system based on 21 the design of Windows® XP/2003. Written 20 completely from scratch, it aims to follow 19 the Windows® architecture designed by Microsoft 18 from the hardware level right through to 17 the application level. This is not a Linux 16 based system, and shares none of the unix architecture.

The 15 main goal of the ReactOS project is to provide 14 an operating system which is binary compatible 13 with Windows. This will allow your Windows 12 applications and drivers to run as they 11 would on your Windows system. Additionally, the 10 look and feel of the Windows operating system 9 is used, such that people accustomed to 8 the familiar user interface of Windows® would 7 find using ReactOS straightforward. The 6 ultimate goal of ReactOS is to allow you 5 to remove Windows® and install ReactOS without 4 the end user noticing the change.

When I 3 am investigating some rarely seen Windows 2 construct, ReactOS is often the only credible 1 reference.

IDA Pro is your best bet here, but please please double please don't 8 actually use them for anything ever.

They're 7 internal because they change; they can (and 6 do) even change as a result of a Hotfix, so 5 you're not even guaranteed your undocumented 4 API will work for the specific OS version 3 and Service Pack level you wrote it for. If 2 you ship a product like that, you're living 1 on borrowed time.

Look at the system dlls and what functions 3 they export. Every API function, whether 2 documented or not, is exported in one of 1 them (user, kernel, ...).

For user mode APIs you can open Kernel32.dll 4 User32.dll Gdi32.dll, specially ntdll.dll 3 in dependancy walker and find all the exported APIs. But 2 you will not have the documentation offcourse.

Just 1 found a good article on Native APIS by Mark Russinovich