radare integration
This article shall curtly discuss the why's and what's of the radare button, found at the bottom of the analysis page since somewhere between releases 2.5 and 2.6.
The hex dump button introduced a binary view to FACT. The idea was to use it for quick peaks on container headers, aiding in container reversing and false positive detection regarding file type. Since some users increasingly used FACT in combination with reverse engineering parts of the firmware, a disassembler seemed a nice addition. Luckily the open source radare2 comes with a built-in webUI. So we would just open the binary of a given firmware or file object in radare and forward the port to the webUI.
Internally the setup includes a docker container running radare along with a small flask application. The flask application will take a http request including the binary, start radare on that and answer with a link to the web interface. To allow multiple instances of radare, the link will depend on the radare instance, identified by its port.
A second docker container running nginx wraps the different port from the radare container (defaults are 8080 for flask and 8001-8004 for the max. 4 parallel radare instances) to a single outgoing port (default 8000) on the host machine. The ports are each mapped to a unique path, /v1/retrieve for flask and /radare{1,2,3,4} for the webUIs.
When clicking the radare button, the fact endpoint will send a post request to the outgoing radare port and then calculate the local url from the response (e.g. /radare1).
This mechanism is still a bit hacky, since port 8000 is hardcoded here, as is localhost in case of a delivery through nginx. A discussion on this is given below @ ssl and hostname issues.
The radare connection will time out after some minutes (10 is the default). After that, the port - along with its route - is free for a new session.
The configurations for docker-compose and docker, given in the bootstrap folder, include passing the environment variable http_proxy, HTTP_PROXY and its https counterparts to the containers at build time.
Luckily this doesn't interfere with proxy-less installations. To allow docker to pull the images behind a proxy, additional configurations have to be made on the host machine, see. On some machines, depending on the specific proxy, npm won't work despite the forwarded environment variables. stackoverflow has a solution for this problem. On our problem machine, changing the registry did the trick.
Opening FACT to a local - or global - network brings some additional configuration with it. Since that has to be done to nginx and uwsgi configurations anyway, no perfect one-value-change-for-all solution has been made for this integration yet. There are ideas how to do it, but as of now let's see what has to be done:
There are two scenario's:
- FACT is used with nginx on 80 or 443
- FACT exposes 5000 (or your favourite other port) to the network
For case 1, make sure the updates of the nginx.conf (the new radare location) are added to your config. For new installations, just add the -N option when calling ./install.py.
Next change the nginx parameter in the configuration (ExpertSettings) to true. Then go to src/helperFunctions/web_interface.py::get_radare_endpoint and replace https://localhost/radare with your preferred host (and keep the trailing radare). Done.
For case 2, you just have to change localhost in src/helperFunctions/web_interface.py::get_radare_endpoint to your hostname or ip address and it should work. Since the radare service runs on a different port that FACT, you might have to allow this port through your firewall. Done.
