I was wondering if it was possible to retrieve the text from a textbox on a window without using the standard API calls (like getwindowtext, getdlgitemtext, etc.)

Reformulated: Is it possible to directly read the contents of an object (e.g. textbox, button, etc.) without using an API call? And if so, how?

I believe this is a relatively easy way of getting to know ins&outs, when reading code (mostly a disassembled listing) of more advanced Win32Asm programmers. At also gives me some inside in how things are and can be done within a windows environment...
Posted on 2002-04-25 04:42:25 by the_anomaly
anomaly,

The only instances I have seen for this technique is for protection systems where the author is trying to make it more difficult for a cracker to set a breakpoint in SICE on API calls like getWindowText or similar.

If this is what you are doing, I would recommend using the Sendmessage WM_GETTEXT as a SendMessage call is used a lot more than the text specific API calls and it makes the task a lot harder.

I think from memory that you can access the direct memory in a normal edit control using API calls but this would defeat the purpose of what you are doing I guess.

Regards,

hutch@movsd.com
Posted on 2002-04-25 04:53:55 by hutch--
an idea:
you can check which key is pressed with GetAsyncKeyState and move the letter direct to a buffer.
Posted on 2002-04-25 04:54:27 by adapix
GetAsyncKeyState? *laugh*. First, you'd have to constantly poll for
all the keys you want to check, and second you'd get keys even if
your app doesn't have focus... pretty ugly way of doing it.
Posted on 2002-04-25 06:16:26 by f0dder
hutch--,

I know, i mean the API calls all (as far as I know) generate a windows message (correct me if i'm wrong). Like calling a getwindowtext will generate a WM_GETTEXT.

But still, all these message need to know where the data is stored and then retrieve it. Possibly I can find this position and retrieve it myself. Could it be that this is somewhere beyond Ring3? Or is everything downwards only for windows core code?

This way it is made even more difficult to detect (and might be faster when executed) the retrieval. I am currently into looking for some 'anti'detection methods increasing the protection for my apps and not using a dongle or something alike.

And indeed, I know the way peeps try to break into protection schemes (BTW very interesting and learnfull how protections are made. Some are trully stupid:rolleyes:).
Posted on 2002-04-25 06:55:56 by the_anomaly
anomaly, window text buffers are usually stored in "you shouldn't
touch this" memory. In 9x, iirc, it is stored in the 16bit subsystem,
and would be pretty messy to get your fingers on (unless there is
some API that I don't know about). Unless you can find some documented,
official, and 100% win32 way of getting direct access, I'd advice you
against it. Crackers will soon enough figure out whats going on,
and in the end it'll only be the end users having trouble when your
app breaks on some future windows version :).

Also, direct access to the text buffer... there's a few problems
involved. If you *set* the buffer, you'll still have to let windows know,
so it can redraw the control. If you're getting buffer contents from
a thread, the user could still be typing while you're reading the buffer,
and you might get partial results...
Posted on 2002-04-25 07:02:11 by f0dder
Wow 16bit ?!?! Thought we didn't have it anymore ;)
Well your advise is clear, use the general way (either API or message (which is API too, duh:grin: )). Retrieve it from some dark and unpleasant 16 bit (similar to DOS??) envorinment is not recommended...

Ok, well then I'll have to look for other ways of protecting (or hiding, which is nice too) the code.

Well, thnX for all the advise
Posted on 2002-04-25 08:02:20 by the_anomaly
anomaly,

The drift of my previous suggestion was to use SendMessage() because it is far more common in a Windows program and setting a breakpoint on SendMessage will not automatically give them the result they are after.

The old edit control in Windows (not richedit) has an option from memory to access the memory used in a direct manner so you may be able to get the data through the appropriate API functions but I doubt that it will stop a determined cracker for long as they would have access at the import table to see what API calls are being used.

I am a gradualist in terms of protection, the more you do the harder it is to crack and the other trick is to vary the method every release so they have to do it over again every time.

Good luck with it.

hutch@movsd.com
Posted on 2002-04-25 08:15:59 by hutch--
Just using SendMessage will not give much protection/confusion,
as softice supports conditional breakpoints... which means I can
"bpx SendMessage if message equals WM_GETTEXT" (look at the
softice manual for exact syntax). You only end up writing more code :).
Posted on 2002-04-25 08:28:14 by f0dder
Not sure if this might be relevent or not so I will just throw it out there and see what the answer is :P

I remember about a month ago I used some interesting SW. Think it was called umm UPX? Ultimate packer or something. Basically it compressed your prog and added itself to to the front of the resulting exe file. When you run the new packed file it compresses back to normal size to execute all transparent. Very neat idea imo.

My question would be, if you do not know the unpacking algo, would it help hide the code to any large extent? Just an idea...
Posted on 2002-04-25 21:13:23 by Graebel
Graebel,

I'm aware of such packing routines (and there a a lot of them, some better than others). The problem here is that those unpacking routines (commercial ones) are generally already reversed and don't support the protection I need.
Writing one of my own is indeed a possiblity which makes it some harder and gives me more control over this.

What might even be an solution is to use different packing routines for different parts of code. this will make stuff a bit harder but not impossible...

Coming to this. Mmmmm... Might be intersted in writing a double packer (or something alike) and also depacking the unpacking routine (?!?) resulting in a procedure to be executed by the application... Right, that's kinda hard I guess and might be just a fairytale... I'll be on coding now....

Will be checking back later on... ThnX Thusfar
Posted on 2002-04-26 04:26:10 by the_anomaly
I'm very sorry, but exe compression is futile as a way to protect data.
Safedisc and asprotect, both relatively advanced methods, are unpacked
daily without too much sweat. Loss of time, loss of performance,
more trouble for the endusers, and no trouble for the pirates.
And there's a lot of disadvantages to using packers... read my article
on it if you want.
Posted on 2002-04-26 07:54:23 by f0dder
Please f0dder, provide me with your article. Always eager to learn new programming stuff (at least new to me)
Posted on 2002-04-26 08:38:24 by the_anomaly
check out my site - click the www button, or the following link.
http://f0dder.didjitalyphrozen.com . The article is under articles
and is named "packing, data handling, stuff".
Posted on 2002-04-26 12:05:45 by f0dder