How to enable Code section (Read / Write) in x64

[New Tiger]

Anyone have an example on how to enable Code section (Read / Write) in x64 please?
Thanks

[Stingered]

Are you talking about the section headers? If so, then CFF explorer has this option to enable/disable the sections flags. Apologies if I misunderstand your question.

This might help you:

https://github.com/OsandaMalith/PESecInfo

[New Tiger]

Originally Posted by Stingered

Are you talking about the section headers? If so, then CFF explorer has this option to enable/disable the sections flags. Apologies if I misunderstand your question.

This might help you:

https://github.com/OsandaMalith/PESecInfo

Thanks for your reply. I tried already CCF and Stud_PE. Both show that the section flag for read and write are already ticked, meaning you can write to the specified section but no way. I tried also to patch the VirtualProtect function using the same way in x32 OS's but it always returns zero !!!!
I used the same way as below:

PUSH ESP
PUSH 40 // code writable
PUSH 1000 // size of code to make writable
PUSH 401000 // start address of code to make writable
CALL VirtualProtect // xxxxxxxx is address of VirtualProtect

I did this in several x32 app's and worked just fine but in x64 no way

[Kerlingen]

Based on the original question, there are two ways:

• Use the VirtualProtect function to make the memory region writable.
• Edit the PE file header on disk and make the sections writable.

Both methods have been successfully used many times by many people.

Based on your second post, the most promising answer would be:

• First, read a book about x86 assembler.
• Next, read a book about Win32 programming.
• Next, read a book about x64 assembler.

Your very short text and code fragments already violate at least 4 core principles of x86/Win32/x64 assembly. Your problem definitely is not some write permission, but the basic understanding of the CPU architecture.

[New Tiger]

Originally Posted by Kerlingen

Based on the original question, there are two ways:

• Use the VirtualProtect function to make the memory region writable.
• Edit the PE file header on disk and make the sections writable.

Both methods have been successfully used many times by many people.

Based on your second post, the most promising answer would be:

• First, read a book about x86 assembler.
• Next, read a book about Win32 programming.
• Next, read a book about x64 assembler.

Your very short text and code fragments already violate at least 4 core principles of x86/Win32/x64 assembly. Your problem definitely is not some write permission, but the basic understanding of the CPU architecture.

From this "Your very short text and code fragments already violate at least 4 core principles of x86/Win32/x64 assembly", It's clear that your brain is full with junky stuff sir!.
Also, based on yor answer, Mr VIP, in particular the last line "Your problem definitely is not some write permission, but the basic understanding of the CPU architecture" can you teach me Mr professional these fundamentals. Understand the question before you show off your muscles. It's real useful for you to keep this advice for your own as when I was handling these x32 stuff you were still asking for suckle, I don't know how admins promoted you to VIP here???????
Just get away! you're really very rude

[Stingered]

@New Tiger

Take a look at this link and see if it helps:

https://ethical.blue/textz/n/28

[Rasmus]

Originally Posted by New Tiger

Thanks for your reply. I tried already CCF and Stud_PE. Both show that the section flag for read and write are already ticked, meaning you can write to the specified section but no way. I tried also to patch the VirtualProtect function using the same way in x32 OS's but it always returns zero !!!!
I used the same way as below:

PUSH ESP
PUSH 40 // code writable
PUSH 1000 // size of code to make writable
PUSH 401000 // start address of code to make writable
CALL VirtualProtect // xxxxxxxx is address of VirtualProtect

I did this in several x32 app's and worked just fine but in x64 no way

With my limited knowledge I will try to help
@New Tiger The calling convention in 64-bit is different from that of 32-bit.

The x64 Application Binary Interface (ABI) uses a four-register fast-call calling convention by default. Space is allocated on the call stack as a shadow store for callees to save those registers.

Meaning that the parameters are passed to the function through registers as a default which differs significantly from the 32-bit manner where the stack can be wholly used for passing the parameters.

Example:

func1(int a, int b, int c, int d, int e, int f);
// a in RCX, b in RDX, c in R8, d in R9, f then e pushed on stack

The addresses and registers in your example are also 32-bit. Maybe my mistake but you should check them once again

Please read these 2 pages for more info:

https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170
https://accu.org/journals/overload/22/120/orr_1897/

They highlight the differences in the 64-bit calling conventions.

Then the VirtualProtect should work just fine in 64-bit also

[New Tiger]

@Stingered
Thanks mate for the provided link.
@Rasmus
Appreciated, really useful information mate.

[New Tiger]

Problem is solved

[WRP]

I think this Tiger trying break brains.
But possible he banned in Google.

[New Tiger]

Originally Posted by WRP

I think this Tiger trying break brains.
But possible he banned in Google.

Really, are you sure?

Where are the admins?
Isn't this a false accusation and defamation

[chessgod101]

Hi New_Tiger,
I think it would be easier for people to help you if you were to post the assembly code you were using in x64 to attempt to solve this. Since you only provided the code in 32 bit assembly, we are left only to speculate what the issue could be. Anyway, since you posted the screenshot of what you were doing, it is clear that you were using the wrong calling convention. In x64, parameters are not passed to the WINAPI using the STDCALL convention, but rather a FAST CALL convention. Your code show be something like the following:

MOV ECX, ADDRESS_OF_SECTION
MOV EDX, SIZE_OF_SECTION
MOV r8d, NEW_PROTECT_CONSTANT
MOV r9, Address of an empty dword where the old_protect is returned
CALL VirtualProtect

[New Tiger]

Originally Posted by chessgod101

Hi New_Tiger,
I think it would be easier for people to help you if you were to post the assembly code you were using in x64 to attempt to solve this. Since you only provided the code in 32 bit assembly, we are left only to speculate what the issue could be. Anyway, since you posted the screenshot of what you were doing, it is clear that you were using the wrong calling convention. In x64, parameters are not passed to the WINAPI using the STDCALL convention, but rather a FAST CALL convention. Your code show be something like the following:

MOV ECX, ADDRESS_OF_SECTION
MOV EDX, SIZE_OF_SECTION
MOV r8d, NEW_PROTECT_CONSTANT
MOV r9, Address of an empty dword where the old_protect is returned
CALL VirtualProtect

Thanks for your clarification, I admit that my knowledge is very limited in x64 but what it got me out of the mode is some vulgar posts.

Once again, thanks and do apologize!

[chants]

However if you are dealing with Linux and 64 bit ELF files, the advice is similar but the headers and format different. Instead of VirtualProtect there is mprotect, etc. Based on responses, it's clear everyone here still uses Windows, myself included.

Also at ring0 there exists possibility of modifying page tables and changing the protection directly without using the OS API wrappers for this purpose.

The 32 bit calling conventions include fastcall, register, vectorcall and thiscall which do use registers. Sure cdecl and stdcall or Pascal conventions are common, but it's incorrect to say it doesn't use registers. Those conventions exist on a multitude of compilers. By 64 bit era there are so many registers added beyond there mere double bitwidth that for performance reasons there was no reason to keep stack only methods.

[New Tiger]

I was not aware of the calling convention in x64 but with the aid of the provided references I could solve the issue.