AHK: Проверка защиты скрипта. (Страница 1 из 2)

Ну, этот способ давно известен, компиляция в AutoHotkey_H. Зачем эта таинственность?

Я как-то пробовал покопаться, но там приняты меры против использования отладчика, а других идей у меня не возникло. Чисто теоретически должен быть способ. Задача интересная, конечно, но вот сколько времени на это уйдёт? Правда, квалификация взломщика у меня близка к нулю, нет опыта такой работы.

Давно это было. Насколько помню, я там пробовал разобраться с TLS-callbacks. Через них, ещё до точки входа самой программы, выполняется код, который обнаруживает (разными способами) присутствие отладчика и до выполнения скрипта дело даже не доходит.

По идее, если даже изначально код скрипта зашифрован и из файла его не извлечь, то для его выполнения он должен быть расшифрован и передан интерпретатору. Значит, в какой-то момент времени он присутствует в памяти в расшифрованном виде. Отсюда и идея выполнять программу пошагово в отладчике и смотреть её память. Но это мне не удалось ввиду принятых там антиотладочных мер. Я пробовал их выявить и обойти, но в какой-то момент мне это надоело, т.к. я вообще-то не любитель таких нудных занятий, да и знаний по этой теме мало, а попробовал чисто из любопытства, не имея никакой практической цели.

Хе, так что получается, защита AutoHotkey_H — миф? Или надо уметь её готовить?

Не "Тоже", а "Удалось", так как я просто посмотрел listlines.
Круто у тебя получилось!

Я, к сожалению, связан некоторыми обязательствами.

А я думал, ты всякие дебаггеры ковырял!

teadrinker, а не хочешь поделиться, как ты решил эту задачу (алгоритм)?
Я загуглил этот вызов DllCall("msvcrt\memchr" и нашел только упоминание Lexikos о нём:
https://autohotkey.com/board/topic/8298 … hod/page-2

Как код работает я вроде понимаю - ищет в памяти букву D и проверяет не начало ли она слова DllImport.
А вот откуда ты взял, что надо искать DllImport и вот этот  адрес while c := StrGet(pPtr + 12*2 + (A_Index - 1)*10, 1) и длину?

Зря вы раскрываете алгоритмы — теперь baplo усложнит защиту)).

Чтобы усложнить защиту, придётся пересобрать исходный код — это не так просто для неспециалиста.
С отладчиками я пока не в ладу — знаний ассемблера не хватает. Здесь YMP'у карты в руки!

Тут ещё знание отладчиков нужно. Я только с OllyDbg немного имел дело.

Есть "Кулибины", которые этим занимаются в целях самообразования, не преследуя никаких целей. А есть ещё те, кто это творчество монетизирует, при этом оставляя в открытом доступе довольно приличные "заманухи", с которых тоже можно стартовать своё обучение, но то, не для слабых духом.

Так что, увы, вся защита кода:

Почему, можно собрать свою версию AHK_H, как я выше писал.

При компиляции не получится поменять, пароль вшит в исходный код, поменять его можно только там.

Не знаю, зачем, видимо, просто не доделано.

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

Не знаю, на данный момент это не так. Я ввожу любой пароль в Ahk2Exe, компиляция происходит. Другое дело, что этот файл не запустится, так как Ahk2Exe не пишет новый пароль в результирующий файл.

Ну да, но файл-то правильно зашифруется с новым паролем. Чтобы такой файл запустился, достаточно его пропатчить, заменив пароль на новый.

Ну тогда получается, что всё доделано?

А ты пробовал собрать исходники с другим паролем, скомпилировать скрипт и вытащить пароль?

А как собирал?
Я пробовал изменить букву A на B тут, после компиляции переименовывал  AutoHotkey в Ahk2Exe, компилировал им скрипт, но пароль оставался прежним.

pw[i] = pwd == g_default_pwd ? (TCHAR) _T("A\0\0\0\0u\0\0\0\0t\0\0\0\0o\0\0\0\0H\0\0\0\0o\0\0\0\0t\0\0\0\0k\0\0\0\0e\0\0\0\0y\0\0\0\0")[i*5] : (TCHAR)*pwd[i];

https://github.com/HotKeyIt/ahkdll/blob … .cpp#L3219

Так вообще не запускается.
Может потому что на выходе после MVS я получаю файл размером 1.09 MB (1,146,880 bytes)?
И вот тут автор пишет, что можно свою функцию по созданию пароля вписать.
Как думаешь, со своей функцией тоже пароль виден будет?
https://github.com/HotKeyIt/ahkdll/issues/15

Можно сделать по другому: взять mac текущей машины+пароль и всё это в hash. Чем длиннее пароль, тем больше потребуется вычислительных мощностей, чтоб раскодировать пароль. Можно еще несколько раз завернуть в hash, приписать пару значений и хацкер не будет спать очень длительный промежуток времени.

Когда вы занимаетесь security through obscurity нужно делать так, чтобы никто кроме вас не знал как вы это сделали. В этом и заключается безопасность.
Если кто-то сделает и покажет как он это сделал, то вся защита пропадает.

HotkeyIt изобрел и показал. Теперь вы недовольны что он это показал, ведь если вы сделаете также, это не будет секретом.
Поэтому HotkeyIt прямым текстом говорит делать по-своему. Если вы не осиливаете сделать по-своему или писать на компилируемых языках, то может и защита вам не нужна? Откуда уверенность, что кто-то вообще настолько заинтересуется творчеством "чайника"? Продаете лицензии тысячами? Страдаете от пиратов? Наймите программиста, пусть перепишет ядро на плюсах или вынесет код на сервер, это не дорого с вашими-то оборотами .

А ты какой версией собирал?
Я делал по этой инструкции, но что-то видно пошло не так.
https://autohotkey.com/boards/viewtopic … mp;t=13373

Но пароль будет находиться всё-равно после слова DllImport?

А 2017 полный устанавливал со всеми дополнениями?
Просто мне интересно, если вставить туда какую-нибудь простейшую функцию шифрования пароля, то что будет показываться в экзешнике.

Пока вот, что имею:
Если компилирую из VS2015, то ошибок нету ни при создании x64 ни при win32.
Если после этого переименовываю эти оба файла в Ahk2Exe, то ahk-компилятор запускается.
Выбираю в качестве базы Ahk2Exe, компилирую и в итоге с x64 базой скрипт запускается нормально, а с win32 нет.
Можешь у себя проверить?

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

Чтобы убедиться, что AutoHotkey.exe собран правильно, нужно просто запустить с его помощью любой ahk-скрипт.

Так зачем что-то переименовывать? Просто берёшь любой скрипт и опускаешь на свой новый AutoHotkey.exe.

Конечно, а почему должен не запускаться? И 32, и 64 запускаются.

Это как?
Вот у меня файл win32 autohotkey.exe.
https://failiem.lv/u/aghyk8pu
Как, взяв его за базу, скомпилировать скрипт?

Я не менял. Просто не понимаю, почему не могу использовать его как базу.

Делал также - не работает.
Но у меня версия 1.1.29.1.
Может зальёшь свою - я проверю?

А ты можешь, пожалуйста, залить ahkdll-v1-release-master 1.1.28.0 версии и ahkdll-master.zip (исходник) 1.1.28.0 версии?

Вот AutoHotkey.exe v1.1.29.01 w32 с паролем 1234.

В общем результат тестов:
Если в VS2015 поставить в code generator /MT (как это написано в инструкции) и вывести в win32, то у меня в итоге получается нерабочий для последующей компиляции интерпритатор.
Если же оставить /MD, то всё ОК.
Для x64 версии работают оба варианта.

Не пробовал свою функцию подставлять?
Я пытался, но ничего не получилось.
Задал вопрос HotKeyIt - может подскажет...
https://github.com/HotKeyIt/ahkdll/issu … -400874587

Аналогичная проблема. Все компилируется, на выходе autohotkey.exe весом ~1мб, скрипты запускает и вроде все работает, но при компиляции через этот autohotkey.exe выходит сломанное приложение, при запуске вылазит ошибка, что что-то там не найдено. Пробовал компилить в vs2015/2017 x32.

Только что пытался собрать v1.1.29.01 — тоже получаются файлы меньшего размера. Целевая платформа проекта — 10.0.15063.0. Если указать по инструкции Multi-threaded (/MT) — тоже получаются незапускающиеся файлы при компиляции. Если оставить Многопоточный DLL (/MD) — вроде работает.

Пароль находится в открытом виде?

А, нет, рано обрадовался, оказалось, что просто без пароля компилится.

А в АНК Basic вроде свои пароли можно было вводить, его взломали?

Да, да, верим, верим.

Никуда не надо, он его сам находит.

В открытом доступе я рабочих декомпиляторов для AHK_H вообще не видел, ни с паролем, ни без. А из памяти, по идее, в любом случае код вытащить можно, он туда попадает уже расшифрованным, только он там недолго держится в целости.

Подробностей не знаю, пробовал искать код в памяти процесса после запуска — только отдельные куски находятся.

У меня в итоге получилось изменить алгоритм формирования пароля с минимальными дополнениями в исходном коде.

А код выполняемый с помощью загруженной autohotkey.dll тоже виден в памяти?