Для получения куска кода dll делаем следуюшее

if (::VirtualProtect( pTest, blockSize, PAGE_READWRITE, &dwOldProtect))
{
CopyMemory( pCopy, pTest, cryptBlockSize);

::VirtualProtect(pTest, cryptBlockSize, dwOldProtect, &dwOldProtect);
}

, но все бы было хорошо, если бы после чтения небыло бы кривых байтов.

Принципиально оно работает и без VirtualProtect, но у меня есть предположение что надо сделать используя функции Virtual... что бы некоторые байты последовательности не портились.

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

F>Для получения куска кода dll делаем следуюшее

<поскипано>

F>, но все бы было хорошо, если бы после чтения небыло бы кривых байтов.

Во-первых, под Win32 копировать кусок кода можно без извращений c VirtualProtect, например, с помощью memcpy или CopyMemory. В середине марта была нитка на эту тему, называлась "Как запустить данные на исполнение?", почитай.
Во-вторых, что стоит за словами "кривые байты"? До сих пор проблем при копировании куска кода не замечалось. Кроме случая, когда скопированный код нужно выполнить, а в нем присутствуют call. Вот эти call могут лажать. А насчет кривых байтов — непонятно. Поясни.

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

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

P>Во-первых, под Win32 копировать кусок кода можно без извращений c VirtualProtect, например, с помощью memcpy или CopyMemory. В середине марта была нитка на эту тему, называлась "Как запустить данные на исполнение?", почитай.
P>Во-вторых, что стоит за словами "кривые байты"? До сих пор проблем при копировании куска кода не замечалось. Кроме случая, когда скопированный код нужно выполнить, а в нем присутствуют call. Вот эти call могут лажать. А насчет кривых байтов — непонятно. Поясни.

Поясняю. У меня есть указатель на блок в памяти. в памяти валяется загруженная dll. Когда я смотрю на память используя memory window в VS память вижу одни данные, а после копирования из этой области в другую, некоторые байты не соответствуют байтам, которые отображает memory window. То-что VS не лажает — это однозначно. То что касается "Как запустить данные на исполнение?", это не относится к это проблеме, к сожалению, никаким образом.

Причем *pCopy = *pTest; // VS отображает 0x55;
после присвоения *pCopy; // 0xCC

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

F>Поясняю. У меня есть указатель на блок в памяти. в памяти валяется загруженная dll. Когда я смотрю на память используя memory window в VS память вижу одни данные, а после копирования из этой области в другую, некоторые байты не соответствуют байтам, которые отображает memory window. То-что VS не лажает — это однозначно. То что касается "Как запустить данные на исполнение?", это не относится к это проблеме, к сожалению, никаким образом.
Очень сомнительный эксперимент. Уверен ли ты, что в memory window видишь именно то, что думаешь? Не пробовал в Disassembler посмотреть на коды?

F>Причем *pCopy = *pTest; // VS отображает 0x55;
Где VS отображает 0x55? В *pTest? pTest лежит в коде? Как ты ее туда засунул (любоптно просто, к делу почти не относится)? Какого типа pTest?
F>после присвоения *pCopy; // 0xCC
А откуда эта информация? Из memory window? Или ты в отладке *pCopy смотришь? Какого типа pCopy?

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

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

P>Очень сомнительный эксперимент. Уверен ли ты, что в memory window видишь именно то, что думаешь? Не пробовал в Disassembler посмотреть на коды?
Естественно смотрел все как положено.

F>>Причем *pCopy = *pTest; // VS отображает 0x55;
P>Где VS отображает 0x55? В *pTest? pTest лежит в коде? Как ты ее туда засунул (любоптно просто, к делу почти не относится)? Какого типа pTest?
F>>после присвоения *pCopy; // 0xCC
P>А откуда эта информация? Из memory window? Или ты в отладке *pCopy смотришь? Какого типа pCopy?

LPBYTE pCopy // указатель на блок, куда копировать.

VS *pTest отображает значение 0x55
далее
BYTE byCopy = pTest;
после присвоения byCopy равен 0xСС и pTest (как собственно логично) не изменился.

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

F>LPBYTE pCopy // указатель на блок, куда копировать.

F>VS *pTest отображает значение 0x55
F>далее
F>BYTE byCopy = pTest;
F>после присвоения byCopy равен 0xСС и pTest (как собственно логично) не изменился.

Возможно, тут опечатка, а если нет, то ошибка.
pTest — указатель? sizeof(pTest) == 4?
byCopy — BYTE? sizeof(byCopy) == 1?

Тогда — лажа. Не то копиреутся, а именно первый байт из 4-х байт представления указателя. Так? Если это ошибка, то надо

BYTE byCopy = *pTest

писать

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

F>Поясняю. У меня есть указатель на блок в памяти. в памяти валяется загруженная dll. Когда я смотрю на память используя memory window в VS память вижу одни данные, а после копирования из этой области в другую, некоторые байты не соответствуют байтам, которые отображает memory window. То-что VS не лажает — это однозначно. То что касается "Как запустить данные на исполнение?", это не относится к это проблеме, к сожалению, никаким образом.

F>Причем *pCopy = *pTest; // VS отображает 0x55;
F>после присвоения *pCopy; // 0xCC

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

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

F>Поясняю. У меня есть указатель на блок в памяти. в памяти валяется загруженная dll. Когда я смотрю на память используя memory window в VS память вижу одни данные, а после копирования из этой области в другую, некоторые байты не соответствуют байтам, которые отображает memory window. То-что VS не лажает — это однозначно. То что касается "Как запустить данные на исполнение?", это не относится к это проблеме, к сожалению, никаким образом.

F>Причем *pCopy = *pTest; // VS отображает 0x55;
F>после присвоения *pCopy; // 0xCC

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

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

F>>>Причем *pCopy = *pTest; // VS отображает 0x55;
P>>Где VS отображает 0x55? В *pTest? pTest лежит в коде? Как ты ее туда засунул (любоптно просто, к делу почти не относится)? Какого типа pTest?
F>>>после присвоения *pCopy; // 0xCC
P>>А откуда эта информация? Из memory window? Или ты в отладке *pCopy смотришь? Какого типа pCopy?

F>LPBYTE pCopy // указатель на блок, куда копировать.

F>VS *pTest отображает значение 0x55
F>далее
F>BYTE byCopy = pTest;
F>после присвоения byCopy равен 0xСС и pTest (как собственно логично) не изменился.

Нифига не понимаю, можно все-таки поподробнее объяснить? Если считать, что

BYTE byCopy = pTest;

где pTest имеет тип BYTE* — это опечатка, а должно быть

BYTE byCopy = *pTest;

то из твоего объяснения получается, что код выглядит примерно так:

BYTE* pTest;
*pTest = 55;
BYTE byCopy = *pTest;

и после этого в byCopy оказывается 0xCC.
Что я неправильно понимаю?

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

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

F>>Поясняю. У меня есть указатель на блок в памяти. в памяти валяется загруженная dll. Когда я смотрю на память используя memory window в VS память вижу одни данные, а после копирования из этой области в другую, некоторые байты не соответствуют байтам, которые отображает memory window. То-что VS не лажает — это однозначно. То что касается "Как запустить данные на исполнение?", это не относится к это проблеме, к сожалению, никаким образом.

F>>Причем *pCopy = *pTest; // VS отображает 0x55;
F>>после присвоения *pCopy; // 0xCC

ZY>Попробуй ReadProcessMemory (даже если ты читаешь из текущего процесса) — это может решить твою проблему. И дебагер VC использует эту ф-ю для отображения дампа памяти твоего процесса.


BYTE byTest = 0;
DWORD dwRead = 0;
LPBYTE pTest = .... ; // (указатель на отрывок dll в памяти); VS показывает, что *pTest == 0x55

ReadProcessMemory( GetCurrentProcess(), pTest, &byTest, sizeof(byTest), &dwRead);

после копировования
dwRead == 1
byTest == 0xCC ????
*pTest == 0x55 (каким ты был, таким ты и остался.) (ну вообще то, это логично)

Здравствуйте whiteForest, Вы писали:
F>byTest == 0xCC ????
F>*pTest == 0x55 (каким ты был, таким ты и остался.) (ну вообще то, это логично)

Так, маленько не в тему, но...
0xCC это int 3, т.е. DebugBreak.

Отладчик запросто может показывать тебе что-то одно,
а на самом деле там брякпоинт, поставленный отладчиком.

Попробуй без отладчика. И выведи результат
с помощью MsgBox'a.

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

S>Здравствуйте whiteForest, Вы писали:
F>>byTest == 0xCC ????
F>>*pTest == 0x55 (каким ты был, таким ты и остался.) (ну вообще то, это логично)

S>Так, маленько не в тему, но...
S>0xCC это int 3, т.е. DebugBreak.

S>Отладчик запросто может показывать тебе что-то одно,
S>а на самом деле там брякпоинт, поставленный отладчиком.

S>Попробуй без отладчика. И выведи результат
S>с помощью MsgBox'a.

Сделал, тоже самое только без отладчика и..
получилось почти, то что нужно. byTest тепеерь после копирования 0x55, но
при копировании блока длинной 200 байт, были несоответствия:

01 10 заменены 68 0A
02 10 заменены 69 0A

во всех случаях встречи этих комбинаций в блоке копирорвания.

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

F>при копировании блока длинной 200 байт, были несоответствия:
F>01 10 заменены 68 0A
F>02 10 заменены 69 0A
F>во всех случаях встречи этих комбинаций в блоке копирорвания.

А код-то какой этому соответствует? не

Call DWORD PTR [_imp_SomeApi]

случайно?

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

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

F>>при копировании блока длинной 200 байт, были несоответствия:
F>>01 10 заменены 68 0A
F>>02 10 заменены 69 0A
F>>во всех случаях встречи этих комбинаций в блоке копирорвания.

S>А код-то какой этому соответствует? не

S>Call DWORD PTR [_imp_SomeApi]

S>случайно?

оки. эти байты во время загрузки подменяются на instance загружаемой dll.
все большое спасибо.