I would like to learn how to patch and save an exe that I have made and opened and have it save the changes.
The rules of the forum (http://masm32.com/board/index.php?topic=4.0)
I read the rules.
Nothing in there about what I am asking for.
There is even a similar message in the old forum archive asked by Japheth.
Andy
Surely, Andy, at your age you should not start to compete with the script kiddies :eusa_naughty:
We are all very curious here: Why don't you just change the source code?
include \masm32\MasmBasic\MasmBasic.inc ; download (http://masm32.com/board/index.php?topic=94.0)
Init
Inkey "Hello World"
Exit
end start
include \masm32\MasmBasic\MasmBasic.inc ; download (http://masm32.com/board/index.php?topic=94.0)
Init
Let esi=FileRead$("HelloWorldA.exe")
mov eax, Mirror$("o Wo")
mov ecx, LastFileSize
sub ecx, 3
.Repeat
dec ecx
.Break .if Sign?
.Until eax==[esi+ecx]
.if !Sign?
mov dword ptr [esi+ecx+2], Mirror$("Andy") ; patch it!
mov byte ptr [esi+ecx+6], " "
.endif
Open "O", #1, "HelloWorldB.exe"
PrintBuffer #1, esi, LastFileSize
Close #1
Launch "HelloWorldB.exe" ; test it!
Inkey
Exit
end start
Quote from: Magnum on December 01, 2012, 01:41:20 PM
There is even a similar message in the old forum archive asked by Japheth.
Would be interesting which message you mean. Might very well be possible, though - because I may have read the "forum rules" once and then forgot them - or perhaps I tend to interpret rules somewhat differently.
What's even more interesting ( at least for me ) is why I am a "guest" in the old forum. IIRC there was no possibility to "deregister" your own account. I surely didn't ask to be deregistered, so somebody must have done this on his/her own. Why?
> What's even more interesting ( at least for me ) is why I am a "guest" in the old forum.
Its a malicious plot that came from having to reconstruct the old forum on a much later 64 bit server on the other side of the world. It is now only an archive and no-one can register, deregister or post.
Andy,
Patching an EXE is easy, while it is not running open it as a file, move the file pointer to the offset you require then write the bytes you require at that address. Alternately you can load the whole file into memory, patch it in memory then write it back to disk.
Hi Magnum,
As Hutch explained, it's an easy task. You can code your own patcher. Have a look at the file functions in the masm32 library.
Andy,
I've done a similar task some years ago. The point was: PowerBASIC for DOS was a real mode compiler, so it produced exe files for real mode or V86 mode. Addresses over 1 MB couldn't be accessed. On the other hand, it was very easy to switch the program into the protected mode. But once there, it was impossible to use the PowerBASIC RTL in protected mode, because the addresses, for example for the PRINT, was segment:offset and in the protected mode it must be selector:offset.
My solution was to write a small starter program which established the protected mode and after that, the starter changed the real mode addresses in the exe file into valid protected mode addresses. That strategy worked well.
Gunther
Quote from: hutch-- on December 01, 2012, 07:47:01 PM
> What's even more interesting ( at least for me ) is why I am a "guest" in the old forum.
Its a malicious plot that came from having to reconstruct the old forum on a much later 64 bit server on the other side of the world. It is now only an archive and no-one can register, deregister or post.
Andy,
Patching an EXE is easy, while it is not running open it as a file, move the file pointer to the offset you require then write the bytes you require at that address. Alternately you can load the whole file into memory, patch it in memory then write it back to disk.
I just want my program, based on what is in one particular register and in one memory location, to change a few things in my data section and replace a few statements in one procedure and then write it back to disk.
I understand that I will have to carefully determine the exact positions in the exe where to write the data so as not to overwrite the wrong code, write past the boundries, and other things I have not learned about yet.
I have been and continue to do a lot of studying and appreciate all the help I have gotten from everyone here.
I suspect that Right*rocessMemorex and &irtualPro%%ct may have done that in a test program I made which resulted in a problem
until I rebooted.
I used to not think much about Dr. Watson, but it's user dump etc. spotted some problems that even Olly couldn't find when I had it as my JIT debugger. :-)
Andy
If I patch it in memory and write it back
Quote from: jj2007 on December 01, 2012, 06:22:25 PM
Surely, Andy, at your age you should not start to compete with the script kiddies :eusa_naughty:
We are all very curious here: Why don't you just change the source code?
include \masm32\MasmBasic\MasmBasic.inc ; download (http://masm32.com/board/index.php?topic=94.0)
Init
Inkey "Hello World"
Exit
end start
include \masm32\MasmBasic\MasmBasic.inc ; download (http://masm32.com/board/index.php?topic=94.0)
Init
Let esi=FileRead$("HelloWorldA.exe")
mov eax, Mirror$("o Wo")
mov ecx, LastFileSize
sub ecx, 3
.Repeat
dec ecx
.Break .if Sign?
.Until eax==[esi+ecx]
.if !Sign?
mov dword ptr [esi+ecx+2], Mirror$("Andy") ; patch it!
mov byte ptr [esi+ecx+6], " "
.endif
Open "O", #1, "HelloWorldB.exe"
PrintBuffer #1, esi, LastFileSize
Close #1
Launch "HelloWorldB.exe" ; test it!
Inkey
Exit
end start
Now be nice.
After you read my recent post, maybe you will rethink your statement about my age and script kiddies.
Sometimes I think the worst in situations until some time has passed to think about it.
Take care,
Andy
Quote from: Gunther on December 01, 2012, 10:01:55 PM
Andy,
I've done a similar task some years ago. The point was: PowerBASIC for DOS was a real mode compiler, so it produced exe files for real mode or V86 mode. Addresses over 1 MB couldn't be accessed. On the other hand, it was very easy to switch the program into the protected mode. But once there, it was impossible to use the PowerBASIC RTL in protected mode, because the addresses, for example for the PRINT, was segment:offset and in the protected mode it must be selector:offset.
My solution was to write a small starter program which established the protected mode and after that, the starter changed the real mode addresses in the exe file into valid protected mode addresses. That strategy worked well.
Gunther
That is interesting Gunther. Will that code still work in XP under cmd ? I still occasionally write some 16 bit code and would be interested in looking at some of that code to learn.
Andy
Quote from: Magnum on December 01, 2012, 11:08:08 PM
Now be nice.
After you read my recent post, maybe you will rethink your statement about my age and script kiddies.
Sometimes I think the worst in situations until some time has passed to think about it.
Take care,
Andy
Andy,
I am about your age so I guess I'm allowed to tease you a little bit ;-)
Take care, too
Jochen
Hi Andy,
Quote from: Magnum on December 01, 2012, 11:13:38 PM
That is interesting Gunther. Will that code still work in XP under cmd ? I still occasionally write some 16 bit code and would be interested in looking at some of that code to learn.
Andy
Sure, because XP supports DPMI.
Gunther
before you spend a lot of time on this, Andy....
i think windows 7 will bark if you alter an executable file
i know that some AV's will flag it as infected
maybe you can make an entry in the registry or alter an INI file that is hidden away someplace :t
Dave,
Quote from: dedndave on December 02, 2012, 03:37:14 AM
before you spend a lot of time on this, Andy....
i think windows 7 will bark if you alter an executable file
i know that some AV's will flag it as infected
maybe you can make an entry in the registry or alter an INI file that is hidden away someplace :t
only some points. It is not necessary to alter the exe file; one can patch the exe during runtime in the RAM. Furthermore, I've strong doubts that native 16 bit code will run under Windows 7 (64 bit). Probably only inside a virtual machine.
Gunther
Quote from: dedndave on December 02, 2012, 03:37:14 AM
before you spend a lot of time on this, Andy....
i think windows 7 will bark if you alter an executable file
i know that some AV's will flag it as infected
maybe you can make an entry in the registry or alter an INI file that is hidden away someplace :t
I am not worried about it running on windows 7. I will insert code to check on Windows 7, and then give a message saying condolences for spending money on it. :t
There is one well known flaw that is present in Vista and Win 7, but not on earlier Windows versions.
Mein Freund,
My code for my project is 32 bit, unless you are talking your older code being run on XP.
Future project is a nanomite.
Andy
Vergessen Sie nicht die 5 Ps. Die richtige Planung verhindert schlechte Ergebnisse.
in that case, you want to read the EXE header in and parse it
there is an MZ section, which has a pointer to the PE section
then, in the PE section is a table that has offsets into the file of the different PE sections
once you find the .DATA section (if that's the one you want), you can go from there with a data offset
what you want is the PE/COFF version 8 spec, which Hutch converted into a nice PDF someplace :P
Is the data offset one of these ?
Characteristics 0xc0000040
SCN_CNT_INITIALIZED_DATA 0x40
SCN_MEM_READ 0x40000000
SCN_MEM_WRITE 0x80000000
PointerToRawData 2048 (0x800)
VirtualAddress 0x403000
VirtualSize 100 (0x64)
SizeOfRawData 512 (0x200)
in this pic, you can see the DOS MZ header, followed by the DOS "stub"
at the end of the MZ header, is an offset to the PE header (00000080h, in this case)
i think it's always at offset 3Ch
following the "PE" marker are some offsets to the different section descriptors
if you follow this link, it will give you more details, i think...
http://mirror.sweon.net/madchat/vxdevl/papers/winsys/pefile/pefile.htm (http://mirror.sweon.net/madchat/vxdevl/papers/winsys/pefile/pefile.htm)
(http://img213.imageshack.us/img213/849/pehdr.png)
If I understand correctly, I am looking for the offset to the .data section.
Andy
yes look at the spec - or that link i posted
after the PE marker, there is a location that will give you an offset (PE-relative) to the section table
there is also an entry that tells you how many sections you have
then, you have to parse to find the .data section header
after the text ".data", there is an offset and size
if you wanted to know where it winds up when loaded, you'd have to calculate the RVA
but, i don't think you have to do that to locate it in the PE file
Andy,
If its a file on disk, the easiest way to locate the section you want to write into is to build the executable with markers in it. Now this can be either data or code sections, for data you make an entry that has a recognisable content, "XXXXXXXXXXXXXXXXXXXXXXXX" etc .... then when you open the file on disk to patch it, you just scan for the marker. If it in the code section that you want to patch then you need to make a jump over a location but the same logic holds, place a marker in a DB block them look for it when patching the EXE.
If its "in memory" patching, we may think you are trying to do something naughty. :biggrin:
Thanks Hutch.
From a previous post I made, I thought it was clear enough to understand.
I have never written nor solicited any code that would harm anyone.
There are some, who know me well, know I can be trusted and have helped me thru PMs.
<I just want my program, based on what is in one particular register and in one memory location, to change a few things in my data section <and replace a few statements in one procedure and then write it back to disk.
Andy
happynews.com
Andy,
Quote from: Magnum on December 03, 2012, 02:38:13 AM
I have never written nor solicited any code that would harm anyone.
I've no doubts about that, because you're a serious coder. I think that Steve made a little joke.
Gunther
we're not worried about you Andy
at least, not for that :P
Quote from: Magnum on December 03, 2012, 12:10:14 AM
If I understand correctly, I am looking for the offset to the .data section.
You can find this information is the section header (IMAGE_SECTION_HEADER.PointerToRawData). See the example in the attachment.
I am having problems with the code.
When I saw inkey, I thought it was a console program.
I have tried assembling it as a console and as a GUI.
I am going to take a break from coding.
Andy
Quote from: Magnum on December 03, 2012, 05:01:34 AM
I am having problems with the code.
OK
Quote from: Magnum on December 03, 2012, 05:01:34 AMI have tried assembling it as a console and as a GUI.
It is a console application that also use a dialog for selecting the file.
Quote from: Magnum on December 03, 2012, 05:01:34 AMI am going to take a break from coding.
:dazzled:
@qWord
I am getting errors as well ......
C:\Masm32\Bin\ML.EXE /c /coff /Cp /nologo /I"C:\Masm32\Include" "C:\PE.asm"
Assembling: C:\PE.asm
C:\PE.asm(131) : error A2008: syntax error : &
fn(5): Macro Called From
C:\PE.asm(131): Main Line Code
C:\PE.asm(144) : error A2008: syntax error : &
rv(5): Macro Called From
C:\PE.asm(144): Main Line Code
C:\PE.asm(145) : error A2008: syntax error
C:\PE.asm(146) : error A2008: syntax error : cbSize
C:\PE.asm(147) : error A2008: syntax error
C:\PE.asm(158) : fatal error A1011: directive must be in control block
Make error(s) occured.
Total compile time 234 ms
Do you have a modified macro.asm by any chance?
I can re-assemble qword's pe without any problem. MASM SDK 11 here.
qWord's PE example build fine here with masm32 version 11.
Microsoft (R) Macro Assembler Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: K:\qword_pe\PE.asm
***********
ASCII build
***********
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Volume in drive K is 2tb_k
Volume Serial Number is 88B3-84DA
Directory of K:\qword_pe
12/02/2012 06:33 PM 4,960 PE.asm
12/04/2012 01:58 AM 4,608 PE.exe
12/04/2012 01:58 AM 4,514 PE.obj
3 File(s) 14,082 bytes
0 Dir(s) 972,622,176,256 bytes free
Press any key to continue . . .
Hmmmm, slightly later, it builds fine but the file open dialog does not display and it always returns with,
no file selected
Press any key to continue ...
Its after 2am so I might have a look at it tomorrow. :P
Quote from: hutch-- on December 04, 2012, 01:58:21 AMHmmmm, slightly later, it builds fine but the file open dialog does not display and it always returns with,
no file selected
Press any key to continue ...
Strange, I've also test it with WinXP and it does work.
Anyone has the same problem?
if i build it with masm32 v10, i get the exact same errors as Heather...
pe.asm(131) : error A2008: syntax error : &
fn(5): Macro Called From
pe.asm(131): Main Line Code
pe.asm(144) : error A2008: syntax error : &
rv(5): Macro Called From
pe.asm(144): Main Line Code
pe.asm(145) : error A2008: syntax error
pe.asm(146) : error A2008: syntax error : cbSize
pe.asm(147) : error A2008: syntax error
pe.asm(158) : fatal error A1011: directive must be in control block
if i build with masm32 v11, no problem
something tells me that Heather is not using the latest version of the masm32 sdk :biggrin:
My Sincere apologies qWord :(
dedndave is right !.... I was using MASM10 I forgot I switched folders .... I was working on something that I needed Kernel32.inc and Kernel32.lib from version 10
Sorry ....
Your example works
Quote from: hfheatherfox07 on December 04, 2012, 06:29:24 AM
dedndave is right !....
that's the first time, this week :lol:
Quote from: qWord on December 04, 2012, 03:09:25 AM
Quote from: hutch-- on December 04, 2012, 01:58:21 AMHmmmm, slightly later, it builds fine but the file open dialog does not display and it always returns with,
no file selected
Press any key to continue ...
Strange, I've also test it with WinXP and it does work.
Anyone has the same problem?
It does the same thing here ....you have to click on it a few times ...and sometimes it just works
I have service pack 2 on my xp ...if that makes a difference
I am assuming it has something to do with the way it handles the file name ....
You get this in the file name box before you select ... always different characters too
p¼§
Quote from: hfheatherfox07 on December 04, 2012, 07:18:48 AM
I am assuming it has something to do with the way it handles the file name ....
You get this in the file name box before you select ... always different characters too
p¼§
yep, I simply forget to write a termination zero in the buffer pointed by OPENFILENAME.lpstrFile.
Quote from: qWord on December 04, 2012, 07:33:10 AM
Quote from: hfheatherfox07 on December 04, 2012, 07:18:48 AM
I am assuming it has something to do with the way it handles the file name ....
You get this in the file name box before you select ... always different characters too
p¼§
yep, I simply forget to write a termination zero in the buffer pointed by OPENFILENAME.lpstrFile.
Works %100 here :t
Works fine on XP SP3.
Yep, works fine here. I don't claim to be coherant at 2am. :biggrin: