The question is wrongly placed
You are asking the wrong question. Literally. The question is by no means why it isn't possible (it is possible in many cases). The better question is: why it isn't practical?
It's interesting to ask it, nevertheless.
Why not use hardware assisted virtualization?
For starters I've had arguments in the past with certain ...
an input set that can has 100% coverage of the code
This may be very difficult to achieve, especially if the code behavior depends on something that you don't directly control (time, memory, OS version/environment, random number generator etc.). Additional observations:
actually executing all that code may take more time than you can afford
executing some ...
What does "(not) emulating hardware other than the CPU" mean?
This means that whenever the software being emulated accesses hardware, it won't work in Unicorn in the same way as on actual hardware.
We have several questions about emulating firmware on QEMU. The general answer is that, when you try booting a firmware kernel in QEMU, that kernel will access ...
Emulating a complete physical device is always going to be more of an experimental exercise. In this regard you can use firmadyne which aims to emulate Linux based embedded firmware for MIPS and ARM devices. It's based on the venerable QEMU project. There's also firmware analysis toolkit which is a wrapper around firmadyne allowing you to automate some of ...
There is no need for emulation because x64 processors can execute x86 (32-bit) code natively using so-called compatibility mode. You only need to set up proper descriptors in the GDT (L=0 for 32-bit code, L=1 for 64-bit code) and it "just works". This is what Windows does. E.g. from this OSR post, the windows 7 x64 GDT has these entries:
GDT[0x04] = 32 bit ...
Can we use dynamic analysis (or just emulator) to achieve 100% code coverage?
No, if I was right, it equals to Turing Halting problem.
emulator based disassemble approach
I am afraid this may not be a very new idea, and code coverage is a big issue.
But it is always possible that you find a different angle and make some contributions in related area.
Just the firmware and qemu won't help you much. When the firmware starts up, it will try to communicate with the hardware - initialize the network card, check which channels have cameras attached to them, probably read some configuration values from non-volatile storage, check the total/free space of the hard disk, this kind of stuff.
On a plain qemu ...
You get this error message because the ELF is stripped. See qemu-vs-strip for more information.
This problem is fixed in the latest QEMU, so you have to update your QEMU or compile the latest from source.
If you want a simple answer. Code coverage. If you only trace called/executed code, how do you know you found all the code.
Emulation is good to understand code when it has memory altering behavior or to understand code. Like in one of my projects I knew I had some double math functions implemented in software. So running an emu to see the results was ...
These information pieces are generally stored in the NVRAM (Non-Volatile RAM), which is stored in one of the flash partition. To emulate a device successfully, you generally have to fill up the NVRAM with valid settings.
Firmadyne contains an NVRAM emulation and you can find more information about the problem itself in this blog post.
If I remember well, ...
The 24 pin debug connector on the GR-55 seems to have all required signals for the E10A-USB, so I'm guessing they just used a smaller connector to reduce board space and cost. The connection diagram below is for a different CPU, but the pin designations match those in the GR-55 so I bet they are compatible. You just have to make a custom adapter cable.
According to the source code, the EABI from your ELF is not compatible. It seems to be specific to MIPS, you can find the structure here, this structure is stored inside a specific ELF segment, the code in charge to read it is here. I suggest you to make sure this segment is present and if it contains correct values. I think you can dump this information ...
Is movq rax, xmm0 buggy in Radare2?
No, it's just not fully implemented in all debuggers yet.
Native Debugger Works!
This instruction works fine using the native debugger. The native debugger is launched with r2 -d yourFileGoesHere. Alternatively, if you are already in r2 looking at the file, but r2 wasn't launched with the -d switch, the file can be ...
I fought a similar error for a while and figured I was naming the disk image as "disk.img". When I renamed it to something else, it worked. In your example, you're naming it to floppy.img, so you could try something else.
It's a bit of a guess, but seems like bochs doesn't like files with reserved words, like disk or floppy.
Unfortunately QEMU is not well suited for your use case. As explained in your addendum, it is mostly used to emulate embedded Linux systems, that’s why there are many assumptions in its code: that the kernel is a Linux kernel (i.e. an ELF file) and the disk image contains a Linux rootfs. In addition, the specific hardware configurations (“machines”) emulated ...
Unicorn only supports concrete values in registers.
You could cheat your way around this by doing two runs with two sets of magic values.
But what you really want is a symbolic execution framework like angr. There registers can be undefined after execution or even contain expression trees like old_ebx*2+1.
an emulator requires your input to emulate if you didn't define something you would obviously get what it was initialized with
apparently unicorn starts initialized with 0 for all registers it seems
src to read all registers using the given api
#define REG_NUMS 9
void main (...
Dis-assembly as a technique isn't a problem As long as you know the boundaries of your binary file (where the data/code starts) and you know the Instrustion Set.
If you know you have UNIX ELF file on x86, you can just run objdump on it to get disassembled output:
objdump -d <file>
Their research was on security. They wanted to read the code ...