I wonder if these fuckers just skipped using the windows DLL loader and wrote their own so they could use them on win32?

oh goody, they're not using the regular CreateFile

they're using _lopen. The 16-bit windows compatibility one!

and CreateFile.
they use both. fun!

see the cool thing about reversing 32bit or 64bit code is that it's not segmented, so when you look in your debugger and it says it's running a function at 0x004013cc, you can go over to ghidra and type in "0x004013cc" and it'll show you that same function!

this may seem "boring" and "mundane" and "how debuggers always work?" but just imagine you have lost that simple ability to compare code between the two programs?

that is the horror of 16bit segmented code

I've been doing too much GBA reverse engineering. I saw a 32bit pointer starting with 0x02 and tried to remember if that was on-cartridge RAM.

this is a /windows/ program. on windows 10.

THERE ARE NO CARTRIDGES!

now let me copy this program onto this SD card in my laptop's built-in SD card reader

yeah this is some windows 3.x-ass code. They definitely recompiled it as 32bit and did all the changes that required, but the general feel of the code is that it's 3.x code, with how it handles most things.

WHAT IN THE BORLAND TURBO C PLUS PLUS IS GOING ON HERE?

Ghidra is better at reversing MSVC-style arguments than Borland-style. Makes sense. Probably not a lot of Evil Malware written in Borland Turbo C++ these days

What happened: I'm looking at a function that's clearly a strcmp of some kind. It seems to compare against a length, so... strncmp? looks like it, except it takes FOUR ARGUMENTS?! what could this be?

I look at several variants of strncmp to see if there's a 4-argument version, then give up and look back at ghidra's decompilation: it never uses argument 1.

there's some nonsense going on here with pascal calling convention but I think I'm too tired already to figure out the exact details well enough to explain it.

but the bottom line is that it's not a 4-argument function, it's a 3-argument function. the decompiler just didn't get the calling convention exactly right.

so I live another day, safe from the horror that is the 4-argument strcmp.

what does it do? how does it work? I don't want to know.

I figured out the hypothetical 4-argument strcmp:
it's a locale-specific strnnicmp.

That's stricmp (compare insensitively) and also strncmp (compare only the first n characters), but with TWO LENGTHS! Why? To compare two strings of different lengths, case-insensitively.

and you might say "why would you compare two strings you know are of different lengths, of course they're not equal"

Well, if the compare is case insensitive, they might still match... in a german locale!

To greatly oversimplify, the german letter "ß" is lowercase, and in uppercase you write it "SS".

So if you have two strings, one reading "straße" and one reading "STRASSE", they are different lengths (6 vs 7), but case insensitively comparing them should return a match.

Try it out on your local javascript console:

>> "Straße".length
6
>> "Straße".toUpperCase().length
7

so yeah hypothetically if you had a version of stricmp that was strncmp and compared two strings of different length, this might still be a match, if your locale treated the German Eszett this way.

enough writing about FICTIONAL C LIBRARY FUNCTIONS, what the hell writing brain, let's get back to reverse engineering

someone should write a fictional programming library reference book.

like, fit enough interesting ideas in about what the fictional world needs functions for, worldbuild in the cracks, but stay clearly still a dry list of man pages?

writer-brain grabs the mic:
C'S MEMORY HANDLING IS SO BAD IT CAN BE EXPLOITED BY THE GERMAN LANGUAGE ITSELF

the funniest part? I'm back in reverse engineering mode.

it's not even a 3-argument version of strcmp. it's just a weird strcmp(char*,char*): It only takes two arguments! not even three!

how do you confuse a two-argument function for a FOUR argument function?

borland. borland is how you do that.

DirectSound?!

this windows 3.x-ass program uses DirectX?!

haha, 1991-1997 programmer: you made the LoadDirectSoundFuncptrs return a 0 for success, but you only ever return 0. your code smells with your bad decisions, which I can see THROUGH TIME from 30 years later

you even check, in the calling code, that it returns 0 and not some other value. you have fallback code for if it fails.
it can't fail.

correction, you're returning a boolean.

and it's hardcoded to always return a 0, which is false.

so this ALWAYS fails.

I'm guessing this is dummying out code that didn't work

yeah this code is just casually mixing pascal and stdcall calling conventions. I am in hell

okay yeah. this is not remotely delphi. this is C++. ghidra mis-detected it, and that may have messed up the analysis

yep and it's buggered every single function, even after changing language. I can delete and recreate functions, but that might not fix them because they're getting hints from downstream functions which it still thinks are __fastcall and not __stdcall

maybe I just need to delete every function and re-analyze from scratch

(i just re-imported the EXE as a new file, and I'll manually port over the dozen or so symbols I've found.)

BTW it turns out there's cheats in the windows version.

maybe in the other versions too? I don't think anyone has found them if so.

https://www.speedrun.com/super_solvers_gizmos_and_gadgets/forums/vcalv

I spotted them in the EXE and googled to see if they were known. Yep. At least in that one post!

ah-ha!

see that?
They call GetVersion(), then no matter if it's below 4 or not, they jump to the SAME PLACE, and there's dead code below it.

This EXE has been patched after compilation!

yeah the EXE has a modification date of 1998, but the compile time inside the EXE says 1994