passing variables between external programme and PB

[PB]

> For security reason (to avoid hacks) every window app uses its own
> RESTRICTED memory area to store values, etc.

How true is this? I have a VB source that opens Calculator, then modifies
the text on one of its buttons, by memory hacking using OpenProcess and
WriteProcessMemory, all on Win2K Pro. So it would seem you can hack the
memory space of other apps, even on a "secure" system like Win2K Pro...

[ricardo]

> For security reason (to avoid hacks) every window app uses its own
> RESTRICTED memory area to store values, etc.

How true is this? I have a VB source that opens Calculator, then modifies
the text on one of its buttons, by memory hacking using OpenProcess and
WriteProcessMemory, all on Win2K Pro. So it would seem you can hack the
memory space of other apps, even on a "secure" system like Win2K Pro...

Yes, but its not 'easy' to do it, not like sending just an API call.
You are doing something that was not planed when MS developes the Calculator.
In the other hand, you can control most aspects of excel or word (for say some of many other) that was designed having this possibilitie in mind.

That was my point , trying to explain the difference.

[cecilcheah]

Hi PB

Where do you get the source where you can change the text of the calculator, i am interested in seeing how this can be done. Can you change the function of the button too?

I am contacting someone who knows the Toolbook internal source code who maybe able to help me by showing the source in C++ code on how to send variables from Toolbook to external application, like PB.

Cecil

[GedB]

Cecil,

I'd have to agree with you, what your asking is practically impossible.

Unless a program deliberately exposes the information you require: either through an API or a window, there is no reliable way of getting at it.

It might be possible to hack something, like the calculater example given, but you could spend weeks and get nowhere.

[cecilcheah]

Hi there

Just a thought

If i am able to send a message to Toolbook by copying the Toolbook Openscript to a memory address that Toolbook knows where it is like below:

Code: Select all

MyData.COPYDATASTRUCT 
  MyData\dwData = #COPYDATA_EXECUTE 
  MyData\cbData = SizeOf(COPYDATA_EXECUTE)+Len(lpStatements) + 1
  hStr = GlobalAlloc_(#GMEM_ZEROINIT|#GMEM_MOVEABLE, MyData\cbData) 

  If hStr 
   ; *lpExec.COPYDATA_EXECUTE = GlobalLock_(hStr) 
    *lpExec.COPYDATA_EXECUTE = GlobalLock_(hStr) 
    If *lpExec 
      MyData\lpData = *lpExec 
      *lpExec\bSysSuspendOff = bSysSuspendOff 
      *foo = @*lpExec\szStatements[0]

      CopyMemoryString(lpStatements, @*foo) 
      bResult = SendMessage_(hWnd, #WM_COPYDATA, #NULL, MyData) 
      GlobalUnlock_(hStr) 

Can i not use PB to poke this memory to fetch some variables back?

Just a thought.

Cecil

[oldefoxx]

The structure of any program is dependent, in part, on the language and compiler that it was created in. Based on the MASM Assembler model (which is often followed in higher languages where suitable), Global variables are kept in one part of memory and available to all code segments, and local variables appear in the local code segments. To determine one from another, you have to follow the execution trail, as this is what determines if data is actually part of a computer's instruction sequence, then determine what portions of memory are deemed to be variables and structures, and what parts are likely constancts, these again being recognized by the manner in which they are referenced and positioned in memory. Now this "idea" of how a program is organized and retained in memory really relates to DOS, rather than windows. But you can already tell that there are significant problems in understanding a program from just its existence in memory.

Windows is far more complicated because it allows multiple programs, multiple instances of programs, and multiple users of multiple programs, parent threads with instances of child processs running in their own threads, and Virtual Memory to retain inactive portions of programs that can be offloaded to the hard drive while other needed elements are loaded up in place of those elements. So you don't dare try to directly interact with another program - you have to use the mechanisms provided by the Windows APIs, which may or may not fit your needs, and which evolve with time from one version of Windows to the next.

You can identify certain things about programs, such as resouces (opened windows, controls, etc.), but in fact, unless you understand the mechanisms involved and how to pass information to and from that resource, that isn't going to help you very much. If a portion of that program involves functions in external DLLs, then conceivably you can use the same DLLs to perform the same functions - but not to share the same variables and structures, since the DLLs themselves are designed to be multi-threaded and reused by different programs as necessary without allowing one to interfere with another.

It should be obvious that these are just part of the mechanisms that are in play, and cannot categorically be said to cover all situations. it is obvious that some programs do interfere with others, such as virus and anti-virus programs that take up residence in memory. But the means by which they work is far beyond my humble background, other than to say that what can be done by software can be circumvented or compromized by other software - it is just a metter of learning or knowing how.