2

enter image description here

I have a dll that is loaded by the program i'm reverse engineering, this dll only contains .text section without any exported functions, my guess is that dll main function contains something interesting. I have a breakpoint trigger when the dll is loaded with the LoadLibraryA function and can see the EIP jump to the beginning of .text section of the dll, and see all the register update as the code is executed inside the dll, however, the instructions I'm looking at seem to not change and still are in the address of the program. also worth mentioning is that the dll is not loaded at the requested address so idk if it's a bug or what, I'm using x32dbg. Any help would be greatly appreciated, thanks

0xC0000022L
  • 10,908
  • 9
  • 41
  • 79
asdfs99
  • 41
  • 3
  • The payload could just as well be in the TLS callbacks. And depending on what it does, it could also delay whatever it does by registering some callbacks that it knows will get called later on. But it's really difficult to say anything without more information or having a look at the DLL in question. – 0xC0000022L Nov 08 '22 at 10:23
  • @0xC0000022L Ive added a picture of the problem, dll loader is loaded at the base address of 40000 however the .dll file (highlighted) is loaded at the address of 713E0000, and when i try to see program flow inside dll main it won't show. by forcing to look up the address manually with (ctrl +g) command i get an invalid address. – asdfs99 Nov 08 '22 at 13:45
  • The screenshot doesn't even touch on anything from my comment, except that the names let me guess what you're looking at. Assuming you are looking at the sample with SHA-256 40f1324a0fde19f064945951fed877a49e82c391ca7c34c35839de064a4b68ba then there don't seem to be TLS callbacks in it. First thing it seems to do is figure out the name of the .exe that loaded it from the PEB::Ldr -> InMemoryOrderModuleList.Flink. Then uses the name to facilitate the deobfuscation, it seems. – 0xC0000022L Nov 08 '22 at 14:29
  • Am I right to assume it's the DLL of the same name from here? – 0xC0000022L Nov 08 '22 at 14:46
  • @0xC0000022L yes that would be correct, I solved the first puzzle with ease and im scratching my head with the second one but a challenge is always welcome. anyway, i managed to find out the issue, when the dll main function was being executed i had to manually load up the address of the dll. but i want to thank you for taking interest in my problem :) – asdfs99 Nov 08 '22 at 19:11
  • Thank you for the replay, however, im looking for a challenge and maybe a job – asdfs99 Nov 08 '22 at 19:14

0 Answers0