R!SC's Process Patcher -- RPP
=====================

Это старинный генератор лоадеров.

Утилита очень не новая, на паблике её версия 1.5.1 (с сорсами для TASM'а) аж с 2000-го года.
Здесь расскажу о её слегка (ну, может, и не слегка..) осовремененном ремейке, которым иногда пользуюсь, мне нравится.

**********************************************
--> RPP v.1.5.1.006p [(c)2000-2018] <-- Только RPP.EXE
**********************************************

За основу взята та старая версия 2000-го года, но там поправлены пара багов,
сделана б.м. корректная передача арументов целевой программе и добавлены пара-тройка полезных опций.
Например, добавлен поиск целевых байтов по маске и безусловный патч по заданному адресу.
Также поддержка ASLR, в далёком 2000-м никто не предполагал, что микрософт дойдёт до таких низостей.
Ещё из добавленного можно отметить такую опцию, когда в скрипте .RPP не задаётся имя запускаемого процесса (";;;;;;f=FileName.EXE:").
Тогда сгенерённым лоадером будет выводиться диалог для выбора целевого файла для запуска.
Такое может быть полезно, если лоадер должен патчить байты с поиском их по маске в разных версиях софта, имеющего разные же и имена EXE-файлов. - Нужный файл можно выбрать в диалоге.

Изначально программа была на TASM'е, но при возне с нею стало окончательно ясно,
что от использования TASM'а всё же придётся уходить.

А вцелом идеология программы и синтаксис .RPP файлов остались прежними,
совместимость "сверху вниз" соблюдена.

Более того, бывали случаи, когда лоадеры, сгенерированные оригинальной версией RPP от 2000-го года оказывались нерабочими в новых системах, а будучи заново сгенерёнными новой версией RPP 1.5.1.00x оказывались работоспособными. И не только из-за ASLR'а. - Добавлена опция повторов попыток патчения не только по числу этих самых попыток, но и до истечения определённого интервала времени.
Хотя задание этих интервалов это мутное решение, нужно стараться его избегать, может пострадать работоспособность в других системах.

Программа проста, как велосипед, и в некоторых случаях очень удобна,
поскольку работает со скриптами, на основе которых генерируется лоадер-патчер.
Скрипты эти бывает полезно хранить, поскольку там сжато и компактно описан процесс запуска и патча целевого процесса.
Сам же лоадер часто хранить нет смысла, его можно быстро заново сгенерировать на основе хранящегося скрипта RPP.

Никакой документации нет, только та, что к оригинальной версии RPP 1.5.1 от 2000-го года, её можно найти в архивах,

--> RPP v.1.5.1 (2000 г.) + TASM Sources <-- - Это оригинальная версия 2000-го года, с сорсами.

а также имеется подсказка по использованию в самой программе, которая генерируется по ключу командной строки "/h".
Эта подсказка, сохранённая в файл, является одновременно же и шаблоном файла-скрипта RPP.

Вообще, ремейк сделан в виде консольной программы, это оказалось удобнее всяких GUI.

Вот пример скрипта, выдаваемого в виде подсказки по ключу "/h" - видны опции программы.
Видно, что ненужные опции в шаблоне закомментированы.



В природе есть ещё GUI для подготовки аргументов запуска RPP.EXE, старая версия, 2000-го года:
--> (с)NchantA - GUI for using with RPP.EXE <--
(Не знаю, зачем оно нужно, - но есть).

| Сообщение посчитали полезным: gajemuxi, zNob, sendersu, GMAP, HandMill

dosprog, а сырков от свежака не пробегало? Хоть глянуть что в коде намутили. Старая версия с сырками давно лежит в закромах, пользовался несколько раз.

| Сообщение посчитали полезным:

Нет, сорсы только старые, в архиве 2000-го года.
В новых - там и поменялось-то немногое, просто малость допилено/пофиксено по мелочам. Не уходя от концепции.

Программа транслировалась с ASM'а, дизассемблировать одно удовольствие. В общем, надо пробовать.

-- Добавлено 01.01.2018 --

Перезалита версия в стартпосте [1.5.1.006p (2018)] - добавлена реакция лоадера на отсутствие файла под заданным изначально именем.
Тогда файл для запуска предлагается поискать самостоятельно.
Так, как это сделано в DUP2.



| Сообщение посчитали полезным:

Такой вопрос - есть ли рабочие генераторы лоадеров x64, загружающих и патчащих x64 же и программы?
Поиском находятся только обсуждения поведения x32 лоадеров в x64-системах.
Ну, и ещё всякий мутняк с запуском PE-файлов из памяти, для малвари.

А интересует штатный, приличный алгоритм, x64-аналог вызова x32<CreateProcess()>.
Понадобилось такое на днях - так ничего путного и не нашлось.

.. Неужели с этим всё пичально?



| Сообщение посчитали полезным:

dosprog
AT4RE Patcher v0.7.5 не подходит? Только что им лодырь делал для x64 софтины. В W7 x64 все нормально работает.

| Сообщение посчитали полезным: dosprog

Спасибо. Не следил за ним в последнее время.
Буду пробовать.
.. Размер создаваемого лоадера, конечно, устрашающий..
Во всяком случае, под x32 генерирует лоадер для x64, как оно и должно быть.

| Сообщение посчитали полезным:

dosprog

#4 - так вы посмотрите на блэк площадках, где школьники собирают загрузчики/крипторы для установки всякого говна, их навалом на каждом ресурсе. Не знаю рабочее ли оно, но такого типа софт там является базовым.

-----
vx

| Сообщение посчитали полезным:

Говно не нужно. Школьники увлекаются подгрузками его в память и настройками там его самостоятельно,
ссылаются даже на некоего клерка, который такое якобы умеет.
Но это не интересует.
Посмотрю по свободе на at4re patcher, вроде, должно работать.
Просто нет сейчас в распоряжении x64 системы.



| Сообщение посчитали полезным:

dosprog
Подскажи пожалуйста в чем проблема. Делаю лодырь с S&R для нескольких софтов, во всех нужно изменить один байт, после этого софт регистрируется и лодырь уже не нужен, все софты запускаются напрямую.
Вот что выдает RPP:
Error in script, line 4
'=' expected, found nothing

ldr.rpp
---------------------
T=2000:
O=*.exe:
B=400000:
a=401000/83FFFF/8B,55,F4,58,E8,?,?,?,?,75,0C,C7,83/8B,55,F4,58,E8,?,?,?,?,75,00,C7,83:
$
--------------------
Делаю обычный лодырь с параметром P, тогда все работает, но для одного экзешника и одного конкретного байта.

| Сообщение посчитали полезным:

Это нормально.
"O=*.EXE:" лишняя. Закомметрировать вообще или исправить на что-то вроде "O=reg!.exe:".
Это имя файла для создаваемого лоадера, - как можно создать файл с именем "*.EXE" ?
А запускаемую программу EXE тогда нужно будет выбрать ручками, в диалоге.
Поскольку имя файла для запуска и патчения не задано (";F=")
Так работает:

.. Только с таким диапазоном "a=401000/83FFFF/..." лоадер будет работать очень вяло. Лучше сузить.
Эта опция хороша в пределах разницы адресов ~1000h, а иначе получается слишком медленный запуск целевой программы.
Хотя, если требуется только единичный запуск, для регистрации, тогда можно и подождать.

(
Проверил запуск с таким диапазоном "a=401000/83FFFF/..."
- процесс стартует примерно через 10 секунд, на довольно шустрой машине. Это безобразно долго.
Это потому, что лоадеру приходится наугад читать все адреса из указанного в "a=" диапазона,
даже если уже пошли и невалидные адреса.
//Хотя, может быть, в этом случае можно было бы и прекратить поиск байтов//.
Это опция "a=" требует понимания происходящего.
).



| Сообщение посчитали полезным:

dosprog пишет:
Так работает
У меня не работает, та же ошибка. Да, с "О" я косякнул, думал это wildcard для выбора файлов. Пробовал как показано выше, пробовал с O=reg!.exe:, результат тот же - '=' expected, found nothing. И не очень понимаю какие признаки у патчера и лодыря? RPP их отличает только по заданным параметрам или это "!" в имени лодыря?

| Сообщение посчитали полезным:

Патчение файлов в этой программе изначально не предусмотрено. Только запуск процесса и патчение его в памяти.
Что и отражено в названии программы - "Процесс патчер".

Имя файла для лоадера ("O=...") может быть любым желаемым, без масок, а может и вообще отсутствовать строка "O=",
тогда по умолчанию создаётся файл "loader.exe".

У себя проверил - лоадер создаётся нормально с приведенным выше скриптом (добавлен в аттаче).
Пишет: "No problems creating loader.exe".

Кстати, под какой системой запускается?
Пробуй версию из стартпоста, 2018-го года, - пользуюсь ею. Должна, в принципе, нормально работать любая из версий. Новых, не 2000-го года.

Файл скрипта должен быть чисто текстовым, без UNICODE.
Это как бы подразумевается, - это же скрипт.
Вот так: 63cf_23.02.2018_EXELAB.rU.tgz - 1.rpp



--Добавлено--

Кстати, в современной версии в том числе поправлена и работа с текстом скрипта - допускаются пробелы в аргументах.
В оригинальной версии требования были строгие, пробелы не допускались.
Сейчас можно, например, и вот так:
и вот так:



| Сообщение посчитали полезным:

dosprog пишет:
без UNICODE
Ну не знаю, открыл приаттаченный файл в Бреде 2, где отродясь не было никакого юникода, опять та же ошибка, ругается на line 5, а ее, если правильно понимаю, ваще не существует, строк всего четыре. Другой комп, система XP SP3. Наверное, нечистая сила Если не трудно, скомпили в виде exe:
T=2000:
B=400000:
a=730000/8BFFFF/8B,55,F4,58,E8,?,?,?,?,75,0C,C7,83/8B,55,F4,58,E8,?,?,?,?,75,00,C7,83:
$
а я попробую как это будет работать.

| Сообщение посчитали полезным:

GMAP
Ошибка в том, что используешь RPP.ver.1.5.1.English.zip, а нужно RPP.ver.1.5.1.005p.English.rar/RPP.ver.1.5.1.006p.English.rar.

-----
Don_t hate the cracker - hate the code.

| Сообщение посчитали полезным: dosprog, GMAP

GMAP пишет:
попробую как это будет работать.

4499_23.02.2018_EXELAB.rU.tgz - loader.exe

Добавлено спустя 7 минут
mysterio пишет:
используешь RPP.ver.1.5.1.English.zip

)) Похоже, да. Если текст об ошибке выводится в месиджбоксе, то это старая версия 2000-го года, она такие конструкции, как "a=", не понимает.
Новая v.1.5.1.006p сообщения выводит только в консоли.

GMAP, текст в консоли или в месиджбоксе?

--Добавлено--
Ну, ясно. А то удивился, что RPP путает номера строк скрипта с ошибками. Такого, вроде бы, быть не должно.
В современной версии.



| Сообщение посчитали полезным:

dosprog
Спасибо, все ОК! Крайне нужная фича и, похоже, уникальная.
mysterio
Совершенно верно! Благодарю за подсказку, попробовал, все получилось как и у dosprog. Все вопросы решены.

Добавлено спустя 4 часа 33 минуты
dosprog
Забыл спросить есть ли ограничения и какие на количество обрабатываемых байт в лодырях? Как редактируемых напрямую: P=..., так и S&R: a=...

| Сообщение посчитали полезным:

GMAP пишет:
Спасибо, все ОК! Крайне нужная фича и, похоже, уникальная.

Да, это так.
Программа вышла в паблик как раз после обсуждения этой фичи в теме лоадеров у ManHunter'a.
Ссылку не дам - туда у меня сейчас нет доступа.


--Добавлено--

Это здесь --> Link <--

--Конец добавленного--



Добавлено спустя 12 минут
GMAP пишет:
есть ли ограничения и какие на количество обрабатываемых байт в лодырях? Как редактируемых напрямую: P=..., так и S&R: a=...

Есть.
Под двоичные данные патчей зарезервировано 8Kб (2000h байт).
(Поэтому, кстати, неупакованный лоадер выглядит "рыхлым". Много "пустого" места).
Вместе с тем, в одной строке типа "p=" можно задать до 1'0000h байтов OLD + 1'0000h байтов NEW.
То есть, фактически, только одной строкой "p=" можно превысить общий лимит данных. Теоретически.
Если суммарный размер данных в скрипте будет превышать эти лимиты, то будет выдано сообщение
об ошибке на этапе чтения скрипта/создания лоадера. - Лоадер создан не будет.
В оригинальной версии 1.5.1 2000-го года под данные патчей было зарезервировано на порядок меньше места
(что-то около 200h байтов, можно уточнить в архивных сорсах).
Как вариант, - можно было бы сделать весь пакет данных патча в виде оверлея, что существенно
увеличило бы их предельный размер, но это решение было признано сулящим головняк и принято не было.
Кроме того, оверлей такого файла не сжимался бы упаковщиками EXE.
- А если данных патча поболе 8Кб, то лучше уже не возиться с RPP, а запатчить сам исполняемый файл.
Пожалуй, что так.

(
Напрягать новый RPP на объёмные патчи приходилось только пару раз,
нового размера данных хватило с избытком,
- но делалось это больше из спортивного интереса
).

Таким образом, RPP 2018-го года это уже немного [и даже очень] другая программа, чем RPP 2000-го.
Но с концептуальной преемственностью. Продукт эволюции.
- Потому и сохранено оригинальное название программы.
К тому же лень было перебивать копирайты, да и не гоже.



| Сообщение посчитали полезным: GMAP