+=======================================================+
| *ABEL* Self Learning Loader Generator by c0rdat ^ind. |
+=======================================================+

         +----------+
     The | A ny     |
         | B uild   |
         | E nabled |
         | L oader  | project.
         +----------+

Platform: Win 9x,Me,NT,2000,XP
Language: English
 contact: cordat@go2.pl

Latest version of this loader generator available at:
http://free.hostdepartment.com/c/c0rdat/
if this site is down, email me or use google with keywords:
"abel process patcher". Please note that it can take a few weeks
for google to add my new site to url list.

-------------------------------------------------------------------------------

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.

-------------------------------------------------------------------------------

3. Icon handling

If you wish, you can change standard icon for generated loaders (not installers,
installer always has a floppy disk as an icon). Active icon is shown in the left
side of the main window (just below Detection Method radiobuttons).
You can load chosen icon from disk (form an '.ico' file) or extract it from
any executable. When you choose to extract an icon from .exe or .dll file, you
can switch between available icons by up-down spin button on the right side
of an icon. Over the spin-buttons there is '()' or '(S)' visible. When icon should
be saved with .ldr file, there will be (S), and if icon wasn't changed,
and will not be saved automatically there will be (). You can click that symbol,
and force generator to save icon, or not to do that.
Sometimes (when loaded icon contains pink pixels close to standard icon background)
some part of an icon may become transparent after saving unintentionally. You can
click small square below spin-buttons, and change icon background color to avoid
this effect. Chosen color will be saved in .ldr file.

-------------------------------------------------------------------------------

4. Patch data entering.

Using generator program is easy, every edit-box displays a hint with short explanation
when mouse cursor stops over it. Every data (besides timeout) must be entered as hex.
When entered data is invalid, background of edit becomes red. Data check is performed
in background all the time.
Single patch data contains:
- RVA address - address that data should be found in target program memory
- search range - number of bytes that characteristic bytes (entered as original sequence)
will be search up and down (starting from base RVA) in autolearning mode.
- original bytes - bytes sequence, that will be search in target program memory
- patched bytes - contains information, how data found above will be patched by loader.
- Apply patch while target is still suspended after loading - means that this patch
will be applied while target process is suspended after loading into memory.
This option is useful, when we want to patch exe-unpack procedures before they
are executed. This option may be also used to make loader behave as 'normal'
patcher - changing original bytes when target program isn't running yet.
When this option is active, autolearning process may be divided into two stages:
after loading target process into memory (when data doesn't match) loader does
learning process for patches that should be applied before resuming the process,
displays message like 'First part of learning process finished...', runs target,
and if the rest of data doesn't match the second part of the learning process
is executed.
- Apply patch after resuming, but before waiting for specified window - useful,
when we have protection with "envelope" (that should be patched right after
loading a process and running it) and normal protection, that should be patched
after all the CRC-checks ;)

Allowed special symbols in patch data are:

symbol | meaning
-------+----------------------------------------------------------------------
  **   | wildcard, used in original sequence means that any byte matches it,
       | used in patched sequence means that particular byte won't be changed
       | by loader in any way (memory byte will not be patched)
-------+----------------------------------------------------------------------
  =A   | (can be =A, =B, =C, ..., =Z) when used in original sequence means
       | that particular byte will be copied to something like work-register
       | A, B etc. Used in patched sequence means that byte will be copied
       | from work-register to program memory. This is particulary useful
       | when loader should 'move' some instructions a few bytes forward or
       | backward in memory (see examples)
-------+----------------------------------------------------------------------
  'a   | means character 'a' (or any other). Useful when patching strings.

Any other string entered to patch data will be interpreted as 1-byte hex number.

-------------------------------------------------------------------------------

5. How to prepare patch for succesful autolearning.

There is no (and can't be ;) universal way to do that. You'll just have to
UNDERSTAND the code you are patching. Think: what parts of the code are characteristic,
and what parts may possibly change after re-compiling target program.

Here is just a few hints:
a) Decide what is characteristic for specified instruction: opcode, argument or both.
(to do that successfully you should first study assembler instruction op-codes,
and understand target program code).
b) Always check if chosen characteristic bytes sequence is unique in target program code.
c) Search the net for any other (earlier or later) version of cracked program
to look into procedure you are patching (if protection scheme is the same, or course).
This can save you from tears ;)
d) Beware of arguments passed by the stack (local variables for particular procedure).
In this case (most probably) instructions argument (which is an address, in fact)
is not characteristic, and due to compiler optimization a part of opcode
(if multi-byte) is not characteristic, too.
e) Remember: jump and call addresses are not characteristic.

-------------------------------------------------------------------------------

6. Examples.

This example is for explanation only.

Original code:
:0041722C 8BD8                    mov ebx, eax
:0041722E B205                    mov dl, 05
:00417230 8BC3                    mov eax, ebx
:00417232 E879120000              call 004184B0
:00417237 8D5508                  lea edx, dword ptr [ebp+08]
:0041723A B9208B4100              mov ecx, 00418B20
:0041723F 8BC3                    mov eax, ebx
:00417241 E886F9FFFF              call 00416BCC
:00417246 C3			  ret

Now we'll mark all non-characteristic bytes by wildcards...
:0041722C 8BD8                    mov ebx, eax
:0041722E B205                    mov dl, 05
:00417230 8BC3                    mov eax, ebx
:00417232 E8********              call ********
:00417237 8D55**                  lea edx, dword ptr [ebp+**]
:0041723A B9********              mov ecx, ********
:0041723F 8BC3                    mov eax, ebx
:00417241 E8********              call 00416BCC
:00417246 C3			  ret

The characteristic bytes sequence for this code should be:
8B,D8,B2,05,8B,C3,E8,**,**,**,**,8D,55,**,B9,**,**,**,**,8B,C3,E8,**,**,**,**,C3

If we want to change this piece of code to (it's an example only):
:0041722C 33C0                    xor eax, eax
:0041722E C3                      ret
(the rest of code doesn't matter)

The 'patched' bytes:
33,C0,C3,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**

Full patch data:
RVA: 41722C
range: 2000 (for example)
byte data:
8B,D8,B2,05,8B,C3,E8,**,**,**,**,8D,55,**,B9,**,**,**,**,8B,C3,E8,**,**,**,**,C3
33,C0,C3,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**,**

It's simple, isn't it?

----------------------------------------------------------------

Original code:
:0041722C 8BD8                    mov ebx, eax
:0041722E B205                    mov dl, 05
:00417230 8BC3                    mov eax, ebx
:00417232 E8********              call ********
:00417237 8D55**                  lea edx, dword ptr [ebp+**]
:0041723A B9********              mov ecx, ********
:0041723F 8BC3                    mov eax, ebx
:00417241 E8********              call 00416BCC
:00417246 C3			  ret

Suppose we want to change code this way (instruction at 41723A is moved a few bytes
down, and xor eax,eax is put before it... mov eax,ebx is useless and deleted.
I'm not a moron, ;) I know it is not a good example but I wanted to show you an idea only).

:0041722C 8BD8                    mov ebx, eax
:0041722E B205                    mov dl, 05
:00417230 8BC3                    mov eax, ebx
:00417232 E8********              call ********
:00417237 8D55**                  lea edx, dword ptr [ebp+**]
:0041723A 33C0                    xor eax, eax
:0041723C B9********              mov ecx, ********
:00417241 E8********              call 00416BCC
:00417246 C3			  ret

Patch data should look like this:
8B,D8,B2,05,8B,C3,E8,**,**,**,**,8D,55,**,B9,=A,=B,=C,=D,8B,C3,E8,**,**,**,**,C3
**,**,**,**,**,**,**,**,**,**,**,**,**,**,33,C0,B9,=A,=B,=C,=D,**,**,**,**,**,**

Data marked with =A, =B, etc. will be copied into a new location after applying a patch,
and will not be checked in any way (=A, =B is treated as a wildcard in characteristic
bytes sequence).

-------------------------------------------------------------------------------

I hope these examples will help you understand *ABEL* loader idea.
If you have any questions or comments, don't hesitate to mail me at:
cordat@go2.pl
If you find any bugs, mail me too and help to improve *ABEL*.
