PatchMe No.1 2024 (x86 32-Bit)

PatchMe.exe

MD5: DD4E072F8B5CA241927EAA63DED47383
SHA1: 08F4699C3A84F5E40343CE9A9AD05046EE15D6DD
CRC32: 9A4C0721

PatchMe No.1 2024

Please check the ReadMe.mp4 in the zip package, you'll understand what I mean...
If you have solved this challenge, please make tutorial(s)...  I will mark the answers with tutorials as a solution.

About This Challenge...
 - Author: boot
 - Date: February 10, 2024
 - Difficulty: ★★☆☆☆
 - Architecture: x86 32-Bit
 - From: Tuts4you
 - Platform: >=Win95

File Information

Submitter boot

Submitted 02/10/2024

Category CrackMe

View File

@boot 

Quote

First try to use Ring3 mode to modify memory if failure then try to use Ring0 mode to modify memory...

Do you mean using the M$ windbg by saying "Ring0 mode"?

Regards.

sean.

You could try the glorious SoftIce 37 years old (wow!) kernel mode debugger if you dare to

 

33 minutes ago, jackyjask said:

You could try the glorious SoftIce 37 years old (wow!) kernel mode debugger if you dare to

 

No joking please.

Regards.

sean.

Quote

 

no jokes

Install VM

install win XP

have some fun as a real oldschool hacker

 

dont be tiktok newbee

2 minutes ago, jackyjask said:

不开玩笑

安装虚拟机

安装 Win XP

享受真正的老派黑客乐趣

别当新手

Use Amiga computer

On 2/11/2024 at 5:57 PM, windowbase said:

Do you mean...

It is theoretically impossible or very difficult for typical debuggers (Olly, xDbg) or patch tools (Baymax, Dup) to modify the memory of "Current Address:", so you need other methods to achieve it.

3 minutes ago, boot said:

It is theoretically impossible or very difficult for typical debuggers (Olly, xDbg) or patch tools (Baymax, Dup) to modify the memory of "Current Address:", so you need other methods to achieve it.

Hmm. so you say Ring0 debugger. I see.

Regards.

sean.

I provide some tips: typical Ring3 methods cannot directly solve this challenge. Therefore, you can try coding kernel drivers to modify memory and solve this challenge.

5 hours ago, boot said:

I provide some tips: typical Ring3 methods cannot directly solve this challenge. Therefore, you can try coding kernel drivers to modify memory and solve this challenge.

Nice trick 

May be I will analyse when I have free times and it seems very good.RWE>R_E.

Just hooked NtReadVirtualMemory and changed the first byte to 0x00 and it gives success.

43 minutes ago, HostageOfCode said:

Just hooked NtReadVirtualMemory and changed the first byte to 0x00 and it gives success.

This is an indirect method. But what if you run the program directly, wait for it to start completely, and then modify the memory of "Current Address"? In other words, run the program first, and then try to directly modify the memory.

e.g.

Edited February 21, 20241 yr by boot

Tried but it does not let me to change the page protection. Tried to hook NtProtectVirtualMemory but it is too hard this way... I saw that you create and load a second shadow ntdll.dll that redirects some of the ntdll api to the vmp section of the patchme. Clever trick

i used an old tool 😁

 

PatchMe_PROCESS_WRITE_by_terco.txt

Amazing stuff!

it is your own build of old good Olly?

1 hour ago, jackyjask said:

it is your own build of old good Olly?

yes.... 😉 old but Gold

Hi. I never expected this challenge to be solved by using IceSword before. If it is a 64-bit PatchMe, can it still be solved by using IceSword?

39 minutes ago, boot said:

64-bit PatchMe...

PatchMe64.zip

19 minutes ago, boot said:

PatchMe64.zip 4.58 MB · 0 downloads

Why need after allocate memory calling ReadProcessMemory and GetThreadId everytimes to make the memory unwritable?

 

1 hour ago, boot said:

PatchMe64.zip 4.58 MB · 2 downloads

In x64 bit OS, the icesword doesn't run.

Regards.

sean.

7 hours ago, boot said:

PatchMe64.zip 4.58 MB · 3 downloads

Is there a way of contacting you privately to discuss something?

Freddy,

After understanding the principle of map, remapping can solve the problem under r3. I have added this corresponding anti debugging to my x64dbg