Статьи нет. Скажу пару слов.
Когда я увидел комплекс (где-то в июле 2003), это была безграмотная работа. Объясню почему.
1. Память – не мусор.
Цель данной разработки была в сокрытии исходных текстов 1с. Но, расшифрованные тексты программных модулей находились в памяти процесса.
Найти их было не сложно. Для просмотра памяти вы можете использовать information. Блоки с текстом начинаются с 12 байт: «01(или 02) 00 00 00 gh ef cd ab gh ef cd ab». Далее идет текст. abcdefgh – размер текста, abcdef – первые три байта совпадают с первыми тремя байтами размера блока памяти (ну или - теоретически - на 1 меньше). Можете воспользоваться gettext1c для поиска таких блоков.
Говорить: «Но это долго – открывать документ, находить текст в памяти, вставлять его в конфигурацию - это же куча времени уйдет на декодирование целой конфигурации» - мягко сказать, непрофессионально, как и оставлять защищаемые данные в памяти. На сегодня эта тема закрыта.
2. Видимо опыта защит не было совсем.
В декабре один из пользователей решил проверить предупреждение о несостоятельности защиты, и предложил декодировать файл конфигурации, защищенный комплексом (конечно без знания пароля). Модули были декодированы. Данную дыру нужно описать немного подробнее. Комплекс состоит из inserter, цель которого кодирование и декодирование модулей с использованием пароля, и decoder.dll – внешняя компонента, цель которой декодировать модули перед их компиляцией. В decoder.dll для декомпиляции использовался ключ. Этот ключ получить было не сложно – он использовался каждый раз для декодирования всех модулей. Оставалось выполнить следующие действия: запустить inserter, набрать любой пароль, нажать кнопку «Декодирование» и подставить нужный ключ. Вот и все. Inserter сам декодировал весь файл конфигурации. На сегодня эта тема закрыта.
3. Декодируется то, что прячется?
Самое слабое место в комплексе – это то, что происходило декодирование защищенных текстов для компиляции. Достаточно просто посмотреть, что передается на компиляцию. Вот почему говорилось «обойти защиту» – мы ее даже не трогаем.
Можете посмотреть compileviewer:
idHelper.exe: Работа с md файлами и памятью процессов. Позволяет изменять md файл, получать тексты модулей из памяти процессов.
idh.dll: Вспомогательная библиотека. Внедряется в процесс 1с для упрощения получения компилируемых текстов.
patchBlang.dll: Патчер. Изменяет blang.dll так, чтобы при вызове функции компиляции, вначале загружалась idh.dll, которая сообщает адрес и размер компилируемого текста.

Думаю, для комплекса, этот метод уже не будет работать. Поэтому я реализовал несложную "Псевдо-защиту". На ее примере мы можем увидеть и не затираемую память и просмотреть тексты, передаваемые на компиляцию. Несмотря на простоту, данный вариант защиты хорош тем, что он может быть незаметным и на его основании можно утверждать: «выполняется не обязательно тот код, который вы видите в модуле».
Можете посмотреть "Пример псевдо-защиты". 1cv7.md – если посмотрите глобальный модуль, то там ничего интересного. Dec.dll – кладите в системную директорию. PatchSevenDll – изменит seven.dll (не забудьте вначале сохранить исходный seven.dll). И запустите 1с к нашему md. Внимательно читайте сообщения, выдаваемые при начале работы системы. Ну и если все в порядке – dec.dll будет удален.
Внимание!!!- не забудьте вернуть на место исходный seven.dll.


Ничего сложного. Исправляйте ошибки, переписывайте и пользуйте.

В заключении хотелось бы добавить: если модули декодируются – то они получаемы, и говорить о хорошей защите в таком случае глупо.

Если что - idjogod.fromru.com и idjogod.narod.ru