[русский]

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
											xTG
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

Здесь рассмотрены движки RANG32, FAKA, xTG (rang32.asm, faka.asm, xtg.inc, xtg.asm, logic.asm). Ты 
можешь объединить их в один большой двигл, так и использовать отдельно. 
Примеры работы движков ищи в test.asm (+ test.bat). 
Замечания, предложения, пожелания приветствуются=)
Также, буду благодарен, если Ты, найдя неточности в работе движков, сообщишь мне об этом. 
																		
																m1x
																pr0mix@mail.ru
																EOF
																		
																вирмэйкинг для себя...искусство вечно
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
											xTG
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx





								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx

								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
	




xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
											RANG32
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

=========================================================================================================
I. 
RANG32
RAndom Numbers Generator
Генератор (Псевдо)Случайных Чисел (ГСЧ)
rang32.asm
=========================================================================================================
ПРОТОТИП:
(stdcall) DWORD RANG32(DWORD n);	
n - число. Функция RANG32 вернёт Случайное Число (СЧ) в диапазоне [0..n - 1].
=========================================================================================================
ФИЧИ:
[+] генерация СЧ (в заданном диапазоне); 
[+] базонезависимость;
[+] прост в использовании; 
[+] без дельта и данных - только чистый код; отлично подходит для мутации;
[+] не использует WinApi'шек;	
[+] самодостаточный двигл; нет привязки к другим моторам; 
=========================================================================================================
ИСПОЛЬЗОВАНИЕ:

1. Подключение:
	rang32.obj/rang32.asm
	
2. Вызов (пример stdcall):
	push	05					;кладем в стэк число
	call	RANG32				;вызываем ГСЧ -> в EAX после вызова будет случайное значение [0..5-1]
=========================================================================================================	
ВЕРСИЯ:

v1.0.2 
=========================================================================================================
ИСТОРИЯ:

[v1.0.2]	:
				и предыдущие. Мелкие изменения в движке.
			
[v1.0.0]	:
				Релиз - первая версия!
=========================================================================================================                                                                                                       

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
											RANG32
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx





								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx

								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								
								
								
								
											
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
											xTG
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

=========================================================================================================
II. 
xTG
eXperimental/eXtended/eXecutable Trash Generator
ЭКСПЕРИМЕНТАЛЬНЫЙ/РАСШИРЕННЫЙ/ИСПОЛНИМЫЙ ГЕНЕРАТОР МУСОРНЫХ ИНСТРУКЦИЙ/ДАННЫХ
xtg.inc, xtg.asm, logic.asm	
=========================================================================================================
ПРОТОТИП:
stdcall: DWORD xTG(DWORD xparam);
xparam - адрес (заполненной) структуры XTG_TRASH_GEN. После выполнения данной функи:
	1. сгенерируются мусорные команды;
	2. заполнятся выходные поля структуры XTG_TRASH_GEN; 
	3. EAX = адресу для дальнейшей записи трэша/кода/etc. 
=========================================================================================================
ЗАМЕТКИ:
[+] входные поля структуры XTG_TRASH_GEN (и всех других структур) после отработки движка всегда 
	остаются теми же, что и перед вызовом - то есть не портятся, не изменяют своих значений;
[+] если структуры (XTG_TRASH_GEN etc) будут как-либо меняться (добавляться новые поля и т.п.), то 
	делать размер этих структур кратный 4 (x86);
[+] если не устраивает статистика опкодов (частота появления команд), то её с лёгкостью можно изменить в 
	сорцах (xtg.asm) (смотрим в сорцы!); 
[+] данный двиг состоит из файлов: xtg.inc, xtg.asm, logic.asm. xtg.inc - заголовочник. В нём ты найдёшь 
	все необходимые структуры, константы etc, а также их краткие описания. xtg.asm - сама реализация 
	движка xTG. logic.asm - построение логики команд;
[+] xTG предназначен для генерации мусорных инструкций и данных (строк, чисел etc). Может использоваться 
	как самостоятельный двигл, так и совместно с каким(и)-либо другим(и) движком(ами): полиморф, 
	пермутант etc. Варианты применения в вирусах/червях/троянах/etc, навесных защитах (крипторы, 
	протекторы, пакеры etc), и других прогах; 
[+] здесь, там, в коментах (может ещё где) есть суть, неточности можете кому-нить подарить;
[+] может что-то ещё xD;
=========================================================================================================
ДЕТАЛЬНОЕ ОПИСАНИЕ ПОЛЕЙ СТРУКТУР:
[0] - означает, что это входной параметр. То есть данное поле должно быть заполнено перед вызовом 
	  движка. 
[1] - означает, что это выходной параметр. То есть данное поле заполняется самим движком, и на выходе
	  из движка будет иметь некотороe осмысленное значение.
	 

---------------------------------------------------------------------------------------------------------	  
XTG_TRASH_GEN
Главная/основная структура, чей адрес (после заполнения) передаётся в двигл xTG. 

[fmode]					: [0]
						  Режим генерации трэша (трэш-кода). Движок имеет 2 режима генерации мусора:
						  XTG_MASK и XTG_REALISTIC. 
						  Первый режим, XTG_MASK aka "маска" - можно генерировать любые команды и как 
						  угодно: хоть все, или же выбрав генерацию какой-то конкретной инструкции 
						  (юзая маску (о ней ниже)). В данном режиме можно создать и антиэвристический 
						  мусор, и пиздец хаос. Может пригодится для slow-polymorphism'a. 1-ая версия 
						  движка имеет только этот режим. 
						  Второй режим, XTG_REALISTIC aka "реалистик". В данном режиме код 
						  генерируется так, чтобы быть правильным, максимально похожим на код обычных 
						  стандартных программ (написанных на ЯВУ). Для этого команды строятся 
						  теперь правильно: опкоды (заточка на ms-компилеры), конструкции, используется 
						  статистика частоты встречаемости опкодов в прогах, построение логики кода и 
						  многое другое. 
						  Если в режиме "маска" можно выбрать генерацию конкретной команды, то в 
						  режиме "реалистик" будут генерироваться все доступные здесь команды. Это 
						  сделано для генерации правильного кода. 
						  Какой режим по душе, тот и используй!
						  Кстати, сейчас движок работает так: если в fmode лежит значение, отличное от 
						  XTG_REALISTIC, то по умолчанию двиг считает, что юзается режим XTG_MASK. Но 
						  лучше указывай конкретный режим. 
						  Ещё, если указан режим XTG_MASK и выбрано, скажем, 2-3 команды в маске, то 
						  двиг может медленней генерить трэш - подожди, и всё будет. Это норма (a так 
						  всё быстро);
						  
[rang_addr]				: [0]
						  Адрес ГСЧ. Данный двиг построен без привязки к каким-либо другим движкам. 
						  В комплекте с xTG (по идее=)) идёт двиг RANG32 (и другие). Но если есть нужда 
						  юзать другой ГСЧ, тогда прототип функи ГСЧ должен быть такой:
						  (stdcall) DWORD xRandNumGen(DWORD n);
						  Такая функция должна возвращать (в EAX) случайное число (СЧ) в диапазоне 
						  [0..n - 1]. Регистры (кроме EAX) (реги) после вызова функи должны остаться 
						  неизменёнными. Имя функи, впрочем, как и переменной (n) можно задать любое =). 
						  Так что, либо передавай сюда адрес RANG32, или любой другой ГСЧ.
						  
[faka_addr]				: [0]
						  адрес движка генерации фэйковых винапи функций. etc.
						  В комплекте с xTG идёт двиг FAKA. Но если есть нужда юзать другой движок, 
						  тогда прототип функи генерации фэйк-винапи должен быть такой:
						  (stdcall) DWORD xGenFakeApi(DWORD xaddr);
						  xaddr - адрес на структуру, идентичную FAKA_FAKEAPI_GEN. Если поля будут 
						  другие, или юзаться по другому или еще какие-то изменения, тогда возможно 
						  придётся изменить что-то в xTG. 
						  Такая функа должна вернуть адрес для дальнейшей записи кода.
						  Так что, либо передавай сюда адрес FAKA, или любой другой двиг, генерирующий 
						  фэйк-винапи; 
						  Также, если не важна генерация винапишек, тогда в этом поле можешь пихать 0;
						  
[faka_struct_addr]		: [0]
						  адрес структуры FAKA_FAKEAPI_GEN (или любой другой идентичной etc). Данная 
						  структура нужна для работы движка генерации фэйковых винапишек (FAKA) в двигле 
						  xTG.
						  Также, если не важна генерация винапишек, тогда в этом поле можешь пихать 0;
						  
[xfunc_struct_addr]		: [0]
						  адрес структуры XTG_FUNC_STRUCT. Если генерируются функи (с прологами, 
						  эпилогами и т.п.) в другом движке, а этот двиг (xTG) вызывается для генерации 
						  трэша в таких функах, и нужна генерация некоторых конкретных команд (например, 
						  команд с участием EBP) - тогда заполняем структуру XTG_FUNC_STRUCT и передаём 
						  её адрес в это поле. 
						  Если же функи (те, что с прологами и т.п.) генерируются этим движком (xTG, 
						  режим "реалистик" с флагом XTG_FUNC etc), тогда здесь можно написать 0. 
						  Если же функи не генерятся, тогда здесь смело можно пихать 0; 
						  
[xdata_struct_addr]		: [0]
						  адрес структуры XTG_DATA_STRUCT. Если нужна генерация таких команд, как 
						  mov	ecx, dword ptr [403008h] etc, и/или генерация трэш-данных 
						  (строк, чисел), тогда заполняем такую структуру (правильно) и её адрес 
						  передаём в это поле.
						  Если же нахер такое не всралось, тогда вбиваем 0; 
						  
[alloc_addr]			: [0]
						  адрес функи выделения памяти. Отмечу, что очень желательно передавать 
						  такой адрес, так как тогда движок ипользует свои возможности на 100%. 
						  Если сюда передавать адрес такой функи, тогда движок под свои нужды будет 
						  брать память не со стека, а выделит память с помощью этой функи и будет юзать 
						  эту память. Также, нужно будет ещё указать и адрес функи освобождения памяти 
						  (в поле [free_addr]). 
						  Прототип функи выделения памяти:
						  (stdcall) DWORD xFuncAlloc(DWORD xsize);
						  Такая функа должна выделить память для чтения-записи-исполнения, и вернуть 
						  (в EAX) адрес выделенной памяти, размером xsize байтов. После вызова реги 
						  (кроме EAX) должны остаться неизменёнными.
						  Как альтернатива, в это поле можно передать 0; 
						  
[free_addr]				: [0]
						  адрес функи освобождения памяти. Отмечу, что очень желательно передавать 
						  такой адрес, так как тогда движок ипользуется свои возможности на 100%; etc;
						  Протоtип функи освобождения памяти:
						  (stdcall) DWORD/void xFuncFree(xaddr);
						  Такая функа должна освобожить память по адресу xaddr. После вызова реги 
						  должны остаться неизменёнными.
						  Может быть, еще передавать в такую функу кол-во выделенных байтов и что-то 
						  возвращать?
						  
[tw_trash_addr]			: [0]
						  адрес, куда записать сгенерированный трэш. Всё;
						  
[trash_size]			: [0]
						  размер генерируемого мусора (в байтах);
						  
[xmask1] & [xmask2]		: [0]
						  маска (64-битная = 2 32-х битных числа) для генерации мусора.
						  Маска может применяться (по разному и с разными флагами) в каждом из доступных 
						  режимов: XTG_MASK/XTG_REALISTIC. Если заглянешь в xtg.inc, то увидишь, какие 
						  флаги применяются в режиме XTG_MASK, а какие в XTG_REALISTIC. 
						  Тут же скажу, что функи (с прологами etc) можно генерить только в режиме 
						  XTG_REALISTIC, задав флаг XTG_FUNC, передавав в [alloc_addr] & [free_addr] 
						  адреса соответствующих фунок, и, конечно же, заполнив остальные поля так, как 
						  надо. 
						  Логику построения трэш-кода можно использовать, если соблюдены 
						  аналогичные условия, только вместо XTG_FUNC указываем XTG_LOGIC; 
						  
[fregs]					: [0]
						  занятые (реги)стры. Значения для этого поля можно найти также, в xtg.inc. 
						  Значит, если, например [fregs] = XTG_EAX + XTG_EDX, тогда 
						  движок-пирожок будет генерировать команды, в которых реги EAX & EDX не будут 
						  изменяться/использоваться. И далее, когда трэш отработает, то значения 
						  в этих регах останутся прежними (неизменёнными). Такое бывает нужно, например, 
						  для полиморфа (построение декриптора) etc. 
						  Для правильной работы данного движка нужно оставлять свободными минимум 3 
						  32-x битных регистра (это связано с генерируемыми командами). Но можно и 
						  меньше - если будут генерироваться конкретные команды - тут всё по ситуации.
						  Также, например, если генерируются винапишки, и [fregs] = XTG_EAX + XTG_ECX, 
						  тогда реги EAX и ECX всеравно могут изменить свои значения - их изменит 
						  вызов фэйк-винапи в трэше. Так что генерируй мусор по уму.
						  Ещё - регистры ebp & esp всегда считаются занятыми и не изменяют своего 
						  значения после отработки трэш-кода; 
						  
[nobw]					: [1]
						  количество реально записанных байтов. Если используется режим XTG_REALISTIC, 
						  тогда [nobw] = [trash_size] (в этом режиме всегда будет сгенерирован трэш 
						  размером = [trash_size]). Теперь другой пример: допустим, что задан режим 
						  XTG_MASK, [trash_size] = 4 (байта), 
						  [xmask1] = XTG_NOT_NEG___R32 + XTG_THREE_BYTES_INSTR, [xmask2] = 0 (ну и все 
						  остальные поля тоже заполнены корректно). И допустим, что сгенерировалась 
						  команда movzx edx, dx (XTG_THREE_BYTES_INSTR). Размер этой команды = 3 байта. 
						  И после такой генерации движок вернет управление, а поле [nobw] = 3 байта 
						  ([nobw] < [trash_size]). Так произошло потому, что в данном примере 
						  размер самой короткой команды, доступной для генерации = 2 байта 
						  (not/neg reg32). А у нас остался только 1 байт - поэтому движок больше ничего 
						  не сгенерит и выйдет. 
						  
[ep_trash_addr]			: [1]
						  точка входа в сгенерированный трэш. Если для генерации команд юзался режим 
						  XTG_MASK, тогда [ep_trash_addr] = [tw_trash_addr]. Если же юзался режим 
						  XTG_REALISTIC, но без флага XTG_FUNC, тогда [ep_trash_addr] = [tw_trash_addr]. 
						  Если же юзался режим XTG_REALISTIC, и был указан флаг XTG_FUNC - то значит, 
						  строились функи, и в [ep_trash_addr] - будет лежать адрес той функи, с которой 
						  начинает работать трэш-код. 
						  
[fnw_addr]				: [1]
						  адрес для дальнейшей записи кода/трэша. 
---------------------------------------------------------------------------------------------------------


---------------------------------------------------------------------------------------------------------
XTG_FUNC_STRUCT
Структура, необходимая для/при генерации функций (те, что с прологами, эпилогами etc). Также читаем про 
XTG_GEN_TRASH.xfunc_struct_addr.

[func_addr]				: [0]
						  адрес функции. По этому адресу будет сгенерирована (или уже построена) 
						  функа (с прологами etc). 
						  Это поле и вообще все поля всех структур должны содержать корректные значения.
						  
[func_size]				: [0]
						  реальный размер функции, которую двиг будет строить или уже построил;
						  
[call_num]				: [0]
						  кол-во вызовов (также, будущих или уже построенных) (call'ов) в данной функе 
						  (что по адресу [func_addr]); 
						  
[local_num]				: [0]
						  кол-во локальных переменных в функе. 
						  Например, если после пролога есть команда sub esp, 0Ch - тогда кол-во 
						  локальных переменных в функе = 0Ch (12) / 4 = 3 локальных переменных 
						  ([local_num] = 3). Точно также считаем наоборот;
						  
[param_num]				: [0]
						  кол-во входных параметров в функе. 
						  То есть, сколько входящих параметров функа принимает. Неясно? =)
						  Допустим, есть такая конструкция:
							push	ecx							;вот это и есть входящие 
							push	dword ptr [ebp - 04]		;параметры - как видно, их 2;
							call	func_x
						  Тогда для функи func_x поле [param_num] = 2;
---------------------------------------------------------------------------------------------------------


---------------------------------------------------------------------------------------------------------
XTG_DATA_STRUCT
Структура, необходимая для генерации команд, юзающих адреса памяти, а также для генерации трэш-данных: 
строк, чисел etc. Также читаем про XTG_TRASH_GEN.xdata_struct_addr

[xmask]					: [0]
						  маска для генерации трэшЪ-данных. 
						  Данное поле заполняется, если нужно сгенерировать трэш-данные. Если же, 
						  например, нужно сгенерить только команды, которые юзают адреса памяти, тогда 
						  здесь пишем 0;
						  Можно генерить такие трэщ-данные: строки, числа. 
						  Флаги для этого поля можно найти в xtg.inc; 
						  
[rdata_addr]			: [0]
						  адрес, куда будут записаны трэш-данные; 
						  в это поле можно передавать как VirtualAddress (VA), так и абсолютный 
						  физический адрес в файле (для записи в файл); 
						  Если здесь 0, тогда трэш-данные сгенерированы не будут. 
						  Этот переданный адрес только для генерации трэш-данных! Сгенерированный 
						  трэш-код не должен изменять значения по адресам в этой области (для трэш-кода 
						  она только для чтения). Для генерации команд, которые читают/записывают что-то 
						  в область памяти, выделяй другую область памяти, указав адрес в [xdata_addr] и 
						  размер в [xdata_size]. 
						  Если же области адресов (памяти)
						  [rdata_addr] + [rdata_size] 
						  и 
						  [xdata_addr] + [xdata_size]
						  будут пересекаться, то сгенерированный трэш может неправильно работать. 
						  Так как же это заполнять? 
						  Допустим, у нас есть секция данных (.data). Адрес этой секции = 405000h, 
						  размер = 5000h. Так вот, можно сделать так:
						  [rdata_addr] = 405000h
						  [rdata_size] = 1000h
						  [xdata_addr] = 406000h
						  [xdata_size] = 1000h
						  и т.д. Тогда всё будет отлично работать =); 
						  Очень желательно, чтобы адрес был кратен 4;
						  
[rdata_size]			: [0]
						  размер этой области (памяти); значение должно быть >= 4 (байта);
						  
[rdata_pva]				: [0]
						  какой адрес передаётся в [rdata_addr]: VA или физический в файле? 
						  Допустимые значения для данного поля можно найти в xtg.inc; 
						  
[xdata_addr]			: [0]
						  адрес области памяти - адреса из этой области будут использоваться 
						  такими сгенеренными командами, как 
						  add	ecx, dword ptr [403008h]
						  sub	dword ptr [40300Ch], edx
						  и другие; 
						  в это поле передаётся VA; 
						  Очень желательно, чтобы адрес был кратен 4; 
						  
[xdata_size]			: [0]
						  размер этой области памяти; значение должно быть >= 4 (байта); 
						  
[nobw]					: [1]
						  кол-во реально записанных байтов трэш-данных. 
						  Если трэш-данные не генерируются (а, например, генерим только команды), 
						  тогда это поле игнорируется; 
---------------------------------------------------------------------------------------------------------


---------------------------------------------------------------------------------------------------------
FAKA_FAKEAPI_GEN
Основная структура, чей адрес передаётся в двигл FAKA, а также в поле 
XTG_TRASH_GEN.faka_struct_addr.

[mapped_addr]			: [0]
						  база мэппинга файла (ака адрес файла в памяти (ака резалт функи 
						  MapViewOfFile)).
						  
[rang_addr]				: [0]
						  адрес ГСЧ. Читаем про это поле XTG_TRASH_GEN.rang_addr. 
						  Если движок FAKA юзается внутри движка xTG, тогда сюда также можно передать 
						  адрес RANG32 или другого ГСЧ. То есть можно сделать и так:
						  FAKA_FAKEAPI_GEN.rang_addr = XTG_TRASH_GEN.rang_addr. Эту же фичу можно 
						  проделать и с другими полями (alloc_addr, free_addr, xfunc_struct_addr etc); 
						  
[alloc_addr]			: [0]
						  адрес функи выделения памяти. Читаем XTG_TRASH_GEN.alloc_addr
						  
[free_addr]				: [0]
						  адрес функи освобождения памяти. Читаем XTG_TRASH_GEN.free_addr
						  
[xfunc_struct_addr]		: [0]
						  адрес структуры XTG_FUNC_STRUCT. Читаем XTG_TRASH_GEN.xfunc_struct_addr. 
						  В дополнение: структуру XTG_FUNC_STRUCT нужно заполнять, чтобы стало 
						  больше вариантов генерации различных команд - параметров для винапишек. 
						  Например, заполнив эту структу, и передав её адрес в это поле, могут быть 
						  сгенерированы такие команды как push dword ptr [ebp - 14] etc;
						  
[xdata_struct_addr]		: [0]
						  адрес структуры XTG_DATA_STRUCT. Читаем XTG_TRASH_GEN.xdata_struct_addr
						  и FAKA_FAKEAPI_GEN.xfunc_struct_addr. 
						  В дополнение: тут могут быть сгенеры такие команды как 
						  push dword ptr [403008h] etc; 
						  
[tw_api_addr]			: [0]
						  адрес, куда записать сгенерированный фэйковый вызов винапишки. 
						  Если движок FAKA юзается внутри движка xTG, тогда здесь можно передать хоть 0. 
						  xTG сам подставит в это поле нужное значение;
						  Если же ни одной интересующей нас винапи не будет найдено, тогда в этот буфер 
						  ничего не будет записано;
						  
[api_size]				: [0]
						  максимальный размер винапи-конструкции. Винапи-конструкция - это конструкция, 
						  например, такого вида:
							push	0
							push	403000h
							push	403000h
							push	0
							call	MessageBoxA
						  То есть считается размер каждой инструкции, и суммарный размер - это и есть 
						  размер винапи-конструкции; а нам нужен размер самой большой генерируемой 
						  конструкции=); 
						  Если движок FAKA юзается внутри движка xTG, тогда здесь можно передать хоть 0.
						  xTG сам подставит в это поле нужное значение (значение WINAPI_MAX_SIZE); 
						  
[api_hash]				: [0] [1]
						  Поиск винапи (а точнее VA) происходит по хэшу от имени нужной винапи. Если 
						  это поле != 0, тогда будет поиск только этой винапишки, хэш от имени которой 
						  указан. И если винапишка будет найдена в файле, который спроецирован в память, 
						  тогда в поле [api_va] вернётся VirtualAddress (VA в IAT), по которому и будет 
						  адрес интересующей нас апишки. Если указанный хэш ещё находился в (заранее 
						  подготовленной) табличке хэшей, тогда будет сгенерирован и записан в буфер 
						  ([tw_api_addr]) фэйковый вызов найденной винапи. Если же хэша не было в таблице 
						  хэшей, тогда генерации не будет. Её можно будет сделать самостоятельно 
						  (заюзав адрес в [api_va]). 
						  Если же данное поле = 0, тогда будет поиск одного из хэшей в таблице хэшей 
						  (хэши случайно перемешиваются и затем ищутся один за другим, и как только 
						  один из них будет найден, будет генерация, и после выход из движка);
						  Если апишка будет найдена, независимо от того, сгенерируется она или нет, 
						  то в это поле на выходе сохранится хэш от имени найденной апишки. Если же 
						  винапи не найдена, тогда здесь будет 0; 
						  
[api_va]				: [1]
						  Если интересующая нас апишка найдена (совпали хэши), то в это поле 
						  кладётся VA, по которому будет лежать адрес интересующей апишки. Если 
						  апишка не найдена, тогда здесь будет 0;
						  
[nobw]					: [1]
						  кол-во реально записанных байтов;
						  
[fnw_addr]				: [1]
						  адрес для дальнейшей записи кода; 						  
---------------------------------------------------------------------------------------------------------

=========================================================================================================
МУЛЬКИ:
[+] генерация x86 инструкций/конструкций (множество вариантов);
[+] генерация данных (строк, чисел);
[+] генерация команд по маске;
[+] генерация "правильного" кода:
		x правильный;
		x реалистичный;
		x антиэвристический;
		x антиэнтропийный;
		x статистика частот встречаемости опкодов;
		x логика построения трэш-кода (новая фича!); 
[+] генерация функций (те, что с прологами, эпилогами etc);
[+] генерация винапи фунок;
[+] базонезависимость; 
[+] самостоятельный самодостаточный движок; нет привязки к другим моторам;
[+] без дельта и данных - только чистый код; отлично подходит для мутации;
[+] не юзает winapi;
[x] некоторые куски кода дублируются в движках, так что кому не по кайфу - сделайте по другому
=========================================================================================================
ИСПОЛЬЗОВАНИЕ:

1. Подключение:
	xtg.obj / xtg.inc, xtg.asm, logic.asm
	
2. Вызов (пример stdcall):
	;пример вызова/использования движка находится в файле test.asm (+ test.bat etc);
=========================================================================================================	
ВЕРСИЯ:

v2.0.0
=========================================================================================================
ИСТОРИЯ:

[v2.0.0]	:
				на основе v1.0.0 движок полностью переписан с учётом многих фишек. Движок получает 
				"новое дыхание"; 
			
[v1.0.0]	:
				Релиз - первая версия!
=========================================================================================================

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
											xTG
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx





								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx

								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
			
			
			
			
								 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
											FAKA
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

=========================================================================================================
I. 
FAKA
FAKe Api generator
Генератор фэйк-винапишек (фэйковых вызовов винапи-функций)
xtg.inc, faka.asm
=========================================================================================================
ПРОТОТИП:
stdcall: DWORD FAKA(DWORD xparam);
xparam - адрес (заполненной) структуры FAKA_FAKEAPI_GEN. После выполнения данной функи:
	1. сгенерированная фэйк-винапишка;
	2. заполнятся выходные поля структуры FAKA_FAKEAPI_GEN; 
	3. EAX = адресу для дальнейшей записи трэша/кода/etc. 
=========================================================================================================
ЗАМЕТКИ:
[+] Смотри заметки для xTG;
[+] смотри детальное описание полей структур xTG - там будет описуха всех нужных полей нужных структур 
	и для FAKA'и;
[+] etc
=========================================================================================================
ФИЧИ:
[+] генерация различных винапишек с улучшенными входящими параметрами;
[+] нахождение (и возможная генерация) конкретной винапишки;
[+] базонезависимость;
[+] без дельта и данных - только чистый код; отлично подходит для мутации;
[+] не юзает winapi;
[+] самодостаточный двигл; нет привязки к другим моторам;  
=========================================================================================================
ИСПОЛЬЗОВАНИЕ:

1. Подключение:
	faka.obj / xtg.inc, faka.asm
	
2. Вызов (пример stdcall):
	;пример вызова/использования движка находится в файле test.asm (+ test.bat etc), а также 
	;в xtg.asm (метка xwinapi_func); 
=========================================================================================================	
ВЕРСИЯ:

v2.0.0
=========================================================================================================
ИСТОРИЯ:

[v2.0.0]	:
				на основе v1.0.0 движок полностью переписан с учётом многих фишек. Движок получает 
				"новое дыхание";
			
[v1.0.0]	:
				Релиз - первая версия!
=========================================================================================================                                                                                                       

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
											FAKA
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx





								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx

								xxxxx		xxxxx		xxxxx
								xxxxx		xxxxx		xxxxx
	

