When analyzing binaries, it is important to be able to put what is observed into context. For example, how can CPU instructions be differentiated from data in a binary with a non-standard format? This requires some background knowledge of computer systems in general. I would argue that before any attempt at reverse engineering firmware ...
To convert a raw offset in a PE file to its corresponding "disassembler offset" (known as the virtual address or VA), you need to perform the following steps:
Using a PE editor, look at the PE file's section table to find the section containing the file offset.
For example, let's say your PE file's section table looks like this:
From the Wikipedia article to which you linked:
A binary file is a computer file that is not a text file; it may
contain any type of data, encoded in binary form for computer storage
and processing purposes.
That's what you're seeing in your screenshot above, but the hex editor you're using is displaying binary data (0s and 1s) in hexadecimal form to ...
While in IDA's Hex View you can go to Edit->Patch Program->Change Byte, but I think this only lets you patch 16 bytes at a time. If you need to patch more bytes than that you can use IDAPython's idc.PatchByte / idc.PatchWord / idc.PatchDword to change bytes in the IDA database.
Just a quick note, if you want your patches applied to the original file ...
I published some tools on github which can do just that: https://github.com/nlitsme/pyidbutil and https://github.com/nlitsme/idbutil.
The first is written in python, the second in C++, both have similar functionality.
pyidbutil provides the most low level recovery options: using --pagedump you can dump each page in the file without the need of an intact ...
According to J1708 a message is composed like this:
byte 0 byte 1 byte 2 byte 3 to N byte N + 1
(N not to exceed 20)
MID PID Data Addit. Pids & Data Checksum
The checksum is calculated by adding all the bytes, invert it and add 1. A message is considerid valid if the message bytes + checksum = 0 (512).
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 ...
My first idea would be to perform a frequency analysis on aligned bytes. For most of the assembly languages, the most relevant bytes are aligned on the most significant bits.
So it might be quite easy to create a distinguer that can recognize the type of asm. But, suprisingly, after a few googling, I didn't find any tool or paper about this...
Adding sections to PE files is not always as simple as editing the sections table. Sometimes you'll have to handle several edge cases such as menifest, signatures and other potential end-of-file optional "extensions".
Although LordPE is a great tool, it isn't the best tool for this task. It is too low-level, and doesn't let you create a complete new section ...
Like others I would recommend trying to get the assembly code that computes the checksum. If you obtain that the rest is easy.
However sometimes that can be very hard to obtain, so here are some tips on reverse-engineering checksums without any code.
Remember that a checksum algorithm is a design choice made by engineers, so think about the constraints and ...
The fact that some messages are different sizes leads me to think you might be using the wrong baud rate. J1708 is specified to be 9600/8-N-1, which means you need to ensure you are connecting at that rate (and not, say, 2400 baud). It is also possible that the OCU is using a non-standard serial port configuration, but a standard J1708-derived protocol ...
It seems you're new to Hex. You can think of Hex as a compact form for binary. The following table might help you:
0 hex is 0000 binary
1 hex is 0001 binary
2 hex is 0010 binary
3 hex is 0011 binary
4 hex is 0100 binary
5 hex is 0101 binary
6 hex is 0110 binary
7 hex is 0111 binary
8 hex is 1000 binary
9 hex is 1001 binary
a hex is 1010 binary
b hex is 1011 ...
To determine where the faces/vertices are laid out purely via inspection can be pretty time consuming and hit-and-miss. Given the executable is available that processes these files, I think it's probably a better starting point - it definitively knows how to process the format.
I used IDA Pro to analyse the code in the executable that's involved in loading ...
Since no details about the binary are provided in the question, only a general answer can be given. It sounds like you are trying to statically modify an executable ELF binary. This is also referred to as patching. This is different from dynamic modification, or program runtime instrumentation.
Tools and Examples
Tools that can be used for patching include ...
There is no real prolog in IL code because it does not need to manage the stack, save clobbered registers, or do any other standard bookkeeping necessary in the native code.
However, the bytecode itself is preceded by the method header, and those have a limited number of possibilities. From the book .NET IL Assembler:
Method Header Attributes
if(len(sys.argv) != 2):
sys.exit("usage %s 0xdead" % os.path.basename(sys.argv))
if((sys.argv.startswith("0x")!=True) or (len(sys.argv)!=6 )):
sys.exit("0x prefixed hexinput must be in range 0x0000 to 0xffff padded to 4 digits")
indate = int(sys.argv,16)
year = str(((indate & 0xfe00) >> 9) + 2000)...
The application can check only a part of itself, excluding the checksum part. You can also have a runtime decryption, that will be wrongly decrypted if tampered with. There are several research projects in this area.
The ASEC file is a TwoFish encrypted container which in turn is a dm-crypt volume that gets mounted by Linux's device mapper at /mnt/asec/[app_id] (The AppID is based on the package name). The 128-bit key to the container can be found in /data/misc/systemkeys but this file requires root access for reading. You can read exactly how the encryption works here. ...
I don't know of tools designed for this. In practise, loading it into IDA (or any other disassembler) with different architectures until it looks right is probably the easiest way to do it. You might be able to write a script to automate this.
If you want to build your own tool, I suggest you look at Christopher Domas's talk "The future of RE Dynamic Binary ...
I'm not sure that this is the right place -- StackOverflow would have been a fine place to ask -- but I'll answer anyway. Essentially the issue is that %x treats the argument as an unsigned int. So the value f8ba38ae is the two's complement representation of the original signed int.
You can convert it back easily, though, for example with this Python ...
Unfortunately, I cannot provide answer what to do when your database is already corrupted. That's the nature of proprietary binary databases: if you're hosed, you've got to keep all the pieces.
But I may suggest that you should foresee and be prepared to IDA database corruption, which is imminent and happens sooner or later to almost everyone. So:
This is quite hard question to answer due to variables within reverse engineering.
I would recommend you start off with:
Get some coins or whatever is saved then save the game.
Restart the game and get more coins and save the game.
Replace the new save with your old file.
Does it load? See Answer 1. Otherwise, Answer 2.
Your modified ...
I dont think .NET is as simple.. you can clearly see it in IDA Pro - there at least a few different one byte function prologues.
Why not use a decompiler library for dnSpy/de4dot - dnlib to decompile and then use code clone detection, for example Simian or implement some fuzzy matching (hashing?) algorithm.
.NET generally decompiles nicely when its not ...
It's different, because it isn't just 0x28FA190 + 0x374, but it's *(0x28FA190 + 0x374).
0x28FA190 is a base address, probably of a structure, and 0x374 is an offset, when you sum these values and dereference the result, you get value of a field that's 0x374 bytes away from the beginning of this structure. This field seems to be a pointer, that's why it's ...
Converted to binary with 010 Editor, extracted the strings with Strings, and used some clever regex work with Notepad++ to remove some obvious bad strings. Results below.
Walk the ...
I do not know of a disassembler that will do this, but I have written a Java decompiler that has a bytecode output mode. It is open source, and it would be easy enough to modify to suit your needs. Feel free to check it out here.
(Answer converted from comment)
Recovering the toolchain provenance of the binary code you've specified, at the very least, requires comparing the results of various PIC compilers, I don't know PIC assembly but the last two instructions look interesting for identifying the compiler (Provided your disassembler has misinterpreted the information at 0x38, how ...
Below are two functions from fwrapper that give examples on how to patch IDBs and import data from a file. I'd recommend checking out the code. I use it all the time for samples that decodes/decrypts data or when I have to manually dump a block of memory and patch an IDB.
def patch(self, temp = None):
'''patch idb with data in fwrapper.buffer'''