Exetools

Exetools (https://forum.exetools.com/index.php)
-   General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)
-   -   How to enable Code section (Read / Write) in x64 (https://forum.exetools.com/showthread.php?t=20459)

New Tiger 02-20-2023 23:20

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

Stingered 02-21-2023 00:33

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 02-21-2023 01:40

Quote:

Originally Posted by Stingered (Post 127202)
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 02-21-2023 02:40

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 02-21-2023 05:11

Quote:

Originally Posted by Kerlingen (Post 127205)
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 02-21-2023 06:35

@New Tiger

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

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

Rasmus 02-21-2023 06:52

Quote:

Originally Posted by New Tiger (Post 127204)
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:
Quote:

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:
Quote:

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 02-21-2023 07:22

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

New Tiger 02-21-2023 14:47

Problem is solved

WRP 02-22-2023 02:16

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

New Tiger 02-22-2023 02:55

Quote:

Originally Posted by WRP (Post 127216)
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 02-22-2023 03:25

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 02-22-2023 03:36

Quote:

Originally Posted by chessgod101 (Post 127220)
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 02-23-2023 06:08

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 02-23-2023 06:25

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


All times are GMT +8. The time now is 08:17.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2026, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX