Abel Self Learning Loader Generator

1. What is this ?

This is loader generator tool, that allows you to generate loaders (don't ask me, what's this, please ;) based on ABEL engine (written by me). To learn more about ABEL and learning ability, read 'learning_ability.txt'.

2. Basic options

a) Detection method - there are 3 possibilities: standard, window caption, window
class. Standard method means periodic 'sampling' of target process memory, checking
if original bytes sequence matches data found in memory. If match is positive,
patching process begins. Other methods work a little different: before sampling
target process memory, loader searches for window of desired caption or class
(check this with hwnd directive in SoftIce). Window methods are suitable when
used exe-packer double-checks unpacked program before running it.
Additional options:
* Hide window - 'trigger' window will be hidden after the patching process is
complete
* Attempt to kill it - an attempt will be taken to kill trigger window
* Get ProcessID from handle - after finding selected window loader will
get ProcessID of the thread that owns 'trigger' window, and continue
patching in the virtual memory of that process. This option allows
patching of exe-packers running main program as child process (not just
thread), what makes 'normal' patching impossible (this method is used
by some versions of A?ma?illo).

b) Timeout - time (decimaly, integer in sec) that loader will wait for target process
to load. Usually time about 10 sec is OK, 15 sec is more than enough for most
programs even on slow machines.

c) Patch delay - time (decimaly, float in sec) that loader will wait before
patching process will begin. You should use this option with caution - delay that
works OK on your machine, can be improper on faster (or slower) PC.

d) Priority boost - when target process runs at higher priority than "normal"
level, loader may not be able to apply patches on time - that option sets
loader's thread priority to highest.

e) Autolearning - enables searching for characteristic bytes sequences (entered
in each patch data) along target process memory. Remember: target process must
be fully loaded and working for autolearning process to be succesful. (see par.4
for more information on autolearning).

f) Ignore memory faults - if checked, *EVERY* memory fault (such as process
protection errors etc.) will be ignored while learning. This is useful, when
patch should be applied to data memory area of the target process (parts of
data memory can be read/write protected, so "normal" learning will fail.
The main drawback of this method is that even if target process will terminate
during learning, the learning process will continue :( this can be confusing.

g) Show splash screen - enables displaying of splash screen with 'Learning Owl Logo'
on it at loader startup. It will be shown every time someone uses your loader.
At the bottom of splash there will be information about you (entered as author name
and author mail). You can switch splash off, but even then it will be shown when
loader uses self-learned data (after a succesful learning process). If this feature
pisses you up, try to relax, sit down and write your own loader ;).
When splash screen is shown, there is a real Owl sound in the background.

h) Debug mode - enables creating learn debug file during learning process.
It may be useful, when autolearning doesn't work as expected. In this mode user
is also asked about permission to delete files to be cleared at loader startup.
This can save you from tears, if you mistype path/filename ;)
Created file looks like this:

'!res' - begin of patch data (plain string)
RVA, length, search_range - binary DWORD data for patch 1
patch data - plain text for patch 1
...
RVA, length, search_range - binary DWORD data for patch n
patch data - plain text for patch n
'!end' - end of patch data

You should view this file as hex.

i) First child process is the main process - after executing target process,
loader waits for the first child process of the target to initialize, and
continues patching in this process.

j) Include simple installer - enables generating an installer file instead of
generator itself. Installer changes target program .exe file name by adding
'_' in front of it, and installs loader under original target program's name.
(target file name for loader 'hidden' in installer file is changed in order
to work correctly ;) Installed can display 2 messagebox-es - one at installer
startup, and the second one when installation has finished OK. You can edit
these messages, by clicking 'installer options' button.
If you leave any of messages clear, NO DIALOG will be displayed.

k) Include DateFaker module - before starting target process, loader will change
system date/time. After clicking "Date options" button, you can set the fake
date/time that is to be used by loader.
Correct date will be restored (depending on options set)
- when target process is terminated
- xx seconds after last patch is applied
If you check the "Use ~datefaker.ini file" checkbox, text file containing the
fake date will be created in the loader's directory. If that file exist,
loader will try to load date/time from it - this option allows loader's final
user to adjust date/time if needed by editing text .ini file.

Unique datefaker feature is incremental mode - every time the loader is started,
fake date/time will be incremented xx seconds (and saved to .ini file). This
can defeat most "smart" time-based protections, which don't allow date to be
smaller or equal the date you have last runned the target application.
Sometimes target can check, if the date/time is later than the moment of
last closing the app... you can work this out, checking the options:
- Restore correct date when target process is terminated
- Use ~datefaker.ini file
- Use smart date increment mode
In the smart date increment mode, loader will set date/time 10 seconds beyond
the moment of last restoring the correct date. If that mode is combined with
"Restore [...] when terminated" option, it will be almost impossible for target 
application to detect the cheating.

l) Do file clearing - before starting target process, loader will attempt to
delete entered files. You can use wildcards, and system variables:
%T\ - means default temp directory (e.g. c:\windows\temp\)
%W\ - means windows directory (e.g. c:\windows\)
%S\ - means system directory (e.g. c:\windows\system\)
For example "%T\*.tmp" will delete every file with .tmp extension in the default
temporary directory. When using debug mode (see options above), user will be asked
before files will be deleted. I strongly recommend using this for test purposes,
because file clearing can be dangerous, especcialy when you use wildcards.

m) Do registry clearing - before starting target process, loader will attempt to
delete specified registry keys. You can import registry keys from windows RegEdit
.reg file. Note that particular key will be deleted ONLY if no subkeys exist.
You have to delete subkeys one-by-one prior to deleting the main key.
(if you import keys from .reg file, you don't have to worry about that).
When OK button is clicked, entered keys will be sorted, that sub-key is always
before the main key.