0

i have found the following code sequence in a sample which I try to analyze:

....
push offset LibFileName ;    "KERNEL32.DLL"
call LoadLibraryA
mov esi, eax
test esi, esi
jz short loc_40EDF2
lea edx, [ebp+var_108]
...
...
mov eax, offset aUmehyJ ; "UmehyJ{j"
push eax                ; lpProcName
push esi                ; hModule
call GetProcAddress_0

So, I know what the combination of LoadLibrary and GetProcAddress does. But what I do not understand is the following line:

mov eax, offset aUmehyJ ; "UmehyJ{j"

I would say that the process name is somehow encrypted. I searched a little bit and read that XOR-encryption in combination with a loop is frequently used in malware. So, I let IDA PRO search all occurences of a XOR and try to locate of course those with a register-immediate combination, for example xor eax, 12h. But I could not find something like this.

After that, I have read that Base64 encoding is also used in malware. So, I type the string "UmehyJ{j" in a online Base64 decoder tool ( http://www.opinionatedgeek.com/dotnet/tools/base64decode/ ) but without success.

So, now I am at a point where I do not know how I should make the next steps. Because of that, I hope somebody can help me.

best regards,

1 Answer 1

2

Yes, the function name appears to be encrypted.

You can double-click on aUmehyJ in IDA to see cross-references to the "UmehyJ{j" string: http://resources.infosecinstitute.com/ida-cross-references-xrefs/

This will allow you to find what code in the program decrypts the string before it is passed to GetProcAddress().

Alternatively, you can open your target in a debugger and place a memory-write hardware-breakpoint on the first byte of the "UmehyJ{j" string and wait for the breakpoint to be hit. This will allow you to find the code that decrypts the string.

4
  • yes, I have tried that, too. I marked "offset UmehyJ{j" and click Strg+X to get the cross-reference list of offset UmehyJ{j , but in the list the mentioned line with mov eax, offset UmehyJ{j is the only place where that string appears. There is no other reference to it. Commented Oct 31, 2014 at 18:58
  • Thanks for your comment. I've updated my answer above with an alternative approach. Commented Oct 31, 2014 at 19:03
  • hahaha...sometimes I could beat myself for my stupidity. I opened the program with ollydbg, go to mentioned place and then I see that ollydbg shows me the real name of the process. It is "RegisterServiceProcess". But thanks for your advice with the breakpoint. I´ve perceived it. Commented Oct 31, 2014 at 19:26
  • @user3097712 It's not process, it's address of the procedure. See on MSDN
    – 0xec
    Commented Nov 1, 2014 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.