I have a binary file for some old music hardware I own that's been out of production for the past 3 years. The company is now bust and no longer exists.
I'm trying to reverse engineer the binary file.
I've tried opening in a hex editor, I can see some ASCII text, but there are lots of symbols and characters in there that make no sense. Does this mean its encrypted?
I've tried to disassemble using gdb but I always get "No symbol table is loaded. Use the "file" command.". If I use the string command at the terminal I can see a lot of strings that are using the software. Again, there is also lots of strings that are not human readable.
Can anyone push me in the right direction so that I can get some workable assembly code for this?
You need some HW knowledge of what CPU/Environment for this binary is used, IDA Pro tool and lots of patience.
Related
In the Xbox 360 game Project Sylpheed: Arc of Deception. There are secret sub objectives for each level. On stage 11 "Flaming Clouds" there are 4, I have found two sources claiming they know each of them, but is actually untrue. One is still hidden. This is a very unpopular game, and no one has investigated it, and I want to know what it is. I have a disk image file of the game (ISO file). How would I go about finding the level trigger for the sub objective? I have already attempted to extract the 7gb iso using 7zip and Winrar, but each yielded the same 12mb files that contain nothing relevant what so ever. Obviously the core of the information is hidden and remains unextracted. Please advise.
https://wincdemu.sysprogs.org/ or linux/mac mount -o loop /path/to/my-iso-image.iso /mnt/iso
from there you're going to need a reverse compiler probabably but I don't know what your game is written in. You might luck out and find the levels coded in lua or something though.
Something else that can be happening is 7zip is actually opening the iso right, and the 12mb could be instructions to go download the actual game code from somewhere else. That sometimes happens with consoles.
I have zero 'hacker' skills and once the code is compiled, the executable is more or less a black box to me.
I am trying to find where a particular line of code ends up in the binary.
This is to test my own code to see how often, where, etc. the code is put in the binary, to test the effects of changes I'm making in both debug and release builds.
I tried adding some code before or after the line I'm interested in. Like so:
char *test = "Tr#ck" ;
but I believe "Tr#ck" is put in the resources somewhere (Is that correct?) so I don't think if I search for this string with a hex editor I will find it where the code really resides ?
So I was wondering if a small piece of assembler code would work instead ?
Something that is totally inert in itself, will not change anything, but is easy to look for with a hex editor ?
(Or 'something' c/c++ that achieves the same.)
Would that work ?
Can you recommend something ?
Never added assembler before, so if that is the solution, kindly provide an example.
FYI, Using Borland C++ Builder 2009.
I'm writing code on C++ that will map to the nearest available drive using "net use * \server...etc" and afterwards I want to open a file on it.
Is there a command that will let me interact with this new drive without needing to know on which drive it was mapped beforehand? (Usually it will be drive Z:, but not always!)
Clearer example:
system("net use * \\server\folder\ p455word /user:server\user /p:no")
(output: "Server succesfully mapped to drive Z:")
Then I would normally try to open the file:
system("Z:\\folder\mydoc.docx")
My question is on how to do this:
system("*\\\folder\mydoc.docx")
With * being whatever the drive the computer chose to map to, or if there's a workaround to this. Thanks!
If you're looking for some net use-specific magic here, you're going to be disappointed. Your program simply passes a text string to the Windows shell, and has no knowledge or information about the command you've performed. It certainly can't pull out status information about the result of that call, beyond reading the command's text output.
Fortunately, the text output is all you need — your quote shows that the assigned drive letter is right there. You just need to pull it out, then construct the subsequent system calls dynamically by building up a string from the now-known drive letter, and the fixed part of your path.
system is not really designed for any of this, though. Here's how to execute a command and retrieve its output. Extracting the drive letter from the string "Server succesfully mapped to drive Z:" would also be a separate question. In general, when you have a problem, break it down into component parts; then you'll be able to "look it up" with success.
Okay so I just made a C++ program that is basically a notebook,
you write stuff in it and it saves it to a .dat file and then you can
read it later.
I compiled it with Microsoft Visual C++ and now I sent it to a friend and it's
saying that it is a virus? I scan it online and it also says that it's a virus.
I don't know why this is happening, as I literally just used some if/else statements, created some strings and used a couple getlines. (and fstream to create the .dat files).
This is the virus report: https://www.virustotal.com/en/file/a1b72280a32915429607fd5abeef1aad4f8310867df1feb7707ea0f7a404026e/analysis/1455735299/
Here is my code. (Its 400+ lines). And I'm almost certain there's nothing wrong
with it. http://pastebin.com/ZwJZrRSu
Any idea why this is happening?
Most probably your PC is already infected by a virus, which adds itself to any executable it can find on your machine. That would easily explain this behavior. Try to compile the same program on PC that is clean for sure and check your PC by antivirus.
I am not sure but I think it because you imported kernel32.dll
Again, it is hard to tell without the source
Also take a look at the file detail in the report
I'm trying to learn the level format in one of my favourite games, which is almost totally undocumented. Basically the only document that describes the level format is simply by saying things like First 12 bytes: header 4 following bytes: number of materials x next bytes: array of materials, and things like that.
I'm very inexperienced in hex and don't completely understand what they're saying. However, there is a level editor, and the source is freely available on google code. I was thinking of adding this in to my visual studio and trying to learn the level format by reading how the level editor opens the files.
However, another problem, I don't know c++ (I know python). This means I probably won't be able to locate which part of the code reads the bytes and whatnot.
What I'm looking for, is something that will allow me to follow the flow of the code, in its execution. Essentially something that acts similar to setting a breakpoint on every line, and having it show me what specific portion of code is executing when reading the file contents.
However, obviously setting breakpoints on every line is very messy and slow. I'm looking for something that will simply show me what code is being run when I open the file in the editor.
Does anyone know what I could do? Thanks.
You're looking for a feature to step from one statement to the next; every debugger I know has such a feature. You start by setting a single breakpoint at the beginning of the interesting region, and starting from there you "step" through your code.
E.g. in Visual C++ 2010, the key F10 does one step; you can also "step into" the next statement (e.g. a method call) with F11.
In your case, set the breakpoint to where the reading of the level file starts, and continue from there. To find the place where the file is read can be a hard problem as well - depending on the clearness of the code; but if it's well written code, there should be a method with "read" in the name or "load" or something similar - you'll figure it out!
You might have to know at least some basic C++ syntax to be able to follow what's going, though.
I would also recommend reading up on Debugging HowTo's (e.g this one).
The document wich you find so obscure, is just the level format specifications, in most cases the specifications are all you need. You need as well some little extra experience with file reading.
When reading a file you have to warry about few things.
1) When reading byte by byte (8 bits) order is no changed.
2) When reading 32bits at a time byte order can change according to endianness of machine.
(for example 0x12345678 becomes 0x78563412 when endiannes changes)
There was a very old tutorial that can help you loading 3D models that helped me to start working with files:
http://www.spacesimulator.net/wiki/index.php?title=Tutorials:3ds_Loader
this is usefull because you have part of the specifications (like in original documentation) and it shows how you can create a loader just starting from specifications. That's all you need. That's C but there is no big difference from C++ in this case.
If you need some other simple file format specification with related file loader for making things clearer to you, you can also look at libktx and ktx specifications:
http://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/
If I remember correctly there's also a unofficial C++ KTX loader you can look at if you itend to write C++ oop code rather than C.