Skip to content

emba-quickstart.md

Latest commit

 

History

History
1341 lines (973 loc) · 36.6 KB

emba-quickstart.md

File metadata and controls

1341 lines (973 loc) · 36.6 KB
Raw

EMBA Quickstart For Firmware Assignments

Date: 2026-05-25

Use this file first. It is the canonical EMBA setup/troubleshooting path for the assignment.

After EMBA is installed and healthy, use emba-analysis-walkthrough.md for the command combinations and firmware-analysis workflow.

Use emba-install-use-guide.md only when you need background detail or a slower step-by-step explanation.

EMBA Doc Order

  1. emba-quickstart.md

    • current file
    • use for VM sizing, Kali/EMBA setup, Docker pull issues, update warnings, and first scan

  2. emba-analysis-walkthrough.md

    • use after EMBA works
    • contains the actual analysis sequence and command combinations

  3. emba-install-use-guide.md

    • detailed reference
    • do not read straight through during a time-boxed assignment

  4. ubuntu-no-emba-backup-guide.md

    • fallback only
    • use if Kali/EMBA/Docker blocks you

Redundancy note:

This quickstart repeats a few critical safety/setup points from the long guide on purpose.
When there is a conflict, follow this quickstart for setup order.
Use the long guide for explanation, not as the primary checklist.

Compact Menu

Plain-English Model

EMBA has two main parts:

Host VM
  -> Kali or Ubuntu
  -> Docker installed/enabled
  -> EMBA repository

EMBA Docker environment
  -> heavy analysis tools
  -> firmware extraction/scanning modules
  -> downloaded during install/first run

The confusing sentence in the official docs means:

Do not manually install every EMBA dependency.
Use sudo ./installer.sh -d.
The installer prepares the host and Docker-based EMBA environment.

Do not use developer mode (-D) for normal firmware analysis.

Recommended Local VM

Best practical local setup:

VMware Workstation Pro
  -> current Kali VM for EMBA
  -> 8 vCPU / 16 GB RAM minimum if available
  -> 120-200 GB virtual disk preferred
  -> NAT networking
  -> snapshots

If your host has only 4 logical cores:

Use 2 vCPU for the VM.
Run EMBA quick-scan only.
Avoid broad/default scans on large firmware.
Prefer manual triage + Binwalk + Ghidra/IDA on Windows host.

Disk Reality

Official EMBA requirement:

30-100 GB free disk space, more is better.
Prepared Docker image: about 14 GB.
Compressed download: about 6 GB.

Practical recommendation:

80 GB VM disk: too tight for comfortable EMBA use.
120 GB VM disk: workable minimum.
200 GB VM disk: better if you will keep logs, images, and multiple firmware samples.

Why 80 GB is tight:

  • Kali itself consumes space.
  • apt full-upgrade needs temporary space.
  • Docker image/layers are large.
  • EMBA logs can be huge.
  • Extracted firmware trees can multiply disk usage.
  • Failed Docker pulls may leave partial data.

Check before install:

df -h
docker system df 2>/dev/null || true

If VMware created an 80 GB disk and you can change it before serious use:

Power off VM.
VMware Settings -> Hard Disk -> Expand.
Set 120 GB or 200 GB.
Boot VM.
Expand the Linux partition/filesystem if the guest did not do it automatically.

Inside Linux, inspect:

lsblk
df -h

Do not start EMBA if / has less than about 50 GB free.

Resize Kali Root Partition After VMware Disk Expand

Your current case:

sda      200G disk
sda1    80.1G part mounted on /
/dev/sda1 79G filesystem mounted on /

Meaning:

VMware disk is already 200 GB.
Linux partition sda1 is still 80 GB.
You need to grow partition 1, then grow the filesystem.

First, confirm filesystem type:

findmnt -no SOURCE,FSTYPE,SIZE,USED,AVAIL /
lsblk -f

Most Kali installs use ext4. If / is ext4, use this path.

Install grow tools:

sudo apt update
sudo apt install -y cloud-guest-utils e2fsprogs

Grow partition 1 to fill the 200 GB disk:

sudo growpart /dev/sda 1

Grow the ext4 filesystem:

sudo resize2fs /dev/sda1

Verify:

lsblk
df -h /
findmnt -no SOURCE,FSTYPE,SIZE,USED,AVAIL /

Expected result:

sda   200G disk
sda1  ~200G part /
/     ~196G filesystem, depending on overhead

If growpart says the partition is busy, reboot and run the same commands again:

sudo reboot

If growpart is unavailable or fails, use parted carefully:

sudo parted /dev/sda print
sudo parted /dev/sda resizepart 1 100%
sudo resize2fs /dev/sda1
df -h /

Only use the parted path if you are sure /dev/sda1 is the root partition and there is no swap/recovery partition after it. Your shown layout has only sda1, so it is the simple case.

If the filesystem is XFS instead of ext4, do not use resize2fs; use:

sudo xfs_growfs /

Snapshot advice:

Take a VMware snapshot before resizing if the VM already contains anything valuable.
If this is a fresh Kali VM, resizing now is low risk and worth doing before EMBA.

Should You Upgrade Kali First?

Not strictly for EMBA.

The current installer.sh -d does not require you to run a full Kali upgrade first. It runs its own host preparation:

  • apt-get update
  • installs python3-venv
  • creates external/
  • creates an EMBA Python virtual environment
  • installs basic host utilities
  • installs Docker CE / Docker Compose plugin if missing
  • checks disk/RAM
  • pulls/prepares the embeddedanalyzer/emba Docker image
  • installs/downloads host-side data such as the NVD feed

The small host helper set currently includes tools such as jq, shellcheck, unzip, bc, coreutils, ncurses-bin, libnotify-bin, inotify-tools, dbus-x11, git, net-tools, curl, file, python3-pip, and Python requests.

So the sentence "Install all dependencies for EMBA in default/docker mode" means:

The installer prepares the host enough to run EMBA's Docker mode,
then uses the Docker image for the heavy analysis environment.

The installer still calls many module installer functions, but in -d mode the heavy analyzer module installers are guarded and are not broadly installed onto the host. Treat the Docker image as the home of the heavy EMBA toolchain.

It does not mean "everything happens only inside Docker".

For a fresh Kali VM, an OS upgrade is optional hygiene:

sudo apt update
sudo apt full-upgrade -y
sudo reboot

Reason to do it:

  • Kali is rolling.
  • It reduces stale package and Docker compatibility surprises.
  • It gives you a clean baseline snapshot.

Reason not to do it:

  • It can change many packages.
  • It is not required by EMBA.
  • If the VM already works and you are time-boxed, it can introduce avoidable risk.

Practical recommendation:

Fresh Kali VM, before assignment pressure: full-upgrade, reboot, snapshot.
Time-boxed assignment or already-working VM: skip full-upgrade unless apt/Docker is broken.
Your current VM: apt state is clean, so stop touching apt and proceed to snapshot/EMBA.

After a successful upgrade, snapshot:

kali-clean-updated

After the reboot, cleanup is optional:

sudo apt clean
df -h /

Answer to "autoremove?":

Fresh Kali VM with plenty of disk: skip autoremove for now.
Fresh Kali VM with low disk: inspect autoremove first, then decide.
Active analysis VM with custom tools: inspect the package list first.
Mid-assignment: avoid cleanup unless disk pressure forces it.

Use a dry run:

sudo apt autoremove --dry-run

If it proposes removing Java, Ghidra-related dependencies, Docker pieces, desktop components, or anything you recognize as useful, do not run it. With a 200 GB VM disk, saving a few GB is not worth introducing uncertainty before EMBA.

Do not upgrade in the middle of an active assignment if EMBA already works. Snapshot first.

VMware Power / Screen Lock Bug

Before a large Docker pull or sudo ./installer.sh -d, disable guest screen lock and power saving.

In terminal:

xset s off
xset -dpms

In Kali XFCE:

Settings -> Screensaver -> disable
Settings -> Power Manager -> Display -> Never
Settings -> Power Manager -> System -> Never

Why:

VMware guest throttling / screen lock / power management can interrupt long Docker/containerd writes.
This can appear as a silent hang or containerd timeout during a huge layer pull.

Diagnostic hints:

context canceled
write timeout
total=8821973491

Do not use a ctr image pull workaround for Docker images. ctr defaults to a different containerd namespace, while Docker uses the moby namespace. The image can be downloaded but invisible to Docker, wasting bandwidth.

Correct action:

disable screen lock/power management
run sudo ./installer.sh -d normally
watch docker/containerd logs if it fails

Slow Docker Pull Troubleshooting

The EMBA Docker image is large. Slow download can be caused by Docker Hub, your ISP, VMware NAT, guest DNS, IPv6 problems, power throttling, or Docker retry behavior.

Start with the low-risk checks.

1. Confirm Basic Network Speed In The VM

curl -L -o /dev/null https://speed.hetzner.de/100MB.bin
curl -I https://registry-1.docker.io/v2/
docker pull hello-world

Interpretation:

general curl slow        -> VM/host/ISP/network issue
Docker registry slow     -> Docker Hub route/rate/path issue
hello-world fast, EMBA slow -> large-layer/Docker Hub issue, not basic connectivity

2. Keep VMware NAT First

Default recommendation:

Use NAT first.
Do not switch to bridged immediately.

NAT is usually stable and safer. Bridged can be faster on some networks, but it exposes the VM as a LAN host and may run into corporate/home router filtering.

Try bridged only as a test:

Power off VM.
VM settings -> Network Adapter -> Bridged.
Boot VM.
Test docker pull.
Switch back to NAT if not clearly better.

Do not run unknown firmware services while bridged.

3. Fix DNS In The Guest

Check DNS:

resolvectl status
getent hosts registry-1.docker.io
getent hosts auth.docker.io

Temporary DNS test:

sudo resolvectl dns eth0 1.1.1.1 8.8.8.8
sudo resolvectl flush-caches
getent hosts registry-1.docker.io

Your interface may not be eth0. Check with:

ip -br addr

If resolvectl status shows eth0 with no DNS servers and Default Route: no, DNS is not configured for the VMware NIC. Immediate temporary fix:

sudo resolvectl dns eth0 1.1.1.1 8.8.8.8
sudo resolvectl domain eth0 '~.'
sudo resolvectl default-route eth0 yes
resolvectl query registry-1.docker.io

If your interface is not eth0, replace it with the interface shown by:

ip -br addr

If resolvectl hangs, do not keep waiting. Use NetworkManager directly:

nmcli dev status
nmcli con show --active
nmcli dev show eth0 | grep -E 'IP4.DNS|IP4.GATEWAY|GENERAL.CONNECTION'

Find the active connection name for eth0, then set DNS through NetworkManager:

CON="$(nmcli -t -f NAME,DEVICE con show --active | awk -F: '$2=="eth0"{print $1; exit}')"
echo "$CON"
sudo nmcli con mod "$CON" ipv4.method auto
sudo nmcli con mod "$CON" ipv4.dns "1.1.1.1 8.8.8.8"
sudo nmcli con mod "$CON" ipv4.ignore-auto-dns yes
sudo nmcli con mod "$CON" ipv4.never-default no
sudo nmcli con down "$CON"
sudo nmcli con up "$CON"

Restart resolver/network services if needed:

sudo systemctl restart systemd-resolved
sudo systemctl restart NetworkManager

Verify without relying on a long-running resolvectl status:

timeout 5 getent hosts registry-1.docker.io
timeout 10 curl -I https://registry-1.docker.io/v2/

Last-resort temporary DNS bypass for this VM session:

ls -l /etc/resolv.conf
sudo cp -a /etc/resolv.conf /etc/resolv.conf.bak
printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' | sudo tee /etc/resolv.conf
getent hosts registry-1.docker.io

This direct /etc/resolv.conf edit is a quick workaround, not the preferred persistent fix. Prefer NetworkManager once the VM is stable.

3A. VMware NAT DNS Failure: Known Working Fix

Observed failure pattern:

curl: (6) Could not resolve host
resolvectl status shows eth0 with VMware DNS, or hangs
eth0 has a valid VMware NAT IP such as 192.168.206.x
gateway 192.168.206.2 responds to ping
public IPs such as 1.1.1.1 respond to ping/curl
Docker registry fails until DNS is bypassed

This means:

network routing works
internet works
DNS path through VMware NAT / systemd-resolved is broken or unreliable

In this situation, do not restart VMware services if a direct resolver fix already works. Fix DNS first and continue the Docker pull.

Temporary direct fix:

sudo cp -a /etc/resolv.conf /etc/resolv.conf.bak.$(date +%s)
sudo rm -f /etc/resolv.conf
printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\noptions timeout:2 attempts:2\n' | sudo tee /etc/resolv.conf
cat /etc/resolv.conf
getent hosts google.com
getent hosts registry-1.docker.io
curl -I https://registry-1.docker.io/v2/

Expected:

getent returns addresses
curl returns HTTP/2 401 from Docker registry

HTTP/2 401 is success here. It means the Docker registry is reachable but requires Docker auth/token flow.

Then test Docker:

docker pull hello-world

Then continue EMBA:

xset s off
xset -dpms
cd ~/tools/emba
sudo ./installer.sh -d

Permanent NetworkManager fix:

CON="$(nmcli -t -f NAME,DEVICE con show --active | awk -F: '$2=="eth0"{print $1; exit}')"
echo "$CON"
sudo nmcli con mod "$CON" ipv4.method auto
sudo nmcli con mod "$CON" ipv4.dns "1.1.1.1 8.8.8.8"
sudo nmcli con mod "$CON" ipv4.ignore-auto-dns yes
sudo nmcli con mod "$CON" ipv4.never-default no
sudo nmcli con down "$CON"
sudo nmcli con up "$CON"

Restore /etc/resolv.conf to systemd-resolved management if you want the clean setup:

sudo ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
sudo systemctl restart NetworkManager

Verify:

resolvectl status
getent hosts registry-1.docker.io
curl -I https://registry-1.docker.io/v2/

If the clean setup breaks again, keep the direct /etc/resolv.conf workaround until EMBA install finishes, then revisit networking.

Likely culprit:

VMware NAT DNS proxy or guest systemd-resolved/NetworkManager integration did not provide a usable DNS route.
The VM had IP routing, but name resolution via the VMware-provided DNS path failed.
Replacing DNS with public resolvers bypassed that path and restored Docker pull speed.

When to restart VMware NAT/DHCP services:

Only if the VM cannot get an IP, cannot ping the VMware gateway, or direct public DNS also fails.
Do not restart VMware networking while a large Docker pull is successfully progressing.

Windows admin fallback:

Restart-Service "VMware NAT Service"
Restart-Service "VMware DHCP Service"

Then reconnect in Kali:

sudo nmcli con down "Wired connection 1"
sudo nmcli con up "Wired connection 1"

If DNS becomes better, make it persistent through NetworkManager:

nmcli con show
sudo nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"
sudo nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
sudo nmcli con down "Wired connection 1"
sudo nmcli con up "Wired connection 1"

Use the actual connection name from nmcli con show.

4. Test IPv6 Problems

Some networks resolve Docker endpoints over IPv6 but transfer poorly.

Check:

getent ahosts registry-1.docker.io

Temporary IPv6 disable test:

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
docker pull hello-world

If this helps, document it. Do not make permanent changes unless needed.

5. Check Docker Hub Rate / Auth

Anonymous Docker pulls can be throttled.

Login if you have a Docker Hub account:

docker login
docker pull embeddedanalyzer/emba

This can help with rate limits, but it will not fix a bad network path.

6. Avoid Bad Mirror Advice

Do not use random Docker registry mirrors from the internet. A mirror can be stale, broken, malicious, or missing the image.

Do not use:

ctr image pull ...

for this workaround. Docker uses the moby containerd namespace, so images pulled with default ctr can be invisible to Docker.

7. Use Docker Daemon DNS If Needed

If Docker itself has DNS issues even though the VM shell works, configure Docker daemon DNS:

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json >/dev/null <<'EOF'
{
  "dns": ["1.1.1.1", "8.8.8.8"]
}
EOF
sudo systemctl restart docker
docker pull hello-world

Only keep this if it helps.

8. Watch Logs While Pulling

In another terminal:

sudo journalctl -u docker -f

For containerd:

sudo journalctl -u containerd -f

Useful symptoms:

context canceled
i/o timeout
TLS handshake timeout
write timeout
no space left on device
connection reset by peer

9. Check Disk And Trim

Large layers can fail when disk is fine in Linux but host/VM storage is struggling.

df -h /
docker system df
sudo fstrim -av

Also ensure the Windows host disk containing the VM has plenty of free space.

10. Best Practical Retry Sequence

xset s off
xset -dpms
sudo systemctl restart docker
docker login
docker pull embeddedanalyzer/emba

If direct pull succeeds, rerun:

cd ~/tools/emba
sudo ./installer.sh -d

If Docker pull remains unusably slow:

Use a short-lived paid EC2 Ubuntu host with good bandwidth.
Run EMBA there.
Download final reports/artifacts.
Terminate the instance.

11. Download Image On Windows, Load It In Kali

Yes, this is possible.

Use this when:

  • Windows host downloads from Docker Hub faster than the Kali VM.
  • Kali DNS/NAT is annoying but Windows networking is fine.
  • You have enough disk space on both host and VM.

Do not use ctr for this. Use Docker's normal image archive flow:

Windows Docker: docker pull
Windows Docker: docker save
Copy tar to Kali
Kali Docker: docker load
Run EMBA installer again

Important:

The EMBA image is a Linux image.
Docker Desktop must be using Linux containers / WSL2 backend.
Windows containers mode will not help.

On Windows PowerShell:

docker version
docker pull embeddedanalyzer/emba:latest
docker save embeddedanalyzer/emba:latest -o C:\Temp\emba-docker-image.tar

Expect the tar file to be large. It may be larger than the compressed pull size.

Copy it to Kali. Options:

Option A: temporary read-only/shared folder, then copy into Kali local disk
Option B: scp from Windows to Kali
Option C: external disk/USB if configured safely

Inside Kali:

docker load -i /path/to/emba-docker-image.tar
docker images | grep embeddedanalyzer

If the image tag is not exactly what EMBA expects, tag it:

docker tag embeddedanalyzer/emba:latest embeddedanalyzer/emba:latest

Then run:

cd ~/tools/emba
sudo ./installer.sh -d

The installer should detect the local image and skip the huge download:

Found local image embeddedanalyzer/emba:latest, skipping download.

If EMBA's docker-compose.yml references a different tag, check:

grep -n "image:" docker-compose.yml
docker images | grep embeddedanalyzer

Then tag accordingly:

docker tag embeddedanalyzer/emba:latest embeddedanalyzer/emba:<expected-tag>

Tradeoffs:

  • Needs Docker Desktop installed and working on Windows.
  • Needs large temporary disk space on Windows and Kali.
  • Copying the tar may still take time.
  • Still safer and cleaner than ctr namespace hacks.
  • Does not avoid Linux/Kali Docker entirely; it only avoids downloading the image inside the VM.

Docker Containers: emba and emba_quest

Seeing both containers is normal:

emba        -> main EMBA analysis container
emba_quest  -> secondary Quest/Q-modules container

Current EMBA docker-compose.yml defines both services. The main emba service runs the regular firmware analysis pipeline. The emba_quest service is used for Q-modules, currently including:

Q02_openai_question.sh
Q20_dependency_track_connector.sh

Why emba_quest exists:

  • EMBA starts it separately from the main analysis container.
  • It waits for the main log to show that pre-checking started.
  • It then runs Q* modules and exits.
  • It is configured as more restricted than the main container: read_only: true, no-new-privileges:true, no privileged mode.
  • It uses network_mode: host, which matters for online/API-style modules.

Your docker system df -v output:

embeddedanalyzer/emba:2.0.1b   32.2GB image
emba                           4.1kB Created container
emba_quest                     4.1kB Created container

Meaning:

The 32.2GB image is stored once.
The two containers are tiny metadata/writable-layer entries.
There is no second 32GB copy for emba_quest.

If no EMBA scan is currently running and both containers are stuck in Created, it is safe to remove only the containers:

sudo docker ps -a --filter name=emba
sudo docker rm emba emba_quest

Do not remove the image unless you want to download/load the whole 32GB image again:

# Avoid unless intentionally freeing all EMBA Docker space:
sudo docker rmi embeddedanalyzer/emba:2.0.1b

If a future EMBA run fails with a name conflict such as container name "/emba" is already in use, remove the stopped containers:

sudo docker rm emba emba_quest

Install EMBA

Use Kali if possible.

mkdir -p ~/tools ~/firmware ~/emba_logs
cd ~/tools
git clone https://github.com/e-m-b-a/emba.git
cd emba
sudo ./installer.sh -d

What this does:

  • installs host prerequisites needed by EMBA
  • installs/enables Docker pieces if needed
  • prepares/downloads the EMBA Docker image
  • downloads large data/tools during install or first run

Do not separately chase cve-search unless the installer specifically fails and tells you to. The docs mention it, but EMBA dependency handling has changed over time. The installer is the source of truth.

Fresh Pull But EMBA Says Docker Image Updates Available

If sudo ./emba -d 1 prints:

Docker image version - Updates available

that does not necessarily mean your pull was old or failed.

What EMBA currently does:

  • clones the separate online-check metadata repo during dependency check
  • reads the expected Docker image hash from EMBA_CONTAINER_HASH.txt
  • runs docker inspect on embeddedanalyzer/emba:latest
  • compares the local image digest to the expected hash

So the warning means:

local embeddedanalyzer/emba:latest digest != EMBA online-check expected digest

It is not a timestamp check.

Common reasons this happens after pulling today:

  • EMBA updated the online-check hash after your pull.
  • Docker Hub or your Docker cache is still serving an older manifest.
  • The image was loaded/tagged manually and has no matching RepoDigests entry.
  • docker-compose.yml expects a specific EMBA image tag, while you only pulled latest.
  • The upstream online-check hash and Docker Hub tag are briefly out of sync.
  • The warning is from the digest check only, while the actual Docker Compose image check may still pass.

Check the current state:

cd ~/tools/emba
sudo ./emba -V
sudo ./emba -d 1
docker image inspect embeddedanalyzer/emba:latest --format '{{json .RepoDigests}}'
grep -n "image:" docker-compose.yml
docker images | grep embeddedanalyzer

Normal update path:

cd ~/tools/emba
sudo ./emba -U
sudo ./emba -d 1

sudo ./emba -U updates the EMBA git checkout, pulls the EMBA Docker image, updates EPSS data if present, updates the NVD data feed if present, and pulls the Docker image again. It does not update all Kali system packages.

If only the Docker image warning remains after sudo ./emba -U, pull the exact image again and re-check:

docker pull embeddedanalyzer/emba:latest
cd ~/tools/emba
sudo ./emba -d 1

In the sudo ./emba -d 1 output, look for the status line named Docker-compose EMBA image version. That is EMBA output text, not a command to run. If that line is ok, Docker starts correctly, and scans run, treat Docker image version - Updates available as a warning to record, not an automatic blocker. Do not delete the image during a time-boxed assignment unless you are confident you can re-download the full image.

First Scan

Put firmware somewhere simple:

mkdir -p ~/firmware/fw1 ~/emba_logs/fw1
cp /path/to/firmware.bin ~/firmware/fw1/
sha256sum ~/firmware/fw1/firmware.bin | tee ~/firmware/fw1/sha256.txt
file ~/firmware/fw1/firmware.bin | tee ~/firmware/fw1/file.txt

Run quick scan first:

cd ~/tools/emba
sudo ./emba -l ~/emba_logs/fw1/quick_scan \
  -f ~/firmware/fw1/firmware.bin \
  -p ./scan-profiles/quick-scan.emba

Current upstream quick/default profiles enable some QEMU user-mode version checks inside EMBA's Docker mode. Treat this as Dockerized code execution, not as pure static analysis. For full-system/service emulation, switch VMware to host-only first.

Only run broader scan if quick scan completes and the VM is healthy:

sudo ./emba -l ~/emba_logs/fw1/default_scan \
  -f ~/firmware/fw1/firmware.bin \
  -p ./scan-profiles/default-scan.emba

EMBA Emulation Warning: Safe VMware Network Settings

EMBA warns:

If you plan using the emulator (-E switch) your host and your internal network needs to be protected.

Meaning:

Firmware emulation may start unknown services or execute firmware logic.
Those services should not be exposed to your home/LAN/internet.

For normal static scans without emulation:

VMware network: NAT
Shared folders: disabled or read-only
No bridged networking

For EMBA -E user-mode emulation or any service testing:

Best default: Host-only network only, no NAT and no bridged adapter
Acceptable for short tests: NAT, only if no services are exposed/forwarded
Avoid: Bridged

VMware settings:

  1. Power off the VM.
  2. VM Settings -> Network Adapter.
  3. Use NAT for package installs and Docker pulls.
  4. Before emulation/service testing, either:
    • switch adapter to Host-only, or
    • add a second Host-only adapter and disconnect NAT.
  5. Ensure Bridged is not selected.
  6. In Edit -> Virtual Network Editor, use VMnet1 / Host-only for emulation. It should not bridge to a physical adapter.
  7. Keep shared folders disabled or read-only.
  8. Disable clipboard/drag-drop when running unknown firmware services.
  9. Do not configure VMware NAT port forwarding for emulated services.

Recommended profiles:

Install/update profile:
  Adapter 1: NAT connected
  Adapter 2: absent or disconnected

Emulation/service-test profile:
  Adapter 1: disconnected or NAT off
  Adapter 2: Host-only connected
  Bridged: never

Inside Kali, verify interfaces:

ip -br addr
ip route

The emulation profile should show either no default route, or only the route you intentionally kept. If you see a normal default route through NAT while testing unknown services, stop and disconnect NAT unless the test explicitly needs internet access.

If you use host-only testing, bind services only to localhost or the host-only IP. Do not bind to all interfaces unless you know what is exposed:

Prefer: 127.0.0.1 or host-only IP
Avoid: 0.0.0.0 while NAT/bridged is connected

Simple firewall belt-and-suspenders inside Kali:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

Only add an SSH allow rule if you actually SSH into the VM, and restrict it to the VMware host-only subnet shown by ip -br addr, not your whole LAN.

For the interview assignment:

Do not use -E at first.
Run quick-scan/default static scan.
Manually choose a candidate.
Only use emulation when it helps prove that candidate.
Switch to host-only before starting unknown services.

Free-Tier EC2?

Do not use AWS free-tier micro instances for EMBA.

Reason:

Free-tier instances are too small for EMBA.
EMBA wants 16 GB RAM or more, 8 cores recommended, and lots of disk.
Free-tier micro/small shapes are useful for learning SSH/Linux, not heavy firmware scanning.

If renting AWS for EMBA, use a short-lived paid instance:

OS: Ubuntu 24.04 LTS x86_64
CPU/RAM minimum: 4 vCPU / 16 GB
Better: 8 vCPU / 32 GB
Disk: 200-500 GB gp3 EBS
Security group: SSH only from your IP
Run time: start only when needed, stop/terminate when done

Reasonable families to check:

m7i-flex.xlarge or m7i.xlarge: 4 vCPU / 16 GB
m7i-flex.2xlarge or m7i.2xlarge: 8 vCPU / 32 GB
c7i-flex.2xlarge: 8 vCPU / 16 GB if CPU matters more than RAM

Avoid:

t2.micro / t3.micro / t3.small for EMBA
ARM-only instances unless every required tool supports ARM
exposing emulated firmware services to the internet

Cloud checklist:

confirm assignment allows cloud upload
create budget alarm
SSH only from your IP
use 200+ GB EBS
run quick scan first
download reports
terminate instance and delete unused volumes/snapshots

Current EMBA Review Takeaways

I have not audited every EMBA module line by line. I did review the parts that change how you should use the tool: official wiki pages, installer behavior, update behavior, scan profiles, AI/OpenAI configuration, emulation documentation, recent EMBA 2.0 reporting, and the EMBA book chapters that explain SBOM/vulnerability aggregation.

The practical model is:

EMBA is a triage and evidence amplifier.
It is not the final vulnerability proof.

Best current use for your assignment:

  1. Get the Docker/default install healthy first.
  2. Run quick-scan.emba or default-scan.emba without AI.
  3. Open the HTML report, but also inspect the raw log/module output.
  4. Select 3-5 leads that have reachable surface: web route, network service, script, binary, config, credential, or vulnerable component.
  5. Manually prove reachability and impact.
  6. Use emulation only after static results tell you what service or route is worth exercising.

What changed in EMBA 2.0 guidance:

  • System emulation is now much more important. Recent reporting says EMBA 2.0 improved system emulation substantially and added stronger SBOM/VEX/Dependency-Track support.
  • The official AI page was edited in 2026 and explicitly warns that the older OpenAI integration documentation is outdated and under heavy rework.
  • The LocalAI page currently exists but is still under construction, so do not base your assignment plan on LocalAI mode yet.
  • The update path is separate from Kali package upgrades. EMBA update means git pull, docker pull embeddedanalyzer/emba, and CVE/feed updates; it is not the same thing as apt full-upgrade.

High-value EMBA outputs to chase first:

Output type What to do with it
Web routes / CGI / Lua / PHP / shell scripts Map request input to command/file/network sink.
Credentials / keys / tokens Prove where they are used and whether they expose meaningful access.
Service versions / SBOM CVEs Confirm the component and version inside the firmware, then check reachability.
Dangerous shell/script patterns Trace attacker-controlled input, not just eval/system existence.
System-emulated services Capture the port, request, response, and crash/behavior evidence.

Do not spend the first day trying to understand every EMBA module. Spend it turning EMBA leads into one manually verified finding.

AI In Firmware Analysis

The Eclypsium podcast is useful background, but it should not change the EMBA setup.

Practical takeaway:

Use EMBA/manual tools to produce facts.
Use AI to ask targeted questions over extracted files, scripts, routes, and logs.
Do not ask AI to "find all vulnerabilities" across a giant firmware tree.

Good AI tasks:

  • summarize EMBA leads
  • explain shell scripts
  • prioritize web routes
  • draft report sections
  • compare evidence against exploitability criteria

Bad AI tasks:

  • declare exploitability without reproducer
  • invent routes or services
  • treat EMBA CVE output as confirmed vulnerability

EMBA AI Mode / OpenAI API Key

Do not enable EMBA AI mode as your default first scan.

Current EMBA source shows:

  • GPT_OPTION=0 is the default, meaning AI mode is off.
  • Q02_openai_question.sh sends selected code/script snippets to https://api.openai.com/v1/chat/completions.
  • The GPT profile default-scan-gpt.emba enables GPT_OPTION=1.
  • The same GPT profile also enables QEMULATION=1, so it is not a pure static scan.

Usefulness score for your interview scenario:

Use case Score Reason
First scan of unknown firmware 2/10 Adds privacy/cost/noise and may enable emulation through the GPT profile.
Summarizing selected EMBA evidence 7/10 Very useful if you feed small, concrete snippets.
Finding a real vulnerability automatically 3/10 It can point at leads, but still needs manual reachability and reproduction.
Report drafting after manual proof 8/10 Good for turning evidence into clear reviewer language.

Only add an API key if all of these are true:

  • the firmware/code can legally be uploaded to OpenAI
  • you understand API usage may cost money
  • you have already run a normal quick/default scan
  • you will verify every AI claim manually

Setup:

cd ~/tools/emba
cp config/gpt_config.env.template config/gpt_config.env
chmod 600 config/gpt_config.env
nano config/gpt_config.env

Use this shape:

OPENAI_API_KEY="sk-..."
GPT_QUESTION="For the following firmware code or script, identify only concrete attacker-controlled inputs, dangerous sinks, and verification steps. Do not invent vulnerabilities."
MINIMUM_GPT_PRIO=3

Note: the current template contains MAXMIUM_GPT_PRIO, but the current EMBA code uses MINIMUM_GPT_PRIO. Higher MINIMUM_GPT_PRIO means fewer GPT requests because EMBA only asks about entries at or above that priority.

If you run the stock GPT profile, treat it as an emulation-capable profile:

sudo ./emba -l ~/emba_logs/fw1/gpt_scan \
  -f ~/firmware/fw1/firmware.bin \
  -p ./scan-profiles/default-scan-gpt.emba

For a time-boxed assignment, my recommendation is simpler:

Run EMBA without AI.
Select 3-5 concrete leads.
Use ChatGPT/Claude/Codex manually on copied snippets/log excerpts.
Keep EMBA AI mode optional.

External Methodology

The OWASP-style Firmware Security Testing Methodology is useful as a checklist for:

  • firmware collection
  • extraction
  • filesystem analysis
  • credential search
  • config review
  • binary analysis
  • emulation/dynamic testing
  • reporting

Use it as a checklist, not as a substitute for a concrete finding.

Sources