Кое-что известно из MSDN о сегментном регистре FS. Как правильно записать туда из дебагера?
Смотрю код IsDebug.asm из IsDebuggerPresent plugin для OllyDbg и не понимаю почему оно работает. Там есть код:

mov eax,dword ptr fs:[30h] ; pointer to PEB
add eax,2h
mov byte_location,eax

где dword ptr fs:[30h] - есть содержимое fs:[30h] в текущем потоке, как я понимаю - это поток созданный
из дебагера, и соответственно, - читающий FS из процесса дебагера. Потом там вызывается Олина функция Writememory, которая пишет. У меня WriteProcessMemory (XP sp2) падает с ошибкой
(писал по byte_location=7FFD4002) : 'Попытка обращения к неверному адресу'. Оно вобдщем-то не удивительно, потому что читаю мой FS а пишу в чужой. Возможно плагин написано в расчете на совпадение адресов в FS. Как мне кажется, этот код должен выполняться в отлаживаемом процессе.

Может я где-то ошибаюсь. Но суть не в этом, нужна информация про то как туда писать/читать правильно.

| Сообщение посчитали полезным:

код бы показал... вообще имхо адрес PEB во всех процессах один, а во WriteProcessMemory первым параметром передаётся хэндл процесса открытого для записи, в чём и суть...

-----
Shalom ebanats!

| Сообщение посчитали полезным:

Код, вот он :

bool RemoveIsDebuggerPresents(CONTEXT &context,PROCESS_INFORMATION &pi)
{
Sleep(200);//это мне вроде как не нужно, просто по аналогии с...
context.ContextFlags=CONTEXT_FULL;
bool b=GetThreadContext(pi.hThread,&context);
DWORD dwBytesMoved;
DWORD byte_location;
byte_location=context.SegFs +0x2;
BYTE cNull=0x00;
__asm{
mov eax,dword ptr fs:[30h] // ; pointer to PEB
add eax,2h
mov byte_location,eax
}
bool bRet=WriteProcessMemory(pi.hProcess, (PVOID)byte_location,
&cNull, sizeof(BYTE),
&dwBytesMoved);
if ( !bRet || (dwBytesMoved != sizeof(BYTE)) )
{
PSTR pErr=GlePSTR();
Le("RemoveIsDebuggerPresents: WriteProcessMemory failed");
sprintf(str,"byte_location=%X pErr=%s",byte_location,pErr); Le(str);
}
else Le("RemoveIsDebuggerPresents: WriteProcessMemory OK");
return bRet;
}

Функция вызывается из потока, который является дебагером, вызвающий WaitForDebugEvent и ContinueDebugEvent.

| Сообщение посчитали полезным:

хз, VirtualQuery, посмотри память куда указывает, какойто протект.....

-----
Shalom ebanats!

| Сообщение посчитали полезным:

проходил мимо просто не мог не ответить

AlexKlm пишет:
потому что читаю мой FS а пишу в чужой

В этом ничего страшного, главное осознание этого факта, лично у меня когда-то тоже такое было)

AlexKlm пишет:
нужна информация про то как туда писать/читать правильно

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



be31_11.08.2007_CRACKLAB.rU.tgz - PEB.rar

| Сообщение посчитали полезным:

Сейчас попробую сначалу у себя в процессе сделатьто что в подопытным, потом сравню их. Может просто не туда попадаю. Ну и VirtualQuery заодно сделаю.

| Сообщение посчитали полезным:

Вот лог, что вышло:

RemoveIsDebuggerPresents: Not BadReadPtr 7FFDD002 , OK
RemoveIsDebuggerPresents: Not BadWritePtr 7FFDD002 , OK
Мой процесс (дебагер):
VirtualQueryEx( dwPageStartAdr: 7FFDD000 &mbi: 15CFD3C dwLength: 1C ) returns 1C
VirtualQueryEx: _MEMORY_BASIC_INFORMATION : Base 7FFDD000 AllocationProtect ' "PAGE_READWRITE"'
AllocationState ' "MEM_COMMIT"' RegionSize 1000 Protect ' "PAGE_READWRITE"' AllocationType ' "MEM_PRIVATE"'
Чужой процесс (подопытный):
VirtualQueryEx( dwPageStartAdr: 7FFDD000 &mbi: 15CFD3C dwLength: 1C ) returns 1C
VirtualQueryEx: _MEMORY_BASIC_INFORMATION : Base 7FFDD000 AllocationProtect ' "(empty (0))"'
AllocationState ' "MEM_FREE"' RegionSize 2000 Protect ' "PAGE_NOACCESS"' AllocationType ' "(empty (0))"'
RemoveIsDebuggerPresents: WriteProcessMemory failed
byte_location=7FFDD002 pErr=Попытка обращения к неверному адресу.
Что-то не так, ведь должен же плагин работать. Там бы что-нибудь знакомое прочитать, чтобы понять что верный адрес читаю. Структура большая по размеру, но там все Reserved.

| Сообщение посчитали полезным:

Для одной операционки, как сказано в MSDN, структура PEB в одном месте, а в другой она может быть в другом. И может эту дыру MS заделала, чтобы не читали и не писали, хотя это нас мало остановит, написать кусок кода и испольнить в другом процессе не проблема.

| Сообщение посчитали полезным:

какойто протект.....
- Да. Это мой проект игрушечный, который может перерасти в серьезный, что маловероятно. Слишком много надо работать. А как IDE для особо ленивых, - условно пригодна, лежит на alexklm.ru : Easy DE 1. 5 мБ.

| Сообщение посчитали полезным:

To nik0g0r:
Сразу не заметил. Спасибо. NtQueryInformationProcess я тоже видел, но так нахально её использовать не пробовал. Вот теперь я попробую проверить, адреса как не совпадают ли.

| Сообщение посчитали полезным:

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

Попробую обьяснить тогда
AlexKlm пишет:
__asm{
mov eax,dword ptr fs:[30h] // ; pointer to PEB
add eax,2h
mov byte_location,eax
}

здесь ты получаеш адрес BeingDebugged структуры PEB своего(!) процесса (тот кот отлаживает)

AlexKlm пишет:
bool bRet=WriteProcessMemory(pi.hProcess, (PVOID)byte_location,
&cNull, sizeof(BYTE),
&dwBytesMoved);

а здесь ты записываеш по этому адресу, но в другой(!) процесс (отлаживаемый)
и ты считаеш это правильно?

если не хочеш использовать код кот я дал,
AlexKlm пишет:
написать кусок кода и испольнить в другом процессе не проблема

тогда так и делай, именно этот способ я иногда использую)

| Сообщение посчитали полезным:

nik0g0rРезультат такой:
По коду из IsDebug.asm адрес PEB = 7FFDC000
а по коду из be31_11.08.2007_CRACKLAB.rU.tgz - PEB.rar ( nik0g0r )
PEB = 7FFDE000
---------------------------------------------------------------
ошибка в 2 страницы
Зато работает, вызвлал ReadProcessMemory еще раз и BeingDebugged = 00.

| Сообщение посчитали полезным:

nik0g0r - спасибо тебе за помощь. Все правильно, я и раньше грешил на неидентичность адресов расположения. Это хорошо, что так просто можно обойтись.

| Сообщение посчитали полезным:

Еще, интересное наблюдение, пока олаживая дебагер я запускаю экзешник запакованный ExeCryptor'ом. Так тот находит мой проект (вижу по OutputDebugString) и туда пакостит (куда точно - не заметил), после чего мне приходится пересобирать все. Хорошо что сорцы не трогает.

| Сообщение посчитали полезным:

OpenProcess с нужным процесс Id
NtQueryInformationProcess для получения адреса PEB в ProcessBasicInformation
NtWriteVirtualMemory - для записи значения длинной UCHAR
CloseHandle

Вот и все.

-----
Security through obscurity is just an illusion

| Сообщение посчитали полезным:

pushick - а можно ли достать адрес TIB также, при помощи ntdll.dll, не выполняя код в подопытном процессе?
Я понадеялся что это просто, оказалось - никто не хочет об этом распростроняться, писатели дебагеров.
А пока я попробую вписать в процесс код, потом перевести на адрес кода eip подопытного:

push eax
mov eax, dword ptr fs:[0]
int 3 ; - здесь я ловлю бряк и читаю из context.Eax что в fs:[0]
pop eax
int 3 ; - здесь я возвращаю eip на место (через context.Eip)

| Сообщение посчитали полезным:

по-моему так мона:

hThread:=OpenThread(THREAD_ALL_ACCESS,false,dwThreadId)
ctx.ContextFlags:=CONTEXT_FULL
GetThreadContext(hThread,ctx)
GetThreadSelectorEntry(hThread,ctx.SegFs,LDTE)



-----
[nice coder and reverser]

| Сообщение посчитали полезным:

Hellspawn, - большое спасибо, сейчас попробую.

| Сообщение посчитали полезным:

Вызвал GetThreadSelectorEntry,
собрал :

DWORD dwFS_Adr=MAKELONG(ldte.BaseLow, MAKEWORD(ldte.HighWord.Bytes.BaseMid,ldte.HighWord.Bytes.BaseHi) );
получил dwFS_Adr 7FFDF000.

Проверил:
VirtualQueryEx: _MEMORY_BASIC_INFORMATION : Base 7FFDF000 AllocationProtect "PAGE_READWRITE"
AllocationState "MEM_COMMIT" RegionSize 1000 Protect "PAGE_READWRITE" AllocationType "MEM_PRIVATE"

Похоже что правильно. Попробую рассмотреть что там лежит, надо же получить стека начало и. т.д.

| Сообщение посчитали полезным:

Вот что там на начале страницы:

000000 00000000 FF FF FF FF 00 00 13 00 00 E0 12 00 00 00 00 00 |яяяя.....а......|
000010 00000010 00 1E 00 00 00 00 00 00 00 F0 FD 7F 00 00 00 00 |........аэ....|
000020 00000020 48 0E 00 00 78 0B 00 00 00 00 00 00 00 00 00 00 |H...x...........|
000030 00000030 00 F0 FD 7F 00 00 00 00 00 00 00 00 00 00 00 00 |.рэ............|

Второй и третий DWORD очень похожи на стек.
А Exception handler не установлен (-1). Считаю что эксперимент удался. Спасибо за помощь!

| Сообщение посчитали полезным:

Еще раз проверил в структуре NT_TIB указатель Self (офсет в структуре 0x18). Он совпадает с полученым ранее dwFS_Adr, что подтверждает правоту Hellspawn.

| Сообщение посчитали полезным:

AlexKlm почитай в мсдн про эту функу она для этого и создавалась.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

AlexKlm

Может я не в тему, но вот это

AlexKlm пишет:
а можно ли достать адрес TIB также, при помощи ntdll.dll

можно сделать через NtQueryInformationThread c ThreadBasicInformation

-----
Security through obscurity is just an illusion

| Сообщение посчитали полезным:

Оказалось все проще:
WaitForDebugEvent(&event,...);
event->u.CreateProcessInfo->lpThreadLocalBase.
Наверное для другого потока будет аналогично.

| Сообщение посчитали полезным:

ну дык я те универсальный способ привёл... а для отлажеваемой проги конечно лучше
через lpThreadLocalBase читать...

-----
[nice coder and reverser]

| Сообщение посчитали полезным:

Еще я бьюсь с одной проблемой. Никак не хочет загрузчик разрешить мне обработать точку останова на EP апликации запакованной ExeCryptor'ом. И это - серьезная проблема, и связана она, как я предполагаю, - с безопасностью. На обычных прогах все нормально, а тут - болт. Без WinIce бесполезно искать, можно попробовать методом перебора вариантов, попробовать убрать возможно установленный операционкой нелегальный обработчик. Но это - другая тема. Когда найду причину - сообщу. Спасибо всем за участие.

| Сообщение посчитали полезным:

AlexKlm
В ExeCryptor может как-то с TLS Callbacks связано, если во всех других прогах всё нормально пашет.

| Сообщение посчитали полезным:

Archer пишет:
В ExeCryptor может как-то с TLS Callbacks связано, если во всех других прогах всё нормально пашет.

конечно связано, не любит он бряки на ер

-----
[nice coder and reverser]

| Сообщение посчитали полезным:

И что же? Кажется причина найдена, ещё не понял механизм, но копать надо в дата директорию TLS. Это я сам нашел, и только сейчас увидел что Archer правильно сказал, видимо. Ntdll.dll выходит туда. А я ссылку 4 го DWORD на ссылку на второй EP (который запускается раньше) обнулил, тогда апликация стала запускаться с EP указанного в PE заголовке. Ура! Осталось изучить материал по дата директории TLS. Наадеюсь что-то накопаю.

| Сообщение посчитали полезным:

А чего там особенного изучать то по ТЛС? Бери формат PE-файла да кури. Если вкратце, то callback поле в TLS-указатель на массив коллбеков, заканчивающийся 0. Они выполняются до ОЕП. Другим словом, при загрузке файла смотри: есть коллбеки, ставь бряк на них, нету-на EP.

| Сообщение посчитали полезным: