Задача сводиться к следующему,

необходимо получить список ссылок на метки

LPVOID aLabel[] = { jmp_label1, jmp_label2};

из различный функций

void fun1()
{
...
asm {jmp_label1:}
...
}

void fun2()
{
...
asm {jmp_label2:}
...
}

реализация с ниже преведенным подходом не подходит

typedef (* PFN_fun)();
PFN_fun aLabel[] = { fun1, fun2};

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


K>необходимо получить список ссылок на метки

K>LPVOID aLabel[] = { jmp_label1, jmp_label2};

K>из различный функций

K>...
K>asm {jmp_label1:}
K>...
K>asm {jmp_label2:}
K>...

Так делать категорически нельзя
Стек запорешь в результате Access Violation со всеми вытекающими на твою голову проблемами

Покажи всю задачу !!! А то, так, мало понятно, что надо сделать.

A>Так делать категорически нельзя
A>Стек запорешь в результате Access Violation со всеми вытекающими на твою голову проблемами

A>Покажи всю задачу !!! А то, так, мало понятно, что надо сделать.

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

Большая просьба писать только по теме и не высказывать мне ваши опасения. Если бы они мне понадобились, я попросил бы их у Вас.

Здравствуйте Аноним, Вы писали:

A>>Так делать категорически нельзя
A>>Стек запорешь в результате Access Violation со всеми вытекающими на твою голову проблемами

A>>Покажи всю задачу !!! А то, так, мало понятно, что надо сделать.

А>Задача как стояла получить список всех глобальных меток так и осталась. Всю задачу раскрывать нет смысла, она ни каким образом не повлияет на предлагаемые решения.

Вопрос задан не корректно.
Метка это адресс, фактически целое число unsigned int и оно неможет быть глобальным или локальным. Это не переменная в процедуре место под которую выделятся в стеке.
Уточни что ты подразумеваешь под глобальнойй меткой

А>Большая просьба писать только по теме и не высказывать мне ваши опасения. Если бы они мне понадобились, я попросил бы их у Вас.
No comments

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

A>Вопрос задан не корректно.
A>Метка это адресс, фактически целое число unsigned int и оно неможет быть глобальным или локальным. Это не переменная в процедуре место под которую выделятся в стеке.
A>Уточни что ты подразумеваешь под глобальнойй меткой

void fun()
{
...
__asm jmp_test2:;
...
}

void main()
{
__asm 
{

jmp_test:;
     mov eax, offset jmp_test; получаемый смещение, другими словами метку
     mov eax, offset jmp_test2; // а вот здесь не получиться. не из-за того, что этой метки нет, а из-за того что компилятор позволяет оперировать метками текущего тела функции. Так вот... Вопрос... Как получить jmp_test2 из main.
}
}

Если ответ Вам не известен, просьба не отвечать.

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

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

VC++ очень правильно делает. Это в народе называется защита от дурака

объясняю подробно

есть некая функкция

void a(int x,float y) // возвращаемый тип значения не имеет
 {
  // some local variables here
  char z;
  // code

  __asm
   {

   label1:

   }

 }

её стековый кадр для stdcall напрмер

1 byte  // char  z
4 bytes // int   x
6 bytes // float y
4 bytes // адресс откуда вызвали a()

есть другая процедура

void b(char p)
 {
  // some local variables here
  long q;
  // code
  __asm
   {
    
    label2:
   
   }
 }

её стековый кадр

4 bytes // long q
1 byte  // char p
4 bytes // адрес откуда вызвали b()

Если перепрыгнуть с адреса label1 на label2, то поле работы процедуры будет очищено из стека 5 байт и процедура возвратит управления по адресу не тому откуда её вызывали а старшие 4 байта локальной переменной y типа float

Такие пререходы нарушают принцыпы структурного программирования на которых базируются C и C++ и не разрешены ни стандартом, ни компилятором, ни элементарной логикой
Такое позволяют только автономные ассемблеры tasm masm wasm
F>Если ответ Вам не известен, просьба не отвечать.

На вашем месте я бы
1) Ознакомлся с азами архитектуры Intel x86 процессоров прежде чем писать на ассемблере
2) Прочёл пару книг по структурному программированию и его преимуществам
3) защёл на сюда так как вы пока новичок на этом форуме и вам наверное не понятно что здесь люди привыкли уважать друг друга и писать сообщения в вежливой форме !!!

A>Такие пререходы нарушают принцыпы структурного программирования на которых базируются C и C++ и не разрешены ни стандартом, ни компилятором, ни элементарной логикой
A>Такое позволяют только автономные ассемблеры tasm masm wasm

Ну может хватит меня лечить. И про стек хватит, знаю я все. И не надо мне советовать что читать.

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

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

A>>Такие пререходы нарушают принцыпы структурного программирования на которых базируются C и C++ и не разрешены ни стандартом, ни компилятором, ни элементарной логикой
A>>Такое позволяют только автономные ассемблеры tasm masm wasm

F>Ну может хватит меня лечить. И про стек хватит, знаю я все. И не надо мне советовать что читать.

F>Мне нужно решение (ключик или pragma какая нибудь), которое позволет сделать это.
F>А данная задача нужна не с целью написания программы основанной на переходе между функциями, мне нужен список со смещением меток. Для чего, это уже мое дело. да и долго объяснять.

tasm masm wasm

На VC build-in assembler (да и по-моему на любом другом встроенном ассемблере) это не выйдет

Напиши на чистом asm раз уж ты всё знаешь. На самом деле не так уж и сложно !!!

Да и почему метки не могут быть началами функций в конце концов? Удобнее было бы создать массив ссылок на функции. Это единственное что можно сделать на VC.

PS Если ты хочешь оптимизировать переход по условию где условие это число из диапазона то пиши switch-ем компилятор оптимизирут в релизе как раз в массив ссылок и переход по элементу

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

A>Напиши на чистом asm раз уж ты всё знаешь. На самом деле не так уж и сложно !!!

A>Да и почему метки не могут быть началами функций в конце концов? Удобнее было бы создать массив ссылок на функции. Это единственное что можно сделать на VC.

Выдержки из переписки 1:

Задача сводиться к следующему,
...
реализация с ниже преведенным подходом не подходит

typedef (* PFN_fun)();
PFN_fun aLabel[] = { fun1, fun2};

Кстати, а зачем мне левые метки... Мне нужны именно конкретные... Причем тут прога на asm? Если бы реализация нужна была бы на асме, я вообще ничего бы не спрашивал.

A>PS Если ты хочешь оптимизировать переход по условию где условие это число из A>диапазона то пиши switch-ем компилятор оптимизирут в релизе как раз в массив A>ссылок и переход по элементу

Выдержки из переписки 2:
задача нужна не с целью написания программы основанной на переходе между функциями, мне нужен список со смещением меток

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

НЕЛЬЗЯ НА VC ТАКОЕ СДЕЛАТЬ !!!
НЕЛЬЗЯ И ВСЁ !!!

Кто-нибудь докажет что я неправ — буду на него год беслатно работать !

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

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

A>НЕЛЬЗЯ НА VC ТАКОЕ СДЕЛАТЬ !!!
A>НЕЛЬЗЯ И ВСЁ !!!

Ну с этого и надо было начинать. А то сделай так, почитай это, перепеши на этом и еще кучу нравоучений.

A>Кто-нибудь докажет что я неправ — буду на него год беслатно работать !

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

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

Чё то у вас тут уже не диалог, а канкретна пацанские разборки пошли

Роман, хоть и несколько эмоцианально, но прав, на C++ такого сделать нельзя. Можно ещё поразбираться с setjmp/longjmp, но как минимум ты должен пройтись по тому месту куда хочешь потом сигануть.

F>задача нужна не с целью написания программы основанной на переходе между функциями, мне нужен список со смещением меток

Более конкретная информация дала бы больше пищи для размышления и возможно нашёлся бы нормальный вариант реализации. Сейчас это всё пока больше смахивает на неправильное проектирование задачи.

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


Как верно сказал adontz, в лоб решения не видно.

Но можно сделать криво:
1.

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

Потом найти в коде слово Label1

void main()
{
  find ("Label1", &fun1, &main);
}

2.

int arr[100];
int arr_i = 0;

void fun1()
{
  __asm
  {
    mov arr[arr_i++], $;
    bla-bla-bla
  }
}

Повызывать все функции, они сами заполнят массив

void main()
{
  fun1();
  for (int i = 0; i < arr_i; ++i)
  {
    std::cout << arr[i] << "\n";
  }
}

3. Разобрать символьную информацию, который пихает компилятор для debugger-а.
В частности информацию о том, для какой линии C-кода, какой адрес соответствует.

Причем эту информацию можно получить и для Release-версии.

Компиляем Release с добавлением Debug-информации.
Разбираем Debug-информацию и на ее основание патчим exe-шник, заполняя какой-нибудь массив.
С помощью Strip-а убераем Debug-информацию.

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

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

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

DG>Как верно сказал adontz, в лоб решения не видно.

DG>Но можно сделать криво:
DG>1.
DG>void fun1
DG>{
DG> __asm
DG> {
DG> jmp q;
DG> DB "Label1"
DG> q:
DG> bla-bla-bla
DG> }
DG>}


Ну вот и первое толковое решение... правда уже имея это решение я и полез на форум. Метку для поиска лучше поставить в начале функции. следом за меткой сразу будет нужное нам смещение (так-то побыстрее будет). Вот только без вызовов не обойтись. ну думаю, что нибудь еще придумаем.

Итак пол приза достается DarkGray за сообразительность.

Ждем интересных решений.

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

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

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

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


DG>>Но можно сделать криво:
DG>>1. <...>

F>Ну вот и первое толковое решение...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что Игорь тебя тоже досали ?

#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