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 ...
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 ...
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 ...
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 ...
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 ...
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:
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)...
This is only a partial answer but the data at offset 0x100 looks very much like that produced by Microsoft's C++ MFC serialization.
Specifically, the FFFF is a 'new class tag' followed by -
0001 a schema version
0011 length of class name
'CSampleBackupFile' class name (using naming convention consistent with MFC's)
Decent information on MFC Serialization ...
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. ...
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 ...
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 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 ...
Well, you have several options to do so. These are the two simplest:
Supplying the input through the pipeline:
$ python -c "print '\xde\xad\xbe\xef'" | ./binary
$ python -c "print 0xdeadbeef" | ./binary
Supplying the input from within GDB:
(gdb) r <<< $(python -c "print '\xde\xad\xbe\xef'")
(gdb) r <<< $(python -c "print 0xdeadbeef")
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 ...
The data are floating point encoded on 32 bits Little_endian
byte 0 to 3: 00 00 00 00 = 0 channel number
byte 4 to 7: 1f 85 a3 41 = 0x41a3851f = 20.4400005341
Some preliminary notes only – may evolve into a complete answer.
My approach was the following. Clearly, the numbers at the end are floating point numbers. Also, they are not all floating point; the sequence 0C 00 00 00 a few bytes in is not a reasonable floating point number. Counting off to the next "unreasonable" value (which happened to be 0C 00 00 00 ...
One of the close reasons on Reverse Engineering is:
Questions asking for help reverse-engineering a specific system are off-topic unless they demonstrate an understanding of the concepts involved and clearly identify a specific problem.
... and you don't appear to understand the "concepts involved". This is because I asked for a "binary", and you posted ...
This is always a 1:1 ratio. 0x60 is a byte 0110 0000 always. Its very beneficial to understand that everything just comes back to binary. The rest is all just representations. There is no difference between 'A', 0x41, and 0b01000000. You will have to put the leading zero infront of your example, although compilers could assume, that i'm not sure of) but ...
This is an encrypted message (hex-encoded, your guess is correct). The cipher is very weak.
As far as I understand there is at least one more additional challenge after this one.
If you want to learn more about working with challenges like this I'd suggest you to try "Matasano crypto challenges".
Update: I've done a write up on the entire file format here: http://www.tkte.ch/2017/02/27/air-strike-3d.html
These files aren't compressed, so don't worry about that. Since all you want to do is extract those waves we can cheat (a lot) and ignore everything else. Lets do a naive check:
> strings -n 4 pak2.apk | grep RIFF -c
> strings -n 4 pak2....
This is not the pascal/delphi string format, as those are either constant 1 byte or 4 bytes long length fields.
It does have some resemblance to the ASN1 format, except ASN1 comes with an additional field denoting the type of the object.
Anyways, This looks like the Most significant bit of the first byte is not part of the length and has the special ...
From what I can see, it appears to be a binary image for a MIPS processor (big endian). The image appears to be loaded at offset 0x80000000. There is a subroutine at 0x80001d70 offset which prints out the initial "Start to decompress!" message at PC 0x80001e38. Hopefully that should get you started.
I'd recommend using something such as OllyDbg or IDA PRO rather than just plain HexEditor since just using HexEditor you've got no idea what section of the PE you are editing. For example, you could be editing the .text PE section and editing an essential part of the program rather than .idata or .data section which just store variable data.
So, few methods ...