Many moon ago in a getto far far away back when i converted from Delphi and founded masm32 i read some information on protecting an executive from cracker and something has always stucked with me. That hard drive crash a long time ago so i don't know if it was Bill of USA, Hutch, Icz or a link from one of them who said this.

" The best thing anyone can do for an executive is to write an well organized .data? section and avoid using PTR's".

Do anyone have any ideas on the PTR story because i found a block of code by Qages to zeroes out a range of memory that works perfectly on 95B and may work on all Windows version because it is 100% ASM code.

I don't want to give it up just because of the PTR thing.

So could someone explain to me where the hole is or whatever, and how to fight it if it is there, if it is even possible.

Qages Coding Style:

"why dont you try this"

cleanbuff proc
mov eax, offset logfont
xor ebx,ebx
mov BYTE PTR ,0
@@:
inc ebx
mov BYTE PTR ,0
cmp ebx,SIZEOF LOGFONT
jne @B
ret
cleanbuff endp

PS: Posted on 2002-05-25 14:12:22 by cmax
There is no reason not to:
cleanbuff proc

xor eax,eax
mov edi, offset logfont
mov ecx,SIZEOF LOGFONT
rep stosb
ret
cleanbuff endp
You have to use PTR because your moving an immediate value to memory - MASM doesn't know what you want - you have to tell it BYTE PTR, or use a byte register, or use a memory location that is defined as a BYTE, or use ASSUME EAX:PTR BYTE. Somewhere you have to say, "MASM this is a byte value."
Posted on 2002-05-25 14:22:27 by bitRAKE
Thanks bitRAKE,

You posted an reply to someone question a few days ago about zeroMem and if this is the same code, i tried it and it did not wipe out the whole line in memory as Qages dose. I will try it again and see what i was doing wrong with-in a few hours this evening for sure.

Posted on 2002-05-25 16:20:26 by cmax
not using ptr doesnt mean any thing, that isnt a way to protect from crackers/hackers becuase ... i really dont want to say this becuse of rules and its illegal, but i ...m mmm i modify things in other words i am a (r4xx0r; i only use my skillz to debug my progs, i say this only to help you protect your programs. you should pack your program with a less "known" exe/dll packer. in code dont referance any strings, code by bytes. use stack as much as possable becuase the stack pointer usualy changes every timme you start up ur prog. dont use the .data section. put a lot of junk code if needed to throw them off.
Posted on 2002-05-25 18:50:31 by Qages
bitRAKE,

It Works,


My mistake yesterday when i tried it was i was removing a 8 BYTE string and i declared 12 BYTE and it remove part of another string....

So, this code has not really declared PTR up-front in the code, am im right....

Please allow me to ask this question....

bitRAKE,
i got an idea about how to keep Macro's from the so-call EXPANDING your Executive doing runtime.........

OK, Macros are best to be used doing execution of your program and not to be used too much as your program is running because it EXPAND the SIZE of your program in Memory or something.

I read your post about Macro and you laid the law down about what it really do. You said it is a simple cut and paste operation. So that lead me to thinking that this is what cause your Executive to EXPAND in the first place,,,,, am im right...

So with Hutch new stamp of approval about using macros and If my new founded understanding is correct, How About This...

At anytime doing while the user is running your program, clicking buttons or whatever that run Macros CODES doing that Procedure ...... After that MACRO has finish it job....Use your *True supper small pure ASM ZeroMemory* to Delete it out of Memory.... The so called Macro Expansion is now Out of Here.....Hey...Hey...Hey one less API gone with a big PLUS.

What do you think... If i am right i am on my way to bitRAKE Heaven...
Posted on 2002-05-25 18:51:52 by cmax
Qages

Your code lead me to seeing what is really happing in mem for sure and i will never forget that. but bitRAKE surely have cut the code size down to nearly nothing.

If this is true i got another piece of code produced by JimmyClif that will cut my executive nearly in half ... I am sure you are right but can you tell me one MO time that you know nearly for sure ....

PTR is ALL Good in Code... One More Yes or No will Do me Fine.

And one more thing, my exe is big because i don't use to many proc so it is in-line and supper fast....Now suppose i break down and start using proc and do 10 calls from one button click, will i loss speed and/or security because of it... if not I Will Go There for GOOD. (keep in mind that a few hundred milisecond extra will not be a major problem for me.)


Thanks Qages

and Thanks again for those great tips, i see can what you mean...
Posted on 2002-05-25 19:15:58 by cmax
im pretty sure rep stosb is slower then a jmp one, but dont use it on large strings i know that for sure.
also you dont want self contained code, like if ur using that buffer clearer 5 times in yer exe, if the hacker/cracker needs to modify somtin in it,it wont effect the others, however, if its in a proc called 5 times, it will effect all 5, hackers/crackers dont want that.
but if speed is better then security, thats ur prerogative.
100th post
Posted on 2002-05-25 19:33:52 by Qages
rep movsX

is 3+n which I can not beat, the best is
m+2*n
Posted on 2002-05-25 19:56:17 by bdjames
cmax, you are learning at a good pace, but what you state can not be with MASM macros - macros are expanded at assemble-time, not at run-time.
Posted on 2002-05-26 00:24:57 by bitRAKE
I don't think i am wording things the right way... Give me some time to get my disk organized and i will post or send you the info that lead me to this understanding. These people are not rookie, but maybe i mis-understood what they were saying.

I will have it all line up by or before Tuesday....Believe me searching my hard drive is like searching *5* Win32ASM Community messageboards. I down loaded everything that i ever saw...It will be a good thing for me to do over this weekend... I will start the minute i wake up... I got to get to the bottom of this because i see the light about the use of marcos. I read the post about API and Macro replacements for some of them...Lest API has always been my goal, that's why i came to ASM anyway.

Thanks bitRAKE
Posted on 2002-05-26 03:35:47 by cmax
Hello bitRAKE

This in one more was the tute i founded awhile back about macros, You may have read it already but this is where i skim through and got some of my ideas about macros usage. It's may be worth re-reading anyway.

Written by Philippe Auphelle
Reformatted from TXT to HTML by Stefan Krause Homepage

About Macros Go to: http://win32asmnewbies.cjb.net/ and get the win32asm_guide.zip in chapter3.html and chapter5.html he talk seriously about Marco and maybe in other chapters to.
...............................................................................................
I can't find the 2nd Tutor that got my attention awhile back, but the minute i find it i will let you know. I will have to stumble across it as i usually do thing, that's the way things comes up for me.

In that 2nd Tutor all he was saying is : Bottom line is only at the time when you double click the your executive icon,, at that time while executing than loading it this is the best time that Macros codes to be used.....Once the program has been loaded into Memory, (DON'T USE ANY MORE MACROS)

Now the program is running for the rest of the day or even forever so now is the time not to have Marcos being used through-out using the already running program because Macro will now began to really expand the program in memory or something....

Basically this is what he was saying but i really don't know.

That's why i said maybe there is a way to do some kind of clean-up after any additional Marcos being used while the program is in operation ( just an idea, may not even be possible because nothing may be there anyway ) i don't know. But i know you and your Marcos got the power i need to replace a few more API that i don't want to use anymore, so i will be studying how to defeat this problem if it is at all possible.


PS: I think that is bit7 Website
.................................................
.................................................

Qage,

You were more right than you know....

I always start out with 96% System Memory ( i always check in with the control panel, system, performance tab to keep an eye on everything i use up. I am building for someone else machine so i keep track very well )

I just finished my trial hook to run with my app, all the code is inside the app in-line like a monster.... After a 15 minutes or so i only got 45% of System Memory...Windows is really to die.

So i took your advice that many said since i got the masm32 v5... but i wanted to do it MY WAY....not so cleaver of me but it paid off to see all of this happen....

I broke all the code up into procedure as they should have been..........
UNBELIEVABLE...... 1 GOT 88% of System Memory no mater what i do while doing things with the program....and when it get intensive it goes down to 72% ( i got to fix my dll to beat this one ) But the best thing of it all is when i shut the program it down it goes back to 95% All System Memory Restored .....BIG TIME..i got to pat myself on the back, M32.lib and the Win32 Community taught me well....I am taking 98kb Program on this one...That's a lot of ASM code to be lined up perfectly and using a Icz MouseHook Style Dll to boot .... And believe me it do a whole lot of stuff all day long, you'll see.

Run WordPerfect, IE, or even some Simple Window Folders, you find it will hold up 4 to 8kb of memory even after closing.. Running through them for a a minute or two than shut them all down you be left with only 88% ... They never re-least all the System Memory.

I Belieive the secret in using CALLs is that the OS release the presure or something..Freeing Memory used after each call .... it's really worth it...

I don't like ASM anymoreeee ... I LOVE it

Thanks for Telling it Like it is Qage,


Posted on 2002-05-27 15:35:38 by cmax
One more thing Qage, what do you mean by this. Could you put together 3 lines or two pieces of code and point to what you mean... I don't really know things by technical definitions. I usually play it by ear but i don't understand and i don't want to make any more mistaking thinking what it mean is what i come up with. Look what happen to me already. Scare of PTR



The only idea i got is:

mov esi, Buffer1 ........ do this mean not referencing
mov edi, Buffer99
mov ecx, 24 ..............

if buffer1 has 24 letters in it would this way be consided coding by bytes and instead of using SIZEOF....

Thanks again
Posted on 2002-05-27 16:29:52 by cmax
First, repeat after me: executable, not executive :).

Now, what's with the "ptr" stuff? Do you mean the "ptr" override
in masm, or the use of pointers? No reason to avoid either, really.
Whether you're using static or dynamic buffers, whether they are
global (.data, heap, whatever) or local (stack), you still have
to take care that buffer overflows will not be possible. In many
situations dynamic buffers have the advantage of wasting less
memory (allocate and discard as needed). Furthermore, memory locations
with dynamic buffers wont be as fixed, so it'll be a bit harder
for a cracker to trace consecutive runs.

Macros are expanded assemble-time, and are only expanded once (or
rather, expanded where they are put - which can of course be
multiple places). As for macros taking up more space than procs,
well, that's what you get when inlining (except in a few cases
where there's more overhead of pushes+call than the actual inlined code).

As for inlining and the speed, I wouldn't really worry when dealing
with GUI code, and in fact not with most API calls. You're going to
be bound to the speed of the windows routines, which is usually slow
enough that 'optimizing' your gui for speed is a waste of time and space.

As for memory usage... there's a lot of stuff going on in windows. You
can't necessarily contribute the "lesser available memory" with leaks,
as the cache subsystem also takes fair chunks of your memory. Remember
that unused memory is wasted memory - while 88% free ram sounds nice,
I'd prefer to have 42% free, have a lot of re-usable files in the cache
subsystem, and know that the cache can be discarded if memory is required
elsewhere. Of course if memory usage goes down and down and down and
down while your app is running, a leak is very likely ;).

Most resources are reclaimed after apps terminate, however some of this
is done 'lazily' when windows feels there's enough idle-time to do it.
Other resources, especially GDI on the cruddy 9x systems, will not always
be cleaned up if you don't do cleanup yourself, and leaks can end up fatal
(BSOD because a GUI resource is low? Gimme a break...)

You need more detailed monitoring tools than eg taskman, it's only good
for a very rough overview to give a hint if something is terribly wrong...
or if you're bored and need to look at something that moves.

Now, what's up with the mousehook? Are you doing it just to avoid the
WM_MOUSE* messages, or does your app *require* the hook? If it's just
to get rid of the messages, this is not good - it'll end up eating more
resources than having WM_MOUSE* processing, take longer (since your code
must process events for other applications as well), etc.
Posted on 2002-05-27 16:45:03 by f0dder
Hey f0dder,

I think i am bad now f0dder, I know where everything is at and what it do any how it do it. I figured.....ABOUT TIME.

If anyone got an app running with the help of an dll at certain time an it is running as many line of code as i did ( OVER 8000 lines of ASM code ) on an Icz MHook.dll and all the Memory is TOTALLY, I mean TOTALLY RELEASED at shut down time....What more can you ask FOR.... Nothing but D**e good coding can do THAT.., I learned well from you guys as far as that much goes...

I wrote my app near completed 2 ? years ago in Delphi. The reason i came to ASM is because i did not want the extra help that Delphi had handed down to me for my app. Extra Junk...

So Just like Delphi, i don't want any help from any OS other than what i call for. So that bring me to another question that Maverick was once concerned about ...........

How do i Flush the CACHE for my *executable information ONLY and anything else MAYBE*. When the user shut down my app i don't want to leave *nothing* not even it NAME behind in Windows or the Processor as it Should BE. I have no problem coming back in lighting SPEED as it is with MY ASM :) Posted on 2002-05-27 23:41:56 by cmax
cmax, I would just like to say that you always sound very enthusiastic and postive about programming - I think you have a great outlook on life and keep an open mind. You have got to be one of the best newbies around here. Your eagerness is appearant and your always very respectful of those trying to help.
It is good having you here. :alright:
Posted on 2002-05-28 00:16:57 by bitRAKE
I think any self respectable application need to free all the used memory before exit. It it doesn't, I call it a bug.
I also think you got the wrong understanding about macros. They are expanded at assemble time and they don't exist in the exe-file in any form. You seem very interested about programming though!
Posted on 2002-05-28 00:35:07 by gliptic
Let's look at the mousehook example again. This is still assuming
you're only using it to avoid WM_MOUSE* messages, if you *do* need
to intercept mouse messages sent to other programs, you have a valid
reason for a mousehook. Now, what are the bad things then? First, a
hook dll will use more memory than handling windows messages (since
you need additional PE headers, imports, . . .) Next, hook code must
be visible to all processes (since it receives messages meant for all
processes), which at best means extra page table entries. If you have
read/write data in the hook DLL, you'll also have copy-on-write, which
is additional memory overhead. Also, your hook will be processing
messages for all processes, instead of just your own, which means
wasted CPU time.


How do i Flush the CACHE for my *executable information ONLY and
anything else MAYBE*. When the user shut down my app i don't want
to leave *nothing* not even it NAME behind in Windows or the Processor
as it Should BE.

Well, that isn't as it should be :). The disk cache subsystem is
there for a reason. While "cleaning all traces of yourself" might
have a "neatness factor", the practical value is nil, and it would
be working against the system. Imo it's better to work *with* the
system to get the best performance you can.

Also, don't confuse processor and filesystem cache. Processor cache
should lose whatever information about your applications rather quickly
after it has terminated, as processor cache is a very limited and
"local" resource. Filesystem cache... don't worry about this. I'd
personally be rather pissed if apps of "considerable size" decided
to flush the filesystem cache after they terminate. Yes, I do have the
habit of shutting down msdev or photoshop or <whatever> only to open
it again a few minutes later - having the app in the FS cache is a
really neat thing then.
Posted on 2002-05-28 05:13:07 by f0dder
gliptic: Even though it isn't strictly necessary (NT is pretty good at
cleaning up most resources itself), I think you're right - an application
ought to free any resources it has allocated itself. Cleaner programming
imo. But it shouldn't mess with OS-managed resources such as
filesystem cache.
Posted on 2002-05-28 05:15:08 by f0dder
cmax,

Lets try to make sense of you view of what macros are. A number of the guys here have told you what they do but I guess youy did not connect what they have said.

A MACRO is run "BEFORE" the code is assembled, once it IS expanded, its ONLY asm code. MACROs are often called PRE-processors because they process parts of the code BEFORE it is assembled.

The program that does the assembly also has the MACRO capacity inside it and when it first runs, it reads the MACROs first and expands them up into assembler code which is then assembled into normal binary code.

In order,

1. MACRO expansion,
2. ASSEMBLY of the code
3. BINARY code

What MACROs really do is give you the capacity to modify code BEFORE its assembled so that you can more accurately tailor it to do what you want. You can have a single line of MACRO code that is expanded up to many lines of assembler code and this allows you to write your code more like a high level language if you design them that way.

Regards,

hutch@movsd.com
Posted on 2002-05-28 10:41:01 by hutch--
Thanks everybody,

I am glad to hear it straight up, and it do make a lot more since to me now. I hate to miss out on the Marco thing because i do know it is a really powerful thing to use. I have a habit of reading things an when i find an major negative view, i immedialy say *Well It Out of Here* and turn the page, without even trying to get to the root of why. These could have been very old doc and maybe i simply mis-understood ...

....and bitRAKE, it is Great to be here. It took me a long time to figure out what things really mean... From the day The Svin showed me how to do Real Math in code, everything else started kicking in, and now i am so happy about ASM that i don't know What to Do ... I rather scan code than sleep .... Most of ALL i learn how to understand ASM just playing with M32.lib ... it's all The Svin fault.

But i still intent to find that last doc ( just in case )
Posted on 2002-05-28 12:19:04 by cmax