Ida Pro runs on Windows, Linux and Mac OS, so i guess the Linux equivalent of Ida Pro is Ida Pro. The debugger that's used mostly seems to be gdb, possibly enhanced with a GUI.
Hopper and Radare2 run on Linux as well.
VMWare can capture USB traffic between the device and the VM. A VMWare engineer even made an open-source tool for analyzing and visualizing USB logs - Virtual USB analyzer.
Alternatively, a tool for converting VMWare logs to .pcap for analyzing in Wireshark is available from Sogeti.
It is actually very simple and works for me just fine as you can see in the following gif:
First you need to figure out the tty of the terminal you want to redirect the STDIO to (a.k.a Terminal 2, T2).
You can do this by simply execute:
This tty will soon be used on the rarun2 profile file.
Meantime, let's put T2 to sleep by using sleep ...
Here is the list of few decompilation tools / resources that you may find useful.
IDA Pro + Hex-Rays decompiler
Hopper disassembler (has a decompiler)
ODA (Online Disassembler)
Injecting payload and hexadecimal addresses through program inputs depends on the type of input you get. Here is a list of all the possible inputs and the way to do it with both a pure shell environment and from within gdb.
Getting inputs from char *argv
In this case, the arguments are read from the initial command line, so the most convenient thing is:
Matt Cutts wrote a series of blog posts outlining the general approach of reverse-engineering a USB device and getting it working with linux, and explaining how he did this for a USB controlled toy missile launcher. You may find them a useful starting point.
It is possible to determine what command line arguments or options can be passed to a Linux executable. Of course, how this can be done will depend on the type and design of the program and on factors such as obfuscation, encryption, compression, etc.
Linux executables designed to be easily usable by humans and whose behavior ...
Hypothesis: the file is encrypted
1. Absence of Compression Signatures
The relevant compression formats that Binwalk detects are as follows: bzip2, lzop, lzip, lrzip, LZO, 7z, gzip, rzip, LZMA, zlib, and LZ4. Since running Binwalk against H201LV2.0_Cur_config.bin returns no results even though Binwalk normally will recognize any of these compression ...
First of all, I have bad news for you ! Doug Lea's malloc is almost no more used in any C library implementation (even if understanding dlmalloc can help a lot to understand new ones).
The new implementation that is most widely used is ptmalloc2 and the best way to learn about it is... to read the code... So, if you are using a Debian(-like) distribution, ...
Apart from the ptrace trick, you can check /proc/PID/cmdline, raise a SIGTRAP, use getppid, ...
You may want to check pangu (disclamer: I'm the author).
Pangu a a little toolset to mess around with debugging-related tools
from the GNU project, and especially on GNU/Linux x86.
There are a plethora of things programmers do not know about how ELF binaries work internally. And, unfortunately, there's almost no solid references apart from two or three which broadly cover the subject. Many tools (linkers, loaders, assemblers, debuggers, ...) remain a mystery for most of you. When it comes to linkers and loaders, the main reference is ...
functionpointer is declared before char buffer; on the stack so How comes it overwrites it ???
The order of objects in the stack is implementation defined. C does not mention any stack and the direction of the stack growing is also implementation-defined (usually it grows downwards but in some systems it grows upwards).
In your case functionpointer is ...
For understanding how dynamic memory allocation (the malloc, free, calloc, realloc library functions) really works there is no substitute for reading the source code of malloc(). It is well commented:
comments on chunks:
1056 malloc_chunk details:
1058 (The following includes lightly edited explanations by Colin Plumb.)
arm64 syscall numbers are defined at: https://github.com/torvalds/linux/blob/v4.17/include/uapi/asm-generic/unistd.h
This is a bit confusing since it is quite different from x86 and x86_64 and arm 32-bit which define syscall numbers under arch/, e.g. arch/arm/tools/syscall.tbl for arm 32-bit, but the arm64 file has a comment saying:
New architectures should ...
If you look at offset 0xDF of your backup file you'll see the two bytes:
These commonly delimit the beginning of a zlib compressed file.
In fact, the original XML config file has been split up into multiple zlib compressed blocks:
$ binwalk default-config.bin
DECIMAL HEXADECIMAL DESCRIPTION
Current IDA versions (as of 6.5) are pretty much equivalent for all three platforms. You can disassemble all file formats on all three platforms. You can definitely analyze PE and Mach-O files on Linux. Most debuggers are also available on all platforms.
A couple of features are available only in the Windows version:
WinDbg and Symbian debuggers
On Linux, in protected mode, the segment registers aren't standard "segments" anymore, instead, they're called selectors, and include information if the segment is readable/writable/executable. The real address they're pointing to is "hidden" in a table in the kernel and the segment register is used as an index into that table, but the physical address ...
In gdb you can set a syscall breakpoint with catch syscall.
If this is in 32-bit x86 (IA-32), check the syscall number in your_linux_source_dir/usr/include/asm/unistd_32.h. There is no syscall called socket in 32-bit x86, do you mean socketcall? Its number is 102.
If this is in x86-64 (AMD64), check the syscall number in your_linux_kernel_source_dir/usr/...
Updated for August 2020:
The below information is accurate to the best of my knowledge. It has been used to decrypt config.bin on 2 different routers at the time of writing.
The obfuscated section of your config file is a series of ZLIB-compressed sections that have been encrypted with AES in ECB mode with a 16-byte key.
There is an application named cspd ...
You can simply export the environment variable LD_PRELOAD (on Linux) or DYLD_INSERT_LIBRARIES (on OS X) pointing to (the full path of) your library before running your target, like in this example:
This is for hooking functions to do whatever you want (not to spy ...
There are no artifacts and surely the compiler, and I mean GCC, can generate a better and faster code if told so. The first version of your generated code is non optimized. Why ? Either because -O0 flag (0 level optimizations ==> No optimizations) was specified, or because no optimization flags were specified and by default GCC turns optimizations off.
It's not run in the example. It's a shellcode, it has to be somehow injected (for example using a buffer overflow vulnerability).
To understand how it works, let's first put some addresses on the strings:
0000004F "cp -p /bin/sh /tmp/.beyond; chmod 4755 /tmp/.beyond;"
Let's look at the disassembly piece by piece.
Radare2 is also able to collect the callgraph of a program based on its binary only.
Some time ago, I asked this question which is somehow related to yours and one of the author of Radare2 answered:
Recursive traversal disassembling with Radare2?
Yet, if you want a graphical representation of the callgraph here is the way to do:
$> radare2 /usr/bin/...
There are several quite good references about the exploitation of the heap in software security, one of my favorite is probably the 'binary hacking course' from LiveOverflow.
You can look at the following lectures for a simplified approach of the heap management (using the Protostar exercise set from Exploit-Exercises):
0x14 - The Heap: what does malloc() ...
Update: See this answer for up-to-date information on where ARM64 syscall definitions are found. Note that the information below may just be for backwards-compatibility.
#define __NR_restart_syscall 0
#define __NR_exit 1
Apart from the classix UPX, you should take a look at Burneye (With its crackers, UNFburninhell and Burndump) and elfuck. They are pretty old, but still interesting.
If you are interested about tricks that can be used, this is a good introduction by aczid, and I would also recommend Binary protection schemes for a more complete overview.
Someone also ...
i wrote a windows specific answer to a question that was marked as duplicate and closed and the close flag referred to this thread so i post an answer here
os win7 sp1 32 bit machine
kernel dump using livekd from sysinternals
a 16 bit segment register contains
13 bits of selector
1 bit of table descriptor
2 bits of requester_privilege_level
The compiler did put the function pointer after the buffer.
In the disassembly, check the memcpy call:
8048525: lea -0x58(%ebp),%eax
8048528: mov %eax,(%esp)
804852b: call 804838c <memcpy@plt>
The first argument to memcpy (the buffer's address) is at [esp+0] and you can see that the value of ebp-0x58 is being put there.
Next is the ...