#include <windows.h>

LPSTR message1 = "This is message for the first function";
LPSTR message2 = "This is message for the second function";

int __declspec(naked) func1()
 {
  __asm
   {
    label1:
    push  0
    push  0
    push  message1
    push  0
    call  MessageBox
    mov   eax,func1
    sub   eax,label1
    ret
   }
 }

int __declspec(naked) func2()
 {
  __asm
   {
    label2:
    push  0
    push  0
    push  message2
    push  0
    call  MessageBox
    mov   eax,func2
    sub   eax,label2
    ret
   }
 }
void func3(int num)
 {
  __asm
   {
    cmp num,1
    jne label_not_1
    pop eax
    jmp func1
label_not_1:
    cmp num,2
    jne label_not_2
    pop eax
    jmp func2
label_not_2:
   }
 }

int main(int argc, char* argv[])
 {
  if ((func1() == 0)&&(func2() == 0))
   {
    MessageBox(0,"It's OK","Especialy for whiteForest AkA Karpov",MB_OK|MB_ICONINFORMATION);
   }
  func3(1);
  func3(2);
  return 0;
 }

Build by Intel C++ Compiler 5.0.1

Я по-справедливости мог бы потребовать что бы ты на меня работал год бесплатно, а то забалаболим !!!
Но думаю, что мы слегка не сработаемся


Пока, сотрудничек !

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

DG>Посчитать контрольную сумму на C можно, вот только нельзя точно узнать где функция кончилась, так как linker не гарантирует, что функции будут в том же порядке, что и при написанни.

Для этого можно воспользоваться #pragma code_seg. Каждую функцию можно поместить в отдельный кодовый сегмент. Линкер сегменты сортирует в определённом порядке (по имени), на это можно смело закладываться, т.к. на этом в VC построена инициализация CRTL.

DG>Но чаще контрольной суммы не хватает и тогда впихивают динамическое(при достижении данного участка кода) кодирование/разкодирование частей программы. И вот тогда возникает проблема как внешнему кодировщику указать какие части проги надо закодить изначально.

Внешние кодировщики опять же могут почитать map-файл и не надо будет оставлять следы в коде.

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

IT>Для этого можно воспользоваться #pragma code_seg. Каждую функцию можно поместить в отдельный кодовый сегмент. Линкер сегменты сортирует в определённом порядке (по имени), на это можно смело закладываться, т.к. на этом в VC построена инициализация CRTL.

IT>Внешние кодировщики опять же могут почитать map-файл и не надо будет оставлять следы в коде.

Обе эти идеи сложно автоматизировать.

void Test ()
{
  bla-bla-bla
  BEGIN_CODE_CRYPT()
  bla-bla-bla
  END_CODE_CRYPT()
  bla-bla-bla
}

"Скобки" BEGIN_CODE_CRYPT()/END_CODE_CRYPT() — указывают какой код паковать и вставляют код для распаковки/запаковки в run-time.

А на уровне функций это сложнее.
1. Надо каждую закоденную функцию оборачивать во wrapper, который ее будет кодить/декодить.
2. Писать внешнюю прогу которая будет разбираться с map-ом, code-seg-ментами и т.д.

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

DG>Обе эти идеи сложно автоматизировать.

DG>

void Test ()
{
  bla-bla-bla
  BEGIN_CODE_CRYPT()
  bla-bla-bla
  END_CODE_CRYPT()
  bla-bla-bla
}

DG>"Скобки" BEGIN_CODE_CRYPT()/END_CODE_CRYPT() — указывают какой код паковать и вставляют код для распаковки/запаковки в run-time.

DG>А на уровне функций это сложнее.
DG>1. Надо каждую закоденную функцию оборачивать во wrapper, который ее будет кодить/декодить.

А в твоём случае разве не нужно этого делать?

DG>2. Писать внешнюю прогу которая будет разбираться с map-ом, code-seg-ментами и т.д.

По-моему, это проще, чем лепить асемблерные вставки

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

IT>А в твоём случае разве не нужно этого делать?
В том то и дело, что не надо. Надо просто добавить в тело функции два макроса.

Был у меня обычный код:

void CClass::Func()
{
  не_важный_код;
  важный_код;
  не_важный_код;
}

Если мы кодируем на уровне функции, то это превратиться во что-то такое:

#pragma code_seg("Func0c")
void Func0c(куча_входных_параметров, куча_выходных_параметров)
{
  важный_код;
}
#pragma code_seg()

void Func0(куча_входных_параметров, куча_выходных_параметров)
{
  расшифровать(Func0c);
  Func0c(куча_входных_параметров, куча_выходных_параметров);
  зашифровать(Func0c);
}

void CClass::Func()
{
  не_важный_код;
  Func0(куча_входных_параметров, куча_выходных_параметров);
  не_важный_код;
}

Что конечно не улучшает читаемость, сопровождаемость и безошибочность кода.

А так же надо как-то сказать внешнему паковщику, что Func0c надо зашифровывать, а Func0 — не надо. Но эту проблему можно победить, если давать хитрые имена, типа, Func0_Crypt_It.

DG>>2. Писать внешнюю прогу которая будет разбираться с map-ом, code-seg-ментами и т.д.

IT>По-моему, это проще, чем лепить асемблерные вставки :)
Так программер вставляет только два макроса, все остальное не его дело.

А если не нравится что увеличивается exe-шник, то на это есть 2 возражения:
1. В нынешних приложениях бОльшую часть занимает не код, а ресурсы: картинки, текст, музыка, мультфильмы. Да и в целом не важно, сколько занимает приложение 20М или 40М. Все равно его по dial-up-у не выкачаешь. А все остальные причины уменьшения размера кода не понятны. Вон Microsoft совсем отказалась от разделяемого кода, теперь для каждого приложения свои версии общих dll-ек.

2. В крайнем случае, ассемблерные вставки индикации кодируемого блока заменять внешним пакером на код динамической распаковки/запаковки.

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

DG>В том то и дело, что не надо. Надо просто добавить в тело функции два макроса.

IT>>По-моему, это проще, чем лепить асемблерные вставки

DG>Так программер вставляет только два макроса, все остальное не его дело.

Выглядит симпатично, только у тебя это пока планы, а я тебе предлагаю более менее реализуемое решение. В этом вся разница. Если тебе удастся это реализовать — очень хорошо, желаю удачи.

DG>А если не нравится что увеличивается exe-шник, то на это есть 2 возражения:

Я этого не говорил, т.е. этим не страдаю

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


DG>>Так программер вставляет только два макроса, все остальное не его дело.

IT>Выглядит симпатично, только у тебя это пока планы, а я тебе предлагаю более менее реализуемое решение. В этом вся разница. Если тебе удастся это реализовать — очень хорошо, желаю удачи.

Нет, это уже реализованное решение, которое уже используется

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

IT>Выглядит симпатично, только у тебя это пока планы, а я тебе предлагаю более менее реализуемое решение. В этом вся разница. Если тебе удастся это реализовать — очень хорошо, желаю удачи.

В принципе можно сделать. Без внешнего кодировщика всё равно не обойтись. Делаем как ты предлагал "криво" , размер буфера должен быть достаточным для вписывания туда внешним кодироващиком кода для вызова функций раскодировки/кодировки, им нужен будет размер кодируемого блока да и всё. Внешний кодировщик его может подсчитать. Адрес кодируемого блока можно взять из стека, его туда процессор положит при вызове. Но главное! Нет гемороя при разработке, если внешний кодировщик не запускался, то и так всё будет работать.
Сделать можно. Но всё равно — пороть

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

IT>В принципе можно сделать. Без внешнего кодировщика всё равно не обойтись. Делаем как ты предлагал "криво" , размер буфера должен быть достаточным для вписывания туда внешним кодироващиком кода для вызова функций раскодировки/кодировки, им нужен будет размер кодируемого блока да и всё. Внешний кодировщик его может подсчитать. Адрес кодируемого блока можно взять из стека, его туда процессор положит при вызове. Но главное! Нет гемороя при разработке, если внешний кодировщик не запускался, то и так всё будет работать.

Вот, примерно, так оно все и работает.

IT>Сделать можно. Но всё равно — пороть
За что?!!!

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

IT>>Выглядит симпатично, только у тебя это пока планы, а я тебе предлагаю более менее реализуемое решение. В этом вся разница. Если тебе удастся это реализовать — очень хорошо, желаю удачи.

DG>Нет, это уже реализованное решение, которое уже используется

Это был не ты, а whiteForest

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

IT>>Сделать можно. Но всё равно — пороть

DG>За что?!!!

Да так, шоб в следующий раз неповадно было

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

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

F>>>Ну вот и первое толковое решение...
F>>>Итак пол приза достается DarkGray за сообразительность.

IT>>За такие решения надо не призы раздавать, а пороть нещадно

DG>Что самое интересное, такое решение часто встречается в коммерческих библиотеках. Особенно в библиотеках по защите кода от вскрытия.

Итак. Воот он. 99% процентный победитель. У него было уже пол приза за сообразительность, так вот еще почти пол приза за догадку. Это нужно для защиты. Есть же умные и опытные люди в этом форуме.

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


DG>А чем тебе не нравится третье решение?
DG>Это решение я привел, только потому что оно стандартное и часто встречается в различных библиотеках. Особенно при защите кода.

Чистить много. А мне нужно сделать использую только возможности модуля. На чистом C++ с примесью asm

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

A>[c]
A>#include <windows.h>

A>LPSTR message1 = "This is message for the first function";
A>LPSTR message2 = "This is message for the second function";

A>int __declspec(naked) func1()
A> {
A> __asm
A> {
A> label1:
A> push 0
A> push 0
A> push message1
A> push 0
A> call MessageBox
A> mov eax,func1
A> sub eax,label1
A> ret
A> }
A> }

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

A>Build by Intel C++ Compiler 5.0.1

A>Я по-справедливости мог бы потребовать что бы ты на меня работал год бесплатно, а то забалаболим !!!
A>Но думаю, что мы слегка не сработаемся
A>Пока, сотрудничек !

Не мог бы ты ничего потребовать, потому-что не я тебе обещал, а ты мне.
Ладно, расслабся... Видно, что ты что-то умеешь.

А у нас функции с параметрами. Я пытался сделать исользуя naked,

А ты из сделай __fastcall

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

DG>void fun1
DG>{
DG> __asm
DG> {
DG> jmp q;
DG> DB "Label1"
DG> q:
DG> bla-bla-bla
DG> }
DG>}

Простой вопрос не много не в тему:
У меня Visual C++ говорит что "DB" ему не известно. dw он вроде знает, а db типа нет.
Чего ему нужно объяснить?

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

T>Простой вопрос не много не в тему:
T>У меня Visual C++ говорит что "DB" ему не известно. dw он вроде знает, а db типа нет.
T>Чего ему нужно объяснить?

DB он и вправду не знает, зато знает __emit