Just let you know that I figured it out.

As the first module name being checked is ntdll.dll, on win2k, the unicode name and the data following it is as below:


6e 00 74 00 64 00 6c 00 6c 00 2e 00 64 00 6c 00 ntdll.dl
6c 00 00 00 42 00 08 00 00 01                   l.B..
                        ^^
This is the byte we are checking.

As you can see, if we only check one byte, the code will think ntdll.dll is kernel32.dll. Checking 2 bytes fixes that problem.

Cheers,

Aniway

Thanks for the feedback!

I understand what you are saying;) theoretically, checking one byte should be enough and it saves one byte of space. But here is the whole story:

I was exploiting a java 0day using a simple calc.exe shellcode from metasploit. The shellcode worked well on Windows 2k and XP, but of course not on Windows 7. So I changed the shellcode as you posted and it worked on Windows 7, but kept failing on Windows 2k after that. I tried a few Win2k VM, same thing everywhere.

I tried to dig the problem out, but whenever there’s olly attached to the affected application, the shellcode runs successfully!!! So I never see a case that really requires a 2 byte check.

As that’s the only change I made to the shellcode, so I started to get picky at the code. The only thing I can think out was that the one byte check might not be sufficient. So I changed it to check 2 bytes, and It worked.

Is it possible that due to unininlized memory or whatever reason, there might happen to be one byte NULL at offset 0×18 for a shorter module name? Or there’s any other reason you can think of?

Cheers,

Aniway

Thanks for the feedback! I’ve not tested this on Win2K, but I don’t know why it would not work as-is.
The fix you suggest makes no sense to me, can you explain what the problem is and how this change solves it?

I designed the code to look for a UNICODE ‘\0′ character in a string that only contains lower-ascii characters coverted to UNICODE. This means that one byte of each character is always 0 and the code need only CMP the other byte to 0 (CL) to find this ‘\0′ character. In this context, I don’t understand why a CMP with CX adds any value and how this could solve any issue.

Cheers,

SkyLined

I’m not sure whether you have tested it on windows 2k. I have to make the following change in order to make it work in my case:

Original:
CMP [EDI + 0x18], CL

New:
CMP [EDI + 0x18], CX

As we are checking the termination of UNICODE string, so I think the change is harmless.

Cheers & regards,

Aniway

Unfortunately, 20 bytes is a lot for a shellcode: it would mean a 10% size increase for mine.

i like this kind of code, don’t get me wrong.

but i’d say at some point in future, a length check might be insufficient, meaning extra code required for extra checks.

in certain situations, it would be ideal to use 1 byte hashes or even hardcoded addresses but this usually means less stable code.

next_module:
    MOV     EBP, [ESI + 0x08]           ; EBP = InInitOrder[X].base_address
    MOV     EDI, [ESI + 0x20]           ; EDI = InInitOrder[X].module_name (unicode string)
    MOV     ESI, [ESI]                  ; ESI = InInitOrder[X].flink (next module)
    CMP     [EDI + 12*2], CL            ; modulename[12] == 0 ? strlen("kernel32.dll") == 12
    JNE     next_module                 ; No: try next module.

what happens if it finds ADVAPI32.DLL first? or some other module which happens to be same length as KERNEL32.DLL?

because of the 1 byte hashes, there can only be 256 possible values, it may resolve the wrong apis and crash.

this is a problem which might occur in process with large number of DLL loaded, hence why it may be better to have a good hashing algorithm and scan all modules.

the difference in size is not that big, maybe at most 20 bytes.