I have the following code. Sometime

[Cagliostro]

I have the following code. Sometimes it works fine, but sometimes not, in dependence of how many times I compile.
Can anyone explain what is the matter?

#define _WIN32_WINNT 0x0500
#include<windows.h>
char* y = &quot;\xFF\x15\xAC\xA2\x42\x00\xC3&quot;;
int WINAPI WinMain(HINSTANCE,HINSTANCE,LPSTR,int)
{
void (*ptr)();
ptr=(void (__cdecl *)())y;
ptr();
return 0;
}
John Fill
ivfmd@mail.md

 

[zallen]

I translate the y into 16bit assembly code (i know it should be 32bit however it doesnot matter to understand it).

ff15 call [di] ;what is in di?
ac lodsb
a24200 mov [0042],al
c3 ret

So you must know what is the content of (e)di.Maybe it is random or something else. I think you can simply disassemble your code to see what the register (e)di means.

Hope this helps you!

zallen@cmmail.com
ICQ:101229409
Long live of freedom!

 

[Cagliostro]

Hi,
I've translate it from 32bit assembly code. The original code is

call 42A2AC15h
ret

The questions is, why the compilled program some times rons ok, but sometimes fails. When I compille it, the rpogram runs ok, but when I compille again, it fails, showing some system errors. How can I know, if the compilled code will be ok, or no.
Some times the program runs only after I delete x00. Some times only with x00 in the string y. But some times it does not run. The string simply calls a windows's system function.
John Fill
ivfmd@mail.md

 

[zallen]

Have you compared the assembly code between right one and wrong one?There must be some difference between them.

Is 42A2AC15h a fixed address?I think it should be different between each compilation.


Regards!
zallen@cmmail.com
ICQ:101229409
Long live of freedom!

 

[Cagliostro]

I believe yes, because is a system function. I compilled many tymes directly calling this function, and everytimes, everywhere I put this call, was called the same address(I reade it in debugger).
You can control:
LockWorkStation(); John Fill
ivfmd@mail.md

 

[Prattaratt]

The problem may be that Windows might be moving the DLL that contains the function around in memory. Windows tries to keep this transparent to the programmer by using system function calls, but when you use &quot;hard&quot; addresses for system functions, Windows has now way of correcting for this. Try using the appropiate system function forgetting the function's address (I can't recall what it is right of the top of my head, but you can research it fairly easily.)

 

[Cagliostro]

I do not want to forget it. I just want to run a string from DataSegment wich is not ReadOnly. I want an idea, how to obtain everitime the right address to put it in the string
John Fill
ivfmd@mail.md

 

[Prattaratt]

Okay, try this: (excerpt from Borland C++ Builder Help)

The following example illustrates an important difference
between run-time and load-time dynamic linking. If the
MYPUTS.DLL file is not available, the application using
load-time dynamic linking simply terminates. The run-time
dynamic linking example, however, can respond to the
error.

// File: RUNTIME.C
// A simple program that uses LoadLibrary and
// GetProcAddress to access myPuts from MYPUTS.DLL.

#include <stdio.h>
#include <windows.h>

typedef VOID (*MYPROC)(LPTSTR);

VOID main(VOID)
{
HINSTANCE hinstLib;
MYPROC ProcAdd;
BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;

// Get a handle to the DLL module.

hinstLib = LoadLibrary(&quot;myputs&quot;

// If the handle is valid, try to get the function
address.


if (hinstLib != NULL)
{
ProcAdd =(MYPROC)GetProcAddress(hinstLib, &quot;myPuts&quot;

// If the function address is valid, call the function.

if (fRunTimeLinkSuccess = (ProcAdd != NULL))
(ProcAdd) (&quot;message via DLL function\n&quot;

// Free the DLL module.

fFreeResult = FreeLibrary(hinstLib);
}

// If unable to call the DLL function, use an alternative.

if (! fRunTimeLinkSuccess)

printf(&quot;message via alternative method\n&quot;
}


Because the program uses run-time dynamic linking, you should not link with the import library when creating the program module.

 

[Cagliostro]

Thanks, I'll let you know the results. John Fill
ivfmd@mail.md