Now, lets get to my report:
EasyHook is really really easy!
I copied the code that I found in EasyHook's manual and started from there. Luckily, the code was just about a "demo application, which logs all file accesses from a given process". That's not what we need, since we're going to keep track of files changes, and not files accesses. But it's very similar and helped me figure out everything.
That code produces 2 files: an executable that injects a DLL into a given process (like explorer.exe or any other chosen by command-line) and our DLL to be injected, wich intercepts pre-defined calls from the attached process. The executable used for injection continues running, acting like a "host": receiving the DLL log and printing it to the console. The injection terminates as soon as that executable ends.
The first and crazy thing I did was finding a way to "eliminate" this executable and make it run from a single file, as DLL, if possible...
That was the most difficult part, and I did! Why? Because otherwise it would be all the time like this: Tabbles calls DLL Injection executable, that calls EasyHook executable, that calls Injected DLL, that calls LOG treatment's DLL. Everyone running at same time, just to keep track of files. D=
And I heard that Tabbles already uses 4 or 5 threads together and is becaming memory consuming...
So, I made a kind of "auto-injectable" DLL!
I became surprised when it worked, because, at the beginning, everything seemed to be like one DLL for each function to inject, and maybe one executable for each one too. But I managed to do everything in a single call, from a single DLL file! Including all the other functions too!
Oh, I also managed to inject the same DLL in more than one process, from this same file! \o/
But, of course, the final DLL needs an external little trigger to run:
Just add a reference to it in your .NET project and call its static "Start" method. The DLL will start, inject itself to the chosen processes, carrying all of our intercepting functions, and stay injected as long as your .NET project executes.
After injected, our function starts to be called right before the original API. Then we can do whatever we want with its parameters, like logging and updating Tabbles with new path/name of files. Since we need to know if the original function will be suceed or not, to avoid updating Tabbles with fictional changes, I tried to call the original one first and then include its result into the LOG too. But the original one executes without returning to my function, and then, avoiding the entire LOG. I've managed to "fix" this, except by the fact that the original function throws a weird "file not found" error. Weird because everything else keeps working properly, finding, moving files, and logging after this! So, for security purposes, I returned the original function back to the end again. This way, we'll have to store the LOG and check it later to know if the files operations were succeed or not - in other words, if we must update Tabbles or not.
Once in our functions, we can pass the LOG to other softwares by writing to a log file, or by calling their 3rd-party DLLs, or writing to registry, or by inter-process communications. What's the best way for you? Any other ideas?
But maybe we should consider performance costs too...
By writing a log to disk or registry, we should somehow delete it every once in a while, watching performance and data losses.
By having my injection call a 3rd-party DLL, I'll need to "register" each 3rd-party DLL into a ".INI" file, for example, and call them in a FOR loop, wrapped inside by a try/catch block, to avoid system messes.
In this case, you'll need to develop your own DLL, install/register it in my ".INI", and then receive my real-time LOG through it. Once received, you'll have your DLL check the result of files operations, and then update Tabbles.
I also can store this LOG in a static Arraylist inside the DLL too, wich could have its operations results verified after some time, and then accessed, and cleaned, and managed by ... by... oh, I don't know... xD
But it's not a good idea, because if it comes to happen some crashing, this in-memory LOG vanishes...
Another important issue is that, using EasyHook, if an already injected process ends, we need to detect its termination and reinject it as soons as it executes again. Otherwise, we might lost track of some files between injections, in case of that process moves or renames them.
Ok. For now, I guess these are the topics we need to think:
- Decide what processes we're going to track; (we could even watch and inject every active process if needed!)
- Decide how to assure a "24-hour injection"; (at windows startup, managed by some "tray-icon-like" program?)
- Decide how to pass the log for softwares; (I think Tabbles shouldn't be the unique one, for performance purposes)
- Decide if EasyHook provides our needs; (I'm kind of lazy to analyze alternatives now...
)- Anything else?
As you can see, I guess we need some major planning or brainstorming before continue improving this DLL.
Since it was practically a two-day-ctrl-C work, I don't care about passing all code to you.
This dll is very useful for me too, so feel free to discard it and take another way...
I'm gonna unwind a bit.
See'ya later! o/
And I was expecting you to write on Google Wave. Oh well. 