Приветствую. Столкнулся с такой проблемой: есть программа на делфи. Ессно в ней с какого-то перепугу есть тлс. Так вот, при запуске программы FS:[2Ch] (в этом поле храниться адрес Thread Local Storage) указывает на один адрес в памяти, а где-то дальше по коду я заметил, что FS:[2Ch] указывает уже на страницу ниже. Т.е. меняется не значение этого поля (не сам указатель на TLS), а именно адрес самого поля! Какие могут быть логические объяснения этого процесса? Скажу сразу, с кодом программы не знаком - вряд ли она сама что-то такое страшное делает. На самом деле, на программу навесили криптор - он правильно настроил TLS. А вот сама программа обращается к ТЛС совсем по другому адресу. Если точноее, то эта программа - какой-то брутфорсер (вроде бы для аськи). Меня интересует сам этот конфликт загрузчика криптора и работы программы - я пока не понимаю причин происходящего. П.С.: на васме сижу давно - тем на подобную тематику не помню. Если уже проскакивала, прошу подсказать.
MSoft Не понятно что меняетсо, значение в fs:[TEB.ThreadLocalStorage], либо адрес страницы на которую ссылаетсо fs ?
т.е. в крипоре идет код Код (Text): mov fs:[2Ch],eax и запись происходит по адресу 7FFDE02С А в программе идет обращение к fs:[2Ch] - данные берутся из 7FFDD02C
MSoft Варианта два: > Запись в старницу 0x7FFDD000 запрещена(PAGE_READONLY ?), установлен хэндлер исключений по обращению к этой страницы для эмуляции. Посмотри права доступа к этой странице. > Установлен хардварный брык на этот адрес, также установлен хэндлер исключений для эмуляции. > fs ссылаетсо на страницу с адресом 0x7FFDD000, следовательно значение в fs отлично от 0x3B, используетсо LDT. Справа показаны регистры.
Может ты в другом потоке? ) он же все таки thread environment block такое изменение указывает именно на это там где регистры справа у селекторов сегементов написаны базы
да, fs не замечал раньше... Глянул в окошке памяти - там действительно выделяется новая страница памяти, на которую указывает новый FS. Great, скорее всего ты прав, т.к. подобные брут форсеры делают как правило многопоточными. Тогда из всего вышесказанного у меня возникает нижеследующий вопрос: этот криптор, судя по таблице директорий, затер все ссылки на TLS в РЕ и настраивает их сам в процессе работы. Как же тогда в этом случае корректней поступить загрузчику? Можно ли как-то прописать (в ПЕБ, ТЕБ или еще где) указатель на TLS, чтобы не возникала эта проблема с новыми тредами?
да там не бряк, а целый эксепшн но вопрос по решению проблемы TLS в многопоточном делфи (при условии очистки таблицы директорий) остается
Так в чём же заключается проблема? Ведь естественно, что у всех тредов разные значения базы FS и различные \ равные нулю значения по адресу FS:[2C].
Sol_Ksacap проблема в том, что из таблицы директорий удаляется информация о TLS, а работоспособность файла надо сохранить. Вопрос - как? Изменить ТЕБ главного треда легко. Но что делать с остальными тредами? В памяти конечно образ, включая таблицу директорий, восстанавливается полностью. Но ТЛС надо как-то настроить во всех тредах. Это и есть мой вопрос
Поправь TEB другим тредам. В чем разница? USHORT fs() { __asm mov ax, fs } GetThreadSelectorEntry (hThread, fs(), &Entry) узнаешь адрес TEB другого потока
дык если на момент настройки образа файла загрузчиком криптора никаких других тредов просто нет - как же я их подправлю?
MSoft Поставь нотификатор на создание потоков и из него загружай, лучше всего через EntryPoint нтдлл.
А вот этого как раз и не хотелось бы - ну какой упаковщик постоянно висит в памяти и следит за упакованным процессом? Это единственный выход? Тогда придется делать как упх - все-таки не очищать таблицу TLS? Есть другие варианты по настройке ТЛС только на стадии настройки образа?