Actually, why all this crap, if we can go to Ring0 (under Win9x it is no big deal) and there intercept our interrupt? :rolleyes:
Posted on 2002-03-18 13:11:44 by masquer
Masquer,
To me it just seems easier and more logical to hook it before windows does. Especially if its for a "protection" scheme, as seems likely in this case. Also those ring 0 "hacks" seem very dirty and improper to me. Especially for a commercial product that may need to one day run on a different OS. Those backdoor ring0 thingy's are all OS dependant and even OS version dependant. This way it will work not only under 9x. but also 2k, ,XP and even linux. To Bogdan this may not be the immediate case, but overall it strikes me as a more reasonable solution for whatever his problem may be. Assuming it works. :)
Posted on 2002-03-18 13:31:12 by emonk
Interesting, how do you achieve your goal in Win2k (I mean with MBR), for example. Do you really think that modifying MBR is more neaty. I know some protection scheme that work that way and I think this is more perverted than viruses and quite weak, IMHO
Posted on 2002-03-18 14:11:00 by masquer
hi,

boot virus only can mantain its int13 hook under windows if they delete HSFLOP.PDR, in /win/sys/iosubsys directory.

the idea that is better 'infect' the mbr to hook a int, instead of using a 'hack' becoz the machine the application can run someday under a updated OS is a joke.

its easier get incompatible by changing the mbr, with all these antivirus, strange OS, somebody else using the mbr for something, large disks schemes et all, than with a hack, that you can put into a seh frame.

ancev

ps: a program that use a win32 hack have the same chance of running in linux than a boot sector that hook a INT have ;)
Posted on 2002-03-18 16:52:55 by ancev
ancev, doesn't that trick only work under 9x? I don't think NT thunks
down to bios/v86 code for something as trivial as HD access :).
Posted on 2002-03-18 16:57:23 by f0dder
I would agree with f0dder that if the irq routine is located in win32 code it has to be in a dll in "shared memory" (mark ALL sections as shared)
Posted on 2002-03-19 02:27:14 by japheth
Ancev or F0dder,
Not to seem like I am arguing the masters :) , ,but could you explain to me then why/how the example I posted works for me on a machine with lilo and linux and win2k all installed? I believe what you say. I would just like to understand the reasoning. have you tried the example? It hooks int 13h so that anything which tries to write or read mbr is returned a "normal" one instead of the bogus one. It did not set off my antivirus (norton 2k). So I assume it works. At least for this authors use. (Norton is supposed to detect changes to MBR.)

PS - Here is a link to MSDN showing how to create "safe" int 13h hook under 95/me. Seems to work under 2k/Linux also for me :)

http://msdn.microsoft.com/library/en-us/wmeother/storage_5l6g.asp
Posted on 2002-03-19 06:46:36 by emonk
I have not been on the net for some days now, and after comming back it is interesting how a thread can deviate from my original intentions :(

To put a STOP to this: i am not interested in any viri operation and infesting the MBR is nowhere even remotly near my intention...

i just want the hardware IRQ1 (aka keyboard) to pass to my code, so int13h (that is a software bios int) in not my concern...

and i also want to be able to do that dynamically (no reboot) and for a short period of time (while certain phase of a programm is running) and then i want to be able to completly reverse it an leave the system/OS in a very clean and nice state

I guess fodder was right and i dont know how was i capable to overlook the paging stuff...it must of been one of my very bad days or the fact that i do not use paging yet in my OS... :)

Japeth: do you think a .DLL (shared) whould work? or i need a VXD?

Thx for everybody that tried to help me here ...
Posted on 2002-03-23 12:16:52 by BogdanOntanu
I have hooked IDT entries for exceptions 0, 1, 3 and 6 with shared win32 code and it worked well in Win9x. The code should be marked as non-pageable I assume.

Other VMs (dos apps) have their own IDT. So you possibly will not get key strokes from these apps. For such purposes a Vxd will be better.

japheth.
Posted on 2002-03-23 14:29:20 by japheth
Instead a VxD maybe CreateFileMapping / MapViewOfFile are enough to have shared memory on all processes ?
Posted on 2002-03-25 02:10:00 by BJZ
I must second Bogdan here, lets keep this crap outa here, its treading very close to the edge of forum rules and our rules are VERY clear about viral techniques.

Regards,

hutch@movsd.com
Posted on 2002-03-25 04:36:34 by hutch--
Bogdan,

here is my (working code) from a win32 dll:



intproc proc
push 0 ;make room for original vector
pushad
pushfd
push ds
push es
mov eax,ss
mov ds,eax
mov es,eax
mov eax,oldaddr
mov [esp+32+12],eax
invoke OutputMonoString, addr szKeyEvent
pop es
pop ds
popfd
popad
ret
intproc endp


what should be mentioned
- when entering an irq routine all registers (except cs) are undefined
- if ring has changed, stack will have been switched. The above routine assumes that ss will always be a flat selector. This should be the case in win9x, but its only a convention.
- you will need to initialize ds and es!

japheth
Posted on 2002-03-25 07:22:11 by japheth
Thx man
I will check it out :)

Some more little Q:
-how to mark code as non-pageable?
-offset stuff will work anymore ?
(hehe... i need to make some C++ interfaces for it)

Thx again
Posted on 2002-03-26 00:16:32 by BogdanOntanu
If I remember correctly you need to kick the cpu
after you change the idt/gdt because it is
cached.

So you can mess with the interrupts in protected
code and ring 3?
Posted on 2002-03-26 02:03:48 by bdjames
Bogdan,

- VirtualLock() will lock a region in memory so it cant paged out.
- Im not sure if I understand your second question. The "offset" operator should always work as long as cs,ds,es,ss are flat selectors.
Posted on 2002-03-26 02:57:52 by japheth
Thx japeth and all

I have moved the Ring0 IRQ handler into a VXD LOCKED section. I as using a VXD for other jobs anyway so even if it looks that code could be in a shared DLL also i guess the "all in a VXD" make for more monolithic code, also more "standard"

Interesting for the debate now comes a now problem: the VMM :(

the VKD driver virtualizes the IRQ1 before i get a chance to do it and because of that i can not use it, so i am back to changeing the IDT. After i do that i get "beeps" on all keys and everything seems to work ok...

But it is not: some keys get pass my IRQ handler (and i trap them i a normal VXD keyboard hook routine)... i was puzzeld at start...

then i realized that diffrent VM machines have their own IRQ handlers and somewhere/sometimes the VMM sheduler changes the IDT back to its original vector :(

I was also trying to place the read keys from my simple IRQ1 handler back into the system keyboard queue using the VKD_API_Force_Key VxDCall but surprise: teere is no include with this call even if it is presented in the 98DDK....hmmmm

I then used VKD_Put_Byte inside my IRQ handler....waiting for a crash... ooops there is no crash but no key inserted in the system keyboard queue neither....

To sumarize my problems are now changed, but in the same range:

1.How to hook ALL VM's IRQ1 handler and not only for some VM's

2.After hook how to insert scancodes read via in al,60h back into the system keyboard queue....

I am working on that....so any help is welcome...

Thx
Posted on 2002-03-28 15:09:04 by BogdanOntanu