[Tigzy]

Yes it is.
Why not a good idea? This is not worst than SSDT restore... :|
Gmer does it.

[rkhunter]

This is not stable for working system, actually, unlike to SSDT restore. Some threads can perform part of code that you are will restore (not only usual threads can perform this code, but system threads too). It is an uncertain situation for system. Therefore, this situation will always be executed with a certain probability of risk.

[Tigzy]

Yes, I was aware of this. But there's almost no chance to fall into the API being restored while it being restored.
So yes it can BSOD, but not always

There is no C or ASM instruction to declare atomic parts of code?

[rkhunter]

atomic parts of code?

What you mean?...

[Tigzy]

I mean which cannot be pre-empted by the system.
It would be useful to overwrite the bytes in one shot, without the chance to be preempted and fall into the not-yet restored function.

[rkhunter]

So, in theory, you may suspend all threads and restore code, but there may be code on the stack, that you can also restore and after that, you get an unexpected situation.

[Tigzy]

So the only way to know is to test...
If I got 1% BSOD, it will be good enough for me.

[Alex]

I think there is nothing to test if you are going to implemented such code in public tool (excluding BSOD'ing ARKs by default). And what about watchdog threads - are you going to suspend all of unknown threads (some AVs creates stealth/unknown threads ...)?

[Tigzy]

No, I won't suspend anything.
Just doing it and watch if I got recurrent BSOD.

I guess AVs got the same problems when pushing their inline hooks...
Don't know how they do it safely

EDIT: We cannot disable interrupts with cli /sti ?

[EP_X0FF]

I need to get the very firsts bytes of all of them in order to restore inline hooks

Hook can be installed deeper in function or/and it can be existing instruction patch.

Why not a good idea? This is not worst than SSDT restore...
Gmer does it.

GMER was always sucking at splicing detection and it restoring.

It would be useful to overwrite the bytes in one shot

cmpxchg8b, cmpxchg16b

I guess AVs got the same problems when pushing their inline hooks...
Don't know how they do it safely

There are exist trampoline methods + locking system activity etc, but still KM splicing is unsafe.
As long as you do not create process in suspended state, patch it and then resume.

Why you want to unhook? To use free from hooks API, or what?