sounds like you didn't change the read/write permission on the CODE
(or .TEXT depending on your compiler) sections of your binary. You
must read up on PE file formats and how to change the PE section
permissions. I believe the CODE section is default to READONLY.

What you're trying to do should be possible - the NT PE loader does
this all the time, ie. changes section permission temporarily while
'snapping' the IMPORT ADDRESS TABLE (IAT) when loading exe/dlls into
process memory.

If you read the PE headers right then you should be able to figure out
all the addresses of relocated and re-based DLLs as well. I've never
tried it tho.





"Ramesh" wrote in message news:...
> A gotcha with this approach that you should be aware of is that Win32 loader
> may patch your executable if it is relocated (ie, loaded at an address
> different from what the linker assumed), some of your entrypted bytes will
> get overwritten *before* you decrypt the code. This will produce invalid
> code and will cause the program to fault.
>
> If you are encrypting only the exe (which does not relocate since it is the
> first executable to be mapped into the process space), you may not have this
> problem. It will apply to only DLLs that may relocate.
>
> - Ramesh
>
>
> "Ray" wrote in message news:rbXscGJIaKbL@cc.usu.edu...
> > Hello,
> >
> > My program is trying to encrypt amd decrypt my algorithm and data by

> itself.
> > My basic idea is to encrypt my executable code/data and write itself to

> hard
> > disk, and decrypt it when it's executed next time. I met a problem when
> > trying to modify itself. Windows said, 'The instruction at "0x00411dcf"
> > referenced memory at "0x004113ac". The memory could not be "written".' I
> > know it must be related with current windows kernal or CPU mode, but I

> don't
> > know more deeply, could you give me some hints? And how to solve it?
> >
> > Thanks.
> >
> > Ray
> >
> >