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
Related
I am trying to understand how code, regardless of the language, works. Specifically thinking about software that runs on Windows.
Is my understanding correct that every built in function of a particular language maps to an exposed function in the Windows API when writing software for the Windows platform?
I guess my question can be even more generally, can a language do anything outside of what the OS provides? If so, how? What is an example of this?
There is a theoretical and a practical answer to this.
Practical: yes.
The WinAPI is the API everything uses to do things on Windows. It’s stable and compatible between versions so you can write whatever you want with it and it will work on practically any version of Windows given you don’t use any APIs that aren’t present in an old version. There isn’t any other interface to talk to the operating system properly.
Any language or platform that wants to work on top of this will call WinAPI. C libraries, Python, etc all are written so that they work on top of it (often other languages use C or C++ libraries which use WinAPI).
Theoretical: no.
Windows itself includes a Native API which is the actual OS interface and WinAPI is built on top of this. It is not really used if it’s not necessary since it’s not really documented. It’s used in a couple of Windows components that need to run before the other parts of the system are running and you can build applications linking to this API. But since it’s undocumented it’s not really reasonable and may change whenever.
There is also the syscall level. Several Windows components provide the lower level services for operations done on the WinAPI level. You can write, for example, an assembly program and use the syscalls directly if you want to. Mostly you don’t want to so this is more of a theoretical rather than practical answer to different platforms communicating with the OS. These also may change based on the OS.
WinAPI is basically only one subsystem that runs on the NT kernel. For example, Windows Subsystem for Linux is another one which implements its own syscalls which are then translated to Windows ones. There has also been a POSIX subsystem previously.
So all in all it depends on which level you look at it, but the practical answer is yes. Everything practically runs on WinAPI.
Yes. Even if an application exits immediately, it uses a windows call.
So it is not only theoretical. In theory, as in practice, every Windows application uses the API, because there is nothing else to use.
Even if you try to rewrite each functionality you are about to use, you would eventually have to install a driver, and this also mean you would use the API.
I was wondering if it's possible somehow to use windows.pas on OS X with Lazarus?
I need to use special library in my project, and one of key-files uses windows.pas :( Any ideas?
Windows.pas only works on Windows. You will have to edit the library to put an IFDEF around it in the uses clause, and then provide alternatives for any functionality that is then broken. Or contact the library author and see if there is already a non-Windows version available.
You certainly cannot use Windows.pas under OSX. Because Windows.pas exposes the functionality of the Win32 library.
If you need to execute Win32 code on OSX pretty much your only option is Wine.
A more plausible solution is that you find an alternative to this "special" library to which you refer.
Windows.pas is mostly a wrapper around different DLLs contained in the Windows operating system. As it is unlikely that you will find those DLLs in OSX I guess you are out of luck.
You could check the library's source code and try to identify the constants, procedures and functions that are used in windows.pas. If it is not too much code you could try to modify the library so that it uses corresponding Carbon functions instead.
While the various answers are correct, and the vast bulk of unit windows is not portable, some functionality IS abstracted. Structures like interlockedincrement, Rect and ColorRef, and some message related functionality. Have a look at types and lcltype and the system unit interface of FPC.
A lot of Delphi code still uses Windows for that functionality, while e.g. unit types already exists since D6.
Some other things are abstracted, but not using the same (windows unit) calls. Better explain what exactly you need in a separate post.
I was wondering if there is any Borland cross compiler that can make my windows code work on linux without wine.I'm using winxp with delphi 7. I was always wondering if it was possible to code same tool I coded in windows , again in Linux and how is it possible to code same tool by using pascal code in linux.Thanks
The best solution is Lazarus, the delphi-like GUI for Free Pascal. If you were using "pure" vcl, without Windows internales or any special add-ons the migration will be a pice of cake :)
Take a look here: http://lazarus.freepascal.org
BTW - Lazarus and FPC are true mulitplatform - you can compile code for Linux, Windows, MacOS and more with the same codebase :)
Your only option, if you want a Borland Delphi cross-compiler, is CrossKylix. This isn't a real cross-compiler. Instead you run the Kylix compiler for Linux under an emulated Linux environment.
Note that you'll be forced to use CLX rather than VCL and that Kylix is well and truly dead nowadays. Personally I think Wine is probably an easier and better option.
First of all, it all depends on what system functions you used in your programm. In most cases, there will be no possibility to cross-compile it under linux.
But, in some cases Borland Kylix can help, but, afaik, it's almost dead now.
Delphi 10.2 Tokyo supports Linux 64-bit Native Code Compilations.
To get some preview screenshots, click this post:
https://helloacm.com/delphi-compiles-code-to-linux-64-bit-server/
Is there an open source program for Windows that offers the same functionality as Linux' /lib/ld‑linux.so.2?
You might want to look at the ReactOS project.
They should have everything to load DLLs, and it is open-source.
The loader is a core part of the OS on Windows; there's no open-source alternative I'm aware of, and I'm not sure it'd be possible to do it correctly in any case - you have to handle the minefield of assumptions that kernel32/ntdll have regarding address space layout, support SxS, ASLR, hotpatching, and more.
Open-source linkers are common (e.g., gnu tools), but I gather that's not what you're after.
The Enhanced Dynamic Linking Library for MinGW under MS-Windows may be helpful. Take a look especially at the bottom for the edll solution.
You mean using dynamic libraries? In Windows that's automatic when you use LoadLibrary on a .DLL.
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