flat assembler
Message board for the users of flat assembler.

Home Search Register
Log in to check your private messages Log in

Index > Windows > fs? TEB?
Author
Thread Post new topic Reply to topic
b1528932



Joined: 21 May 2010
Posts: 287
b1528932 19 Jul 2010, 19:30
fs register point to data segment in gdt (0x38).
Why when i try to access memory under TEB space, im getting diffrent results in each thread?

moreover, 0x38's base change in time... once its 0x7ffdf000, other time 0x7ffde000, and its not smp issue (both cores change this value).

when i try to access this by selector with base 0, im getting diffrent results. WTF!

what magic windows is doing there?
segment is present when i dump it. can someone explain me this?
Post 19 Jul 2010, 19:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20689
Location: In your JS exploiting you and your system
revolution 19 Jul 2010, 19:36
Set your thread affinities to lock them to a core.
Post 19 Jul 2010, 19:36
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932 19 Jul 2010, 19:44
its not core issue!
every single time my thread get diffrent data!


how do i check segment base from ring3? it would make trhings easier.
Post 19 Jul 2010, 19:44
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20689
Location: In your JS exploiting you and your system
revolution 19 Jul 2010, 19:48
Moving to Windows section since the subject doesn't involve fasm.
Post 19 Jul 2010, 19:48
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 19 Jul 2010, 19:57
GetThreadSelectorEntry

BTW, GDT or LDT? Anyway, do you realize that FS is thread-specific and clearly the base has to be different for every thread? Because of this it should not be really necessary to have a fixed base address for the main thread.

PS: 0x38 or 0x3B?
Post 19 Jul 2010, 19:57
View user's profile Send private message Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932 19 Jul 2010, 20:41
Code:
base: 7FFDD000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFDC000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFDA000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFDB000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFD9000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFD7000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFD5000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFAF000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFD8000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFD6000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFAD000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFAE000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFD4000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFAB000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFAC000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFA9000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFAA000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFA7000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFA8000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFA5000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFA3000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFA6000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFA4000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFA2000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FFA0000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FF9F000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FFA1000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FF9D000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FF9E000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FF9B000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FF99000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000
base: 7FF9C000, limit: 00000FFF, present: 1, GDTR: 3FF F7870190
base: 7FF9A000, limit: 00000FFF, present: 1, GDTR: 3FF 8003F000


done this test with few threads.

38 is the same as 3b, only rpl differ.


i found this be examinig getlasterror, first i though its a reace condition between threads.

do you know how does os implement this? 3b is a gdt entry, so segment base has to be changed with each task switch.

but as u can see in my example, gdt isnt changed, so thread scheduler updates gdt entry.

so each time i switch to another thread, GDT is being changed.
Post 19 Jul 2010, 20:41
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 19 Jul 2010, 21:13
Quote:
38 is the same as 3b, only rpl differ.
OK, but if we put this on this terms then we are talking of the 7th selector in the LDT (counting NULL).

Quote:
do you know how does os implement this? 3b is a gdt entry, so segment base has to be changed with each task switch.

but as u can see in my example, gdt isnt changed, so thread scheduler updates gdt entry.
Since bit 2 (Table Indicator) is on (0x3B is LDT selector with RPL=3), then you won't find the answer in the GDT. Check if you see LDTR changes from thread to thread.
Post 19 Jul 2010, 21:13
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 19 Jul 2010, 21:21
No wait, I made a silly mistake... You're right, it is GDT. If you say that GDT is not changed (and neither the entry in the table?), then I don't know how it is implemented.
Post 19 Jul 2010, 21:21
View user's profile Send private message Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932 19 Jul 2010, 22:12
No, entry is changed. my simple program reveals that. It execute sgdt in each thread, along with GetSelectorEntry.
you see that base is always diffrent, and gdt offset is always 8003F000 or F7870190.


i think the topic is closed, unless there is something interesting to add.
what about kernel mode? when i change privilege, i think os also change fs base to point to other structure.
Post 19 Jul 2010, 22:12
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 19 Jul 2010, 22:32
b1528932,

TEB is a per-thread structure, these structures are (usually) stacked starting somewhere near top of user address space (linear 0x7FFDF000 for my XP SP2, and IIRC 0x7FFDE000 on Windows 2000).

To provide uniform access to this structure, descriptor corresponding to fs selector is updated during context switch so fs:0 is the address of TEB for current thread. Naturally, each CPU core has its own GDT (BSP has it fixed, 0x8003F000 in your case, for each AP it's allocated dynamically).

TEB.Self member (fs:18h) contains linear address of TEB to simplify access to its other members (no need for segment override each time).

Last error code is per-thread too, thus it's [fs:34h].

In kernel mode fs points to KPCR.
Post 19 Jul 2010, 22:32
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Main index Download Documentation Examples Message board

Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.