Do you know "pushad pushfd" ocmmand in x64 mode

[White]

Hi,all

 

We all know "pushad" command in x32 mode.

 

Like these:

  Quote

 

pushad

pushfd

mov eax,1

mov ecx,2

popfd

popad

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

Now I know these code needed to be modified.

Like 

  Quote

eax-->rax

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

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

 

Some examples will be nice if possible.  

 

[kao]

Use PUSHFQ/POPFQ

[White]

Hi, kao

 

Thanks for your reply.

this command,I found it in

http://ref.x86asm.net/coder.html 

row 9C & 9D.

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

 

 

http://www59.zippyshare.com/thumb/34044636/file.html

 

http://www59.zippyshare.com/thumb/10002642/file.html

 

http://www59.zippyshare.com/thumb/24901547/file.html

 

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 ?

 

[kao]

#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.

[White]

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

 

Thanks you soo much.

 

:) 

[mrexodia]

Hi,

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.

Greetings,

Mr. eXoDia

TitanEngine.rar

[White]

Hi,Mr.eXoDia

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.

  Quote

 

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.

[mrexodia]

@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

Greetings,

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.

TitanEngine.rar

[White]

@Mr.eXoDia

Thanks  for your additional help.Wiki is a good site.