Hello, Vedern!
You wrote on Fri, 26 Aug 2005 15:45:15 GMT:
V> Как можно максимально усложнить дизассемблирование программы?
Как вариант, использовать подход похожий на подход упаковщиков .EXE (ups, aspack и тд)
То есть, программа изначально упаковывана/зашифрована/итд и распаковывается "на лету" когда какой-то поределенный кусок понадобится.
ЗЫ. впрочем, такое тоже ломается.
Posted via RSDN NNTP Server 2.0 beta
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Hello, Vedern! DEA>You wrote on Fri, 26 Aug 2005 15:45:15 GMT:
V>> Как можно максимально усложнить дизассемблирование программы? DEA>Как вариант, использовать подход похожий на подход упаковщиков .EXE (ups, aspack и тд) DEA>То есть, программа изначально упаковывана/зашифрована/итд и распаковывается "на лету" когда какой-то поределенный кусок понадобится.
DEA>ЗЫ. впрочем, такое тоже ломается.
Здравствуйте, Vedern, Вы писали:
V>Как можно максимально усложнить дизассемблирование программы?
Использовать VMProtect или EXECryptor.
Или реализовать свою виртуальную машину или генератор исполняемого мусора.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Hello, Vedern! DEA>You wrote on Fri, 26 Aug 2005 15:45:15 GMT:
V>> Как можно максимально усложнить дизассемблирование программы? DEA>Как вариант, использовать подход похожий на подход упаковщиков .EXE (ups, aspack и тд)
Не поможет. Перечисленные упаковщики как правило удаляются автоматическими распаковщиками. В худьшем случае дампится весь процесс после распаковки.
DEA>То есть, программа изначально упаковывана/зашифрована/итд и распаковывается "на лету" когда какой-то поределенный кусок понадобится.
Если упакована вся программа, то и распаковываться она будет вся сразу. Некоторые протекторы позволяют шифровать отдельные функции (расшифровываются перед вызовом).. и в этот момент их опять же можно сдампить .
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Vedern, Вы писали:
V>а в программном коде что-то можно сделать?
В современной программе — возможностей очень много. Попробуте проанализируйте 250к машинного кода... (ВАШЕГО КОДА — библиотечный код легко отсеивается) Или, если оно дизассемблировано, то порядка 4 мегов ассемблера. Попа порвется.
Так что, "защит от дизассемблера" для этого совсем не надо. Обьем кода вас защищает. В любом случае, крякер следует за потоком данных — т.е. от момента ввода серийного номера до момента его анализа. Лучше заморочиться на затруднении пути крякера к коду анализа серийника. Простейший для этого способ — хранить данные на хипе.
Причем, перед распределением памяти под "ключевую" информацию, нужно внести в это дело энтропию... То есть, сделать случайное количество пустых распределений и, лучше всего — случайного размера. Короче, чем случайнее, тем лучше. А еще лучше, если те функции из которых вы извлекаете энтропию задействованы но своему прямому назначению...
Второй способ — косвенность. Threads, QueueUserWorkItem, виртуальные вызовы, фабрики классов и тд — чем больше прыжков по коду и косвенных вызовоы — тем лучше. НО... Не забывать про энтропию! Чем СЛУЧАЙНЕЕ, тем ЛУЧШЕ!
Еше одна заповедь: не передавать серийник через глобальную переменную. Только через стек, параметры сообщений, что-угодно, но ТОЛЬКО не ГЛОБАЛЬНАЯ ПЕРЕМЕННАЯ! Именно в итоге таких промашек появляется заметка "The author is klever isdiot" в описании кряков...
...А еще лучше, побродите по сети, попытайтесь что-нить сами сломать, подумайте над результатами и придете к одному порстому выводу (известному вот уже 10 лет): сломают все. Вопрос тоьько в том, сколько автор потратил на защиту.
Мораль: не тратьте на нее слишком много... Все равно сломают, если надо... А если не надо, то нафиг она нужна?
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>>Hello, Vedern! DEA>>You wrote on Fri, 26 Aug 2005 15:45:15 GMT:
V>>> Как можно максимально усложнить дизассемблирование программы? DEA>>Как вариант, использовать подход похожий на подход упаковщиков .EXE (ups, aspack и тд) GN>Не поможет. Перечисленные упаковщики как правило удаляются автоматическими распаковщиками. В худьшем случае дампится весь процесс после распаковки.
Сер, вы вумны как десяць Айнштайнов! Но, все-таки...
...Представьте себе что я не жал всю программу, а пожал ее кусками — как надо мне и моим алгоритмам...
И эти алгоритмы разжимаются только тогда когда в них возникает нужда — проще говоря — когда усеру в голову моча стрелит... Из тхат клир?
DEA>>То есть, программа изначально упаковывана/зашифрована/итд и распаковывается "на лету" когда какой-то поределенный кусок понадобится. GN>Если упакована вся программа, то и распаковываться она будет вся сразу.
...Это если вся. А мне это и даром не надо. Будет надо даром — возьму UPX.
А в данном случае, имеет смысл прогу зашифровать модульно, причем своим собственным методом — распаковщикам неподвластным.
ЗЫ. Вам, в качестве домашнего задания рекомендуется изучить исходники означенного UPX и их возможные приложения.
ЗЗЫ. Алогритм LZO, примененный в данном упаковщике, можете оставить за кадром — к нашей проблеме он отношения не имеет.ё
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
V>>>> Как можно максимально усложнить дизассемблирование программы? DEA>>>Как вариант, использовать подход похожий на подход упаковщиков .EXE (ups, aspack и тд) GN>>Не поможет. Перечисленные упаковщики как правило удаляются автоматическими распаковщиками. В худьшем случае дампится весь процесс после распаковки. DEA>Сер, вы вумны как десяць Айнштайнов! Но, все-таки... DEA>...Представьте себе что я не жал всю программу, а пожал ее кусками — как надо мне и моим алгоритмам... DEA>И эти алгоритмы разжимаются только тогда когда в них возникает нужда — проще говоря — когда усеру в голову моча стрелит... Из тхат клир?
Йес, ит из . Находим функцию расшифровки, перехватываем её, запускаем программу и активно нажимаем на кнопочки, пока все криптованные кусочки не раскриптовались и не сохранились на диске . Протекторы Armadillo и Themida используют подобную технику, и для них существуют автоматические распаковщики.
DEA>>>То есть, программа изначально упаковывана/зашифрована/итд и распаковывается "на лету" когда какой-то поределенный кусок понадобится. GN>>Если упакована вся программа, то и распаковываться она будет вся сразу. DEA>...Это если вся. А мне это и даром не надо. Будет надо даром — возьму UPX. DEA>А в данном случае, имеет смысл прогу зашифровать модульно
И что мы получим? Ключь расшифровки хранится непосредственно в программе. Значит имеем whitebox. В данном случае AES-256 будет не эффективнее шифрования xor'ом .
DEA>причем своим собственным методом — распаковщикам неподвластным.
Вы знакомы с принципом работы generic unpacer'ов? В 2х словах: программа трассируется до выполнения некоторого условия (обычно переход между секциями PE). Здесь совершенно неважно, как и чем упаковано, поскольку программма распаковывает себя сама.
DEA>ЗЫ. Вам, в качестве домашнего задания рекомендуется изучить исходники означенного UPX и их возможные приложения. DEA>ЗЗЫ. Алогритм LZO, примененный в данном упаковщике, можете оставить за кадром — к нашей проблеме он отношения не имеет.ё
И что там можно увидеть интересного? Вот это:
// after some windoze debugging I found that the name of the sections
// DOES matter :( .rsrc is used by oleaut32.dll (TYPELIBS)
// and because of this lame dll, the resource stuff must be the
// first in the 3rd section - the author of this dll seems to be
// too idiot to use the data directories... M$ suxx 4 ever!
// ... even worse: exploder.exe in NiceTry also depends on this to
// locate version info
Так это и так общеизвестный факт
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, Vedern, Вы писали:
V>>а в программном коде что-то можно сделать? DEA>В современной программе — возможностей очень много. Попробуте проанализируйте 250к машинного кода... (ВАШЕГО КОДА — библиотечный код легко отсеивается) Или, если оно дизассемблировано, то порядка 4 мегов ассемблера. Попа порвется.
Распространённое заблуждение. Нет никакого смысла исследовать всю программу, как правило достаточно несколько функций. Кстати, компилятор значит довольно много: после BCB или Delphi восстановить исходный HLL код нампного проще, чем после MSVC или ICC (особенно, при использовании оптимизации вроде WPO).
DEA>Так что, "защит от дизассемблера" для этого совсем не надо. Обьем кода вас защищает. В любом случае, крякер следует за потоком данных — т.е. от момента ввода серийного номера до момента его анализа. Лучше заморочиться на затруднении пути крякера к коду анализа серийника. Простейший для этого способ — хранить данные на хипе.
И вот как это выглядит на практике: вводится серийник, поиском находится его адрес в памяти. Потом ставится breakpoint на чтение этого адреса и програма отпускается. Вуа-ля, мы в функции проверки .
DEA>Причем, перед распределением памяти под "ключевую" информацию, нужно внести в это дело энтропию... То есть, сделать случайное количество пустых распределений и, лучше всего — случайного размера. Короче, чем случайнее, тем лучше. А еще лучше, если те функции из которых вы извлекаете энтропию задействованы но своему прямому назначению...
Хорошая мысль . Это облегчит исследователю поиск ключей в памяти по энтропии . На случай, если вышеописанный метод вдруг не сработает.
DEA>Второй способ — косвенность. Threads, QueueUserWorkItem, виртуальные вызовы, фабрики классов и тд — чем больше прыжков по коду и косвенных вызовоы — тем лучше. НО... Не забывать про энтропию! Чем СЛУЧАЙНЕЕ, тем ЛУЧШЕ!
И это ничем не поможет против аппаратной точки останова на чтение серийника из буфера .
DEA>Еше одна заповедь: не передавать серийник через глобальную переменную. Только через стек, параметры сообщений, что-угодно, но ТОЛЬКО не ГЛОБАЛЬНАЯ ПЕРЕМЕННАЯ! Именно в итоге таких промашек появляется заметка "The author is klever isdiot" в описании кряков...
А большая ли разница? Когда отладчик вроде soft ice ищет строку в памяти, он одинаково хорошо находит данные как в секциях PE файла, так и на стеке. Впрочем, этому совету лучше следовать .
DEA>...А еще лучше, побродите по сети, попытайтесь что-нить сами сломать
А полезнее почитать туториалы по взлому.
DEA> подумайте над результатами и придете к одному порстому выводу (известному вот уже 10 лет): сломают все. Вопрос тоьько в том, сколько автор потратил на защиту.
Совершенно верно. Есть только одно НО. Себестоимость снятия серийной защиты на порядок ниже оной для качественной "доморощенной". Поэтому, если программа не представляет собой огромную ценность, её могут и не сломать.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Mystic, Вы писали: M>Здравствуйте, Vedern, Вы писали: V>>Как можно максимально усложнить дизассемблирование программы? M>Создать свой ассемблер и машину, которая его исполняет.
Здравствуйте, Pyromancer, Вы писали:
P>www.wasm.ru рулит, если почитать что пишут, то поймёшь, что взломать могут всё , можно только увеличить кол-во гемора, нажитого зломщиком.
неверно, правильнее сказать гонорар
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, 0xDEADBEEF, Вы писали:
V>>а в программном коде что-то можно сделать? DEA>В современной программе — возможностей очень много. Попробуте проанализируйте 250к машинного кода... (ВАШЕГО КОДА — библиотечный код легко отсеивается) Или, если оно дизассемблировано, то порядка 4 мегов ассемблера. Попа порвется.
DEA>Так что, "защит от дизассемблера" для этого совсем не надо. Обьем кода вас защищает. В любом случае, крякер следует за потоком данных — т.е. от момента ввода серийного номера до момента его анализа. Лучше заморочиться на затруднении пути крякера к коду анализа серийника. Простейший для этого способ — хранить данные на хипе.
На мой взгляд — ерунда.
Безусловно, большой объем кода способен отпугнуть неопытного атакующего. Однако, посмотрите на возможности современных дизассемблеров. IDA строит графы вызовов по коду, определяет библиотеки и меет собственный отладчик.
Более-менее опытный разработчик побеждает косвенность не особо напрягаясь. А что в таком случае может более или менее опытный реверсер.
А если речь идет про защиту, то есть одна буддийская идея. Отсутствующую защиту победить невозможно. Кто-то видел хоть раз взломанную OpenSource программу? Ну да, вопрос для священных войн, но помедитировать для себя, просто так, однозначно стоит.
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, Vedern, Вы писали:
V>>Как можно максимально усложнить дизассемблирование программы? GN>Использовать VMProtect или EXECryptor. GN>Или реализовать свою виртуальную машину или генератор исполняемого мусора.
Взлом EXECryptor сводится к решению np-полной задачи, которую нельзя решить за полиномиальное время. Однако, соотечественник денег за нее просит.
Здравствуйте, glyph, Вы писали:
V>>>Как можно максимально усложнить дизассемблирование программы? GN>>Использовать VMProtect или EXECryptor. GN>>Или реализовать свою виртуальную машину или генератор исполняемого мусора. G> Взлом EXECryptor сводится к решению np-полной задачи, которую нельзя решить за полиномиальное время.
А где можно взглянуть на математическое обоснование этой теории?
G> Однако, соотечественник денег за нее просит.
AFAIK работа над "дизассемблерами" ведётся, и я не удивлюсь узнав, что они уже существуют в природе (в публичном доступе их естественно не будет).
PS: полностью согласен, что вернуть код к первоначальному виду невозможно. Но есть один "нюанс" — это и не требуется.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>А где можно взглянуть на математическое обоснование этой теории?
Это к автору. Малость не мой уровень, понимаете ли.
Здравствуйте, glyph,
GN>>А где можно взглянуть на математическое обоснование этой теории? G> Это к автору. Малость не мой уровень, понимаете ли.
Так а что автор? "Реклама — это правда, только правда, ничего кроме правды... но не вся правда" .
То, что эта штука хорошо выполняет свои задачи — это факт. Но то, что это NP-полной проблема...
Не нужно делать невозможного — декомпилировать в исходный код.
Решение сволится к реализации оптимизирующего компилятора trash -> псевдокод, с хорошим анализатором flow control. Если заменить "trash" на "неоптимизированный код", то окажется, что тема неплохо изучена.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>>>А где можно взглянуть на математическое обоснование этой теории? G>> Это к автору. Малость не мой уровень, понимаете ли.
GN>Так а что автор? "Реклама — это правда, только правда, ничего кроме правды... но не вся правда" . GN>То, что эта штука хорошо выполняет свои задачи — это факт. Но то, что это NP-полной проблема... GN>Не нужно делать невозможного — декомпилировать в исходный код. GN>Решение сволится к реализации оптимизирующего компилятора trash -> псевдокод, с хорошим анализатором flow control. Если заменить "trash" на "неоптимизированный код", то окажется, что тема неплохо изучена.
Вполне вероятно. Дело в том, что я даже не пытлася разобраться в его внутренностях. Просто видел (не помню уже где) матобоснование защиты за авторством Relayer'a. Ну, еще в некоторых кругах (где мне приходится вращаться в силу объективных потребностей ) наблюдается стойкое и пока что неудовлетворенное желание научиться снимать сей продукт. В квалификации участников забега сомневаться не приходится.
Лично я склоняюсь к мнению о том, что защита представляет собой некий комплекс. Защита ПО является одной из (но не основной) частью этого комплекса. Сегодняшние алгоритмы защиты кода совершенно бессильны против кардеров, пиратов и т.п. маргинальных слоев киберобщества. Так же сложно бороться библиотеке с ограниченностью мышления конечного разработчика, который использует сторонюю библиотеку защиты. Например, фирма Алладин, сумевшая разработать достаточно неплохой аппаратный ключ, не сумела заставить пользоваться им правильно. Поэтому некто +fravia в свое время изрядно посмеялся...
Здравствуйте, glyph, Вы писали:
V>>>Как можно максимально усложнить дизассемблирование программы? GN>>Использовать VMProtect или EXECryptor. GN>>Или реализовать свою виртуальную машину или генератор исполняемого мусора. G> Взлом EXECryptor сводится к решению np-полной задачи, которую нельзя решить за полиномиальное время. Однако, соотечественник денег за нее просит.
.
.
