# How to calculate value inside stack segment (SS)

I have an assembly row which the following information:

``````EBP = 006FFB50
SS  = 002B
``````

When I looked on this row:

``````mov eax,dword ptr ss:[ebp+8]
``````

I assumed that EBP + 8 = 006FFB50 + 8 = 006FFB58.
But according to x64DBG, this is the result:

``````dword ptr [ebp+8]=[006FFB58]=006FFC98
``````

I don't understand how it was calculated.
Why `ss:[006FFB58]` is equal to `006FFC98`?

Registers `ss`, `cs`, `ds`, `es`, `gs`, `fs` are special. They are called segment registers and contain not addresses but selectors.

A selector is used by the CPU as a reference to a segment - area of memory with a specific base (start address), limit (end address) and permissions.

Selectors and segments are set up by the OS and in theory there may be many different segments, however in practice all modern OSes use flat memory segments (0 to 0xFFFFFFFF for 32-bit processes) for the standard code and data segments (`ss`, `cs`, `ds`)1. This means that in the expression `ss:[ebp+8]`, only the value of `EBP` is used for calculating the address. In your case it is indeed correct that

EBP + 8 = 006FFB50 + 8 = 006FFB58

which matches the value shown in brackets.

However, the value after the `=` sign in the debugger is not the result of the calculation but the value which is present in memory at that address. If you open a memory dump and go to address 006FFB58, you should see `006FFC98` there.

The brackets in the debugger hint signify memory dereference, similarly to the assembly syntax.

1 `gs` and `fs` are treated differently and are usually used for Thread Local Storage (TLS) block which is different for every thread and does not start at 0 so e.g. fs:0 does not map to the RAM address 0.