Console access

[firmadyne]

Console access

[ddcc]

I'm not familiar with firmware-mod-kit or how it works. Unless it's using firmadyne internally, this project and firmware-mod-kit are completely separate and unrelated.

If you're trying to emulate a firmware image with firmadyne, you should follow the instructions at https://github.com/firmadyne/firmadyne#usage .

[blischalk]

I understand that the firmware-mod-kit is completely separate. It is a tool used to extract a firmware root filesystem to allow for modifications and then allows the firmware to be built again. https://github.com/rampageX/firmware-mod-kit

The reason I mention it in this issue is that from the instructions for the console, it seems that to enable the console functionality of a firmware being run with firmadyne, that it is necessary to extract and modify the firmware to include the console binary in this repository. Is this accurate?

It seems that firmadyne provides functionality to extract firmware and build it again in a similar manor but firmadyne doesn't seem to leave the firmware in an extracted state where you are able to add the console binary for the applicable architecture and then to rebuild the firmware binary.

firmware-mod-kit aside, what I am and trying to understand is that the instructions for the console seem to just be:

mknod -m 666 /firmadyne/ttyS1 c 4 65

cp console /firmadyne/console

But they don't indicate how the firmware should be extracted and rebuilt to include the console binary. What I am looking for are what steps should be followed to emulate a firmware using firmadyne and to be able to access the running firmware via a terminal.

[ddcc]

From what you've said, the goal of firmware-mod-kit is to allow users to modify a firmware image and flash it back to the original hardware. This is different from firmadyne, which is a framework for dynamically emulating firmware without the original hardware.

As part of the emulation process, we do need to extract the filesystem from a given firmware image, but there's no support for repackaging a potentially modified filesystem back into the format of the original firmware image. The mount.sh/unmount.sh scripts from the instructions are designed to modify the extracted filesystem, so the commands that you mentioned are supposed to be run during this process. However, this console binary is now deprecated because the mechanism it uses is unreliable, and by default executing the generated run.sh script will automatically connect a console. The instructions in the main firmadyne repository detail the process of extracting and emulating an example firmware image, and connecting to the console.

[blischalk]

From what I have seen, run.sh does not present a console:

oit@ubuntu:~/tools/fat/scratch/2$ sudo ./run.sh
[sudo] password for oit: 
Creating TAP device tap2...
Set 'tap2' persistent and owned by uid 0
Bringing up TAP device...
Adding route to 192.168.1.1...
Starting emulation of firmware... Done!
The emulated firmware may not be accessible while booting.
Press any key to destroy the network and shutdown emulation.

The terminal window that is running run.sh allows you to "Press any key to destroy the network and shutdown emulation."

So if run.sh sets up a console, how would someone connect to it? I haven't found this documented anywhere?

[ddcc]

It looks like you're using an old version. Did you clone the master branch? The instructions explicitly state The default console should be automatically connected to the terminal.

[soh0ro0t]

It looks like you're using an old version. Did you clone the master branch? The instructions explicitly state The default console should be automatically connected to the terminal.

I have the same confusion, what's the relationship between terminal and primary console? why the default console should be automatically connected to the terminal? and I have no idea about what the default console actually and terminal is?
I assume that the default console is 'ttyS0' as the unique clue in the kernel command line of 'run.sh', then the terminal should be '/bin/sh', is that right?
Another question is what is purpose of this console? it seems like the console spawns a '/bin/sh' and redirected its STDIN/STDOUT/STDERR to /firmadyne/ttyS1? I login into the firmware system and found there is indeed a '/bin/sh' process running, bu it is not in use, could you explain that for me?

[ddcc]

The terminal is your local shell terminal (e.g. bash, etc) that was used to execute run.sh. The console is the QEMU serial console that is connected to the emulated firmware's terminal, which usually shows kernel messages and may also spawn a shell. Previous versions of firmadyne did not connect the terminal to the console, so you would not be able to easily access these messages or the shell.

Some firmware do not spawn a shell on the terminal, making them difficult to interact with locally (not over the network). The purpose of the console program is to ensure that a shell is spawned, though it didn't always work.