Options

   General Options
   COM Options
   .NET Options

Options Dialog
General Options

Options


   - Get call stack for each call :
As it needs more time and generate bigger log file, if you get no use of this, just uncheck it.
Notice: The stack retrieval can fail according calling convention used
Call stack is shown with parameters values in the details listview of main dialog.

   - Number of stack parameters to retrieve : allow to get parameters values for each calling function Only stack parameters are saved. As calling function are unknown, no advanced parameter parsing can be done, so you will only get raw parameters value (values passed through stack).

   - Allow Tls callback hook instead of entry point : If exe you want to hook has some tls callbacks, begin hooking at tls callback instead of entry point.
As tls callbacks are executed before entry point, this can be usefull (for virus or malware analisys by the way).
You can monitor, break or override api during tls callbacks execution.
Notice: This option applies only for the "Attach at application startup" and "Attach to all new processes" starting option.

   - Uses Debug Symbols Servers : Use the symbols servers for stack information displaying. You will get more accurate results for function names of the Microsoft dlls in the call stack displayed in the Detailed View (Notice option acts for Dumper too). To download Windows symbol packages, goto https://developer.microsoft.com/en-us/windows/hardware/download-symbols

   - Force InOut monitoring mode for all functions : put all monitored functions in InOut logging mode. (Overwrite the options specified in the monitoring files)

   - Monitoring files debug mode : put all monitored functions in InOut logging mode, and stop taking filters into account. Doing this, each hooked called will be log twice: first time before the call, and a second time after the call.
This help to detect crashing hook. The hooked function which make crash your target is the one having a InNoRet log without its Out corresponding log; or it's the last logged function. (For InOut, InNoRet and Out definitions, refer to the Monitoring Directions section of monitoring files description).
Debug mode option will slow down your application execution and logging. Use it only to debug a particular monitoring file.

   - Break Dialog don't break ApiOverride threads : Allow you to make action while the break dialog is displayed. By the way you can do remote calls, load/unload monitoring files or overriding dll.
Unchek this only if you want to make sure there's no other thread running that could disturb your current breaked state.

   - Use Csrss hooks instead of driver to catch created processes : On Vista and Seven only : avoid driver use to catch all created processes (and so avoid drivers signing)

Hooks Type

Powerfull hooks is the recommanded setting (you still can use "|FirstBytesCantExecuteAnywhere" for the only set of function which needed it)

The only intereset of Powerless hook is that all function opcodes are restored before calling the function, so it's interesting for function computing there one checksum, but the "|FirstBytesCantExecuteAnywhere" flag used for such function will do the same for Powerfull hooks

Powerful and Medium hooks use the size length disassembly to install hook. This will comput and check first bytes to try to execute them at another place.
It will have the same effect as  |FirstBytesCanExecuteAnywhere= and  |FirstBytesCanExecuteAnywhereWithRelativeAddressChange= monitoring file options (See monitoring files other options).
The great advantage of doing this automaticaly at hook installation, is that version and code of hooked dll can change, and you don't need to update your monitoring file.

Now let's talk about Secure and Insecure first bytes analysis.

Length size disassembly will give us information of instruction size, so this allows us to execute first instructions at another place, without "cutting" an instruction (only part of all instruction bytes moved).
As hooking needs 5 bytes to be installed, we check instructions until the sum of instruction bytes size is greater or equal to 5.
Of course used algorithm detect unmovable instructions like relative 1 byte jump or a return placed before the 5th byte.
So now there's tow case :
1) the first instruction length is greater or equal to 5 bytes
2) we need to move more than one instruction to put our hook.

In the first case, we are sure that first bytes can be executed anywhere without any trouble.
In the second case, if first bytes match a well known sequence, first bytes can be moved still without trouble; but in other case you can get troubles if a following instruction make a jump into first moved bytes.

Secure analysis : hook is installed if first instruction length is greater or equal to 5 bytes, or if function begins with a well-known sequence.
Insecure analysis : Secure analysis + functions not having unmovable instructions in first bytes.


Example of function that will run into troubles with Insercure mode (XP SP1 ntdll wcslen function code) :
77F41901: 8B442404             mov eax, [esp+04]

* Jump:
 77F4190D(C) 

77F41905: 668B08               mov cx, [eax] // at this point, we haven't detect any trouble 
                                             // in first instructions, and sum of instruction bytes is 7
                                             // --> In insecure mode, first bytes are executed at another place
                                             // and the remainings instructions are executed with 5 first bytes overwritten by the hook
77F41908: 40                   inc eax
77F41909: 40                   inc eax      
77F4190A: 6685C9               test cx, cx
77F4190D: 75F6                 jne 77F41905 // here we jump on second instruction, or, in insecure mode,  
                                            // hook is not removed at execution so application is going to crash
                                            // In secure mode you won't get this error, as the first instruction size is less than 5 bytes, first
                                            // bytes won't be executed at another place, and hook will be removed during function execution
77F4190F: 2B442404             sub eax, [esp+04]
77F41913: D1F8                 sar eax, 01
77F41915: 48                   dec eax
77F41916: C3                   ret 
        
With a picture it can be more expressive.
The crashing jump is drawn in red

The |FirstBytesCantExecuteAnywhere monitoring file options becomes really interesting for an Insecure first bytes analysis use.



First bytes sequences currently considered as secure :

1) Microsoft stuff present since XP SP2
mov edi,edi
push ebp
mov ebp,esp


2) Classical function start with a requiered stack expressed with 1 byte (sub esp)
push ebp
mov ebp,esp
sub esp @8


3) Classical function start with a requiered stack expressed with 4 bytes (sub esp)
push ebp
mov ebp,esp
sub esp @32