Open-source project
0ct0sec/M5PORKCHOP avatar
0ct0sec/M5PORKCHOP

M5PORKCHOP puts a WiFi research rig in a pocket keyboard

ON NO! Someone put an RPG in a packet sniffer

935 stars67 forksC++MIT

At a glance

What is it?
M5PORKCHOP is MIT licensed firmware for the M5Stack Cardputer, an ESP32-S3 board with a keyboard and screen, that adds dual-band packet capture, spectrum analysis and GPS wardriving to a device you can hold in one hand. It suits security researchers and teachers, and it is hardware-specific with no emulator.
Who is it for?
M5PORKCHOP suits a security researcher or an instructor who wants a self-contained, battery-powered WiFi lab tool and can source the specific Cardputer hardware, or who already owns one and wants the firmware. It is the wrong tool for a software-only workflow, since the whole design is bound to a 240 by 135 screen, 56 keys and a 300KB heap, and it is the wrong tool for anyone who needs to evaluate a site rather than study one.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 17 days ago.
What is it written in?
Mainly C++, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A research tool shaped like a pocket keyboard

The project describes itself in one line, and the line is a joke with a real spec sheet attached: someone put an RPG in a packet sniffer.

The README calls PORKCHOP a learning tool for WiFi security research, and the framing is repeated throughout. The device is an M5Cardputer, an ESP32-S3 board running at 240MHz with 8MB of flash, and the firmware turns a pocket keyboard into a WiFi research companion. The feature list covers dual-band packet capture through an ESP32-C5 coprocessor, EAPOL handshake and PMKID extraction with hashcat 22000 plus PCAP output, dual-band GPS wardriving with WiGLE v1.6 export, 2.4 and 5GHz spectrum analysis with sinc-function RF rendering, BLE notification spam, beacon injection with vendor IE fingerprinting, and device-to-device sync over ESP-NOW.

The output formats are named with precision, which is the sign of a project that expects its output to be used elsewhere. The handshake and PMKID work produces hashcat 22000 format and PCAP. The wardriving work produces WiGLE v1.6. Those are formats other tools consume, so the result of a session is not trapped inside the device.

The writing style is deliberately theatrical, with a pig as the mascot and a running joke about a horse that is unavailable for comment. The jokes are consistent and the technical content is not affected by them, but a reader should know the tone in advance, because the documentation is written to be read in one sitting and the humour is load-bearing for the project's identity rather than incidental decoration.

The mode menu is the feature list

The main menu is the clearest summary of what the firmware does, and it is worth reading as a table of capabilities:

code
| [O] OINK MODE     - yoink handshakes. dual-band fangs.       |
| [D] DO NO HAM     - zero TX. passive recon. zen pig.         |
| [W] WARHOG        - dual-band wardriving. legs required.     |
| [H] SPECTRUM      - 2.4 + 5GHz RF. sinc lobes. physics.      |
| [B] PIGGY BLUES   - BLE spam. YOU DIED. in that order.       |
| [F] FILE XFER     - web UI. civilization achieved.           |
| [*] BACON         - fake beacons. via MENU. worth the trip.  |

Two of these lines carry the project's own ethical framing in a single word. Do No Ham is zero transmission, passive reconnaissance only. And BACON, fake beacons, is marked as being reached via the MENU rather than selected directly, which puts it a deliberate step away from the default modes.

The menu also lists the two non-radio features. File Xfer is a web UI for moving files off the device, and the PIG DEMANDS entry is described as session challenges with three trials, which is a game built on the hardware rather than a scanning function.

The closing block of the menu is the part that matters most for anyone evaluating the project, and it is not styled as a joke:

code
| REMEMBER:                                                    |
| 1. only attack what you own or have written permission to    |
| 2. "because it can" is not a legal defense                   |
| 3. the pig watches. the law judges. know the difference.     |

That is the project stating the constraint it intends to operate under, in the place where a user picks a mode.

The hardware constraint is the design constraint

The specs section explains the engineering, and the explanation is really about one fact: there is no PSRAM.

The board is an M5Stack StampS3 with an ESP32-S3FN8, a 240MHz dual-core processor, 512KB of SRAM and 8MB of flash. The README states it plainly, with roughly 300KB of usable heap and a note that every byte matters. The screen is a 240x135 IPS LCD on an ST7789V2, the keyboard has 56 keys, there is an SD card slot on a shared SPI bus with the CapLoRa module, a NeoPixel LED on GPIO 21, and USB-C for power and serial.

That memory figure drives the architecture. The core is a cooperative main loop, with porkchop.update() handling the sound effect ticks inside it, plus Display::update() and Mood::update() as the pig's core functions. State is a single PorkchopMode enum with 24 states, where one mode lives and the others wait, and the README's summary of that is that the pig is a finite state machine with infinite opinions.

TLS is called out separately because it is the constraint that bites hardest. TLS needs about 35KB contiguous, referenced as kMinContigForTls in the heap policy, and on a 300KB heap with no external memory that is a real design pressure rather than a detail.

The optional hardware is where the features come from. The AT6668 or ATGM336H GPS module gives wardriving, and the CapLoRa868 module carries GPS and LoRa while sharing the SD SPI bus. The M5MonsterC5 is the ESP32-C5 WiFi 6 dual-band coprocessor that gives the device its 5GHz capability, running JanOS or projectZero firmware and talking to the Cardputer over Grove UART. The Cardputer ADV adds a BMI270 IMU, which enables a dial mode in the spectrum view.

The hardware section is honest about the parts a desktop cannot do. It lists your legs, for wardriving, with no judgment on wheels.

Buying the hardware is an affiliate arrangement, stated plainly

The hardware section is titled with a joke about selling out, and then it does something unusual: it tells you exactly how the money works before it asks for anything.

The links to the M5Stack Cardputer ADV and the CapLoRa 1262 module are affiliate links, and the README says so in as many words, with a short explanation that they get a cut and you get a pig, followed by a joke about capitalism working sometimes. It also points out that the pig does not mass-produce itself, that the body needs a store and the store needs a link.

The consequence for a reader is that there is no free path to the hardware here. The project is firmware for a specific board, and a contributor without the board cannot test. The README says as much in passing, noting that not buying is also valid and that the pig judges purchases and not people, and that you can clone it, build it or source it however you like since open source means open source.

The repository layout supports that statement in practice. There is a src directory for the firmware, a test directory, a scripts directory, a data directory, a patches directory, a platformio.ini file, sdkconfig.defaults for the ESP-IDF configuration, and partitions.csv for the flash layout. There is also a separate SD card layout section in the documentation, because a device with 8MB of flash and a shared SD bus needs somewhere to put the data that does not fit in memory, and a table of contents entry in the README covers it.

The result is a project that is closer to a piece of hardware design with software attached than to a software project that happens to need a board. That framing matters for anyone deciding whether to build on it.

PigSync and the offline-first shape of the thing

Two features in the list have an engineering story behind them, and both are unusual.

The first is PigSync, device-to-device sync via ESP-NOW, described in the menu as the prodigal son that answers the phone, and given its own section in the table of contents. ESP-NOW is a peer-to-peer radio protocol that needs no infrastructure, no access point and no pairing, which means two Cardputters near each other can exchange data directly. The README's framing is that this is what makes the tool useful in the field, where a capture taken somewhere has to get back to a workstation without a network.

The second is the personality system, the mood and avatar and weather features in the table of contents, and the README is candid that this is a system with opinions about your choices. It is the part of the firmware that has no place in a technical specification and is the part that makes the device pleasant to carry around and use for hours, which for a field tool is not a trivial consideration.

The forbidden cheese economy, XP, ranks and trophies, is a third feature in the same category, and it explains the game framing in the elevator pitch. A device that is a research rig rather than a scanner is easier to justify to a security team if it is also a thing you would want to play with.

The menus and controls have their own section in the table of contents, and the README closes with a troubleshooting section it calls the confessional, followed by a greetz section. For a project whose documentation is written as a series of chapters rather than a reference, that structure is consistent: the reference documentation is the wiki, and this file is the narrative.

A maintained firmware project with an unmaintained release habit

The maintenance picture is worth reading precisely, because the two numbers point in different directions.

The repository is not archived, and the last push was on 2026-10-06, so the firmware is being worked on. The recent releases, on the other hand, are v0.1.8b-PSTH from 2026-02-08, v0.1.8_heapcampf from 2026-01-30 and v0.1.8_YDE from 2026-01-19. The version numbers carry suffixes, which reads like a per-event or per-conference build rather than a semantic version.

The default branch is main, and the homepage in the repository metadata is the releases page rather than a documentation site, which fits a hardware project where the artefact people want is a firmware image and the flashing instructions.

The licence is MIT, with a LICENSE file at the top of the tree, and there is a legal section in the table of contents, placed after the build section and before troubleshooting. The mode menu makes the same point in three lines about only attacking what you own, and about because it can not being a legal defence.

For an adopter, the practical summary is that this is a working, actively developed firmware tree with a small project, a very specific hardware target and releases that are published when there is something worth publishing. The team that maintains it is also the team that writes the documentation, and both have a strong voice, which is either an asset or a filter depending on what you want from a security tool.

Editorial conclusion

M5PORKCHOP suits a security researcher or an instructor who wants a self-contained, battery-powered WiFi lab tool and can source the specific Cardputer hardware, or who already owns one and wants the firmware. It is the wrong tool for a software-only workflow, since the whole design is bound to a 240 by 135 screen, 56 keys and a 300KB heap, and it is the wrong tool for anyone who needs to evaluate a site rather than study one. Before you adopt it, confirm the board variant, since the firmware targets the M5Stack StampS3 with no PSRAM, read the legal section and the reminder in the mode menu about only attacking what you own, and check that the host tools you intend to use, hashcat 22000 and the WiGLE export path, are available in your own environment.

Frequently asked questions

What hardware does M5PORKCHOP run on?

It targets the M5Stack Cardputer, specifically an M5Stack StampS3 with an ESP32-S3FN8, a 240MHz dual-core processor, 512KB of SRAM, 8MB of flash, a 240x135 IPS screen, a 56 key keyboard and an SD card slot. The board has no PSRAM, leaving roughly 300KB of usable heap.

Which modes does the M5PORKCHOP menu offer?

Oink Mode for handshakes, Do No Ham for passive reconnaissance with zero transmission, Warhog for dual-band wardriving, Spectrum for 2.4 and 5GHz RF analysis, Piggy Blues for BLE spam, File Xfer for a web UI, and Bacon for fake beacons, which is reached through the MENU rather than the main screen.

What formats does M5PORKCHOP export captured data in?

EAPOL handshake and PMKID extraction produces hashcat 22000 format and PCAP, and the GPS wardriving mode exports WiGLE v1.6. The README names both formats explicitly.

Is M5PORKCHOP legal to use?

The project states its own condition in the mode menu: only attack what you own or have written permission to, and because it can is not a legal defense. The README has a legal section of its own, and calls the firmware a learning tool for WiFi security research.

Official sources

  1. 0ct0sec/M5PORKCHOP on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/0ct0sec-m5porkchop.svg)](https://hysenlabs.com/projects/0ct0sec-m5porkchop)

Was this useful?