So I've tried a few searches (using the search feature, not "browse-searching") and came up empty-handed. I'm wondering, is there a set of API include files for 64-bit Windows around somewhere? What I'm specifically after are API files like advapi64.inc, kernel64.inc, shell64.inc.

Basically, I'm looking to detour some crypto API calls to test an idea I had on helping protect against ransomware but I need 64 bit APIs to make sure it runs on 64-bit systems. I saw in the equates folder there are structural equivalences, but there's no API folder for 64-bit architectures. I did find a library someone wrote called z77 that mentioned it supported crypto but the link was defunct and I can't download it to look at it. Surely, I must be missing something, because I can't be the first person looking to use cryptographic functions on a 64-bit platform using fasm. Because I feel like I'm missing something, I'm going to ask something that I was pretty darn sure isn't the case but does the 32-bit stuff jut work on the 64-bit either through macros, or 32 to 64 bit address translations, etc? My feeling is it wouldn't; the datatypes of the parameters would have to be different. I say that because the API calls are nothing more than calling functions coded in the DLLs that come with Windows and SURELY those must be coded different. I gotta be missing something...

The include file "ADVAPI32.INC" has all the crypto APIs. It works with both 32bit and 64bit.

Really? So if someone were using, for example, Visual Studio and built an exe under the 64-bit arch config, making it a native 64-bit program (not a 32-bit program running on a 64-bit platform), I could hook those 32-bit function calls and it would hook the very same routines that native 64-bit program were using?

EDIT: Fixed a typo (and -> an)

Yes. The WinSxS system handles all of the DLL loading complexities.

gotcha, thanks!

In case you are not aware, Windows loads different DLLs (with the same names) for different programs to support things like 32/64 bitness and also for supporting run-in-XP-mode and other things like that.

I'm somewhat familiar with the Windows side-by-side system, but I always thought that was basically so each program can have its own set of libraries it loads. Solving the uninstall-breaking-other-programs'-dependencies issue back before the system was put in place. I didn't think it handled address translation as well.

It doesn't. It just loads different DLLs for different programs. For example when a program links to kernel32.dll the SxS system will load in just one of the set of binary files that provide the functions for the programs requirements. This allows each program to only need to reference just one name "kernel32.dll" and the system decides which one of the many kernel32.dll files it will load for that program.

Oh. Then it's exactly what I thought it did

I also realized I think we may discussing two slightly different things -- not sure why I didn't catch it sooner; tired I guess... I'm looking to do a global hook as that's the only way it would work. I'm not sure where Windows SxS fits in. Just to kind've make sure we're on the same page, you're saying that fASM can be used to generate a native 64-bit exe that uses the 64-bit versions of those functions? Let me ask this, maybe it'll help; where is the 64-bit version of, for example, CryptAcquireContextW located? Surely not advapi32.dll? the 32-part indicates those are the 32-bit functions or did they roll the 64-bit stuff in with the 32 bit stuff and leave it as one file for some sort of compatibility? The Microsoft CNG (Cryptographic Next Generation) stuff is mostly implemented in bcrypt.dll and ncrypt.dll since Windows Vista. So I dunno, maybe that's what I should be looking into... ::confused::

I'm not actually looking to side-load DLLs, I'm looking to write a native 64-bit exe that performs a global hook (which also raises the question, does the global hook still work if another application has it's own DLLs packaged with it) on a few of the 64-bit cryptographic functions that are loaded in user mode. What I'm thinking is, if anything, Windows SxS will actually cause me headaches. If an application is allowed to use it's own DLLs, all those functions are loaded into the process's memory (detailed, likely, in the PEB) which is not the same area as where advapi32.dll is loaded globally by Windows when it starts. So if anything, Windows SxS will cause headache more than alleviate them.

Yes, it does. There many examples of 64-bit programs on this board. No it can't. If a program has a private DLL then by definition it is not global. That is not the fault of SxS. If a program has its own DLLs then advapi32.dll could be completely ignored and the system would never know or care.

ETA: A program can also have its own crypto functions in the core exe without needing any DLLs, so there is no guarantee that you could ever use a DLL hook to catch all usage of crypto.

See I had always believed they were 64-bit programs, but using 32-bit functions, much in the same way that a full 32-bit through-and-through application can be allowed to run on a 64-bit system. Interesting. I'll have to check them out; thanks!


Yeah, that's kind've what I thought. Unfortunately, that DEFINITELY throws a serious curveball in how I was hoping to solve the problem.


Well no. I agree. It's just it sounded like, and maybe I interpreted what you were saying incorrectly, that you were implying Windows SxS s what would make what I wanted work. From my idea's standpoint, it creates problems for it. But I agree, it is operating the way intended. Because, basically, even if I were to set up a global hook, if a program loads it's own version of those DLLs, the hook is completely bypassed. I'm going have to go back to the drawing board a little I'm thinking :/ But I'd rather it now then deep into coding and realize it then.

Thanks btw!

It is an unfortunate naming artefact that the file named "kernel32.dll" is actually a 64-bit DLL when linked by a 64-bit program. And, more sensibly, it is a 32-bit DLL when linked by a 32-bit program. Same name, different bitness.

... *mind kind've blown*... I mean I guess it makes sense in hindsight now. Because if it weren't that way, then there'd have to be a kernel64.dll or something. I guess I just never really thought much about it. OH. That's where the SysWOW64 folder comes into play huh? They are literally the 64-bit versions of the 32-bit files. I never really noticed it because they also had the 32-bit parts in their names. Which you'd think the 64-bit ones would actually be named with the 64 qualifier in it.

What scenario would require a 64-bit program compiled as 64-bit to look for it's 64-bit DLLs to be named the same as the 32 monikers? The only logical explanation I can come up with is the filenames are hardcoded somewhere in the MSVC Runtime Libraries and they can manipulate what bit DLLs get used outside of the compiled DLL by playing the games MS typically does, softlinks (in the case of My Documents and Documents, the library feature, etc.), moving files around various directories, etc. But if they change the filename in the source code of the runtime library, they would then have to go into the code and add conditionals depending on the architecture.

Hehe, well kind of. Actually the system32 folder has the 64-bit files and and syswow64 folder has the 32-bit files. I guess that makes sense to someone at MS.

lol. Can't make this stuff up

Yeah, it probably made sense to Balmer

I almost typed I think it's starting to make sense. What I mean to type is, I think I'm starting to understand it.

Thanks!