Map2Dbg 1.3 and 1.4 both actually alter the original target binary when converting its MAP

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Note date last modified of and generate Hash of target .exe/.dll
2. Run Map2Dbg from either of those two versions I tried
3. Note date last modified changed and if you re-gen hash of original 
.exe/.dll, the hash value is different

What is the expected output? What do you see instead?

I expected simply converting the .MAP to leave the binary itself alone.  
Instead the actual content of a byte in the target .EXE with an offset around 
117 (in the first .EXE I tried with v1.3) actually changed

What version of the product are you using? On what operating system?

1.3 and 1.4.   Win7x64

Please provide any additional information below.

We are trying to use this in an automated dump processing scenario.  There is 
no direct way to guarantee you're using the exact match .MAP for any given 
.exe/.dll binary.  The only things you can go by are names and dates.   We need 
hash the binary, hash the .MAP, generate the .DBG, and retain renamed copies of 
all three with the new names as (for "OriginalName.exe") 
"OriginalName_HashValue.exe", "OriginalName_HashValue.map", and 
"OriginalName_HashValue.dbg"  

We need to be able to pull a problem binary from a server, hash it, and then 
use that has to be absolutely certain we had the appropriate .MAP and .DBG. But 
since Map2Dbg here off of GoogleCode actually changes the .EXE, that complicate 
matching everything up; particularly if you ever re-run the Map2Dbg.   There is 
zero justification for a symbol conversion to change the actual binary, but it 
does.

Original issue reported on code.google.com by riddle...@gmail.com on 2 Apr 2014 at 3:00

[GoogleCodeExporter]

Of course, everything is possible :)

But why not including a version number or hash in the exe itself? (custom 
verion info). 
You can easily fetch it by using TJclPeImage.VersionInfo.Items.
That's the way we do it with our version control system (Plastic SCM) by 
including the changeset number + branch name in the exe, so we know exact which 
source code is used.
The same can you do with a hash or whatever. But you need for example an 
automated build server for that like FinalBuilder.

We also include JDBG in the exe to be 100% sure we have the right debug 
symbols. In the JCL there is a tool to compile/compress a big .map file to a 
.jdbg and add it as a JCLDEBUG section in the .exe.
I also made 2 tools that can be used for this:
- the live stack viewer in my Sampling Profiler
https://code.google.com/p/asmprofiler/wiki/ProcessStackViewer
- offline minidump reader (!)
https://asmprofiler.googlecode.com/svn/trunk/MiniDumpReader/ViewMinidump.exe
These 2 tools both can use the internal jdbg (or other debug symbols) and you 
have full debug info (e.g. line numbers) which you don't have with map2dbg

Original comment by andre.mussche on 2 Apr 2014 at 7:43

[GoogleCodeExporter]

I did finally get a copy of the source and saw this behavior was because 
Map2Dbg always wants to flag the target binary as having debug info stripped.  
While I understand why that might be desirable under some circumstances, I'd 
like to request a change where a command-line option would be added to 
optionally NOT alter the executable.  That would meet our needs and also allow 
other uses to flag the .EXE as was done before.

Original comment by riddle...@gmail.com on 2 Apr 2014 at 7:16