Can Win32 apps have and use data in the code section ?

Thanks.

.DATA

.CODE

Start:

jmp    short ready
;mark    db "start",0
number  dw  8

ready:

mov  cx,word ptr

invoke ExitProcess, 0

END Start
Posted on 2007-05-30 10:55:15 by skywalker
Yup, remember it's a flat memory model :)



Posted on 2007-05-30 12:37:12 by Ultrano
Remember that, in most cases, data in the code section is "read only". You may not be able to alter it with your program.

Raymond
Posted on 2007-05-30 13:03:55 by Raymond
sure u can

virtualprotect

and/or mark the section as read, write, execute...

again, skywalker your queries really raise some serious questions as to the nature of your inquiries.....
Posted on 2007-05-30 16:36:06 by evlncrn8

again, skywalker your queries really raise some serious questions as to the nature of your inquiries.....


... personally i can see many reasons for this question that are well within the scope of this board such as

minimizing file size
SMC for file protection

take the following example


push 0
call @F
db "test",0
@@: call @F
db "test2",0
@@: push 0
Call MessageBoxA
Posted on 2007-05-30 19:13:44 by paradox

Remember that, in most cases, data in the code section is "read only". You may not be able to alter it with your program.

Raymond



I am assimilating help I have received. I believe that code can be injected but I looked at that and it is way too complicated. As another poster said, I want to protect/and or slow down DD.(disassembler dudes).

You can put data in a 16 bit program and use it freely. I just want to know if it can be done in a 32 bit app.

Thanks for not thinking the worst. :-)

Take care.
Posted on 2007-05-30 20:26:46 by skywalker


again, skywalker your queries really raise some serious questions as to the nature of your inquiries.....


... personally i can see many reasons for this question that are well within the scope of this board such as

minimizing file size
SMC for file protection

take the following example


push 0
call @F
db "test",0
@@: call @F
db "test2",0
@@: push 0
Call MessageBoxA


Thanks, I will look at it.

Andy
Posted on 2007-05-30 20:28:05 by skywalker

sure u can

virtualprotect

and/or mark the section as read, write, execute...

again, skywalker your queries really raise some serious questions as to the nature of your inquiries.....


There you go with the negative vibes. :-)

Posted on 2007-05-30 20:31:22 by skywalker
There's fundamentally no difference between code and data segments except for the 'permission flags on memory pages', as mentioned by evlncrn8.
These flags include Read, Write and Execute permissions.
With the appropriate flags set, you can do weird stuff, like execute code in a non-code segment (eg data segment).

There's actually two ways to alter these page permissions.
evlncrn8 mentioned one of them, VirtualProtect(Ex) api function can be used to change the permissions at runtime. But there's another way.
You can modify the permissions of the FileSections in the PE file header.
The Windows PE Loader sets the permissions for segments based on the permissions that the corresponding filesection has.
Memory Segment(s) directly inherit the permissions of the corresponding FileSection(s) in the PE File Header.


Posted on 2007-05-31 22:47:21 by Homer
Look up the /SECTION argument for link.exe , if you don't want to do without VirtualProtect.

Imho, you should stay away from self-modifying code, and if you need to construct code at runtime, use VirtualAlloc with READWRITE permissions, construct the code, then use VirtualProtect to toggle to READONLY+EXECUTE.
Posted on 2007-06-01 06:21:25 by f0dder
Windows OS can not be using Paging mechanisms for allowing a page be an executable page. A page can only be set as Present/Not present, Read Only/Read and write and 7 other flags (total number of 9 flags can be set for each PTE (Page Table Entry) and also for each PDE (Page Directory Entry)). Windows must be using the Type field of the segment descriptor for each segment selector in the GDT to prevent something in the data segment to be executed (Bits 8 to 11 inclusive for each Segment Descriptor).

If you invoke the CreateThread Win32 API and trace the code down to NTDLL.dll you will see how the Windows Scheduler puts threads in a queue for the scheduler to pick in its next shot. The Windows' scheduler does not update the CS field of its processes' structure so you should not be able to change the code segment. When you jump to a data in the data segment, you are NOT executing the stuff in the data segment because only codes in the code segment will be executed and the data/code in the data segment will be accessed (read from and/or written to). The CPU uses the CS segment selector to execute code and not DS. So it doesn't matter what you put in DS, it should not get executed.

Finally, I think Win32 APPs *are* allowed to use the CS as DS because AFAIK, the Type field of the segment descriptor of the CS in the GDT/LDT is set to 1010b (Not tested on XP) which is for Code Segment -> Execute/Read so you must be able to access data in the CS.
Posted on 2007-06-01 06:28:45 by XCHG

Windows OS can not be using Paging mechanisms for allowing a page be an executable page.

Wrong, since the NX bit was introduced, it can. It requires being in PAE mode though, and it requires CPU support (though there's some emulation methods that The Owl + friends originally camed up with (and got ripped off by OpenBSD, MS, etc) that can give similar effects at a cost).

Even though the CS,DS,ES,SS selectors all point to the same memory space (base0 limit4g), you can never write with a CS: override, that's hardwired in the CPU. Page permissions are what's interesting in a flat linear memory model operating system, anyway.
Posted on 2007-06-01 06:57:22 by f0dder
Thanks for all the info. I will study and do a search for example code.

The only self modifying code I have is a counter value in a 16bit example that
increments a counter in the program itself each time the program is run.

Andy
Posted on 2007-06-01 07:27:08 by skywalker
Does Windows XP use Physical Address Extension? I don't think so!
Posted on 2007-06-01 07:56:53 by XCHG
If you have a CPU with NX bit support and turn on Data Execution Prevention, it does...
Attachments:
Posted on 2007-06-01 08:10:48 by f0dder
No mine is not using PAE as I guessed and so I was not wrong about Paging protection mechanism. I think the best way is to use the Type bits on the Segment Descriptor in the GDT/LDT to protect a segment's content to be written to. Windows could also be using those 3 available bits of each PTE to put some flags for each of the PTEs (Bits 9 to 11). Whatever mechanism Windows is using I don't think I could care less about it  :lol:
Posted on 2007-06-01 08:53:53 by XCHG
Well, then you don't have a CPU with NX bit support, or you have one but haven't enabled DEP.

And duh, you can't use GDT/LDT to protect anything in a flat operating system.
Posted on 2007-06-01 08:56:29 by f0dder
The Type bits are for protection; why do you they have put it there? Although I am totally against segmentation but those bits can sometimes come real handy!  :P
Posted on 2007-06-01 09:19:48 by XCHG


Imho, you should stay away from self-modifying code, and if you need to construct code at runtime, use VirtualAlloc with READWRITE permissions, construct the code, then use VirtualProtect to toggle to READONLY+EXECUTE.



Well, changing some code to "ro+x" would be fine until someone loaded the exe into something like Ollydbg, and clicked "Set Access" -> "Full Access".
Posted on 2007-06-02 07:44:38 by skywalker
skywalker: that's not the point of page protection... it's to prevent against erroneous code, some types of program exploits, etc.
Posted on 2007-06-02 10:22:07 by f0dder