threadvar, _GetTls, FS:tlsArray

← →
DevilDevil © (2013-11-04 02:46) [0]

Ещё один вопрос, который мне не даёт покоя который день = это threadvar (TLS = thread local storage)

Идём в недра Delphi, в модуль _GetTls
И что мы видим:
function _GetTls: Pointer; asm MOV CL,ModuleIsLib MOV EAX,TlsIndex TEST CL,CL JNE @@isDll MOV EDX,FS:tlsArray MOV EAX,[EDX+EAX*4] RET @@initTls: CALL InitThreadTLS MOV EAX,TlsIndex PUSH EAX CALL TlsGetValue TEST EAX,EAX JE @@RTM32 RET @@RTM32: MOV EAX, tlsBuffer RET @@isDll: PUSH EAX CALL TlsGetValue TEST EAX,EAX JE @@initTls end;

Что мне не понятно:
1) почему в случае приложения (не Dll) мы получаем таблицу в адресе FS:tlsArray, а в случае Dll мы обязаны вызывать TlsGetValue
2) почему мы обращаемся к переменной TlsIndex если в exe он всёравно 0. Или может быть не 0 ?

Bonus 3) вот здесь верхний индекс заканчивается на 0xF28. http://en.wikipedia.org/wiki/Win32_Thread_Information_Block
означает ли это, что верхний диапазон до страницы я могу использовать по своему усмотрению ?

← →
DevilDevil © (2013-11-04 04:48) [1]

Bonus 4) как узнать flat-адрес, куда указывает сегмент ?

← →
bems © (2013-11-04 15:49) [2]

> 4) как узнать flat-адрес, куда указывает сегмент ?

у TEB есть ссылка на себя - на х32 она в леэит в FS:[18h], на х64 в GS:[30h]

как-то так
function GetCurrentThreadTEB: Pointer; stdcall; asm {$IFDEF CPUX64} DB $65, $48, $8B, $04, $25 DD $00000030 // mov RAX, qword ptr GS:[30h] {$ELSE} mov EAX, FS:[18h] {$ENDIF !CPUX64} end;

если нужно получить поинтер на teb не текущего (в общем случае) треда то можно сделать NtQueryInformationThread и в полученной структуре THREAD_BASIC_INFORMATION прочитать поинтер TebBaseAddress

← →
bems © (2013-11-04 16:10) [3]

> 1) почему в случае приложения (не Dll) мы получаем таблицу
> в адресе FS:tlsArray, а в случае Dll мы обязаны вызывать
> TlsGetValue

потому что если длл загружается динамически то DllMain не вызывается для уже существующих тредов, соответственно tls для этой дллки может оказаться не инициализирован, значит надо посмотреть что вернёт TlsGetValue

← →
Rouse_ © (2013-11-04 16:46) [4]

> 2) почему мы обращаемся к переменной TlsIndex если в exe
> он всёравно 0. Или может быть не 0 ?

Значение TlsIndex это результат выполнения функции TlsAlloc

> Bonus 3) вот здесь верхний индекс заканчивается на 0xF28.
> http://en.wikipedia.org/wiki/Win32_Thread_Information_Block
> означает ли это, что верхний диапазон до страницы я могу
> использовать по своему усмотрению ?

В смысле писать по адресу ниже оффсета 0xF28?
Нет конечно, по твоей ссылке структура не полная.
Там еще много всего сидит:

7FFD9F28 00 00 00 00 HardErrorMode = 0 ---------------------------------------------------------------------------------------------------------- 7FFD9F2C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 Instrumentation 7FFD9F3C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFD9F4C 00 00 00 00 ---------------------------------------------------------------------------------------------------------- 7FFD9F50 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 ActivityId = {00000000-0000-0000-0000-000000000000} 7FFD9F60 00 00 00 00 SubProcessTag = 0 7FFD9F64 00 00 00 00 EtwLocalData = 0 7FFD9F68 00 00 00 00 EtwTraceData = 0 7FFD9F6C 00 00 00 00 WinSockData = 0 7FFD9F70 00 00 00 00 GdiBatchCount = 0 7FFD9F74 00 SpareBool0 = 0 7FFD9F75 00 SpareBool1 = 0 7FFD9F76 00 SpareBool2 = 0 7FFD9F77 00 IdealProcessor = 0 7FFD9F78 00 00 00 00 GuaranteedStackBytes = 0 7FFD9F7C 00 00 00 00 ReservedForPerf = 0 7FFD9F80 D0 CA 2D 00 ReservedForOle = 2DCAD0 7FFD9F84 00 00 00 00 WaitingOnLoaderLock = 0 7FFD9F88 00 00 00 00 SavedPriorityState = 0 7FFD9F8C 00 00 00 00 SoftPatchPtr1 = 0 7FFD9F90 50 36 04 0C ThreadPoolData = C043650 7FFD9F94 60 FD 81 05 TlsExpansionSlots = [581FD60] "NULL" 7FFD9F98 00 00 00 00 ImpersonationLocale = 0 7FFD9F9C 00 00 00 00 IsImpersonating = 0 7FFD9FA0 00 00 00 00 NlsCache = 0 7FFD9FA4 00 00 00 00 pShimData = 0 7FFD9FA8 05 00 00 00 HeapVirtualAffinity = 5 7FFD9FAC 00 00 00 00 CurrentTransactionHandle = 0 7FFD9FB0 00 00 00 00 ActiveFrame = 0 7FFD9FB4 50 9D FD 0B FlsData = BFD9D50 7FFD9FB8 00 00 00 00 PreferredLanguages = 0 7FFD9FBC 28 8C 71 04 UserPrefLanguages = 4718C28 7FFD9FC0 A0 5A 22 00 MergedPrefLanguages = 225AA0 7FFD9FC4 01 00 00 00 MuiImpersonation = 1 7FFD9FC8 00 00 CrossTebFlags = 0 7FFD9FCA 00 00 SameTebFlags = 0 7FFD9FCC 00 00 00 00 TxnScopeEnterCallback = 0 7FFD9FD0 00 00 00 00 TxnScopeExitCallback = 0 7FFD9FD4 00 00 00 00 TxnScopeContext = 0 7FFD9FD8 00 00 00 00 LockCount = 0 7FFD9FDC 00 00 00 00 ProcessRundown = 0 7FFD9FE0 C8 93 3B 0C 00 00 00 00 LastSwitchTime = C3B93C8 7FFD9FE8 00 00 00 00 00 00 00 00 TotalSwitchOutTime = 0 7FFD9FF0 00 00 00 00 00 00 00 00 WaitReasonBitMap = 0

← →
bems © (2013-11-04 17:31) [5]

> Значение TlsIndex это результат выполнения функции TlsAlloc

похоже на то, что из экзешника она действительно не вызывается, а используется значение 0, присвоенное в _InitExe (по крайней мере в XE2)

← →
Rouse_ © (2013-11-04 17:38) [6]

> bems © (04.11.13 17:31) [5]

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

← →
bems © (2013-11-04 17:42) [7]

> тот-же _GetTls, который использует данную переменную, вызывает
> как приложение, так и библиотечный код, поэтому заменить
> данную переменную нулем (как было предложено) не получится

в _GetTls есть ветвление по условию ModuleIsLib, не понимаю что мешает использовать 0 в варианте для экзе

← →
Rouse_ © (2013-11-04 18:04) [8]

> bems © (04.11.13 17:42) [7]
> в _GetTls есть ветвление по условию ModuleIsLib, не понимаю
> что мешает использовать 0 в варианте для экзе

Это ничего страшного. Никто не мешает назначить свое хранилище через тот-же
TlsIndex := TlsAlloc;
+ код инициализации оного...

Переменная то доступна из пользовательского кода.

← →
bems © (2013-11-04 18:07) [9]

> Переменная то доступна из пользовательского кода.

мм... слона-то я и не заметил :)
И ТС тоже

← →
DevilDevil © (2013-11-04 19:16) [10]

> Rouse_ © (04.11.13 18:04) [8]
> Это ничего страшного. Никто не мешает назначить свое хранилище
> через тот-же TlsIndex := TlsAlloc;+ код инициализации оного...

Почему код получения TLS в приложении возможен инлайном (EDX,FS:tlsArray)
А для получения того же самого в Dll нужен вызов API-функции ?

> bems © (04.11.13 15:49) [2]
> > 4) как узнать flat-адрес, куда указывает сегмент ?у TEB
> есть ссылка на себя - на х32 она в леэит в FS:[18h], на х64 в GS:[30h]

ясно. я просто пытался lea eax, fs:[const]
и не получалось :)

а GS: в x64 это что ?
дай линк почитать

> Rouse_ © (04.11.13 16:46) [4]
> В смысле писать по адресу ниже оффсета 0xF28?Нет конечно,
> по твоей ссылке структура не полная.Там еще много всего сидит:

а где полную структуру почитать ?
и неужели нет хоть какой-то возможности гарантированно сохранить там 4 байт (или 8 для x64) ?

← →
Rouse_ © (2013-11-04 19:51) [11]

> Почему код получения TLS в приложении возможен инлайном
> (EDX,FS:tlsArray)
> А для получения того же самого в Dll нужен вызов API-функции
> ?

Потому что это разные вещи.
FS:tlsArray указывает на параметр ThreadLocalStoragePointer структуры TEB, а TlsGetValue берет данные из TlsSlots, в которых записано уже что-то свое (что именно я не разбирался, бо небыло необходимости).

> а GS: в x64 это что ?
> дай линк почитать

То-же что и FS для x32, сегмент указывающий на TEB.
К примеру FS:[0] - указывает на первое поле TEB (TEB.NtTIB.ExceptionList) и т.п.

> а где полную структуру почитать ?
> и неужели нет хоть какой-то возможности гарантированно сохранить
> там 4 байт (или 8 для x64) ?

Качай символы для конкретной системы, потом ставь стандартный отладчик и там выводи "dt nt!_teb" выведутся параметры структуры с оффсетами.

Ну как-то так:

kd> dt nt!_teb +0x000 NtTib : _NT_TIB +0x01c EnvironmentPointer : Ptr32 Void +0x020 ClientId : _CLIENT_ID +0x028 ActiveRpcHandle : Ptr32 Void +0x02c ThreadLocalStoragePointer : Ptr32 Void +0x030 ProcessEnvironmentBlock : Ptr32 _PEB +0x034 LastErrorValue : Uint4B

для каждой ОС структура будет своя.

← →
Rouse_ © (2013-11-04 19:56) [12]

Вот так к примеру это выглядит для Windows 7 x32

---------------------------------------------- NT_TIB32 -------------------------------------------------- 7FFDF000 50 FF 12 00 ExceptionList = 12FF50 7FFDF004 00 00 13 00 StackBase = 130000 7FFDF008 00 C0 12 00 StackLimit = 12C000 7FFDF00C 00 00 00 00 SubSystemTib = 0 7FFDF010 00 1E 00 00 FiberData = 1E00 7FFDF014 00 00 00 00 ArbitraryUserPointer = 0 7FFDF018 00 F0 FD 7F Self = 7FFDF000 ----------------------------------------------- TEB32 ---------------------------------------------------- 7FFDF01C 00 00 00 00 EnvironmentPointer = 0 7FFDF020 0C 16 00 00 ClientId.UniqueProcess = 160C 7FFDF024 4C 12 00 00 ClientId.UniqueThread = 124C 7FFDF028 00 00 00 00 ActiveRpcHandle = 0 7FFDF02C F0 2E 18 00 ThreadLocalStoragePointer = 182EF0 7FFDF030 00 A0 FD 7F ProcessEnvironmentBlock = 7FFDA000 7FFDF034 00 00 00 00 LastErrorValue = 0 7FFDF038 00 00 00 00 CountOfOwnedCriticalSections = 0 7FFDF03C 00 00 00 00 CsrClientThread = 0 7FFDF040 98 C9 B4 FD Win32ThreadInfo = FDB4C998 ---------------------------------------------------------------------------------------------------------- 7FFDF044 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 User32Reserved ... ---------------------------------------------------------------------------------------------------------- 7FFDF0AC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 UserReserved 7FFDF0BC 00 00 00 00 ---------------------------------------------------------------------------------------------------------- 7FFDF0C0 00 00 00 00 WOW32Reserved = 0 7FFDF0C4 19 04 00 00 CurrentLocale = 419 7FFDF0C8 00 00 00 00 FpSoftwareStatusRegister = 0 ---------------------------------------------------------------------------------------------------------- 7FFDF0CC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 SystemReserved1 ... ---------------------------------------------------------------------------------------------------------- 7FFDF1A4 00 00 00 00 ExceptionCode = 0 7FFDF1A8 E0 07 18 00 ActivationContextStackPointer = 1807E0 ---------------------------------------------------------------------------------------------------------- 7FFDF1AC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 SpareBytes 7FFDF1BC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDF1CC 00 00 00 00 ---------------------------------------------------------------------------------------------------------- 7FFDF1D0 FE FF 00 00 TxFsContext = FFFE 7FFDF1D4 00 00 00 00 GdiTebBatch.Offset = 0 7FFDF1D8 00 00 00 00 GdiTebBatch.HDC = 0 ---------------------------------------------------------------------------------------------------------- 7FFDF1DC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 GdiTebBatch.Buffer ... ---------------------------------------------------------------------------------------------------------- 7FFDF6B4 0C 16 00 00 RealClientId.UniqueProcess = 160C 7FFDF6B8 4C 12 00 00 RealClientId.UniqueThread = 124C 7FFDF6BC 00 00 00 00 GdiCachedProcessHandle = 0 7FFDF6C0 00 00 00 00 GdiClientPID = 0 7FFDF6C4 00 00 00 00 GdiClientTID = 0 7FFDF6C8 00 00 00 00 GdiThreadLocalInfo = 0 ---------------------------------------------------------------------------------------------------------- 7FFDF6CC 08 00 00 00 00 00 00 00 | 00 05 00 00 00 00 00 00 Win32ClientInfo ... --------------------------------------------------------------------- 7FFDF7C4 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 glDispatchTable ... ---------------------------------------------------------------------------------------------------------- 7FFDFB68 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 glReserved1 ... ---------------------------------------------------------------------------------------------------------- 7FFDFBDC 00 00 00 00 glReserved2 = 0 7FFDFBE0 00 00 00 00 glSectionInfo = 0 7FFDFBE4 00 00 00 00 glSection = 0 7FFDFBE8 00 00 00 00 glTable = 0 7FFDFBEC 00 00 00 00 glCurrentRC = 0 7FFDFBF0 00 00 00 00 glContext = 0 7FFDFBF4 34 00 00 C0 LastStatusValue = C0000034 7FFDFBF8 00 00 0A 02 00 FC FD 7F StaticUnicodeString = [7FFDFC00] "" ---------------------------------------------------------------------------------------------------------- 7FFDFC00 6E 00 74 00 64 00 6C 00 | 6C 00 2E 00 64 00 6C 00 StaticUnicodeBuffer ... ---------------------------------------------------------------------------------------------------------- 7FFDFE0C 00 00 03 00 DeallocationStack = 30000 ---------------------------------------------------------------------------------------------------------- 7FFDFE10 00 00 00 00 3F 6C 4F 76 | 00 00 00 00 00 00 00 00 TlsSlots ... ---------------------------------------------------------------------------------------------------------- 7FFDFF10 00 00 00 00 TlsLinks.FLink = 0 7FFDFF14 00 00 00 00 TlsLinks.BLink = 0 7FFDFF18 00 00 00 00 Vdm = 0 7FFDFF1C 00 00 00 00 ReservedForNtRpc = 0 7FFDFF20 00 00 00 00 00 00 00 00 DbgSsReserved = 0 7FFDFF28 00 00 00 00 HardErrorMode = 0 Остальное давал выше

← →
bems © (2013-11-04 19:59) [13]

> Почему код получения TLS в приложении возможен инлайном
> (EDX,FS:tlsArray)
> А для получения того же самого в Dll нужен вызов API-функции?

я на это вроде ответил

> это что ?
> дай линк почитать

что это что? GS это сегментный регистр, в GS:[30h] лежит поинтер на TEB. поскольку компилятор дельфи делает из инструкции mov RAX, qword ptr GS:[30h] что-то странное, мы используем непосредственно машинный код в функции GetCurrentThreadTEB

← →
DevilDevil © (2013-11-04 22:17) [14]

> Rouse_ © (04.11.13 19:51) [11]

> Качай символы для конкретной системы, потом ставь стандартный
> отладчик и там выводи "dt nt!_teb" выведутся параметры структуры
> с оффсетами.

Это какой-то неправильный путь :)
Всё-равно же должно существовать документированное описание TEB/TIB :)
В код Delphi явно зашито обращение к ThreadLocalStoragePointer, значит часть данных строго регламентирована

Вот ты привёл расширенное описание
Но верхние 8-12 байт получается всёравно свободны

← →
DevilDevil © (2013-11-04 22:32) [15]

Кстати посмотрите ещё поле по смещению 0x700 (x86) или 0x878 (x64)
Может оно ?

← →
DevilDevil © (2013-11-04 22:40) [16]

Только я с размером поля не понял
20 байт в x86 и 24 под x64 ?

← →
Rouse_ © (2013-11-05 10:31) [17]

> Это какой-то неправильный путь :)
> Всё-равно же должно существовать документированное описание
> TEB/TIB :)
> В код Delphi явно зашито обращение к ThreadLocalStoragePointer,
> значит часть данных строго регламентирована

Не регламентирована.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686708(v=vs.85).aspx

> The definition of this structure may change from one version
> of Windows to the next

Но на практике меняются поля как внутри структуры, так и в ее конце.
(Верхние поля обычно остаются не изменные).

> Вот ты привёл расширенное описание
> Но верхние 8-12 байт получается всёравно свободны

От туда-же:

> Do not assume a maximum size for this structure.

> Кстати посмотрите ещё поле по смещению 0x700 (x86) или 0x878
> (x64)
> Может оно ?

Кто оно?
Под х32 и x64 этот офсет находится где-то в районе TEB.in32ClientInfo.

> Только я с размером поля не понял
> 20 байт в x86 и 24 под x64 ?

Какого поля?

← →
DevilDevil © (2013-11-05 11:33) [18]

> Rouse_ © (05.11.13 10:31) [17]
> От туда-же:
> > Do not assume a maximum size for this structure.

Ну... по логике 4Кб предел этой структуры. Я вообще удивлён, что смогли столько засрать :)

> Кто оно?
> Под х32 и x64 этот офсет находится где-то в районе TEB.in32ClientInfo.
> Какого поля?

http://en.wikipedia.org/wiki/Win32_Thread_Information_Block
поле "NT Reserved for user application"

в обед до дома добегу, найду ссылку, которую видел вчера
а пока вот здесь
http://code.ohloh.net/file?fid=--ONVyuzSJsn_16mM5LU8NcCz2A&cid=4x157wI30IQ&s=teb&browser=Default&fp=363563&mp&pro jSelected=true#L0
PVOID UserReserved[5];

← →
Mystic © (2013-11-05 13:06) [19]

Может кому-то поможет
http://www.delphimaster.ru/articles/localmem/

1) почему в случае приложения (не Dll) мы получаем таблицу в адресе FS:tlsArray, а в случае Dll мы обязаны вызывать TlsGetValue

DLL может быть несколько, а приложение одно. DLL могут подгружаться динамически. Поэтому нельзя заранее статично привязать DLL к индексу.

2) почему мы обращаемся к переменной TlsIndex если в exe он всёравно 0. Или может быть не 0 ?

Зато у нас один общий код и для DLL, и для EXE.

означает ли это, что верхний диапазон до страницы я могу использовать по своему усмотрению ?

В документации ничего не сказано, следовательно непереносимый код. Вообще, не понимаю, зачем резервировать страницу, если в нее можно влепить несколько TEB без всякого риска?

← →
Rouse_ © (2013-11-05 13:10) [20]

> DevilDevil © (05.11.13 11:33) [18]
> Ну... по логике 4Кб предел этой структуры. Я вообще удивлён,
> что смогли столько засрать :)

С чего-бы это? На х64 она в размер страницы не влазит.

> http://en.wikipedia.org/wiki/Win32_Thread_Information_Block
> поле "NT Reserved for user application"

Это видимо от каких-то старых версий Windows, там часть параметров вообще не по своим оффсетам указана. По крайней мере эти данные не совпадают с теми что есть начиная с Windows XP и выше.
То-же касается и второй ссылки, вот более-менее актуальное состояние:

http://redplait.blogspot.ru/2010/09/windows-7-peb-teb.html

← →
Rouse_ © (2013-11-05 13:25) [21]

> PVOID UserReserved[5];

Зы, а так вообще это поле по оффсету (AC или E8) занимает в обоих случаях 20 байт, просто в x64 из-за выравнивания поле WOW32Reserved начинается с оффсета 0х100, поэтому у UserReserved появляются лишние 4 Spare байта

← →
DevilDevil © (2013-11-05 13:44) [22]

> Rouse_ ©

во!
http://source.winehq.org/source/include/winternl.h#L297

← →
Rouse_ © (2013-11-05 14:06) [23]

Не то.
CLIENT_ID RealClientId; /* 6e8/0850 */

Начиная с XP это выглядит как

7EFDA6B4 68 08 00 00 RealClientId.UniqueProcess = 868 7EFDA6B8 AC 1F 00 00 RealClientId.UniqueThread = 1FAC

а по оффсету 6e8 сидит Win32ClientInfo

← →
Rouse_ © (2013-11-05 14:10) [24]

Зы и кстати это ты Wine исходники смотришь, а это делать не стоит, там у них некоторые вещи под себя переделаны, например до некоторых пор FS:[C0] использовалось под свои нужны, хотя это должен был быть TEB.WOW32Reserved и т.п.

← →
DevilDevil © (2013-11-05 15:08) [25]

> Rouse_ © (05.11.13 14:06) [23]
> а по оффсету 6e8 сидит Win32ClientInfo

Исходя из твоей ссылки Win32ClientInfo сидит в диапазоне с 0x6cc по 0x7c4
Найди структуру Win32ClientInfo, уверен, по нужным смещениям там будет UniqueProcess и UniqueThread.

Судя по http://en.wikipedia.org/wiki/Win32_Thread_Information_Block
Всё сходится. 0x6e8
"NT Real Process ID" и "NT Real Thread ID"

По поводу XP... то опять таки судя по http://en.wikipedia.org/wiki/Win32_Thread_Information_Block
Там лежит какое-то 124байтное поле

Давай какой-нибудь другой пример

← →
DevilDevil © (2013-11-05 15:12) [26]

Берём 0xfb4
И куда ни глянем - везде будет FlsData(FlsSlots)

← →
DevilDevil © (2013-11-05 15:58) [27]

Можно кстати прописать какое-нибудь значение в это смещение
А потом посмотреть, что напишет твой дебагер. Желательно в нескольких ОС

← →
Rouse_ © (2013-11-05 17:01) [28]

> Судя по http://en.wikipedia.org/wiki/Win32_Thread_Information_Block
> Всё сходится. 0x6e8
> "NT Real Process ID" и "NT Real Thread ID"

Ниче не сходится, вот тебе дамп:

---------------------------------------------------------------------------------------------------------- 7FFDC6B4 2C 0C 00 00 RealClientId.UniqueProcess = C2C 7FFDC6B8 B0 09 00 00 RealClientId.UniqueThread = 9B0 7FFDC6BC 00 00 00 00 GdiCachedProcessHandle = 0 7FFDC6C0 00 00 00 00 GdiClientPID = 0 7FFDC6C4 00 00 00 00 GdiClientTID = 0 7FFDC6C8 00 00 00 00 GdiThreadLocalInfo = 0 ---------------------------------------------------------------------------------------------------------- 7FFDC6CC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 Win32ClientInfo 7FFDC6DC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC6EC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC6FC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC70C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC71C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC72C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC73C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC74C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC75C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC76C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC77C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC78C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC79C 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC7AC 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 7FFDC7BC 00 00 00 00 00 00 00 00 ----------------------------------------------------------------------------------------------------------

Как видишь по оффсету "6Е8" сидят нули, в то время как реальные значения данного параметра сидят по оффсету "6B4".

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

На короче, изучай: https://github.com/AlexanderBagel/ProcessMemoryMap
Компилировать под ХЕ4 полная релизная сборка осуществляется в режиме 32/Release (при этом автоматом компилируется и линкуется 64-битный образ)

ЗЫ:

> Mystic © (05.11.13 13:06) [19]
> Вообще, не понимаю, зачем резервировать страницу, если
> в нее можно влепить несколько TEB без всякого риска?

32-битный TEB на 8 байт меньше дефолтной страницы, поэтому даже при желании туда их несколько штук не влезет :)

ЗЗЫ: и то не факт, уже вышла 8.1 а его структуру я еще не смотрел, вполне возможно что там TEB, по аналогу с 64-битным уже залез и на вторую страницу...

ЗЗЫ:

> DevilDevil © (05.11.13 15:12) [26]
> Берём 0xfb4
> И куда ни глянем - везде будет FlsData(FlsSlots)

Параметр FlsData появился начиная с Windows 2003, в ХР он отсутствует...

> Rouse_ © (05.11.13 17:01) [28]

чёт ломает собирать проект
у тебя бинарников нет ?

Я вообще предлагаю пойти по другому пути
Вот в этом архиве исходники и бинарники (для 32 бит и 64 бит): http://zalil.ru/34795905
Я конечно не знаю, в какой момент ты там смотришь инфо по заполненным записям
Но предлагаю запустить exe, который модифицируют предполагаемую область
И в конечном счёте мы узнаем, как система интерпретирует занятые поля. И всё ли мы (я) правильно предполагаем в плане местоположения и размера

Исходники такие (содержатся так же в архиве):
function GetTEB: pointer; asm {$ifdef CPUX86} mov eax, fs:[$18] {$else} // mov rax, gs:[$30] DB $65,$48,$8b,$04,$25 DD $30 {$endif} end; var i: integer; bytes: pansichar; begin bytes := GetTEB; inc(bytes, {$ifdef CPUX86}$700{$else}$878{$endif}); for i := 1 to {$ifdef CPUX86}20{$else}24{$endif} do begin bytes^ := ansichar(i); inc(bytes); end; Writeln("Modified. Debug and press Enter later"); Readln; end.

> DevilDevil © (05.11.13 17:34) [32]
> > Rouse_ © (05.11.13 17:01) [28]
>
> чёт ломает собирать проект
> у тебя бинарников нет ?

На, смотри сам: http://rouse.drkb.ru/tmp/ProcessMM.zip

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

Кстати раз уж у тебя ХЕ3 на руках есть, то мог бы и проверить собирабельность. А то я там лимит ХЕ4 поставил, на которой и пишу...

> На, смотри сам: http://rouse.drkb.ru/tmp/ProcessMM.zip

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

> только куда смотреть то ?

Смотреть в сторону TEB, фильтруй по Tread (вверху) и в нижнем поле выбирай нить (TEB обычно в самом низу распологаются).
Если у тебя 32 бита, то смотри "Thread Environment Block", если 64 бита, то там у тебя их будет по 2 штуки на каждую нить (для 32 битного процесса).
Выделяешь через ПКМ и там свойства региона.

> и это... ты строковое описание полей сам что ли даёшь ?
> если да, то откуда берёшь

Да сам, выдергивал из символов (про которые тебе говорил ранее)

ЗЫ: ес че, это просто демка для вот этой статьи: http://rouse-debug.blogspot.ru/2013/10/blog-post.html

Я собственно её сейчас и пишу...

> Rouse_ © (05.11.13 18:19) [37]

Розыч, в чём наши точки зрения различаются
Ты считаешь, даже в рамках Win32 различается. Более того одни и те же поля могут и перемещаются на разные смещения в TEB в зависимости от версии Windows. Если я наврал - скажи.

Я предполагаю, что сама структура строго не регламентирована, расширяется, но имеет на Win32 режим обратной совместимости. Т.е. условно говоря на какой-то ранней версии Windows поле было вообще никак не помечено, а в современных версиях детализация полей и размер самой структуры - больше.

Я обнаружил определённые поля, названные UserReserved, которые занимают 20 байт на Win32 в диапазоне 0x700 - 0x714. Пытаюсь определить, константный ли диапазон имеют эти поля, и можно ли реально их использовать под свои нужды.

В свою очередь ты начал выводить логи. И я предположил, что это логи софта, который отслеживает занятые поля в TEB и индивидуально для каждой ОС выводит названия полей, зарегистрированных в ней. Т.е. условно говоря если мы занимаем поля из UserReserved[], то твой софт должен явно на это указать.

Теперь скажи, в чём я заблуждаюсь. И если твой (или другой твой используемый) софт с такой задачей справляется - прогони пожалуйста через него 2 моих экзешника: http://zalil.ru/34795905. Чтобы не было разночтений. Exe-шники как раз заполняют ожидаемую область.

Если конечно не сложно

threadvar, _GetTls, FS:tlsArray Найти похожие ветки