search

JustasMasiulis / lazy_importer

library for importing functions from dlls in a hidden, reverse engineer unfriendly way
Apache License 2.0
1.65k stars 222 forks source link

C++03 compatability #1

Open Mecanik opened 6 years ago

Mecanik commented 6 years ago

Amazing library, but it seems "too good to be true"... Does it work on OS starting XP and above ?

I`m asking because many things were added starting VISTA, and it would be nice to know if this library has any dependencies regarding OS.

JustasMasiulis commented 6 years ago

I wasn't sure myself so simply installed windows XP on a VM. test image

Because it works fine on win XP and on latest windows 10 I'd pretty confidently assume that it will work on vista and others too. However windows xp toolset on visual studio was missing quite a few headers so you might need to trim down the #includes and do some find -> replace all but this might have been a fault on my side by using an existing project and changing up settings a bit instead of creating a new windows xp one.

Mecanik commented 6 years ago

Thanks, I will test as well on all the versions on multiple functions.

Mecanik commented 6 years ago

On this note, I can only compile and use this using VS 2017, 2015, 2013 ( + xp ) always fails. Might be some dependencies ?

JustasMasiulis commented 6 years ago

Yes, for XP there might be some changes needed to be done like remove and adding your own offsetof (which I wouldn't recommend on non MSVC compiler as they use intrinsics) however besides that only minor changes should be needed.

Mecanik commented 6 years ago

I don't think that's the only reason, I tried different versions of VS, none of them can compile. Only VS2017, and I think it's something to do with "constexpr"/c++11 I'm not sure. The errors are as following:

lazy_importer.hpp(319): error C3249: illegal statement or sub-expression for 'constexpr' function
lazy_importer.hpp(329): error C3250: 'value': declaration is not allowed in 'constexpr' function body
lazy_importer.hpp(333): error C3256: 'value': variable use does not produce a constant expression

I tried looking up on this on google, but I cannot find much - other that neither VS 2013/2015 supports "constexpr".

It would be great if your library would work lower than VS 2017.

JustasMasiulis commented 6 years ago

the library requires c++14. I'll look into what I can do about those errors, but that might take some time.

Mecanik commented 6 years ago

I see, c++14, well as I said if it's not impossible to have backwards compatibility that would be AWESOME.

Plus, it might resolve a lot of problems regarding XP for example. ( why do people still use XP ... ).

Thanks for all the effort.

JustasMasiulis commented 6 years ago

I will get it to work on VS 2015 soon which will probably include any c++11 compliant compiler, but I don't think that it is worth for me to port everything to any lower standard like c++03.

Mecanik commented 6 years ago

Yes indeed, VS 2015 (+XP) would suffice at least. However on this note, would it be possible to make work under VS 2013 - and if so, how much time/budget ?

JustasMasiulis commented 6 years ago

VS 2015 should work now. I might make a branch for XP support because as I said that would require rewriting offsetof which other compilers implement as an intrinsic. As for the c++03 I'd guess I would need to heavily rework compile time string hashing and use some macros to get rid of newest keywords which is quite a lot of work.

Mecanik commented 6 years ago

Alright then, got it. I will test your latest push right now, thank you!

Mecanik commented 6 years ago

It compiles and works great. Many thanks for your effort, I will test again on all OS.

JustasMasiulis commented 6 years ago

Sadly c++03 isn't really possible because there is no way to reliably hash strings at compile time. I might be able to work out some errors for VS 2013 which at least supports variadic templates, but won't really go lower as it isn't exactly useful.

Without the hashes being compile time I'd have to rewrite a large portion of the library code which would take me at least an hour or 2 + the time it will take to make the hashing semi-reliably compile time on release builds.

Mecanik commented 6 years ago

I would gladly help you if I could... I think for now even VS2015 is amazing to have.

Mecanik commented 6 years ago

I forgot to ask, and I do not want to create a separate "issue" for this...

How does this work with functions like "wsprintf", "fopen", etc ? Would it be okay to use it like so:

LI_FIND_CACHED(wsprintfA)

Because I have so many functions like this, would be great to use it.

JustasMasiulis commented 6 years ago

As long as they are exported - sure. ntdll has vsprintf, sprintf, memcpy etc

Mecanik commented 6 years ago

Thanks, that's great. I am just worried about what you stated:

LI_FIND[_DEF][_CACHED](function) Iterates trough all modules and their exports.

I mean, if it iterates though EVERY module loaded and their exports... that can affect performance pretty bad I guess.

JustasMasiulis commented 6 years ago

You can use the cached functions if you are ok with putting a variable in data section.

Mecanik commented 6 years ago

putting a variable in data section - what do you mean?

JustasMasiulis commented 6 years ago

The cached versions use a static variable so they do only 1 lookup. Because of that the variable will be placed into the data section inside your executable.

Mecanik commented 6 years ago

To be honest I have not even noticed that in my data section, is it ".gfids" ? I myself wouldn't mind if it's encrypted or something, because it favors speed.