All standard library functions and FASM headers

Index > Main > All standard library functions and FASM headers

Goto page 1, 2 Next

Author

Thread

Mino

Joined: 14 Jan 2018
Posts: 163

Mino 31 Jul 2018, 07:50

Hello,
Are all C functions accessible under FASM, or are they not all available? I looked a little in the FASM files, but I can't find features such as printf, gets, ExitProcess, ... I guess, in this case, they're somewhere else. But where? And how would I know what functions there are? If there was somewhere a documentation on the subject, or a list of C functions, it would be useful to me Smile

Maybe it's in a DLL that's already in the OS... I don't know...

I would also like to know if most of the functions usable under Windows under FASM are also usable under Linux?

Thank you in advance!

_________________
The best way to predict the future is to invent it.

31 Jul 2018, 07:50

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 31 Jul 2018, 10:36

MSDN gives insight on functions provided by Windows. Nearly every function description there contains a note about the DLL the function resides in.

С functions are part of C library. If the library is available as a DLL (say, msvcrt is an MS implementation), the functions become available. Also, equivalents of basic functions like strlen, strcpy, etc. are available from Windows itself without the need to tie your assembly program to a runtime for particular HLL.

31 Jul 2018, 10:36

Mino

Joined: 14 Jan 2018
Posts: 163

Mino 31 Jul 2018, 11:18

Okay, thanks a lot, I'll check MSDN.
As for Linux, I guess it's not the same thing, is it?

31 Jul 2018, 11:18

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20445
Location: In your JS exploiting you and your system

revolution 31 Jul 2018, 11:23

Mino wrote:

Are all C functions accessible under FASM, or are they not all available? I looked a little in the FASM files, but I can't find features such as printf, gets, ExitProcess, ...

Note that ExitProcess is an API provided by Windows OS, it is not a C function. But the other two, printf & gets, are C functions provided by some HLL interface layer.

31 Jul 2018, 11:23

Mino

Joined: 14 Jan 2018
Posts: 163

Mino 31 Jul 2018, 15:26

Thank you for the information Smile

I think I can then say that everything in kernel32 (ExitProcess API DLL) are Windows APIs, is that true?

31 Jul 2018, 15:26

Furs

Joined: 04 Mar 2016
Posts: 2559

Furs 31 Jul 2018, 15:28

Mino wrote:

Thank you for the information I think I can then say that everything in kernel32 (ExitProcess API DLL) are Windows APIs, is that true?

Yeah.

For C functions look at importing msvcrt.dll

Note that msvcrt uses cdecl calling convention, not like the rest of the Windows APIs which are stdcall.

31 Jul 2018, 15:28

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 31 Jul 2018, 18:41

Furs wrote:

Note that msvcrt uses cdecl calling convention, not like the rest of the Windows APIs which are stdcall.

Is msvcrt.dll actually considered part of Windows API? I really doubt so. Just nitpicking…

31 Jul 2018, 18:41

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20445
Location: In your JS exploiting you and your system

revolution 31 Jul 2018, 19:15

DimonSoft wrote:

Is msvcrt.dll actually considered part of Windows API?

No it isn't part of Windows. It is part of the C redistributable. MS like to include it with Windows because they can.

31 Jul 2018, 19:15

Mino

Joined: 14 Jan 2018
Posts: 163

Mino 05 Aug 2018, 10:28

Furs wrote:

Note that msvcrt uses cdecl calling convention, not like the rest of the Windows APIs which are stdcall.

Does that mean you have to use a macro to use a procedure? Can't we call, for example'printf' without cinvoke, stdcall, ...? Like this for example:

Code:

mov word edi, [msg]
call printf

_________________
The best way to predict the future is to invent it.

05 Aug 2018, 10:28

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20445
Location: In your JS exploiting you and your system

revolution 05 Aug 2018, 10:55

You don't have to use any macros. They are only there to help you. If you want to call a ccall function manually you can do this:

Code:

push text
call [printf]
add esp,4 ;ccall requires the caller to adjust the stack

05 Aug 2018, 10:55

Mino

Joined: 14 Jan 2018
Posts: 163

Mino 05 Aug 2018, 11:38

That's good to know, thanks Wink

But why should we call printf into hooks [printf] ? Don't the hooks represent the address of the object in memory?

05 Aug 2018, 11:38

Ali.Z

Joined: 08 Jan 2018
Posts: 732

Ali.Z 05 Aug 2018, 11:43

https://en.wikipedia.org/wiki/X86_calling_conventions#cdecl

_________________
Asm For Wise Humans

05 Aug 2018, 11:43

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 05 Aug 2018, 12:06

Mino wrote:

That's good to know, thanks
But why should we call printf into hooks [printf] ? Don't the hooks represent the address of the object in memory?

printf is actually a label to a dword in import data that gets replaced with actual function address by Windows executable loader. So, when calling imported functions we actually have to take the value stored in import data and use it as target address.

05 Aug 2018, 12:06

Furs

Joined: 04 Mar 2016
Posts: 2559

Furs 05 Aug 2018, 20:53

Mino wrote:

That's good to know, thanks
But why should we call printf into hooks [printf] ? Don't the hooks represent the address of the object in memory?

Except for the lea instruction, the hooks "dereference" what's inside the brackets. So [ebx] is like *ebx in C if ebx was a pointer. lea is the only special instruction here that is like writing &*ebx (i.e. no dereference).

printf, as DimonSoft mentions, is a label that has the address of a pointer in the IAT (Import Address Table). Basically, printf is a fixed address (relative to the base of your executable/dll) that points to a pointer which gets set on load by the application loader, to point to the imported printf. Since you don't know where printf will be loaded, this way you just refer to that pointer that the loader will substitute with its address on load.

So yes, it's an "indirect" call.

05 Aug 2018, 20:53

Mino

Joined: 14 Jan 2018
Posts: 163

Mino 05 Aug 2018, 22:02

Thanks, I understand better now Smile

Is it exceptionally because these are functions that come from Windows APIs, or does it often happen in other APIs? How do I know if I should use the hooks or not?

05 Aug 2018, 22:02

Ali.Z

Joined: 08 Jan 2018
Posts: 732

Ali.Z 05 Aug 2018, 22:06

any call to any module would require [] whether winapi or your dll
unless its a label in your module

05 Aug 2018, 22:06

Mino

Joined: 14 Jan 2018
Posts: 163

Mino 05 Aug 2018, 22:28

Okay, thanks Smile

05 Aug 2018, 22:28

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 11 Aug 2018, 22:39

revolution wrote:

DimonSoft wrote:
Is msvcrt.dll actually considered part of Windows API?
No it isn't part of Windows. It is part of the C redistributable. MS like to include it with Windows because they can.

rev, you know tons about Windows development, apparently, while I don't even pretend to grok any of it. But ....

Are you absolutely sure? I'm pretty sure that MSVCRT.DLL has been an integral part of the Windows default install since a long time (Win95 OSR 2??). At least, since 2k/XP, it has been included by default. That doesn't mean all (or many?) bundled Windows apps relied upon it. I honestly don't know what required it.

But it's considered a "known .DLL" since 2k/XP, so you can't override it on a local level with a replacement (AFAIK). And of course .EXE outputs from several compilers (e.g. MinGW, TinyC) rely on it always being there. And yes, newer MSVC redistributables exist (too many, in fact, ugh: try typing "where msvc*.dll").

So I would definitely say "yes, it's part of the OS", but feel free to correct me as I don't really program for Windows.

11 Aug 2018, 22:39

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20445
Location: In your JS exploiting you and your system

revolution 11 Aug 2018, 23:44

Yes, MSVCRT.DLL has been included with Windows since forever. But it isn't part of the Windows system. It is just an interface DLL for programs written in C to be able to use the C standard library functions when running in Windows. If you want to read the documentation for MSVCRT you have to go to the C related pages to see how to use it. The normal Windows documentation doesn't address it.

11 Aug 2018, 23:44

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 12 Aug 2018, 09:26

rugxulo wrote:

And of course .EXE outputs from several compilers (e.g. MinGW, TinyC) rely on it always being there. And yes, newer MSVC redistributables exist (too many, in fact, ugh: try typing "where msvc*.dll").

And this makes it a headache to write in C/C++: you should always remember to either turn on the static linking option for the standard library or to ship the DLLs along with your program. Some developers don’t bother which makes them as bad as .NET developers: .NET developers also think .NET is a part of Windows that is also there which is also wrong.

12 Aug 2018, 09:26

Goto page 1, 2 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum