Compiling for machine code, need help

[wraithdu]

Boom Local strings did the trick. Thank you! I would like to know if there's a way to use the .rdata strings however.

[Ascend4nt]

To use static data, you'd need to #1 include that data in the binary data, #2 be able to find an offset to that data, and #3 use that offset in your code.  You could alternatively stuff the static data into a separate memory location, and pass that offset to the function, or stuff the strings in DLLStructs, etc.  I'm not sure if trancexx had any other tricks in mind..

In the Assembly stuff I've done for AutoIt, I've had static data embedded right along with the code, but in order to do this I needed to calculate where the binary code started (easy to do with a well-placed 'call' function), store that offset in the ESI/RSI variable, then use that as the base for calculating data offsets.  It requires the segment to have read/write in addition to execute access, which is how we usually set access when we first allocate memory for storing code.

[trancexx]

No, no tricks from me. What I had in mind when I said that it's easy, was to use arrays of characters allocated on the stack, just as shown.

You can't use .rdata data trivially with the original code because then procedure of storing data offset to register that executable code usses is missing. That's job for PE loader and entry point functions.

[wraithdu]

Thanks again both of you.

@Ascend4nt

This works just as well, and easier to write

char sVirtualAlloc[] = "VirtualAlloc";

So I've got it working now, which is awesome. I also did a 64-bit version, and noticed some additional static sections, .pdata and .xdata. Any idea if these are required in the opcode?

[Mat]

Maybe learning assembly is a better option.

I think xdata used to be the extended data section when 16 bit architectures moved into 32 bit memory ranges (a bit before my time so I may be wrong there). Maybe its the same for 64 bit.

[Ascend4nt]

thx for that wraithdu.. I get confused with all the changes in C++11 that I forget what was standard C or C++.

As far as the 64-bit version goes, I don't see a reason why your code would need to access any other sections unless its doing something with the data in those sections?

[wraithdu]

Someone added a patch to that memory DLL loading source that I used. Can anyone remember some of the DLLs people found that didn't work with the old versions from Ward?

I thought maybe bass.dll, or one of the graphics libraries?

Edited July 29, 2013 by wraithdu

[trancexx]

Do you know details about the patch?

I know in details techique used for this. I have written the same thing in AutoIt using nothing but PE specification. The code can be found in examples. When I compared both codes, they turned to be incredibly similar.

What I'm saying is - show me the patch and I'll tell you if it's valid and/or needed.

[wraithdu]

This was the patch: https://github.com/fancycode/MemoryModule/pull/11

However I found the BASSMOD.dll I was thinking of, and this code http://www.joachim-bauch.de/2012/04/09/memorymodule-0-0-3-released/ still fails to load it ( http://www.un4seen.com/ - bassmod v2.0 ). I remember having this problem last year.

Currently, my version and Beege's version both hard crash when trying to load it. Ward's current AutoIt based version does load it, but I don't know if it does so properly or not, or just ignores certain internal errors resulting in a partially loaded DLL (  - reference to Ward's unknown patch).

[trancexx]

I have never seen TLS callbacks used.

Considering you are asking probably the patch didn't work for that dll.

My suggestion is to use script from >here just to try it. It really old script when I didn't even have 64 bit system to try it on and AutoIt didn't have some built-in functions, and I didn't know how to check MSB for 64 bit numbers, but if it works for your dll then you will know that your problem is the original code, not patch that you mention.

I gave quick instructions to a friend of mine to download both your problematic dll and my script and modify it to try. If he does it before you I'll tell you the results.

[wraithdu]

I tried my script with and without the patch, it made no difference. Speaking of, let me attach my latest if you feel like playing with it.

MemoryModule.zip

[trancexx]

Well, I really have no means of testing anything. What I see in the c file is the use of IsBadPtr function which shouldn't ever be used because it bad function.

The line that goes like this:

for (; !module->isBadReadPtr(importDesc, sizeof(IMAGE_IMPORT_DESCRIPTOR)) 
&& importDesc->Name; importDesc++)

 

...should really be more like this:

for (; importDesc->FirstThunk; importDesc++)

 

Do you know where exactly does it crash? In what function?

[wraithdu]

I believe it crashes at the very end when calling the dll entry point. I added some custom code to my AutoIt port that allows the user to not call the entry point with ATTACH / DETACH, and I avoid the crashing. However it likely leaves the DLL in a non-functioning state.

[wraithdu]

My suggestion is to use script from >here just to try it.

This method does work for the BASSMOD dll.

[trancexx]

This method does work for the BASSMOD dll.

In that case it's quite simple. The difference is rather obvious. I will explain what you have to do to get it working correctly when I get time in case you don't figure it out by your self.

[wraithdu]

Well, Ward's current mem dll UDF also works to load the BASSMOD dll. I can get the dll handle, a function pointer, and call a function, then unload it without crashes. So I need to find time to sit down and carefully compare his method to mine / C code. They are very close, but not identical. I'll let you know what I find, then we can compare notes.

[trancexx]

Ok then. I'll just hint then that your current code has three bugs that directly cause failure with that dll.

[wraithdu]

Hehe, like a hidden item game. Let's see how I do.

[Ascend4nt]

she should at least play a game of 'hot and cold' to help out

[wraithdu]

Hehe, I like a challenge, don't mind her teaching method. If I get really stuck, I'll ask for help.