Многоуважаемый алл,

Как оставить метки в коде (например GUID), чтобы в собранном EXE они остались на тех же местах и в тех же функциях где я их оставил, т.е. в коде, а не в данных и не в стеке.

С уважением,
Сергей

Здравствуйте, JDi, Вы писали:

JDi>Многоуважаемый алл,

JDi>Как оставить метки в коде (например GUID), чтобы в собранном EXE они остались на тех же местах и в тех же функциях где я их оставил, т.е. в коде, а не в данных и не в стеке.

Можно так, как пример:

__asm
{
    //rdtsc
    _emit 0fh
    _emit 31h
}

Здравствуйте, JDi, Вы писали:

JDi>Многоуважаемый алл,

JDi>Как оставить метки в коде (например GUID), чтобы в собранном EXE они остались на тех же местах и в тех же функциях где я их оставил, т.е. в коде, а не в данных и не в стеке.

JDi>С уважением,
JDi>Сергей

А зачем это нужно?

Здравствуйте, Glоbus, Вы писали:

G>Здравствуйте, JDi, Вы писали:

JDi>>Многоуважаемый алл,

JDi>>Как оставить метки в коде (например GUID), чтобы в собранном EXE они остались на тех же местах и в тех же функциях где я их оставил, т.е. в коде, а не в данных и не в стеке.

JDi>>С уважением,
JDi>>Сергей

G>А зачем это нужно?

Например, для рассчета контрольной суммы участка кода. Как вариант защиты от взлома.

Здравствуйте, Flamer, Вы писали:

F>Здравствуйте, Glоbus, Вы писали:

G>>Здравствуйте, JDi, Вы писали:

JDi>>>Многоуважаемый алл,

JDi>>>Как оставить метки в коде (например GUID), чтобы в собранном EXE они остались на тех же местах и в тех же функциях где я их оставил, т.е. в коде, а не в данных и не в стеке.

JDi>>>С уважением,
JDi>>>Сергей

G>>А зачем это нужно?

F>Например, для рассчета контрольной суммы участка кода. Как вариант защиты от взлома.
+ Зашифровка (RSA) участков кода с последующим убиранием меток. Тоже для защиты от взлома

Здравствуйте, Flamer, Вы писали:

F>Здравствуйте, JDi, Вы писали:

JDi>>Многоуважаемый алл,

JDi>>Как оставить метки в коде (например GUID), чтобы в собранном EXE они остались на тех же местах и в тех же функциях где я их оставил, т.е. в коде, а не в данных и не в стеке.

F>Можно так, как пример:


F>

F>__asm
F>{
F>    //rdtsc
F>    _emit 0fh
F>    _emit 31h
F>}
F>

Бааальшое спасибо. Я кучу времени убил на это. А так и не нашел Пааааасиба! еще раз.

F>>Например, для рассчета контрольной суммы участка кода. Как вариант защиты от взлома.
JDi>+ Зашифровка (RSA) участков кода с последующим убиранием меток. Тоже для защиты от взлома

Вообще-то нельзя полагаться на то, что тело функции будет единым.
Вы это учитываете?

Здравствуйте, MShura, Вы писали:


MS>Вообще-то нельзя полагаться на то, что тело функции будет единым.
MS>Вы это учитываете?
Нет. Не учитываю. А по подробней можно?

Спасибо

Здравствуйте, JDi, Вы писали:

JDi>Здравствуйте, MShura, Вы писали:


MS>>Вообще-то нельзя полагаться на то, что тело функции будет единым.
MS>>Вы это учитываете?
JDi>Нет. Не учитываю. А по подробней можно?


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

Решения для общего случая не существует.

Рекоммендую поискать в интернете (например на CodeProject — там по-моему была статья по этому поводу).

Здравствуйте, MShura, Вы писали:

MS>Если защищаешь конкретную функцию, то можно посмотреть на генерируемый код и учесть все особенности.
MS>Решения для общего случая не существует.
MS>Рекоммендую поискать в интернете (например на CodeProject — там по-моему была статья по этому поводу).
Я смотрел на CodeProject. Там единственное что нашел — это зашифровка строк.
Просто я вообще не представляю зачем и как компилятор может одну функцию разбить на 2 или вставить return там, где я его не вставлял. Вообще анализ ASM показал, что return тока меньше становится. Это все про C++ код. Delphi вообще лажу генерит .

Я понимаю что общего решения нет. Но какие-нить зацепки по этому поводу есть?

Здравствуйте, JDi, Вы писали:

MS>>Вообще-то нельзя полагаться на то, что тело функции будет единым.
MS>>Вы это учитываете?
JDi>Нет. Не учитываю. А по подробней можно?
Пути оптимизатора не исповедимы.
Может быть что угодно. Инлайнинг, перестановка кода в нутри функции, векторизация циклов...

Здравствуйте, JDi, Вы писали:

JDi>Здравствуйте, MShura, Вы писали:

MS>>Если защищаешь конкретную функцию, то можно посмотреть на генерируемый код и учесть все особенности.
MS>>Решения для общего случая не существует.
JDi>Я понимаю что общего решения нет. Но какие-нить зацепки по этому поводу есть?

Исследуй свой компилятор и защищаемую функцию.

например:

При использовании достаточно большого и последовательного (по значениям) switch() компилятор может сгенерит глобальную таблицу переходов. Она будет за пределом функции.

другое:
Иногда оптимизатор может объединить общие фрагменты у функций (обычно выход из них) в один кусок. При каких условиях это достигается я не знаю.

Здравствуйте, MShura, Вы писали:

MS>Исследуй свой компилятор и защищаемую функцию.
MS VC++ 7.0

MS>например:
[skipped]
Спасибо, понял. Буду каждый раз проверять ассемблерный код, чтоб не напортачить.

Интересно, а можно как-нибудь помечать куски кода для запрета внутри оптимизации? Не вообще отключать, а только куски помечать?

JDi>Интересно, а можно как-нибудь помечать куски кода для запрета внутри оптимизации? Не вообще отключать, а только куски помечать?
Нашел:
#pragma optimize("", off)
// some code here
#pragma optimize("", on)

Спасибо еще раз за советы

Еще можно запихнуть в один сегмент

#pragma xxx_seg( ["section-name"[,"section-class"] ] )

Тогда точно будет в одном месте