[Question] Internal commans handling

Discuss and announce Total Commander plugins, addons and other useful tools here, both their usage and their development.

Moderators: Hacker, petermad, Stefan2, white

User avatar
majkinetor !
Power Member
Power Member
Posts: 1580
Joined: 2006-01-18, 07:56 UTC
Contact:

Post by *majkinetor ! »

I can try to find detailed article at home explanin this.

It was prefiously made by Vioulus guy. But he changed his site recently so it is no longer there. The app I mention he did is named PillowFort. It is still availalbe.

Anyway, this guy never destoryed original procedure like you. He just added jmp at the top of the original func, but I think he executes the overwriten code at the end of his rediretion function. When he returns, the original function just continues... I don't remember this very well, maybe Iam wrong about something.

Google for "violus.com Redirections" and you will see this guy even made a class for this. To bad it isn't cashed.

Your thread problem is indeed nasty. Thread2 has not crit section so it will call garbaged function. This can be fixed with dissasembler like I explained you so Thread2 will call your function as you don't have to do stuff you do now in CS.

But there's no way to ensure that my dll will get the same address in all processes.
Why do you care. Your dll will be loaded at any adress. Then it finds out address of RegisterClass function and patch it in address space of that process. If you put replacement func in the dll itself, its adress will be valid for host process only.


Acctually for particular function you don't need desasm at all, as you can detect its start manuely. U can suppose that WinProc has the same start for every TC version. Violus did so for OpenSocket function. He detects OS version and patch the function with 2 or 3 different codes depending on the version. The desasm is needed for creating universal solution.


Maybe you can try this open-mind solutin:

When you enter critical section, make priority of your tread Real Time so nothing can enter the scene until you finish your cole. Then restore thread priority to normal. Perhaps there is some other way to make trhead un-interuptable by other process threads. Furthermore, perhaps there is a way to make threads non interuptible once they enter crit section so other threads, even those not knowing about crit section can not interupt it.
Habemus majkam!
User avatar
majkinetor !
Power Member
Power Member
Posts: 1580
Joined: 2006-01-18, 07:56 UTC
Contact:

Post by *majkinetor ! »

The only way to prevent it is stopping all running threads instead of entering the critical section. But what if the function waits for some input from another thread or so? Unacceptable.
I didn't see this originaly.

Well, it might work. You can suspend treads, execute functions, and resume threads. It can not spoil the waiting, it will just slow it down. Depending on waiting implementation it might show bugs as thread may check the time and decide that it waited too long for the input.

Also, I beleive TC has not such advanced thread usage (threads communicating with eachother on some greter level of sophistication, like the one you said above, waiting for the input coming from another thread). Ghisler can xplain how he use threads but I doubt he will do that.
Habemus majkam!
User avatar
m^2
Power Member
Power Member
Posts: 1413
Joined: 2006-07-12, 10:02 UTC
Location: Poland
Contact:

Post by *m^2 »

majkinetor ! wrote:It was prefiously made by Vioulus guy. But he changed his site recently so it is no longer there. The app I mention he did is named PillowFort. It is still availalbe.

Anyway, this guy never destoryed original procedure like you. He just added jmp at the top of the original func, but I think he executes the overwriten code at the end of his rediretion function. When he returns, the original function just continues... I don't remember this very well, maybe Iam wrong about something.

Google for "violus.com Redirections" and you will see this guy even made a class for this. To bad it isn't cashed.
Thanks, I'll search deeper for it.
majkinetor ! wrote:I can try to find detailed article at home explanin this.
Yes, please.
majkinetor ! wrote:
But there's no way to ensure that my dll will get the same address in all processes.
Why do you care. Your dll will be loaded at any adress. Then it finds out address of RegisterClass function and patch it in address space of that process. If you put replacement func in the dll itself, its adress will be valid for host process only.
Yeah, right. I thought you're still talking about these shared things.
majkinetor ! wrote:Acctually for particular function you don't need desasm at all, as you can detect its start manuely. U can suppose that WinProc has the same start for every TC version. Violus did so for OpenSocket function. He detects OS version and patch the function with 2 or 3 different codes depending on the version. The desasm is needed for creating universal solution.
Finding the address is faster than finding TC version :D
And doesn't require further mods ;).
majkinetor ! wrote: Maybe you can try this open-mind solutin:

When you enter critical section, make priority of your tread Real Time so nothing can enter the scene until you finish your cole. Then restore thread priority to normal. Perhaps there is some other way to make trhead un-interuptable by other process threads. Furthermore, perhaps there is a way to make threads non interuptible once they enter crit section so other threads, even those not knowing about crit section can not interupt it.
Sounds good :)
majkinetor ! wrote:
The only way to prevent it is stopping all running threads instead of entering the critical section. But what if the function waits for some input from another thread or so? Unacceptable.
I didn't see this originaly.

Well, it might work. You can suspend treads, execute functions, and resume threads. It can not spoil the waiting, it will just slow it down. Depending on waiting implementation it might show bugs as thread may check the time and decide that it waited too long for the input.
I suspend all threads. Then execute this function. And this functions calls WaitForSingleObject on another thread. And never returns.
majkinetor ! wrote: Also, I beleive TC has not such advanced thread usage (threads communicating with eachother on some greter level of sophistication, like the one you said above, waiting for the input coming from another thread).
So do I. :)
User avatar
majkinetor !
Power Member
Power Member
Posts: 1580
Joined: 2006-01-18, 07:56 UTC
Contact:

Post by *majkinetor ! »

Finding the address is faster than finding TC version
I think you don't have to anylise TC version. Different TC versions will have different WinProcedures but you can assume their start will be the same (you can check this easily by examing the code on the start of the function for diffferent versions of TC)
Sounds good
Acctually it sounds good for functions that is not called so often. WinProcedure is called on millisecond basis so you will probably block entire system by making this procedure Real Time.
This can probably be used with some functions not having such big usage.
Habemus majkam!
User avatar
m^2
Power Member
Power Member
Posts: 1413
Joined: 2006-07-12, 10:02 UTC
Location: Poland
Contact:

Post by *m^2 »

majkinetor ! wrote:
Finding the address is faster than finding TC version
I think you don't have to anylise TC version. Different TC versions will have different WinProcedures but you can assume their start will be the same (you can check this easily by examing the code on the start of the function for diffferent versions of TC)
I don't want to do such assumptions, especially as I wrote it already ;)
majkinetor ! wrote:
Sounds good
Acctually it sounds good for functions that is not called so often. WinProcedure is called on millisecond basis so you will probably block entire system by making this procedure Real Time.
This can probably be used with some functions not having such big usage.
Making a procedure Real Time doesn't increase amount of data it has to process. And with TC main window, on modern machines, CPU usage for this procedure is probably never > 1% (of course measured at long enough period of time ;) ).
EDIT:
And the thing I want to capture is not the window procedure but internal commands... Which are (probably) captured somewhere else :/
User avatar
majkinetor !
Power Member
Power Member
Posts: 1580
Joined: 2006-01-18, 07:56 UTC
Contact:

Post by *majkinetor ! »

So, how it goes ?
Habemus majkam!
Post Reply