# GetProcAddress with 0 as lpProcName

I'm reversing a 32bit binary for a challenge I got at a college lab and I'm having a hard time trying to understand the intent of the asm code.

The binary is a 10 level reversing game where you get no info at the start and have to figure out everything on your way on building a flag at the end.

Basically it uses a lot of encryption techniques to derive strings from integer values (as far as I got). I figured out some of the imports it uses like LoadLibraryA, GetProcAddress (I guess it uses them later on somehow).

Where I'm currently stuck is the asm code calls GetProcAddress with kernel32.dll handle as the first argument and 0( or NULL I guess ) as the second argument. The return I get is then used to make some integer division. My problem is that I get NULL from the GetProcAddress call and then when hitting the idiv, I get a Division By 0 Exception thrown.

Here's a picture:

On 0x00401A85 eax is 0(NULL). Any ideas on how to solve this? What's the idea behind passing 0(NULL) as the second parameter?

Thanks!

• It might be an (0)ordinal number, but it might thrown exception by dividing to zero, in that case, check if there is an SEH. May 21, 2019 at 14:07

Turned out it was just a trick inserted in the code to distract us. What can I say, it was very successful haha. I ended up asking my teacher and he told me to try and avoid getting into that part of the code and after that I was able to see my mistake. Definitely learned something by falling into that trap

lpProcName

The function or variable name, or the function's ordinal value. If this parameter is an ordinal value, it must be in the low-order word; the high-order word must be zero.

Here the second parameter is an ordinal value. This may be done intentionally to hide the function name that the program imports. According to Wikipedia: DLL:

Each function exported by a DLL is identified by a numeric ordinal and optionally a name. Likewise, functions can be imported from a DLL either by ordinal or by name. The ordinal represents the position of the function's address pointer in the DLL Export Address table. It is common for internal functions to be exported by ordinal only. For most Windows API functions only the names are preserved across different Windows releases; the ordinals are subject to change.

To get the function name first see the DLL file name in LoadLibrary() or LoadLibraryEx(). Open that DLL in IDA. Go to View Menu > Open subviews > Exports. Or use dumpbin /exports mydll.dll command to list all the exported functions and their corresponding ordinals. See dumpbin reference for further details.

• kernel32.dll typically has an Ordinal Base of 1, which means an ordinal of zero would be invalid. May 21, 2019 at 15:27
• Yes, @joshpoley, that's what I also found.. And then division crashes my program. I'm not sure yet if I'm on the right path. I asked my teacher for some guidance and he told me to look more into error handling and debugger evasion techniques which I found an example here: autosectools.com/Anti-Debugging-With-Exceptions.pdf May 22, 2019 at 14:23
• Using exceptions may be a way to detect debuggers. However, you should have the possibility to pass the exception to the application when debugger receives it. I would give it a try, if such anti-debugging technique is present in code you are analysing. That way, the application will receive an exception as it expects and won't realise that it's being debugged. May 22, 2019 at 19:27
• Turned out it was just a dead end inserted in the code as a trick to "eat" out time out.. My teacher gave me a tip into trying not to get in that area of the code and I was able to solve it after that May 26, 2019 at 18:32