Вопросы по-поводу скомпилированного EXE

[djalex777]

Создаю Native-Exe. Обратил внимание, что VB сохраняет имена функций, классов, методов и свойств классов, форм и т.д.
Вопросы:
1. Для чего это делается (для чего сохраняются имена)?
Следующие вопросы задавать пока бессмысленно... Подожду ответа

[Хакер]

В каждом отдельном случае причина своя. А потом: половина из того, что ты перечислил, в EXE не сохраняется.

[djalex777]

Приведи, пожалуйста, хотя бы две причины (и случая) сохранения имен. Просто для понимания.

А потом: половина из того, что ты перечислил, в EXE не сохраняется.

Перепроверил.
Для форм: сохраняются имена public функций, имена всех событий, имена всех объектов на форме и имена самих форм
Для модулей: имена модулей и public функций
Для классов: имена классов, public функций и public свойств, событий

В целом, похоже что не сохраняются только имена private функций и свойств.

[Хакер]

Приведи, пожалуйста, хотя бы две причины (и случая) сохранения имен. Просто для понимания.

Хорошо, поехали:

Для форм: сохраняются имена public функций, имена всех событий, имена всех объектов на форме и имена самих форм

Сохраняются дважды: первый раз для реализации IDispatch::GetIDsOfNames, второй раз сохраняются в TypeInfo внутри TypeLib внутри TLB-шки внутри ресурсов. TLB-шку можно из ресурсвов извлечь вместе со второй копией, файл при этом работать будет, хоть строки в нём и не будет. Первый случай присутствует всегда, второй только для публичных классов, которые могут быть только в ActiveX-серверах.

Для модулей: имена модулей и public функций

Не верю. Если у тебя ActiveX-сервер, то всё это относится к вышеописанному второму случаю. Если же нет, то, вообще говоря, быть там этого не должно, попросту потому как незачем. Но тем не менее, то что оно там есть не исключено: оно может встречаться как "наполнитель" для межсекционных и межзаголовочных паддингов. Ленивые компиляторы делают паддинг не нулями, а всяким мусором, который есть в памяти. Там может оказаться всё что угодно: матерные слова, введённые ранее в Immidiate Pane, какие-то промежуточные строки, в том числе и названия функций. Я думаю, если это так, то SP к VB должны это исправлять, так как это плохое явление с точки зрения безопасности и конфиденциальности.

Для классов: имена классов, public функций и public свойств, событий

То же самое, что и для формы. Форма это тот же класс, только раннее связывание не по VTable, а по DispId-ам.

[djalex777]

Спасибо. А могу я, скажем, заменить все имена (о которых идет речь выше) в скомпилированном файле Native-EXE, на другие, той же длины естественно, и повлияет ли это как-нибудь на работу приложения? Цель - привести все имена к несопоставимому виду (т.е. чтобы имя функции никак не отражало то, что она делает).

[Antonariy]

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

[djalex777]

Однако смысла в этом нет ни малейшего.

Если бы смысла не было, программ бы таких не делали. Про обфускацию я знаю. Не хотел использовать этот термин. Смысл любых методов защиты (а обфускацию можно отнести к этому) в том, чтобы как можно больше увеличить время взлома программы. Думаю что раскрытие алгоритма работы некоторых программ тоже можно отнести к их взлому. А вот логику работы программы намного легче понять (может и не во всех случаях) видя название функций, классов, форм и т.д. Далее, считаю для некоторых языков программирования (к примеру, php) обфускацию единственным способом хоть как-то защитить программу.

Попробовал заменить в скомпилированном-exe имена форм, имена классов, их методов и свойств... Запускал в Vista и XP. Всё работает. Может я что-то не учел?

Только работать престанет.

Почему?

[Хакер]

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

[djalex777]

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

Никто с этим не спорит. Я говорю лишь про усложнение разбора алгоритма работы программы.

[Хакер]

Он от этого не усложнится.

[djalex777]

Ну вот тебе пример:
Предположим. Есть поисковая система Google. Есть класс для работы с ней (определение различных параметров сайта или сайтов). А так же 50-60 других классов. Тебе нужно узнать алгоритм работы некоей функции, о которой ты только догадываешься по результатам программы. Ведь зная названия классов и функций ты можешь существенно снизить время поиска искомой функции. И для определения алгоритма её работы тебе даже не всегда надо будет смотреть алгоритмы работы второстепенных функций, которые используются в этой. А ты можешь его предполагать уже на основании имени функции.
Или я что-то не так понимаю?

[Хакер]

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

[djalex777]

Просто придумают заново. Делов-то: секунда раздумий и готово.

Ага. Если бы всё так было просто... Но раз ты так думаешь, на тебе пример: разработать алгоритм расчета стоимости продвижения сайта в поисковой системе Yandex. Под продвижением подразумевается вывод сайта по ключевым словам в первую десятку. Входные данные: url-сайта, ключевые слова. Выходные: стоимость в рублях. У некоторых алгоритмов есть ещё такой критерий как точность результата и она очень важна. Данный пример тому подтверждение. Существующие алгоритмы, мягко говоря, считают с огромной погрешностью (в большую сторону естественно). Алгоритм уже готов и вот его мне и хочется как можно лучше защитить.

[Хакер]

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

То есть, когда сложность твоей примитивной защиты сопоставима со сложность реверс-инжениринга, тогда алгоритм придумают сами. Когда несопоставима, обойдут твою защиту.

Вывод: защиту либо никто не будет ломать, либо всё равно обойдут.

[djalex777]

Это-то ты всё правильно говоришь. Понятно, что моя защита примитивна. Так вот я и думаю как можно её улучшить. А при хорошей защите вопрос только в том, сколько времени (а пропорционально получается и денег) потребуется для её обхода... И тогда возникает третий вариант, использовать уже написанную программу (к примеру мою), которая по стоимости дешевле, чем разработка нового алгоритма и реверс-инжиниринга.

[Antonariy]

Если бы смысла не было, программ бы таких не делали.

Смысл изготовления таких программ в том, что найдутся чайники, которые ее купят. А бесплатные делаются из интереса.

И тогда возникает третий вариант, использовать уже написанную программу (к примеру мою), которая по стоимости дешевле, чем разработка нового алгоритма и реверс-инжиниринга.

Ну а смысл ее защищать, если стоит она дешевле реверса?
Понимешь, сложность реверса обфусцированной программы почти не отличается от сложности реверса оригинальной.