A three-line problem under DOS, no-idea-how problem under Windows:
How can a user mode program under WinNT/XP intercept an interrupt?

Details - the program loads some code into memory, runs it, and should react if the code calls int 80h.
I see 2 possibilities - intercepting interrupt ala DOS, or handling an exception arisen from it, getting the address, handling interrupt if address points to int 80h opcode, returning to after the opcode.
Static reconstruction of the code is not feasible.

Any ideas...?

no way... what is point in that? why can't you call what would be interrupt handler directly?

Running Linux ELF executables under Windows?

I see that my WinXP SP2 produces an memory access violation telling that address $FFFFFFFF cannot be read. The problem however is how much you can rely on this. You can trap the exception and perform proper emulation but what if in a newer version of Windows this int starts to be used?

I see no user-mode possible way to achieve this but perhaps the DDK says something about registering ints so you can either make sure that the int will raise an exception or implement the service in the driver (with IPC with a user-mode service or directly in kernel-mode).

Personally I doubt DDK will provide something like that, but it is possible.

Loco: you mean original ELF executables designed for running in linux? I think that is hard enough task to require ring0 code anyway...

vid: Any example of something that mandatory needs ring0? Although I suppose that must be one, none comes to my mind (as if I were imaginative)

Executable layout? For example implementing "brk()" syscall using windows API could be quite big problem. Which call will you use to allocate image of executable, so that later it can be extended to huge sizes in case of brk()? I Think Heap*** won't handle that big block very well, VirtualAlloc won't allow you to enlarge block without moving it, dunno about Global/Local***.

Actually, i wouldn't be so concerned about interrupts that much. AFAIK 99.999% apps use dynamically linked glibc instead of syscalls.

Can't you just call VirtualAlloc using as lpAddress param an address contiguous to the last allocated page? The 3G/1G layout is something that you can't resolve though (and I think that even in ring0 it will be problematic as the rest of the system works with a 2G/2G layout). However, if I remember right this layout is parametrizable in Linux kernels so Linux applications should not rely much in such layout.

About glibc, I was thinking about using native libraries as well so the kernel calls must exist somewhere. Something that must be assured is that binaries uses int $80 and not SYSENTER/SYSCALL instructions as some distros compiled to a specific arch can have. I know that exists a virtual shared library that is used for system calls but I don't know the implementation of it but I suppose the binary expects some patching on the kernel and/or dynamic linker side to use the proper CPU instruction (in which case it would be somewhat easy to perform emulation, I think).

how exactly would you do that? does windows quarantee that all space inbetween is usable? if yes, then it probably could be done.

i hope you aren't thinking seriously about such utility

It is supposed that first 64 KB are unnusable because some functions considers those addresses as atoms. But, from 64KB to 2GB is user address space. If an obsticle appears when you try to expand memory you just return error condition as if there were no more memory.

About if I'm thinking seriously about this utility remember that I'm not the thread author

Also note that such utility already exists but I never tried it and the main site is broken. Anyway, here is the download link (comes with sources).

PS: No, I recalled few minutes ago that this emulator was discussed on this forum so don't tell that I robbed the idea of an Int $80 driver from there

Yes, iam trying to make a small-scale linux binary emulator.

Loading and dynamically linking ELF's to the libc analog is not a problem, so all kind of "hello world" and example programs works, but when i tried some of the real ones, most crashes on int 80h instruction, so i considered the syscalls.

How is it done in virtualisation software? Some kind of static analysis, exception handling, driver or something else?

Thank you for LINE link, looks interesting.
Is there anything alive/under development on that topic?

Driver, with LOTS of trickery.

I think you could go the way with catching that memory access exceptions, and check if they are caused by "int 80" (CD 80).

Also mind differences between MS libc and glibc, you may rather want to use Mingw glibc for win32 (if there is something like that)

hi, currently I'm fighting with the same problem by developping driver for fdbg
something finished to work, something no, the biggest problem - I don't have multi CPU system to test it
only bare copy & paste from my problems.howto, you must extract thoughts usefull for you
I'll be out for 1 week holidays, don't expect anything more from me until my return back from holidays
but don't surrend, your problem really has solution

hooking interrupts

problem No.1
LastBranchFromIP, LastBranchToIP, LastExceptionFromIP, LastExceptionToIP are read-only registers. They can be easily read during task switching, but they CAN'T BE WRITTEN back as threads switch. Microsoft reserved space for all 4 registers in ThreadContext structure, but the space is wasted because it can't be used!
solution: We hook exception interrupts and store these registers at the earliest beginning of exception handler

problem No.2
Multicore CPUs are common todays. We need to load interrupt descriptor table at every CPU in the system.
solution: We won't create new IDTR neither load it using LIDT [IDTR]. We just hook some interrupt vectors which resides in memory. Memory is supposed to be the same for all CPUs in the system as well IDTR is supposed to be the same for every CPU.
-> But:
If the operating system detects an application or driver that patches the kernel, it generates a bug check and shuts down the system. Modifications that trigger this behavior are:
- Modifying system service tables.
- Modifying the interrupt descriptor table (IDT).
- Modifying the global descriptor table (GDT).
- Using kernel stacks that are not allocated by the kernel.
- Patching any part of the kernel (detected only on AMD64-based systems).
Over time, patch protection will be extended to protect additional kernel resources.
successfully run in my Vista x64 without any problem...

problem No.3
LastBranchFromIP, LastBranchToIP, LastExceptionFromIP, LastExceptionToIP registers are specific for only one CPU, they certainly differs in other CPUs in multi-CPU systems.
solution: No matter which CPU holds what addresses of these registers... The only one CPU causing the exception saves these 4 registers at the begin of exception handler which is the same for all CPUs as described in the solution for problem No.2.

problem No.4
The most valuable exception is Page-Fault (int0E). Unfortunatelly, this exception is heavily used by operating system itself for loading pages from swap drive. OS changes all 4 registers with branches very rapidly when loading pages from swap.
solution: Disabling swapping memory. Should work fine. But who want to do it in this way?
second solution: Yes. It exist. Handling int0E requires taking care of the privilege level of the thread causing exception. If the privilege level is the highest, it is allmost OS Page-Fault loading pages from swap (or fatal error in kernel or driver). If the privilege level is the lowest, it is allmost our user-mode program being debugged (or another program running in user-mode). We can access privilege level in rflags register whis is pused into stack by CPU itself just before CPU changes control of execution from program to exception handled.

problem No.5
enabling branches recording requires to enable it in every CPU in multicore CPUs system
solution: enable control register in every CPU KeGetCurrentProcessorNumber, then for every CPU PsCreateSystemThread set thread affinity mask ZwSetInformationThread

edit from 20100201 deleted the attachment because reached the quota limit, download a sample of working driver from download page of flat assembler

This is the Int $80 handler that LINE uses

Not sure if the handling occurs in user-mode though. Take a look on the sources to get an idea. The project seems to be abandoned because the last update is from May 29, 2001 (where he added the driver so, he was using the exception handling approach before?).

I think that running native linux binaries is possible and implementing the syscalls is of moderate difficulty, the problem is simulating the environment, I think that emulating the entire filesystem would be a pain (and I bet LINE does few or nothing at emulating /proc, /dev, etc).

Driver. Tryed that, made a typo, curiously stared at BSOD for a couple of seconds, decided to put it off as last measure.

Problem was relatively solved by using VectoredExceptionHandler, handler checks for instruction at error address, if it's an int 80h then do the syscall.
Works fine for read/write and exit like ones, but i already expect problems with something like fork.
I do compile it with Mingw, and for now just wrapping the functions work fine... Scale is the question.

Thank you for the code, though it's usability is questionable, since i only consider win32.

http://colinux.org/ <- Another project that is not dead

> A three-line problem under DOS

Valid for RM INT's only

> no-idea-how problem under Windows

Very big

> How can a user mode program under WinNT/XP intercept an
interrupt?

Probably via Ring0 only

> see 2 possibilities - intercepting interrupt ala DOS

This won't work on XP/Vi$ta

If you want to explore Ring0, simplest code
I've seen so far:

http://board.flatassembler.net/download.php?id=3251

PS: Posted with Arachne DOS browser.
FASM forum (like most other forums) doesn't look
best here but it's usable

Isn't simplier to just write a driver than relaying on a hacky ring3 program that accesses the physical memory device? LINE sources includes the required driver anyway so he can borrow it from there.

most windows api used kifast and used sysenter

Writing a driver is the best way and easiest way to do things, imho you shouldn't rely on the physmem access hack... hopefully it's going to be patched on future windows systems.

who in here have the source code to windows 2000 or wndows xp?