Many of you may recall the old DOS program--debug. Though outdated in many respects, one of the nice things about it was that one could easily find the byte-sequence for a given instruction without having to go through the steps of writing a program, compiling, disassembling, examining the file contents, .... Enter the instruction, then dump the instruction address. 'debug' regrettably does not do 32 bit instructions.
Does anyone know of a tool that does something similar for 32-bit x86 instructions? I don't want to go through the whole compile process; I just need to be able to enter a couple of instructions and have it spew out the length of the instruction and its byte sequence.
DOS debug was an interactive assembler as well as a debugger, entering assembly code resulted in that line being converted immediately to machine code - which is what you dumped out.
So all you need is to automate your favourite assembler with a script or batch-file.
Here's a bash function I came up with in a minute or two using the popular nasm assembler:
opcode() {
echo $* > tmp.S && nasm tmp.S -o tmp.o && od -x tmp.o
rm -f tmp.o tmp.S
}
Takes less than a second. Invocation looks like this:
$ opcode mov eax, [ebx]
0000000 6667 038b
0000004
$ opcode fadd st0,st1
0000000 c1d8
0000002
Not brilliant, but you can tweak od command-line for better output. This idea should work with any command-line assembler as long as you tell it to use a simple binary output format.
There are a few simple, 32-bit command line debuggers to be found. Based on your description, OllyDbg might fit your needs well. At least some versions of Microsoft's Debugging Tools for Windows include one named CDB, which stands for Commandline DeBugger (though I haven't verified that the linked version includes it...)
Related
I see a string being output to my Terminal, when I ran an executable. I have the source code (in C) of the executable, but it was not written by me. I compiled it with -g flag. Is there any way to know which line in which file resulted in the output, with dtrace, lldb, gdb, or any other means?
I am using macOS 10.13. When I ran gdb and the following:
catch syscall write
I got this error:
The feature 'catch syscall' is not supported on this architecture yet.
Is there any way that can achieve my goal?
lldb tends to be better supported on macOS than gdb. You should be able to trace this call by using its conditional breakpoint feature.
While you can certainly trace the write() call with dtrace and get a stack trace using the ustack() action, I think you'll have a harder time pinpointing the state of the program than if you break on it in the debugger.
Your comment suggests you might be searching for a substring match. I suspect you can create a conditional breakpoint in lldb that matches a substring using something like this:
br s -n write -c 'strnstr((const char*)$rsi, "test", $rdx) != NULL'
I'm assuming lldb does not have argument names for the write function, so I'm using x86-64 calling convention register names directly. ($rdi = first argument, which would be the file descriptor; $rsi = second argument, buffer; $rdx = third argument, buffer length)
For some obscure reason I have written a bash script which generates some source code, then compiles it, using
... whatever ... | gcc -x c -o /dev/stdout
Now, I want to execute the result on the compilation. How can I make that happen? No use of files please.
As Charles Duffy said, to execute a binary, you'd have to tell your operating system (which seems to be a Unix variant) to load and execute something – and Unix systems only take files to execute them directly.
What you could do is have a process that prepares a memory region containing the ELF binary, fork and jump into that region - but even that is questionable, considering that there's CPU support to suppress exactly that operation (R^X). Basically, what you need is a runtime linker, and shells do not (and also: should not) include something like that.
Let's drop the Bash requirement (which really just sounds like you're trying to find an obvious hole in an application that is older than I am grumpy):
Generally, requiring ELF (which is a file format) and avoiding files at the same time is a tad complicated. GCC generates machine code. If you just want to execute known machine code, put it into some buffer, build a function pointer to that and call it. Simple as that. However, you'd obviously don't have all the nice relocation and dynamic linking that the process of executing an ELF binary or loading a shared object (dlopen) would have.
If you want that, I'd look in the direction of things like LLVM – I know, for a fact, that there's people building "I compile C++ at runtime and execute it" with LLVM as executing instance, and clang as compiler. In the end, what your gcc|something is is really just JIT – an old technology :)
If your goal is to not write to the filesystem at all, then neither bash nor any other UNIX program will be able to help you execute an ELF from a pipe - execve only takes a path to a regular file as its filename and will fail (setting errno to EACCES) if you pass it a special file (device or named pipe) or a directory.
However, if your goal is to keep the executable entirely in RAM and not touch the hard disk (perhaps because the disk is read-only) you can do something with the same effect on your machine by using tmpfs, which comes with many UNIX-like systems (and is used in Linux to implement semaphores) and allows you to create a full-permissions filesystem that resides entirely in RAM:
$ sudo mount -t tmpfs -o size=10M tmpfs /mnt/mytmpfs
You can then write your binary to that:
... whatever ... | gcc -x c -o /mnt/mytmpfs/program.out
/mnt/mytmpfs/program.out
and bash will load it for you as if it was on disk.
Note, however, that you do still need enough RAM onboard the device to store and execute the program - though due to the nature of most executable binaries, you would need that anyway.
If you don't want to leave the program behind on your ramdisk (or normal disk, if that is acceptable) for others to find, you can also delete the file immediately after starting to execute it:
/mnt/mytmpfs/program.out &
rm /mnt/mytmpfs/program.out
The name will disappear immediately, but the process will internally hold a hard link to that file, then release that hard link when it terminates, allowing the file to be immediately deleted from disk. (However, the storage won't actually be freed until the program exits, and the program will not be able to exec itself either).
I am trying to automate one process which involves giving interactive input to a .exe utility. It expects the user-input for each step. I wanted to give all those values at single time while giving that command only. For eg: ./test.exe 8\n1\n0 etc. I have tried multiple ways to give input to the 'test.exe' utility like 8\n1\n0 | ./test.exe and 8,1,2 | ./test.exe. None of these worked. Any help how to pass these options 8,1,2 to the interactive utility test.exe in single line so that it will be helpful for my automation
There is no set way to automate a 3rd party program with Powershell. Not all utilities even offer the ability to do so.
I'd look in the utility documentation for any switches.
Try the following to see if you can get any built in help: test.exe -h, test.exe /h, test.exe /?, test.exe -?
use the sysinternals strings utility to try and find anything that look like command line switches inside the exe that you can take advantage of.
https://technet.microsoft.com/en-us/sysinternals/strings.aspx?f=255&MSPPError=-2147217396
The answer depends entirely on how your executable works.
If the executable reads from standard input, you can redirect input to it as follows (PowerShell):
PS C:\> 8,1,2 | .\test.exe
This won't work if the executable doesn't read from standard input or if it clears the console input buffer.
The executable may also let you provide command-line arguments that specify the needed input, but this depends on the executable.
Is it possible to use the GNU debugger on executables that were not compiled with GNU tools(gcc, gas, g++) and dump the assembly code?
Yes, you can use gdb on any executable. Without debugging symbols, some of the commands won't work, but there's plenty of commands that work at the assembly level. stepi to single-step instructions, you can print registers (using C-like expression syntax: print $rbx+($rax<<$rcx)) and modify them.
But for generating an assembly dump of the whole program, objdump -d is easier. objdump -D if there's code in weird places (which is sometimes the case with malware). And objdump -s for a view of the data segment.
I'm trying to get some legacy fortran code compiled on an SGI workstation.
In the Makefile, the lines
.f:
co $#
do appear. Make exits with the error
sh: co: not found
I tried googling for that program, but to no avail. Does anyone know what this could be, and where to obtain it - given the short name, I hope that it is some kind of standard tool, rather than something specific to this very Makefile.
co is part of the RCS version control suite. It "checks out" the version of the file in question from it's "repository" (which is usually same file name with a ,v suffix sometimes stored in an RCS/ subdirectory).