There are tools for that, as well as a codesign flag --remove-signature
First two should work the same. The codesign flag is undocumented and so YMMV (A user reported in a comment the codesign produced a corrupt executable).
You should use any of them with caution and backup the application before using them.
This option has limited value.
IDA produces executable files only for:
MS DOS .exe
MS DOS .com
MS DOS .drv
MS DOS .sys
Intel Hex Object Format
MOS Technology Hex Object Format
-- IDA Help file
While this is the most promising menu option, it unfortunately is also the most crippled. In a nutshell, it doesn't work for most file types...
Start here--specifically, the third technique: "The CreateRemoteThread & WriteProcessMemory Technique". To quote:
Another way to copy some code to another process's address space and then execute it in the context of this process involves the use of remote threads and the WriteProcessMemory API. Instead of writing a separate DLL, you copy the code to ...
As you need just 2 more bytes, you don't need a large code cave. Out of the box, there are four things you can try:
It's very likely you have a function or 2 in your text segment that are present in some source code, but never called. Look for loc_XXXX labels that have the standard function prefix (push ....,LR) and the suffix (pop ....,PC) a few dozen ...
There is a plugin called Reflexil for Reflector which makes it very easy to patch a .NET binary.
Reflexil is an assembly editor and runs as a plug-in for Red Gate's
Reflector and Telerik's JustDecompile. Reflexil is using Mono.Cecil,
written by Jb Evain and is able to manipulate IL code and save the
modified assemblies to disk. Reflexil also ...
use IDA (why olly only? IDA free might do the trick), or OllyDbg with BeaEngine plug-in (it has some specific ASM syntax options)
improve in the disassembler
rename as many labels as possible, using delta address - it's painful to do that later
export to ASM
rework the ASM syntax to get it re-assemblable
make your ASM code EIP-...
Use JD-GUI to examine the jar file
Unpack the jar file
jar -xf yourapp.jar
Modify the .class file with a Java Bytecode Editor
Use Java Bytecode Editor (JBE)
Repack the modified classes into new archive file
jar -cvf yourapp_patched.jar *.*
Credits for this particular solution to Khai Tran @ NetSPI
Multiline Ultimate Assembler is a multiline (and ultimate) assembler (and disassembler) plugin for OllyDbg. It’s a perfect tool for modifying and extending a compiled executable functionality, writing code caves, etc.
I just downloaded the KB2977629 patch file (IE11-Windows6.1-KB2977629-x64.MSU). It looks like the information about which file corresponds to what is inside the _manifest_.cix.xml file (there is a single, very long, line inside). You have for example:
<File id="214" name="amd64_microsoft-windows-s..-downlevel.binaries_31bf3856ad364e35_6.3.9600....
This error means that the processor tried to access the address at 0x004003F8 and failed. The access type was write.
This can happen because that address's page is protected and cannot be written to, or because the address is unallocated.
I'ts crusial to note that the address, 0x004003F8 is eight bytes before your chosen address (0x00400400). I guess the ...
as i commented to Elians post rasm2 works in windows as is
rasm2 -a arm -b 32 "add r0, r1, r2" will return 020081e0
you can use keystone / capstone to assemble and disassemble
>>> from keystone import *
>>> for i in (Ks(KS_ARCH_ARM,KS_MODE_ARM).asm ("add R0,R1,R2" , 0x400000) ):
... print "%02x " % i
If you have IDA pro, IDA patcher was released recently. While I haven't used it personally, it won one of the Hexrays plugin contests, and is probably pretty reasonable.
There's also this simple python script which I have used in the past:
It's not modern, but it works.
The Android Dynamic Binary Instrumentation Toolkit (adbi) should allow you to do what you need to do.
Simple binary instrumentation toolkit for Android ARM + Thumb.
Instrumentation is based on library injection and hooking function
entry points (in-line hooking).
The toolkit consists of two main components the hijack tool and the
You could also add the DLL to the EXE's Import Table. This has the benefit of not loading the DLL into every process that loads user32.dll (which is an issue with #3), and you can do this Import Table addition easily with a tool like IIDKing:
Low-level details and implementation for patching and intercepting .NET code at runtime: http://www.ntcore.com/files/netint_injection.htm
High-level details and implementation for patching and intercepting .NET code at runtime: http://www.codeproject.com/Articles/16359/MethodLogger-Hook-into-method-calls-in-NET-binarie
You don't have to use separate program to patch in ida.
Simple select/highlight in ida-view where you wanna patch, then in Edit(menu)>>patch byte
Then after you are done patching what you need, Edit(menu>>apply patches to input file.
I usually keep the backup ( you get a option for that)
To me it seems the best way to approach this, if planned changes are considerable, is to instead create a DLL (you seem to be discussing windows, although this could work in most environments).
Then, you'll only need to patch calls to your modified or new functionality functions. Either by first editing the Import Table or by dynamically loading your DLL ...
Try using dnSpy. It includes an ability to inject the recompiled code, and has the same interface as ILSpy. Use "Edit Method" option on the method you're editing, then "Build" and save the assembly. You won't need Reflexil then.
ah, to create code there is:
The last question, when I'm trying to create data from code I'm getting False:
Python>create_data(here(), FF_BYTE, 0x79, 0)
This is because I need previously del_items()
MIDI data bytes are 7 bits, meaning they can have decimal values from 0 to 127.
In a 7-bit binary number:
the bit on the right represents a decimal value of 1.
the next bit to the left represents a decimal value of 2.
the next bits to the left represent decimal values of 4, 8, 16, 32, and 64.
Decimal values from 0 to 127 can be expressed in seven ...
There are a few really great options.
First, something that I frequently forget when doing patching is that LD_PRELOAD makes hooking/redirecting library routines very easy.
If you must patch instructions, the tools that I use on a regular basis are pwntools (a Python library) and Fentanyl (an IDAPython script).
For pwntools, the following would be an ...
Here's what i did some time ago, when i had your problem.
Use dependency walker to find a DLL that's imported by the main executable, from which the .exe imports only one or two functions. For the sake of example, let's assume your application someprog.exe used a dll vendor.dll, from which it imports the ShowCopyright function.
Using a hex editor, change ...
Exporting the file to ASM then re-compiling takes a very long time, is very complicated and should be only done if you have a decent active intelligent group. Believe me, I have done this. We reverse engineered a program back to compilable source. This project took way too long.
If your changes were minor, I would recommend codecaving. Just create a PE ...
There are several ways to achieve this:
Decompile .class to .java source (not necessarily original source, but equivalent), make your changes, compile again. There are many Java decompilers out there, I won't list them all.
Disassemble .class to "assembly" (usually Jasmin syntax), modify it, assemble back. Krakatau is a good tool that should be able to do ...
Can you post the classfile, as well as the changes you want made to it? Depending on the changes, it should be possible. Obviously if you want to add a lot of new code or data, that won't be possible without changing the size, unless you delete a corresponding about of existing code from the classfile.
Anyway, Krakatau is capable of editing a classfile ...
You get the “x/y patches applied” message when you try to patch at a virtual address that has no file offset associated with it.
Generally this happens if you add code at the end of a section. In rare cases it could be that there is a bug in converting the virtual addresses to file offsets. If you think that is the case, provide the relevant binary and ...
You are absolutely on the right track
A* a = new A();
Is not going to bother with the vtable at all. Because a can only be of A type. MSVC will still create the vftable, but in that context a->doThing() will just become A::doThing()
Here, I fixed up your example into my own to demonstrate that you were correct, you just ...