# 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. – ismael_akez May 21 '19 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. – josh poley May 21 '19 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 – csanonymus May 22 '19 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. – bart1e May 22 '19 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 – csanonymus May 26 '19 at 18:32