Hello,
I have been told that a program may write into itself on disk ... while I always thought that while running a program may not be modified. Can anyone shed some light on this?
Thanks.

bob

Hiya Bob,

I believe you're referring to Self Modifying Code (SMC). With SMC, its quite possilble to modify a program's code in memory during runtime. Packers and encrypters typically use this technique (as do polymorphic viruses).

And while it sounds really difficult and scary, coding *simple* SMC is not that difficult if you have a little asm knowledge. Here's a small example:

mov edi, offset smc ;address to begin loading smc I's
mov [edi], byte ptr 90h ;move the opcode for the nop instruction into location

smc:
inc edx
xor ebx,ebx
.
.
.

Well, thats a *very* simplistic example, but it shows the idea. The above snippet just replaces the inc edx (a 1 byte instruction) with a nop (another 1 byte instruction). And as you can see, this occurs "on the fly" while the program is executing. If you're in a debugger you'd see the inc edx change to a nop right before your eyes. If not, you'd never know the prog just modified itself.

For a more elegant example of this technique, I'd suggest tracing through some unpacking code in SICE. I know tElock has a bunch. Now some of that SMC is amazing, but I don't think it can be generated by hand... Trust me, I've *tried* (and failed ). I never managed to get past a small handful of SMC instructions before confusing myself utterly.

We had a thread on writing basic SMC a while back in the mini project forum. For a little more information, I'd suggest you have a look at the thread entitled "Harlequin's Task 3 Challenge" posted by Kayaker.

Hope this gives a little insight :-).

Cheers,
Clandestiny

A running program can not write to itself, but you can have another executable stub that would write to the application while it is not running.

It wouldn't be SMC, but you can use a loader (process patcher).

Hello friends,
my question was on programs able to modify themselves ON DISK clandestiny. nofun are you talking of programs on disk or in memory? By the way, I'd appreciate if someone could tell me what is a loader? It's a lot of time that one in a while this term pops up in things I read but I have never understood what loaders are and do.


Regards,
Bob

Oops, I guess I misunderstood the question. I though you were referring to progs modifying themselves *off* disk (in memory).

Clandestiny

technically...they *shouldn't* be able to. adding a registry entry from the program, to change the program at reboot would seem to work. (I'm sure there are other ways too)

However...I said *shouldn't*....nobody that I know of has really figured out why, but with VC++ programs, if you change code in memory or close the program with BP's still set, they write to disk *shrug*

Hello,
are there registry entries to have a program modified at reboot? By the way, more than modified I should say subtituted or overwritten.
I thought that there was some INI file for this type of operations .... I believe that also service parks use it .....


Regards,
BobTheRock

autoexec.bat

wininit.ini (though i thought was only for deleting files, not renaming / replacing, but you know what thought did)

you can create / delete / rename / read / write to file on disk, from the process created by the file .. not sure how though .. but i had a program that once u ran it, it renamed itself

and like the other guy said, some apps (maybe vc related), if you set bpx's or modify the code in them, and the app exits cleanly (no gpf / crash), they can store the modifications onto disk ..

i patched the cd check in tiberian sun in memory, and he patched himself on disk for me, quite handy :-)

Gee, this is interesting indeed.
Has anyone a clear idea of how this can be done?


Regards,
BobTheRock

ok don't quote me on this stuff cause i'm still learning (arn't we all?)...

>nofun are you talking of programs on disk or in memory?
I was talking about a program on disk for the application stub. For the loader, thats modifing the memory which is kinda what Clandestiny was talking about.

> I'd appreciate if someone could tell me what is a loader?
You can think of a loader as a stub basically. And it does what it is named. It will load or start another application.

I think TNT made a nice program that allowed you to create a loader and basically bind it with the exe (makes it look like injection kinda).

And r!sc has a great process patcher as well. Their great tools to mess around with (especially for a beginner like myself).

I may be a genius!!! look my first day on a newbie board and i already got one! HA : )


I believe you could use an old windows trick. (or is it winblows here? I can never keep my boards straight. Anyway call the api and change the directory name under the executable. for example if you loaded out of
C:\foo\foo.exe change that to C:\_foo\foo.exe then windows write protection will fail and now you can write to your hearts content. Finally before your program exits change the directory back to C:\foo.
This also works to get at files other programs are trying to protect.

Ok thats a straight hack in every bad sense of the word but what are your options? That was the big fat way... but i figure you werent into the assembly way so have at it.

Very nice hack .... if it works. I'll verify it on my win2000.

BobTheRock

Altho I'm guessing this wouldn't work on windows 2000, I suspect it might work on win95/98. The idea is inspired from a crackme done a couple of years ago by someone I can't remember the name of.

The idea of the crackme was put together a .lic file that the crackme would load, and then use to modify it's own code in mem. The beauty of the scheme was the way the memory was modified (it was code read-only). The file was read into memory and then copied onto the code in mem, with a hmemcopy or something. Before allowing this, windows checks the desired destination, to see if everything is okay. But these checks could easily be bypassed, allowing you to write to whereever in memory you wanted (as well as I remember), without a glitch.
My guess is, windows checks the file to be written to against processes in memory, and if it finds a match, no write. Bypass the checks, and you're home free.
Or, if bypassing the checks proves to be somewhat difficult, find out what is compared in memory (ie what info of the running processes is compared to the info about the file). Then modify the info in memory about the process, and restore it just before you quit.

Just a thought

Blue skies
Fake