Win32 Dllmain

0 views

Skip to first unread message

Serafin Sonnier

unread,

Aug 5, 2024, 12:13:53 PM8/5/24

to ceilpurupsteph

Icreated a simple win32 dll to verify license using Turboactivate. However application runs locally but when i try to run in production, dll is getting initatiated but functions like TA_IsActivated(), TA_GenuineEx() are not able to execute in the production server. Application simply hangs while executing the above mentioned methods.

This works good in both local and production machines. License verifcation is doing good. But when comes to dll based license verfication it works locally and not in production machines (Tried various production machines results are same with the dll based license verification except the local)

When using TuboActivate static libraries you need to take care that you're not overwriting memory or including conflicting libraries. With the dynamic libraries you don't have to worry about that -- the dynamic libraries are more or less self-contained (it's more complicated than that, but that's broadly true).

So, what we need from you: a way to reproduce what you're seeing. Also, version numbers are very important when reporting problems (we don't know what OS version you're on, what version of TA you're using, etc. -- we can guess but that's not very useful).

Iam trying to create amibroker (www.amibroker.com) dll plugins using amibroker adk -development-kit-adk-for-cc-now-available-to-everyone/ and licensing it with LimeLM. Just to mention that Iam a junior when comes to VC++ coding.

When i tried to use Turboactivate dynamic libraries - Amibroker failed to load the dll. That forced me to try to static version of VC2015. With the static library Amibroker application is able to detect and load the dll. However this works good only with my local machine and remote machines amibroker hangs while loading the dll whenever the methods TA_IsActivated(), TA_IsGenuineEx(), TA_IsGenuine() are invoked.

One demo I've been attempted to get running underretrowin32, my win32 emulatorloads an external DLL to play its musicand, as best as I can tell from the disassembly, uses progress counters fromplaying the music to advance the graphical state. So while I didn't especiallywant to tackle DLL loading or sound, here I am!

In Windows, DLLs are PE files much like executables so loading one wasrelatively easy. The main wrinkle is that DLLs have their own DllMain() thatmust be invoked when the DLL is loaded for initialization purposes. Inretrowin32's architecture we previously started the CPU pointed directly at theexecutable's WinMain() equivalent, so it took me some effort to puzzle throughhow to layer things to invoke code in the proper order.

but I have no single emulate function like that; there is just an x86 CPU thatknows how to emulate basic blocks. In other words, the code I write in theemulator is ordinary synchronous Rust code, while emulated x86 code is invoked asubset at a time in a loop. But I needed to fundamentally solve this problem,because there are plenty of Windows APIs I'm implementing likeDispatchMessage() that need to synchronously call back into the executable'scode.

Ultimately what I wanted was coroutines and I managed to cobble somethingtogether with Rust's async support and the result feels pretty decent. Observehow I defineEnumDisplayModes as an async function and itmanages to await a call to a callback.

I'm pretty sure I didn't do it quite right but it seems to at least work for mylimited purposes. It feels like it might nicely generalize to cases whereemulated code wants to synchronously perform some operation that ends up asyncin the web platform (like reading files) but I haven't explored it too much yet.

In any case, once I had DLL loading roughly in place, I found this particularlibrary's initialization code performs some sort of self-check and fails with aMessageBox(): "This file has been tampered with and MAY BE INFECTED BY AVIRUS!"

What this actually points to is some bug in the emulator; running the program ona native Windows machine is fine. But how can I isolate the bug? Via adisassembler I can see that the initialization code runs a bunch of loops overmemory and at some point things go wrong ... but where?

I had been putting it off, but a friend earlier gave me the idea that I couldwrite a program that traces execution on a native Windows machine. That programcan dump state at various points, and then similarly make the emulator can dumpstate at those same points, and I could then compare traces between the two tofind where I diverge. So I wrote that program.

For extra fun creditI wrote it in Zig,which has a really pleasant cross-compilation story and which generates a tinyexecutable (23kb so far!). It's been pretty interesting how writing code in anenvironment where allocating memory is just a little bit less convenientnaturally leads you down paths where you don't wantonly allocate. One lasthighlight I appreciated is that Zig modelsSentinel-Terminated Pointersin its type system which was particularly important to get right when shovelingparsed command-line argument slices into calls into the Windows library thatwants NUL-terminated strings.

There are downsides too. Zig is basically a statically typed language with alarge compile-time component that is effectively dynamically typed. I think thisis a really fascinating tradeoff to explore but so far it has some pretty roughedges that I am not sure they will be able to solve, particularly aroundbuild-time tooling; much like writing Python, a lot of the errors you get are ofthe form "I ran a bunch of code and something went wrong" and there's not muchbetter it can do.(This blog post isworth your time.) For similar reasons it also feels relatively easy to createreferences to un-nameable types (like my stdout variable in the above). Thereare also plenty of smaller clunky bits (such as incomplete docs) but Iappreciate the language is in development and I'm not as concerned about thoseas I am about the fundamental model.

I hadn't before explored how a debugger works, so let me tell you theinteresting part. My program wants to say "when the CPU hits the instruction ataddress X, stop execution and let me do something". To do this you justoverwrite address X with an int3 instruction, which is helpfully just thesingle byte 0xcc (which also now possibly explainsmy old friend's choice of domain name). Once the programhits that address it suspends and hands control back to the debugger.

To resume execution, the debugger needs to repair the program by (1) writing theprevious code back over the int3, (2) backing up the instruction pointer byone to resume execution starting at address X, and (3) setting a CPU flag sothe CPU single-steps. This last part allows the debugger to single-step executethe repaired instruction and then immediately repatch it back to the int3 sothat it can intercept the next execution.

As a reward for reading this far, you can seethe demo in question rendersome graphics(click 'run' once it loads). This relies on the above async support for invokingsome callbacks (from DirectDraw back into the executable), but with the DLL bitsstubbed out because they don't work yet.

I've just updated from Gimp 2.8 to Gimp 2.10.8 on Windows 10. The installation goes fine, but when I run the programme, I get a series of error messages referring to missing dll files: libtiff3.dll

libgdkglext-win32-1.0-0.dll

glew32.dll

libfftw3-3.dll

liblar-1-0.dll

libpng15-15.dll

pcre3.dll

I believe these have to do with old plug-ins which I need to eliminate, then reload in the new compatible versions. But there are some 769 plugins listed in the plugin browser and I have no idea how to identify those causing the problems! Can anyone help? Many thanks in advance.