I just compiled some C code that reads in input using gets and disassembled the code. The platform is Ubuntu 32-bit.

There are these 3 lines that check if the canary value has been tampered with.

   0x08048455 <+33>:    mov    edx,DWORD PTR [esp+0x7c]
   0x08048459 <+37>:    xor    edx,DWORD PTR gs:0x14
   0x08048460 <+44>:    je     0x8048467 <main+51>

I set a breakpoint on 0x08048459 and saw that the gs register had the value 0x33.

My questions are:

  1. What is gs:0x14 given that gs is 0x33? Is 0x33 an index to something? Is it a memory location of some sort?
  2. Are there any x86 instructions to move the value of gs to any other register? Or perhaps push it onto the stack?

1 Answer 1


Check the stack protection in the linux kernel source. The gs register gets initialized by the kernel to a percpu structure, which contains a random value that's intended to be used as stack canary. This stack canary is at offset 20 (0x14) for 32 bit programs. It's randomized for each process to avoid malware being able to rely on it being always the same value.

The 0x33 is actually an index into a table in the kernel, that you don't have access to, so it's quite meaningless from userland. The virtual memory that makes up the percpu structure is mapped to physical memory "somewhere" though gs and the kernel table index that gs maps to, but this physical memory is not mapped to any address that you can address 'normally', i.e. through the 'normal' cs/ds/ss segments.

When you google for segment registers, you might find some information that says "the segment register is shifted left by 4 bits, then added to the offset, to result in the real address", but that applies to real mode only. Linux has always used protected mode. You can find more detailed information about segments in real and protected mode here.

To read the value, there is a push gs instruction you can use. There's a pop gs as well. But as mentioned, knowing the value won't help you, and setting the value to anything will most likely result in a segmentation fault.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.