Monitoring Files Builder


Monitoring File Builder is a tool design for creating monitoring files and auto detect potential hooking troubles.

  - Monitoring File Generation
  - Binaries Potiential Troubles Detection
  - Monitoring File Update
  - Warning messages explanations.
  - Proxy file syntax

  - How to build a monitoring file (tutorial)



Monitoring File Generation


First select the dll or exe file you want to monitor ("Target File"), and the resulting monitoring file path ("Output Monitoring File")

Next you have to select the "Parsing Type" : if you want to parse Import or Export table.


Parsing Type

Specify the type of monitoring file to generate :

Import table is the list of all librairies and functions address used by the exe or dll.
So instead of hooking the full kernel32 library and monitoring functions that are not directly called by your exe but by noisy dll subfunctions,
you can specify only usefull functions. It's really speedest.

Export table : is the list of all exported functions of a dll.

.Net assembly : allow to generate a monitoring file for all internal functions of your .NET binaries.

Parse Associated Debug File : if your binary has debug information, allow to generate a monitoring file for all internal functions of your binary.

COM Type Library : Parse .tlb (or ocx, dll, exe) files to generate COM auto monitoring file for all interfaces contained in the specified type library file (notice "Output monitoring file" is not used in this case)

COM All Registered Type Library : parse all COM components and their interfaces registered on computer to generate the associated COM auto monitoring file (notice "Output monitoring file" is not used in this case)
COM auto monitoring files generation does not add options for methods creating objects,
you still have to add them manually. See COM : Interface Methods creating objects



Options :

  - "If function definition not locally found, try to find it on online MSDN" :
For Microsoft dll only, you can query to do an online MSDN search to get the full function and parameters description.
You can use a proxy to do it. In this case specify the proxy settings in the "proxy.txt" file on the same directory.
Notice : function description is first searched in the monitoring file diretory, and next, if not found, on online MSDN;
so more you have function descriptions in your "monitoring files" directory, less online MSDN will be used.


  - "If function name don't gives information about number of parameters, call function to try to find their number" :
If no information on the number of parameters can be retrieve from the name of the function, you can ask to make a call of this function.
Warning it can crash the software very easily according function called.
The best way if you want to use this option is to build your monitoring file in two pass :
- first one without this option
- next one with this option and a partial generation (only for function where parameters retrieval has failed).
Make sure you're using another output file name for the second generation.

  - "Detect potential hook troubles during generation" :
During generation , Monitoring File Builder tries to find all functions that can't be hooked and identical functions (a single function can have different exported names).
So by checking this options, quite all potential functions hooking troubles are removed during file generation.

  - "Generate first bytes analysis result. This avoid analysis each time your monitoring file is loaded, but your monitoring file is no more generic, that means you have to update it each time your exe/dll is modified."
This option generate the |FirstBytesCanExecuteAnyWhere options (see monitoring file syntax).
Since v3.1 WinAPIOverride can do the same analysis at hooking time, and the time requiered for analysis is very short, so this option becomes quite useless.
This is usefull if you want to see and verify the analysis results.

The number of parameters tries to be retrieved according to the calling convention

C++ functions are fully decoded

Dll exported functions hooking troubles are auto detected

Dll forwarded functions detection



Binaries Potiential Troubles Detection

Monitoring file builder tries to autodetect hooking troubles.
To do it, put the binary you want to check as the target file, specify the table you want to check (Import or Export), and click the "Detection" button.

A monitoring report troubles is done in the "Generation Log" output.
To know what these messages means report to the Warning messages explanations section.



Monitoring File Update

  - "Update monitoring file for a new version of a binary (search new functions and update first bytes analysis)"
A new monitoring file generation is done according to function description of the old monitoring file.
First bytes analysis is removed, and it is writed again only if the option "Generate first bytes analysis result ... " is checked

  - "Update first bytes analysis only"
As name says, it's don't look for new functions in binary, but just do a new first bytes analysis

  - "Remove first bytes analysis"
Remove first bytes analysis from a monitoring file.



How to build a monitoring file

If you want to monitor few functions (one or two), you can write monitoring file by hand according to the monitoring files syntax.
To check that your functions can be hooked, you can use the Binaries Potiential Troubles Detection.

If you have lots of function to monitor, or you don't know the ones to hook, you should better use Monitoring File Builder.

For an EXE (or to parse an import table)

Notice: This tutorial is only for functions present into import table. To get all functions, static linked and dynamically loaded, follow the notepad tutorial

Select the exe you want to monitor.
Next adjust the output monitoring file name if necessary.

In this example instead of doing a full generation, we are going to do a partial generation to choose functions we want to hook.

By the way for Notpad, we get

On the left list you can select dll you want to watch or not, and for each selected dll, you can specify functions to monitor.

Once done, click the "OK" button.

Monitoring file generation begins

At the end of generation, a message appears querying you if you want to do some adjustments on the built monitoring file
Just reply Yes to open file and check it.

You had better to monitor LoadLibrary and GetProcAddress to see functions dynamically loaded by your application.
(With a view to monitor them next if necessary)
See the notepad tutorial


For a Dll (or to parse export table)

Select the dll you want to monitor.
Next adjust the output monitoring file name if necessary.

In this example Instead of doing a full generation, we are going to do a partial generation to choose functions we want to hook.

By the way for kernel32.dll, we get the following

Select functions you want to hook as done for Exe monitoring file generation.

Click "OK"

As we parse export table, and we don't disable checking, we get an export warning output like

Warning: Function AddVectoredExceptionHandler is a forwarded function for NTDLL.RtlAddVectoredExceptionHandler
...
Warning: Function CreateProcessInternalWSecure can't be hooked: It's size is less than 5 bytes
...
Warning: Function lstrlenA has the same entry point as lstrlen


See Warning messages explanations to know the meaning of these messages

Functions causing troubles when export checking is enable are disable by default


Next, the generation is done in the same way as exe monitoring file.





Warning messages explanations

Warning: Function lstrlenA has the same entry point as lstrlen
: functions "lstrlenA" and "lstrlen" are, in reality, a unique function.
If you try to hook both, you'll get a warning message for the second description saying that function is already hooked.
(See Faq:Multiple hook definitions for the same function)

Warning: Function LZDone can't be hooked: It's size is less than 5 bytes : if you try to monitor such functions, you get 100% of chance to crash
your process after a while. Such functions can't be monitored nor overrided

Warning: Function HeapSize is a forwarded function for NTDLL.RtlSizeHeap : HeapSize is just a redirection to RtlSizeHeap of ntdll.dll.
So HeapSize will have the same address as RtlSizeHeap in your process. So if you try to hook these both functions, you'll get a warning message for the second description saying that function is already hooked.
(See Faq:Multiple hook definitions for the same function)

Warning: function pow() may can't be hooked: It's size seems to be less than 5 bytes --> you have to do a manual checking : function may is
less than 5 byte length but we get no other information. This is the case when a function begins with a short jump (3 bytes).
Hooking availability depends on function algorithm.
Notice : By default you should better not hook these functions

Proxy file syntax

Proxy file is used to retrieve description on online MSDN for those who needs a proxy to connect to the Internet.
It must be in the same directory as Monitoring File Builder.

Use ';' for comments

ip:port:ProxyType where ProxyType is GET, CONNECT, SOCKS4 or SOCKS5

Examples

Using the Connect proxy at ip 66.220.11.235 and port 3128
66.220.11.235:3128:CONNECT

Using the Socks5 proxy at ip 165.229.205.91 and port 4769
165.229.205.91:4769:SOCKS5


Using proxy is very slow. Do it only if you have no other way

Avoid to use public GET proxy as they generally put adds and redirection that make function retrieval fail