Simulating printf

[Vortex]

Here is a well known code to simulate printf :

Code Select Expand

include     \masm32\include\masm32rt.inc

.code

printfX PROC C format:DWORD,arglist:VARARG

LOCAL buffer[512]:BYTE
LOCAL hHandle:DWORD
LOCAL BytesWritten:DWORD

    invoke  GetStdHandle,STD_OUTPUT_HANDLE
    mov     hHandle,eax

    invoke  wvsprintf,ADDR buffer,format,ADDR arglist
    push    eax

    lea     ecx,BytesWritten
    invoke  WriteFile,hHandle,ADDR buffer,eax,ecx,0

    pop     eax
    ret

printfX ENDP

END

Testing the function :

Code Select Expand

include Test.inc

.data

frmt    db '%s %d',0
str1    db 'This is test',0

.code

start:

    invoke  printfX,ADDR frmt,ADDR str1,1

    invoke  ExitProcess,0

END start

[qWord]

Unfortunately w[v]sprintf does not support floating point types.

[Gunther]

Unfortunately w[v]sprintf does not support floating point types.

right, but swprintf (with leading s) can be used for that.

Gunther

[qWord]

right, but swprintf (with leading s) can be used for that.

right, but in this case one could directly call printf/wprintf.

[Gunther]

right, but in this case one could directly call printf/wprintf.

of course.

Gunther

[Vortex]

wsprintf  and wvsprintf are useful functions exported by user32.dll Why MS didn't support floating point, that's very strange.

[TWell]

wsprintf  and wvsprintf are useful functions exported by user32.dll Why MS didn't support floating point, that's very strange.

Even ntdll.dll sprinft doesn't support float ?
In MS there must be those academic HardCore men's who want make things always in HandWork manner ;)
Real man doesn't need floats, just Budwiser 

[Gunther]

TWell,

Real man doesn't need floats, just Budwiser 

but the real Budweiser please, not that muck from overseas.

Gunther

[NoCforMe]

So you all are aware of what a big stink Micro$oft makes over getting you not to use this function, right?

Under "Security Considerations" for this function description, they say:

Using this function incorrectly can compromise the security of your application. The string returned in lpOut is not guaranteed to be null-terminated. Also, avoid the %s format -- it can lead to a buffer overrun. If an access violation occurs it causes a denial of service against your application. In the worse case, an attacker can inject executable code. Consider using one of the following alternatives: StringCbPrintf, StringCbPrintfEx, StringCbVPrintf, StringCbVPrintfEx, StringCchPrintf, StringCchPrintfEx, StringCchVPrintf, or StringCchVPrintfEx.

Myself, I just ignore all this hoo-hah and use the damn thing anyhow (but then, I'm not writing production code and don't have to answer to users whose systems might be corrupted because of my program). What do others think of this?

See the function description here.

[jj2007]

Myself, I just ignore all this hoo-hah and use the damn thing anyhow. What do others think of this?

We are assembly programmers, so we know exactly what our code does. You need to be actively dumb to cause a buffer overrun ;-)

(Personally, I only use Print - safe and versatile)

[sinsi]

You need to be actively dumb to cause a buffer overrun ;-)

Or actively malicious.

[Magnum]

right, but in this case one could directly call printf/wprintf.

of course.

Gunther

You are a man of many words. 

Andy

[Vortex]

Real men code in assembly. :) :) :)

[Gunther]

Hi NoCforMe,

welcome to the forum.

Real men code in assembly. :) :) :)

Right.

You are a man of many words. 

Andy

That's my style, Andy.  :lol:

Gunther