pauliwago
pauliwago

Reputation: 6685

How does sscanf work? (in assembly)

I'm in the process of trying to decode some assembly code generated from a binary. There's a call to the sscanf function in the code:

 400f08:       e8 13 fc ff ff          callq  400b20 <sscanf@plt>
 400f0d:       89 45 fc                mov    %eax,-0x4(%rbp)

Can you tell me how sscanf works in assembly? I'm pretty sure the number of arguments is stored in %eax....does it push the input into the stack in reverse order? So say my input is 0 1, after running sscanf, %eax=2 and the stack looks like:

1
0  <----%rsp (top of the stack)

Is this correct? Thanks!

Upvotes: 4

Views: 17839

Answers (2)

ninjalj
ninjalj

Reputation: 43708

sscanf takes as arguments a string to scan, a format string, and pointers to variables where to store the results of the scan. So, your 0 and 1 numbers would be stored on the corresponding variables, assuming the scan was successful.

EAX contains the return value. The *scanf family of functions return the number of elements scanned successfully, so you can know if the scan was successful, and how successful it was.

Upvotes: 2

atomicinf
atomicinf

Reputation: 3736

Follow the calling convention of the platform, as normal. 32-bit Linux uses cdecl by default, which has you push all the arguments onto the stack in reverse order. 64-bit Linux uses the System V AMD64 ABI convention, which uses RDI, RSI, RDX, RCX, R8, and R9 for integers and address and the XMM registers for floating point arguments (with surplus arguments going on the stack).

The number of arguments isn't pushed anywhere; AFAIK sscanf determines this from the format string (though I'm happy to be corrected). The System V AMD64 ABI (64-bit) does specify that AL is used to store the number of XMM registers used (from 0 to 8), but that applies to floating-point arguments only (which should never be arguments to sscanf).

Upvotes: 3

Related Questions