Binary Patching (binary write)

[dashne]

Problem Description

Hi every one, is there any chance to support binary patching like version 1.0? I mean without validating the file structure when saving the file, because the process of saving of obfuscated file will failed when checking the structure of the assembly, this would not be happened in v 1.0

Thanks

Proposal

Binary patching

Alternatives

No response

Additional Context

No response

[Washi1337]

There are currently no plans for quick binary patching in AsmResolver, but many of the original structures are preserved when using a lower level of abstraction such as AsmResolver.PE instead of AsmResolver.DotNet.

What issues are you running into when saving the binary?

[Washi1337]

Win32Assembly is no longer part of the latest version of AsmResolver. You will need to use use PEImage if you want to use the lower level access on the PE or .NET metadata, which is the closest thing you will get to patching a PE

Relevant docs on how to use PEImage:

• https://asmresolver.readthedocs.io/en/latest/peimage/advanced-pe-reading.html#custom-error-handling
• https://asmresolver.readthedocs.io/en/latest/peimage/basics.html#writing-a-pe-image
• https://asmresolver.readthedocs.io/en/latest/peimage/pe-building.html#pe-file-building

[dashne]

Thank you, the file now work but size of file is different from than the origin file, I wonder why?
here is the Code:
var path = @"...\FileCleaner.exe";' 'var pathout = @"...\FileCleaner1.exe";' ' var bag = new DiagnosticBag();' ' var image = PEImage.FromFile(path, new PEReaderParameters(bag));' 'var builder = new ManagedPEFileBuilder();' ' var peFile = builder.CreateFile(image);' ' using (var f = File.Create(pathout))' ' {' ' var stream = new BinaryStreamWriter(f);' ' peFile.Write(stream);' '}
origin file:
FileCleaner.zip
saved file:
FileCleaner1.zip

[Washi1337]

There are a couple of reasons this happens for your target sample.

The new executable that was constructed is not a byte-patch from the original, but something relatively close to it. The way ManagedPEfileBuilder works, is that it pulls data from all the properties defined in the PEImage instance you made from reading the file, and then makes an assessment on how a new PE file might look like with those properties as contents. It will then reconstruct a new PE file by arranging all these segments into new PE sections as it sees fit (see ManagedPEFileBuilder.cs for an exact description on how it does this). This means that it may decide to place some segments within the PE in a slightly different place than its original place, and/or strip some information that it deemed unused. However, the contents of these segments do remain (apart from perhaps a couple RVAs and sizes) intact.

This is also the case for your sample binary. For instance, the original file contains an extra (redundant) .reloc section, which is not referenced in the PE header as a base relocation directory. The ManagedPEfileBuilder therefore did not include this in its final file, because it was never parsed to begin with (and used by the Windows PE loader anyway). Furthermore, it also seems the new .text section is slightly smaller. This might also be an effect of some reshuffling of some of the segments within the original .text section, that resulted in a slightly more compact version of the .text section that you started with.

These changes should not have any impact on the final binary, so long the final binary does not depend on the exact structure of the PE. Most .NET binaries don't rely on these kinds of raw structures, but this may happen of course with some obfuscated binaries that try to pull data from custom sections (e.g. binaries protected with VMProtect sometimes do this). If you want to pull in the extra sections, you will need to customize the PE file building process, which may involve making your own PEFileBuilder class, or extending ManagedPEFileBuilder by overriding some of the methods it defines.

[dashne]

is there any sample code to force the PEFIleBuilder or ManagedPEFileBuilder to write the file without those changes?

[Washi1337]

It's just not how the current builders operate, or how AsmResolver is designed. There are plans for builders that will try to preserve even more than the current one already does, but as of right now it isn't really possible without some manual labour.