Jump to content
Tuts 4 You

Do you know "pushad pushfd" ocmmand in x64 mode


Recommended Posts



We all know "pushad" command in x32 mode.


Like these:




mov eax,1

mov ecx,2



Do you know how to use these code in x64 mode ?

Now I know these code needed to be modified.



pushad -> push rax.......rdi.

But how to convert "pushfd" command ? This make me confused. -_- :( :(


Some examples will be nice if possible. :) 


Link to comment

Hi, kao


Thanks for your reply.

this command,I found it in


row 9C & 9D.

I use exodia's x64_dbg to vertify that it is correct or not.But I got strange point.See pics.









AS you see,

Pic 1, before execute "pushfq" cmd,the rflag is 10200.

Pic 2, after ,it is 202,and pushed a value 302 ?

Pic 3, restore,it is 202,and pop out 302.

And all, the rflag is not 10200 any more.


Is there something wrong with my operation or exodia's x64_dbg ?


Link to comment

#1 - 0x10000 is "resume flag", it has to do with exceptions and debugging (you can Google for more info, but it's really complicated stuff). In general, this flag shouldn't be set. Also, when I'm loading program in WinDbg and it stops at entrypoint, I'm seeing value 0x246. So, it could be x64_dbg bug or it could be "normal" and expected. Could you try loading your program in WinDbg and see what happens?

#2 - 0x100 is a trap flag, it gets set when you're single stepping code. If you try to run all that code instead of single-stepping it, it should be 0x202's everywhere. Also, no other debugger is pushing trap flag when stepping through code (I tried WinDbg for x64 and Olly for 32bits). So, I'd say this is bug in x64_dbg and can be used as an anti-debug trick.

  • Like 2
Link to comment

yeah.spent a lot of time searching,finally got useful infomation  and use Windbg to traced several files.


Thanks you soo much.



Link to comment


In x64_dbg, when there is a breakpoint set on PUSHFQ/PUSHFD, it would set the trap flag, meaning x64_dbg would be detectable in some cases. However I immediately patched it inside TitanEngine, please try the attached build if you're interested.

Oh, about the resume flag, that was a remainder of TitanEngine's golden *cough* days, immediately removed it, as it seems to serve no purpose whatsoever.


Mr. eXoDia


Link to comment


I have downloaded your fixed TitanEngine rar,and replace it in x64_dbg folder.I found that at system breakpoint, the efalg is 202 in Ollydbg and your x64_dbg and Windbg.

F9,stop at Entrypoint.the eflag is 200 in x64_dbg,but Ollydbg's is 246 like Kao said.And execute that command,ollydbg don't change the efalg.


Now it changes.


1, before execute "pushfq" cmd,the rflag is 200.

2, after ,it is 202,and pushed a value 202

3, restore,it is 202,and pop out 202.

Link to comment

@White: I don't really know what's going on here. On my side you have:

system breakpoint: 246ep: 244after pushfq: 246
You should try changing the EFLAGS in olly from 246 -> 244 and then pushfd, you will see that the 'reserved' (bit 1) will always be set (http://en.wikipedia.org/wiki/FLAGS_register) I don't think this is documented behavior, but since it's a reserved flag it can do anything it likes :)

Also check out this, it might be related to the WinAPI: http://stackoverflow.com/questions/22777727/x86-reserved-eflags-bit-1-0-how-can-this-happen


Mr. eXoDia

PS The attached TitanEngine also fixes various possible detections when there are hardware/memory breakpoints that land on a PUSHFD/PUSHFQ instruction. Also hardware breakpoint are now restored properly.


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...