|
Hey all,
I had a post on here about a week ago about executing code from memory instead of a PE file.
So far this is what I've done.
have this as the test code compiled
############################################
#include <stdio.h>
int main(int argc, char* argv[])
{
printf("Hello World!\n");
getc(stdin);
return 0;
}
compiled that and stored it as RCDATA resource 130 in my new project
############################################
this is the code I'm trying to execute it with, without writing it back to a file in my MFC dialog app
HRSRC hrInfo = FindResource(AfxGetResourceHandle(), MAKEINTRESOURCE(130), RT_RCDATA);
HGLOBAL hbytes = LoadResource(AfxGetResourceHandle(), hrInfo);
int (*ptr)(int argc, char *str[]);
ptr = (int (__cdecl *)(int, char *[]))hbytes;
int j = 1; char *strs;
(*ptr)(j, &strs);
CODE DONE
######################################
MODIFIED:
I also tried reallocating it with a FIXED flag, and it also didn't work
############ TRIED THIS TOO
HRSRC hrInfo = FindResource(AfxGetResourceHandle(), MAKEINTRESOURCE(130), RT_RCDATA);
HGLOBAL hbytes = LoadResource(AfxGetResourceHandle(), hrInfo);
int size = (UINT)SizeofResource(AfxGetResourceHandle(), hrInfo);
HGLOBAL pexec = GlobalReAlloc(hbytes, size, GMEM_FIXED);
int (*ptr)(int argc, char* argv[]);
ptr = (int (__cdecl *)(int, char *[]))pexec;
int j = 1; char *strs;
(*ptr)(j, &strs);
################
OK, the function I cast it to matches that of the main of the test code. BUT, it gives me an access violation. WHY? HGLOBAL DATA is supposed to be executable from memory without any special function right?, Will this work with the HGLOBAL as is, or do I need to explicitly GlobalAlloc it?
I realize that this may be an advanced topic, and I urge some people to refrain from replying as that my last post got a couple of very ignorant responses. Thanks for your understanding.
|
|
|
|
|
The topic is advanced, and using that kind of trickery requires skills and most importantly reason. I am not even going to discuss what possible reason you have to write code like this. Lets concentrate on what you actually trying to do:
Beer26 wrote:
HGLOBAL pexec = GlobalReAlloc(hbytes, size, GMEM_FIXED);
I am not completely sure what you expect from the statement above. I assume you want to create a copy of the resource in memory (I do not think GMEM_FIXED is going to be honored in Win32) You might be better off allocating new block of memory, insteadof realloc-ing something that you did not alloc-ed.
Beer26 wrote:
ptr = (int (__cdecl *)(int, char *[]))pexec;
I read the line above as - you assume that recourse you loaded is actually executable code of the function with signature "int (*ptr)(int argc, char* argv[]);" (please confirm). Are you sure that it is a valid executable code?
Beer26 wrote:
int j = 1; char *strs;
(*ptr)(j, &strs);
the line above actually try to execute the loaded code. (please confirm). Please note also that strs is not initialized.
How did you compile it? How did you put into resource? How are calls "getc" or "printf" going to be resolved ?
|
|
|
|
|
a) there is no guarantee that you have EXECUTE right on a HGLOBAL, but this doesn#t matter on Wintel Boxes
b) You *are+ aware that EXE files come a) with a PE header, and b) with a relocation table? They are not just "sequences of code bytes"...
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
"a) there is no guarantee that you have EXECUTE right on a HGLOBAL, but this doesn#t matter on Wintel Boxes"
From MSDN
"Remarks
If the heap does not contain sufficient free space to satisfy the request, GlobalAlloc returns NULL. Because NULL is used to indicate an error, virtual address zero is never allocated. It is, therefore, easy to detect the use of a NULL pointer.
Memory allocated with this function is guaranteed to be aligned on an 8-byte boundary. All memory is created with execute access; no special function is required to execute dynamically generated code. "
"b) You *are+ aware that EXE files come a) with a PE header, and b) with a relocation table? They are not just "sequences of code bytes"..."
Yes, I am. What if i write a small bit of code in ASM and only generate the OPCODE? Then try it with that? Would that work? I'm assuming it's not going to work with all the PE junk linked and compiled with it?
|
|
|
|
|
Beer26 wrote:
All memory is created with execute access;
Oops, sorry, I missed that (it's late over here ;-O )
b) yes that should work (as long as you refrain from absolute jumps/calls (or adress them correctly, with regards to the allocated base address)
If it doesn't, try to follow the thing in the debugger (disassembly window)
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
__asm
{
jmp (start of your code);
return;
}
|
|
|
|
|
woah, you gotta be kidding me, I'm going to try this now. It kind of makes sense too!
|
|
|
|
|
I'm including a class that has an inline function called
GetOldNodeIndex defined in the header file for that class.
When I try to access it, say in the main() function, the compiler
spills out (seemingly unrelated) unresolved symbol errors....
Here's the class definition
<code>
#if !defined(AFX_SPRINGNODE_H__7DC1CC9F_C211_478F_B542_9B71B4A3C4EA__INCLUDED_)
#define AFX_SPRINGNODE_H__7DC1CC9F_C211_478F_B542_9B71B4A3C4EA__INCLUDED_
#include "CM3DVector2f.h"
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
class CSpringNode
{
public:
unsigned int m_uiEntryTracker;
unsigned int m_uiNodeIndex;
unsigned int m_uiValence;
double m_dEnergy;
CM3DVector2f m_M3DPosition;
CSpringNode(unsigned int Index, CM3DVector2f& rPosition);
virtual ~CSpringNode();
bool operator<(const CSpringNode& rNode) const
{
return (m_dEnergy < rNode.m_dEnergy);
};
protected:
CSpringNode(){};
private:
unsigned int m_uiPreSortIndex;
public:
unsigned int GetOldNodeIndex() { return (m_uiPreSortIndex); };
};
#endif // !defined(AFX_SPRINGNODE_H__7DC1CC9F_C211_478F_B542_9B71B4A3C4EA__INCLUDED_)
</code>
and the main function
<code>
#include "stdafx.h"
#include "SpringNode.h"
#include "CM3DVector2f.h"
int main(int argc, char* argv[])
{
CM3DVector2f Vector;
Vector.x = 5.5;
Vector.y = -4.6;
CSpringNode aNode(0, Vector);
cout << aNode.GetOldNodeIndex() << endl;
return 0;
}
</code>
and the errors:
Compiling...
TrustRegion.cpp
Linking...
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCD.lib(dbgdel.obj)
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __endthreadex
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __beginthreadex
Debug/TrustRegion.exe : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.
TrustRegion.exe - 4 error(s), 0 warning(s)
I should mention that if I remove everything that relates to the
inline function all those errors go away and everything works fine....
Anyone know what's going on here???
|
|
|
|
|
So if you comment out the cout << aNode.GetOldNodeIndex() << endl; line, all is well with the linker?
|
|
|
|
|
|
Then the next obvious question is what happens if you make the function non-inline?
|
|
|
|
|
The same thing. However, if I remove:
<br />
cout << temp << endl;<br />
cout << aNode.GetOldNodeIndex() << endl;<br />
<br />
it's okay. 
|
|
|
|
|
Which implies that you cannot use any method of that class, inline or otherwise. Correct?
|
|
|
|
|
Hmmmmmmmmmmmmm.....I suppose....
|
|
|
|
|
This doesn't work either:
<code>
int main(int argc, char* argv[])
{
CM3DVector2f Vector;
Vector.x = 5.5;
Vector.y = -4.6;
CSpringNode aNode(0, Vector);
unsigned int temp = aNode.GetOldNodeIndex();
cout << temp << endl;
return 0;
}
</code>
|
|
|
|
|
Are you building your application in multithreaded mode? This might be required when you use streams.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
That's just it - I'm not using any threads at all - the app is as
simple as you see it before you. The CM3DVector2f.h file contains
our own vector implementation and has been used EXTENSIVELY in MANY
projects, so I know it's not that - only seems to be related to
the inline function I described...
This is just a simple console app to demonstrate the problem - it's
driving me nutz!
|
|
|
|
|
I know this talks about old versions of the compiler and MFC but I think the result is the same.
SYMPTOMS
When compiling an MFC application using the single-threaded run-time library, you receive the following two unresolved external error messages:
nafxcwd.lib(thrdcore.obj) : error LNK2001:
unresolved external symbol "__beginthreadex"
nafxcwd.lib(thrdcore.obj) : error LNK2001:
unresolved external symbol "__endthreadex"
CAUSE
Starting with version 3.0, all MFC classes are "thread safe" and require the multi-threaded run-time libraries to link successfully. Many people try to use the single-threaded run-time libraries because they assume these libraries are needed to enable the application to run in Win32s. This is not the case. MFC versions 3.0 and later will use a single thread, so as long as you are not creating additional threads in the application, the application will run under Win32s.
RESOLUTION
To avoid these unresolved external errors, do not set the Project Settings to Single-Threaded for an MFC version 3.0 or later application. This setting can be changed by doing the following:
On Visual C 2.x and 5.0:
Select the PROJECT menu (and continue Steps 2 through 5 below).
On Visual C 4.x:
Select the Build menu.
Select the SETTINGS... option.
Select the tab, C/C++.
Select CODE GENERATION on the Category list box.
Finally, make a selection other than SINGLE-THREADED on the Use Run Time Library list box.
STATUS
This behavior is by design.
John
|
|
|
|
|
Hi John,
Thanks for the reply. I tried using Debug-Multithreaded as the setting
to enable multi-threading in the project, however, it has only served to
reduce the umber of errors by half. Now I get:
Compiling...
StdAfx.cpp
Compiling...
TrustRegion.cpp
SpringNode.cpp
Generating Code...
Linking...
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)
Debug/TrustRegion.exe : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.
TrustRegion.exe - 2 error(s), 0 warning(s)
Good God but this is frustrating! 
Surely you can use an inline function to dump data to console????? What kind of "by design" behaviour is this??!?!
I have visions of an extensive re-write flashing before my eyes.....
|
|
|
|
|
The inline function is a red herring, it is perfectly fine and can link against the function. Accessing any other function from the object should produce the same spew. This spew is normally associated when accidentally linking against the wrong threaded libraries. Although you may have changed your project settings to multithreaded, can you be sure that all the other projects in your workspace (and indeed libraries) are of the same thread specification? Check out MSDN Index and type in LNK2005 for more info. Also I notice you use a dummy constructor that is inlined, but not a dummy destructor, have you defined this in your .cpp implementation?
|
|
|
|
|
I concur on the inline function being the red herring. However, the odd thing is is that I noticed this behaviour in another project and couldn't resolve it there. So I
created a simple console application in the Project Wizard (VS 6.0) and attempted to
reproduce it. It is easy to see that I did. Which confuses me....This is just
a simple console app with a main function - no other projects in the workspace - thus
all are of the same thread specification. I have mucked about with the thread options in the project settings to no avail. Actually the dummy constructor can be removed and no, I haven't implemented a dummy destructor, but I don't think this should have much of an effect (??).
|
|
|
|
|
John Theal wrote:
Surely you can use an inline function to dump data to console?????
It has nothing to to with inline functions I use them all over the place in my applications, console or not. Are you using MFC in this application? Is it set in the Project Settings?
John
|
|
|
|
|
I'm not exactly sure why is this but maybe you can try to remove the 2 semi-colons from your code and retry...
class CSpringNode<br />
{<br />
public: <br />
...<br />
bool operator<(const CSpringNode& rNode) const<br />
{<br />
return (m_dEnergy < rNode.m_dEnergy);<br />
};<-- Remove this semi-colon<br />
<br />
unsigned int GetOldNodeIndex()<br />
{ return (m_uiPreSortIndex); };<-- Remove this semi-colon<br />
<br />
...<br />
};
|
|
|
|
|
Thanks for your help, but that didn't seem to clear up the problem.
Surely someone has run into this before???
=[ Abin ]= wrote:
I'm not exactly sure why is this but maybe you can try to remove the 2 semi-colons from your code and retry...
class CSpringNode
{
public:
...
bool operator<(const CSpringNode& rNode) const
{
return (m_dEnergy < rNode.m_dEnergy);
};<-- Remove this semi-colon
unsigned int GetOldNodeIndex()
{ return (m_uiPreSortIndex); };<-- Remove this semi-colon
...
};
|
|
|
|
|
After trying out various ways, and NOT finding a truly successful way to pass "enum" as parametric values, it leaves me using *enums* as global variables.
I don't have a problem with the compiler. It accepts the syntactical manner in which I apply its usage. It is when I start turning on and turning off certain of its values, that I noticed (after extensive debugging) that the values weren't being turned on and turned off when they should've been, which led me to suspect that values weren't being passed correctly to the function parameter. (I don't now what to think at this point.)
IOW, all I'm saying is that the function which receives that parametric value, is not behaving the way it ought to behave (meaning, when a certain value is specifically turned on just before calling that function, when the function is executed, it doesn't react as though the value was turned on, and debugging confirms this).
Thanks.
and 
William
Fortes in fide et opere!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
