Здравствуйте, 0xDEADBEEF, Вы писали:
V>>а в программном коде что-то можно сделать? DEA>В современной программе — возможностей очень много. Попробуте проанализируйте 250к машинного кода... (ВАШЕГО КОДА — библиотечный код легко отсеивается) Или, если оно дизассемблировано, то порядка 4 мегов ассемблера. Попа порвется.
DEA>Так что, "защит от дизассемблера" для этого совсем не надо. Обьем кода вас защищает. В любом случае, крякер следует за потоком данных — т.е. от момента ввода серийного номера до момента его анализа. Лучше заморочиться на затруднении пути крякера к коду анализа серийника. Простейший для этого способ — хранить данные на хипе.
На мой взгляд — ерунда.
Безусловно, большой объем кода способен отпугнуть неопытного атакующего. Однако, посмотрите на возможности современных дизассемблеров. IDA строит графы вызовов по коду, определяет библиотеки и меет собственный отладчик.
Более-менее опытный разработчик побеждает косвенность не особо напрягаясь. А что в таком случае может более или менее опытный реверсер.
А если речь идет про защиту, то есть одна буддийская идея. Отсутствующую защиту победить невозможно. Кто-то видел хоть раз взломанную OpenSource программу? Ну да, вопрос для священных войн, но помедитировать для себя, просто так, однозначно стоит.
Здравствуйте, 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.
Здравствуйте, 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>Или другой сценарий — кто-то спёр опенсоурс, подрихтовал, запаковал EXECryptor'ом (что бы не дай Бог, не докопались до истины) и продаёт
тогда прийдется автомобили и кухонные ножи тоже запретить к пользованию
Здравствуйте, 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
Здравствуйте, gear nuke, Вы писали:
CC>>А если автор прогу писал для того чтоб ее продажей себе на пожрать заработать? OpenSource как то с продажами не очень то дружит. GN>Очевидно, они получают деньги не от продаж?
Здравствуйте, gear nuke, Вы писали:
GN>Мне, кстати, недавно рекомендовали антивирус с хорошим (то есть, лучше, чем у других) эмулятором. Название сходу вспомнить не могу — это к тому, что главные игроки рынка с точки зрения технических возможностей — аутсайдеры. Поэтому не думаю, что их это не беспокоит, и работы в направлеии улучшения не ведутся.
ситуация типичная — 99% рынка потребляют некое "фуфло" которое еле-еле справляется со своими обязанностями и представляет собой вчерашний день в плане технологий. при этом все движется за счет вбухивания немерянного кол-ва денех в маркетинг.
R>>читать вот здесь напрмер: What these tools highlight is that there is a new problem with the old signature-based way of doing security. GN>Вот-вот, как раз ссылка в тему . Чувствуется некоторая обеспокоенность ухудьшающейся ситуацией. Когда грянет буря, вопрос создания uncryptor'а резко повысится в цене.
когда грянет буря — будет поздно. а буря ой как не за горами. и мы здесь совершенно не при чем
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
Здравствуйте, 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.
Здравствуйте, Mystic, Вы писали: M>Здравствуйте, Vedern, Вы писали: V>>Как можно максимально усложнить дизассемблирование программы? M>Создать свой ассемблер и машину, которая его исполняет.
Здравствуйте, 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-полной задачи, которую нельзя решить за полиномиальное время. Однако, соотечественник денег за нее просит.
Здравствуйте, gear nuke, Вы писали:
GN>Так а что автор? "Реклама — это правда, только правда, ничего кроме правды... но не вся правда" . GN>То, что эта штука хорошо выполняет свои задачи — это факт. Но то, что это NP-полной проблема... GN>Не нужно делать невозможного — декомпилировать в исходный код. GN>Решение сволится к реализации оптимизирующего компилятора trash -> псевдокод, с хорошим анализатором flow control. Если заменить "trash" на "неоптимизированный код", то окажется, что тема неплохо изучена.
возможно но
1. качество "неоптимизированного кода" может оказаться "ниже плинтуса"
2. полчаса клацанья мышкой и весь этот анализатор можно выбрасывать в мусорное ведро
так что авфторы не дремлют
Здравствуйте, Relayer,
GN>>Решение сволится к реализации оптимизирующего компилятора trash -> псевдокод, с хорошим анализатором flow control. Если заменить "trash" на "неоптимизированный код", то окажется, что тема неплохо изучена.
R>возможно но R>1. качество "неоптимизированного кода" может оказаться "ниже плинтуса"
Ага, уже вижу, что толковать моё высказывание можно двояко. "Неоптимизированный код" — это source. Подаём его на вход "оптимизирующему компилятору", который и должен поднять качество до уровня потолка. "Тема наплохо изучена" — эээ, ну, есть хотя бы драгонбуки, и другие авторы .
R>2. полчаса клацанья мышкой и весь этот анализатор можно выбрасывать в мусорное ведро
Давайте рассмотрим, например, компилятор MSVC.
Ему на вход можно подать: цикл for;
цикл while;
тоже, но разложенное на if / goto.
В результате, он выдаст одинаковый код.
Аналогичная ситуация будет с "гипотетическим компиляторм" и в случае изменения морфера в EXECryptor.
R>так что авфторы не дремлют
Я думаю, что Вы, как человек, отлично знающий теорию компиляторов, согласны (в глубине души) с возможностью восстановления кода до human-readable формы. Однако, 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
Здравствуйте, glyph, Вы писали:
G> А если речь идет про защиту, то есть одна буддийская идея. Отсутствующую защиту победить невозможно. Кто-то видел хоть раз взломанную OpenSource программу? Ну да, вопрос для священных войн, но помедитировать для себя, просто так, однозначно стоит.
Гм. А если автор прогу писал для того чтоб ее продажей себе на пожрать заработать? OpenSource как то с продажами не очень то дружит.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>А если автор прогу писал для того чтоб ее продажей себе на пожрать заработать? OpenSource как то с продажами не очень то дружит.
Очевидно, они получают деньги не от продаж?
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
Здравствуйте, CreatorCray, Вы писали:
G>> А если речь идет про защиту, то есть одна буддийская идея. Отсутствующую защиту победить невозможно. Кто-то видел хоть раз взломанную OpenSource программу? Ну да, вопрос для священных войн, но помедитировать для себя, просто так, однозначно стоит.
CC>Гм. А если автор прогу писал для того чтоб ее продажей себе на пожрать заработать? OpenSource как то с продажами не очень то дружит.
Хехе. Дело в том, что OpenSource != FreeWare. OpenSource тоже денег стоит. Просто так получается, что чаще всего OpenSource можно получить бесплатно. Вопрос в том, сможет ли обычный пользователь разобраться с набором исходников — все равно потребуется специалист определенного уровня.
Я бы сказал, что OpenSource в некоторой мере антагонист ShareWare... В общем, есть статьи на эту тематику, достаточно широкие... А здесь это оффтопик, в общем-то...
Здравствуйте, gear nuke, Вы писали:
GN>Я думаю, что Вы, как человек, отлично знающий теорию компиляторов, согласны (в глубине души) с возможностью восстановления кода до human-readable формы.
конечно. примерно так же как и согласен с тем, что легко можно создать вечный двигатель. правда это может потребовать неограниченного количества времени
я к чему веду — к затратам на создание "реставратора/анализатора". скажу даже больше — написание такого анализатора достаточно сложная задача даже при знании всех алгоритмов и техник которые применяем морфер. а в случае если мы их знаем частично ситуация усложняется на порядок.
так что взломать можно все. вопрос в затратах и целесообразности. вот тут то и начинается кардинг. но за это уже надо сажать а не по головке гладить.
Здравствуйте, Relayer,
GN>>Я думаю, что Вы, как человек, отлично знающий теорию компиляторов, согласны (в глубине души) с возможностью восстановления кода до human-readable формы.
R>конечно. примерно так же как и согласен с тем, что легко можно создать вечный двигатель. правда это может потребовать неограниченного количества времени
Аналогия неверная вечный двигатель противоречит законам физики.
R>я к чему веду — к затратам на создание "реставратора/анализатора".
А вот это — верно.
R>скажу даже больше — написание такого анализатора достаточно сложная задача даже при знании всех алгоритмов и техник которые применяем морфер. а в случае если мы их знаем частично ситуация усложняется на порядок.
Сложность одно, а рентабельность другое. Ну напишет Вася Пупкин такую штуку, и что дальше? Защитит EXECryptor'ом и толкать как шаровару будет кракерам?
R>так что взломать можно все. вопрос в затратах и целесообразности.
Угу. Вот начнуть трои паковать этой штукой в массовом порядке, тогда и целесообразность возникнет у материально заинтересованных сторон. Хотя ИМХО им бы для начала существующие эмуляторы подтянуть до рабочего уровня.
R>вот тут то и начинается кардинг. но за это уже надо сажать а не по головке гладить.
Социальная инженерия, утюги и паяльники — это отдельная большая тема
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
Здравствуйте, glyph, Вы писали:
CC>>Гм. А если автор прогу писал для того чтоб ее продажей себе на пожрать заработать? OpenSource как то с продажами не очень то дружит. G> Хехе. Дело в том, что OpenSource != FreeWare. OpenSource тоже денег стоит. Просто так получается, что чаще всего OpenSource можно получить бесплатно. Вопрос в том, сможет ли обычный пользователь разобраться с набором исходников — все равно потребуется специалист определенного уровня.
Или другой сценарий — кто-то спёр опенсоурс, подрихтовал, запаковал EXECryptor'ом (что бы не дай Бог, не докопались до истины) и продаёт
G>здесь это оффтопик, в общем-то...
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>>>Я думаю, что Вы, как человек, отлично знающий теорию компиляторов, согласны (в глубине души) с возможностью восстановления кода до human-readable формы. R>>конечно. примерно так же как и согласен с тем, что легко можно создать вечный двигатель. правда это может потребовать неограниченного количества времени GN>Аналогия неверная вечный двигатель противоречит законам физики.
текущим законам, надо отметить физика есть неточная наука. это я как математик утверждаю
GN>Угу. Вот начнуть трои паковать этой штукой в массовом порядке, тогда и целесообразность возникнет у материально заинтересованных сторон. Хотя ИМХО им бы для начала существующие эмуляторы подтянуть до рабочего уровня.
уже полгода как пакуют. по признаниям лиц ответственных лиц нескольких вируслабов на разбирательство кода они "забили".
R>>вот тут то и начинается кардинг. но за это уже надо сажать а не по головке гладить. GN>Социальная инженерия, утюги и паяльники — это отдельная большая тема
Здравствуйте, Relayer,
GN>>Аналогия неверная вечный двигатель противоречит законам физики.
R>текущим законам, надо отметить физика есть неточная наука. это я как математик утверждаю
Вот в том-то и дело, что знаний позволяющих создать perpettum mobile сейчас нет. А (де)компилятор — есть.
GN>>Угу. Вот начнуть трои паковать этой штукой в массовом порядке, тогда и целесообразность возникнет у материально заинтересованных сторон. Хотя ИМХО им бы для начала существующие эмуляторы подтянуть до рабочего уровня.
R>уже полгода как пакуют. по признаниям лиц ответственных лиц нескольких вируслабов на разбирательство кода они "забили".
Это они так колнкурентов в заблуждение вводят .
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>>>Аналогия неверная вечный двигатель противоречит законам физики. R>>текущим законам, надо отметить физика есть неточная наука. это я как математик утверждаю GN>Вот в том-то и дело, что знаний позволяющих создать perpettum mobile сейчас нет. А (де)компилятор — есть.
декомпилятор декомпилятору рознь. в нашем случае нужен не только декомпилятор но и анализатор. а вот с этим похуже. и работа такого анализатора недетерминирована.
GN>>>Угу. Вот начнуть трои паковать этой штукой в массовом порядке, тогда и целесообразность возникнет у материально заинтересованных сторон. Хотя ИМХО им бы для начала существующие эмуляторы подтянуть до рабочего уровня. R>>уже полгода как пакуют. по признаниям лиц ответственных лиц нескольких вируслабов на разбирательство кода они "забили". GN>Это они так колнкурентов в заблуждение вводят .
конкуренты здесь не при чем. антивирусы не готовы к таким вещам. читать вот здесь напрмер: What these tools highlight is that there is a new problem with the old signature-based way of doing security.
поэтому ловят все эвристиками.
Здравствуйте, Relayer, Вы писали:
R>декомпилятор декомпилятору рознь. в нашем случае нужен не только декомпилятор но и анализатор. а вот с этим похуже. и работа такого анализатора недетерминирована.
Поэтому я старался упоминать "компилятор" вместо "декомпилятор". Работа современных компиляторов тоже недетерминирована, тем неменее, они справляются со своей задачей за вполне приемлемое время . Анализатор — конечно же. Ещё и эмулятор.
R>антивирусы не готовы к таким вещам.
Мне, кстати, недавно рекомендовали антивирус с хорошим (то есть, лучше, чем у других) эмулятором. Название сходу вспомнить не могу — это к тому, что главные игроки рынка с точки зрения технических возможностей — аутсайдеры. Поэтому не думаю, что их это не беспокоит, и работы в направлеии улучшения не ведутся.
R>читать вот здесь напрмер: What these tools highlight is that there is a new problem with the old signature-based way of doing security.
Вот-вот, как раз ссылка в тему . Чувствуется некоторая обеспокоенность ухудьшающейся ситуацией. Когда грянет буря, вопрос создания uncryptor'а резко повысится в цене.
R>поэтому ловят все эвристиками.
Это ИМХО еще более безнадёжное занятие, чем вечный двигатель строить. Как-то попались пара статеек на тему, мне чесное слово, смешно было, какими нехитрыми способами там эвристики обманывали
PS: А вообще, интересный диалог получился . Сначала я посоветовал автору топика использовать 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
