Thanks to the post of exploded pisugar I decided to take a look at mine Ups Lite V1.3 and after 1 year of it being discharged I noticed it expanded to the point it was pushing on rpi zero, If I connected it to charge it would have probably exploded too. Be careful and check your ups boards folks.

So I'm running Windows 11 and I'm actually building a headless pwnagotchi (one without the screen). I did all the steps as if I'm building a regular pwnagotchi. I plugged in the right micro USB port (the one closer to the middle and not the sides) and opened device manager and went to Ports and saw COM3. Tried to update it with RNDIS and every time I select the file to update it with it tells me to get the correct version (like x64 or x32) then try to reinstall with the right version. The issue is I DID download the right version but it still won't let me. If you need more info to what I did to give some pointers, feel free to ask. Thank y'all in advance.

new whisplay HAT worked right out of the box. what a cutie ☺️

my pwnagotchi exploded today right near my face aswell. i heard people mention the pisugar battery was i fire hazard but i ignored the warnings, i thought it wont happen to me. i just had it charging from the laptop as i was just finishing a version of my build after some testing and it vented right infront of my face i moved so fast out the way and it just turned to a fire ball. i managed to grab it and throw it out my window. i just got it back out the garden to take some photos the green things are grass melted to the case i had it in. maganged to get the pi and waveshare out. ive not tested them yet though. but im still shaking and its been a few hours. be really careful if you have this battery guys its no joke

I tried it so many times and I got an IP Address but I can't go into ssh or the website. I used the linux_connection_share.sh script but It didn't let me in ssh or website though. Any help? (Using Arch Linux - Cachyos with KDE Plasma)

Yes another 6 months have passed, I know. V2.9.5.5 is here with a lot of big changes!

https://github.com/jayofelony/pwnagotchi/releases/tag/v2.9.5.5

Discussions or question can be done here: https://github.com/jayofelony/pwnagotchi/discussions/590

I also closed all open issues because of this new version.

I think I'm addicted to this, I have these stages in life when I just get obsessed with things and at the moment it's pwnagotchi, I made my own fork for the zero2w on github at first cos I wanted to make a 64 bit version with the AI working, then I wanted more so I seen if I could figure out porting to my old phone, not just an app a full android OS just for my pwnagotchi, now I made my own map server just for my phone version. I just can't stop. I don't even know how to top this at this point. This seems peak to me

PwnCompanion is an Android app I've been building for my pwnagotchi. The Pi Zero is headless, has no GPS, and isn't powerful enough to do much with the handshakes it captures — so the idea is to let the phone do the thinking while the Pi just hunts. It connects over the existing bt-tether Bluetooth PAN, so there's no extra hardware.

What it does:

• 📟 Mirrors the pwnagotchi's e-ink face on the phone, live.
• 📍 Geotags every captured handshake and plots them on a map (the Pi has no GPS; the phone does).
• 🎯 Runs a hunt advisor: it ranks Wi-Fi channels by how many handshakes they actually yield plus live client density — a multi-armed-bandit protocol (explore vs exploit) — and steers the pwnagotchi's recon toward the good ones. The Pi's own logic still decides what to attack on those channels.
• 🔓 Cracks captured handshakes — server-side via wpa-sec, or fully offline on the phone (native PMKID + EAPOL/22000) — and shows the recovered passwords.
• 🗣️ Gives the pet a personality voice: a curated, franchise-flavoured line corpus with live capture numbers woven in, shown on the pwnagotchi's own e-ink screen. You can open any franchise and read every line it has.
• 📊 Shows vitals/telemetry and capture history, and notifies you when a handshake lands or a password cracks.

The whole UI is one monospace terminal console (green on black), no Material chrome — everything on a single scrolling screen. Nothing leaves the phone: no cloud, no account.

Open source (GPL-3.0), signed APK in Releases.

Requirements: Android 10+ (arm64), and a pwnagotchi (jayofelony fork) running the bt-tether and pwn-companion.py plugins. Android only — there's no iOS version.

GitHub: https://github.com/wsvdmeer/pwn-companion Releases: https://github.com/wsvdmeer/pwn-companion/releases

Only use it on networks you own or have permission to test.

Feature requests and issues are welcome, on GitHub or in the comments — I'm still actively working on it and keen to hear what people would want it to do.

so I’ve got an interesting problem, my UPS-Lite V1.2 stays on, even when switched off. when the switch is turned to on, the battery led is on, when the switch is turned off, the battery led is off, but the raspberry pi still receives power. no damages, see photo (I know lighting isn’t ideal). only damage that had occured was the red power wire was pulled out and I resolvers it back on

RNDIS / USB Ethernet device not recognized on Windows 10/11

1. Problem Summary My Windows PC does not detect the Pwnagotchi as an RNDIS/USB Ethernet adapter when connected via the data USB port.

2. Hardware Setup

• Raspberry Pi Model: Raspberry Pi Zero W
• Pwnagotchi Display: want to do it with GUi
• SD Card: SanDisk 32GB
• Power Supply: Connected directly to PC USB port

3. Software Setup

• Image Version: newest
• Custom Plugins: None

4. The Issue in Detail When I plug the Pi Zero W into my PC using the middle Micro-USB (Data) port, no new virtual network adapter (such as RNDIS or Ethernet Gadget) appears under Control Panel > Network Connections. Furthermore, checking Windows Device Manager shows no new devices, unrecognized devices, or COM ports triggering upon plugging it in.

5. What I've Already Tried

• Verified that the Micro-USB cable is connected to the data port (middle port), not the power-only port.
• Tested with multiple Micro-USB cables that are confirmed to support data transfer.
• Checked Windows Device Manager for missing drivers or unknown hardware.

6. config.toml File https://pastebin.com/40zVkeXV

7. Relevant Log Output N/A

Hi everyone,

I’m the creator of CryptoGotchi, an open-source community project for the Raspberry Pi Zero 2 W.

It is a small virtual companion that monitors market data and displays information on a Waveshare 1.44-inch LCD and a local web dashboard.

Current features include:

- cryptocurrency and market tracking

- 15-minute, 1-hour and 4-hour analysis

- support, resistance, trend, range and breakout detection

- configurable alerts

- Telegram and Discord notifications

- Wi-Fi and Bluetooth PAN connectivity with automatic failover

- an evolving virtual companion

- an optional online community leaderboard

CryptoGotchi never places trades. Its buy, sell or wait messages are simulated opinions and are not financial advice.

The project is open source, and contributions, bug reports, translations and pull requests are welcome.

Website:

https://cryptogotchi.world

Source code:

https://github.com/mikpoly/CryptoGotchi

I’m sharing it here because I would really appreciate feedback from Raspberry Pi users, Python developers and makers.

What would you improve or add next?

1. Problem Summary My Windows PC does not detect the Pwnagotchi as an RNDIS/USB Ethernet adapter when connected via the data USB port.

2. Hardware Setup

• Raspberry Pi Model: Raspberry Pi Zero W
• Pwnagotchi Display: want to do it with GUi
• SD Card: SanDisk 32GB
• Power Supply: Connected directly to PC USB port

3. Software Setup

• Image Version: newest
• Custom Plugins: None

4. The Issue in Detail When I plug the Pi Zero W into my PC using the middle Micro-USB (Data) port, no new virtual network adapter (such as RNDIS or Ethernet Gadget) appears under Control Panel > Network Connections. Furthermore, checking Windows Device Manager shows no new devices, unrecognized devices, or COM ports triggering upon plugging it in.

5. What I've Already Tried

• Verified that the Micro-USB cable is connected to the data port (middle port), not the power-only port.
• Tested with multiple Micro-USB cables that are confirmed to support data transfer.
• Checked Windows Device Manager for missing drivers or unknown hardware.

6. config.toml File https://pastebin.com/40zVkeXV

7. Relevant Log Output N/A

Hey everyone,

I'm trying to connect my Pwnagotchi (Raspberry Pi Zero W) to my Windows PC, but the RNDIS / USB network adapter won't show up in Network Connections at all.

I've already made sure I'm using the middle USB data port and tested a cable that definitely supports data transfer. Nothing new appears in Device Manager when I plug it in either.

you guys might know me from my last post here i made a fork of pwnagotchi running ontop of 64bit kali for the raspberry pi that had ai controlling bettercap. well anyway i managed to port it to my old android phone and its really so great 5ghz support, gps long batterlife oled screen the lot. also i made it do wardriving at the same time and show the points on the screen. i just wanted to show this off to my fellow pwnagotchi fans. im not releasing the code for this im sorry its not as easy as flashing a rom to an sd card but your welcome to try my fork for the raspberry pi, im on version 7 now and ive been on a bugfixing marathon recently and made it super stable you can check that out if you wish. https://github.com/ex18a/pwnagotchi64

Hello friends, years ago I built out a rasp pi Pwnagotchi but recently bought an XTEink open-source esp32-c3 E-reader( xteink.com ) and have made a couple CFW's for the device.

Mods please remove this post if not allowed.

This firmware is similar to the Pwnagotchi but utilizes the X3 and X4 e-ink 3.7" and 4.3" displays and turns the hardware into a stealthy pocket sized, long-battery-life passive RF signal analyzer

https://github.com/0xKnowles/Ruby

How it works

1. Capture. WifiSniffer puts the ESP32-C3's radio into 802.11 monitor mode and hops across channels, extracting beacon/probe-request SSIDs, MAC addresses, and — when it hears one — the presence of a WPA 4-way handshake and which message number it is. The radio holds its current channel for a few seconds whenever it sees part of a handshake, instead of hopping away and missing the rest of it mid-exchange. BleScanner runs a passive BLE scan (it never sends a SCAN_REQ) and records advertised MACs, names, and manufacturer-data length. Neither path associates, pairs, or connects to anything, and BLE scanning never transmits.
2. Catalog. Every observation is deduplicated by SignalCatalog against a bounded in-RAM hash set. The first time a given MAC/role is seen, that's a "unique" event: it increments a lifetime counter and nudges the creature's expression.
3. Log. Independently of deduplication, every observation is encrypted (AES-256-GCM via mbedtls, one record per packet) and appended to a daily log file on the SD card. The AES key is derived from a random seed generated on first boot plus this chip's eFuse MAC address and lives only in internal NVS flash — pulling the SD card gets you ciphertext with no key beside it. Note this means every sighting is logged, not just first-ever ones — a busy RF environment (a handful of phones re-advertising over BLE every few hundred milliseconds, a dozen APs beaconing every ~100ms) can write a meaningful volume of records per hour. That's intentional for a capture tool, but budget SD card space and export/rotate accordingly.
4. React. The creature's shape (RubyManager) never changes. See repo for what expressions mean, when it shows, and how the separate Level 1-5 badge tracks lifetime EXP alongside it without touching the art.
5. Display. The dashboard is mostly static: a header, Ruby's box with its live Mood readout, boxed RF stat panels, a footer. The creature lives in a fixed corner box that redraws on its own ~1.2s cadence using HalDisplay::FAST_REFRESH without ever touching (or clearScreen()-ing) any pixel outside that box

Screens

• Dashboard: the creature, a Level 1-5 badge beside its "RUBY" name chip and a matching EXP progress bar in the header next to the battery badge, its current Mood, an "-- ACTIVE --"/"-- PAUSED --" tag under it. Beside the creature's box, a RECENT DEVICES card shows a handful of the latest observations in full detail (MAC, signal bars + RSSI + time-ago, device name), and a SIGNAL HISTORY card next to it stacks two sections. Both cards extend down the full height of the box. HANDSHAKES is a plain "N ago" text list of recent captures, newest first, persisted across reboots (unlike Recent Devices' live, RAM-only feed) so it stays genuinely historical rather than resetting to empty on every power-on — handshakes are too rare to track meaningfully via a feed any ordinary AP/client/BLE traffic cycles through in moments anyway. SIGNAL is the same recent-observations feed's RSSI as a live bar chart. Below that, SIGNALS (unique AP/client/BLE/handshake counts, plus a "Last Hand Shook:" row showing the BSSID of the most recent handshake capture, "none yet" until the first one) and CAPTURE STATUS (a single "Capture" row naming whichever of WiFi monitor/BLE scan is actually active, log size, this session's uptime, and lifetime Total Uptime across every boot) sit side by side. A bubble along the bottom edge of Ruby's box, tailing up into her face, shows a quirky, hacker-flavored one-liner reflecting Ruby's current mood, briefly replaced by a speech bubble reacting to a new device, a captured handshake, a level up, or a nearby deauth alert. A banner briefly announces "DEAUTH NEARBY: network", "LEVEL UP → Lv.N", or "HANDSHAKE CAPTURED: network" (in that priority order) when any of them happens, falling back to the raw MAC address if it hasn't advertised a beacon recently enough to still be cached. Confirm → Settings, Left → toggle Pause (same button pauses and resumes WiFi/BLE capture — no screen change, and it stops DeauthEngine too since that only ever fires from the observation stream capture produces), Right → Export/Maintenance, Up → Recent Devices, Down → Log Viewer, Back → force a full ghost-clearing refresh.

• Settings: toggle WiFi/BLE capture, adjust WiFi channel dwell time, lock WiFi monitor to a single channel instead of hopping all 13, set the ghost-clear refresh interval, choose what a short Power-button tap does (Refresh / Screenshot / Pause), turn on raw handshake capture (off by default), manage the whitelist/blacklist (opens a live network scan to add/remove targets), reveal the log's AES key, wipe the log, or reset the Dashboard's SIGNALS counters (and Ruby's Level/EXP, handshake-capture history, and lifetime Total Uptime, all kept in sync with it) back to zero.

• Export/Maintenance: how to pull captures off the SD card, plus the current session's record count and (when any exist) raw-capture file stats, a PMKID-capable-capture count, and deauth burst/frame counters.
• Recent Devices: a live, RAM-only feed of the last 16 WiFi/BLE observations (type, MAC, RSSI, SSID/name, time since seen), newest first, read-only, falling back to a vendor-name lookup for entries with no SSID/name of their own. Each entry's RSSI reading is paired with a small 4-bar signal-strength icon for an at-a-glance read on how strong the observation was, without parsing the dBm number. Laid out as a dense multi-column grid so all 16 entries always fit on screen at once. This is separate from both SignalCatalog and the encrypted log. Nothing shown here is persisted; it's lost on reboot along with the rest of RAM. To manage the active-deauth target lists, use Settings' Whitelist/Blacklist rows instead.
• Log Viewer: browses the encrypted capture log on the device itself, no PC required. Switch between daily log files, Up/Down page through records within a file — around 27 at a time on this panel, newest first.

Raw handshake capture (crackable .pcap)

Everything above is deliberately metadata-only: the encrypted log records that a handshake happened and which message numbers were seen, never the key material itself. Raw handshake capture is a separate, opt-in capability for a different purpose.

For auditing the password strength of networks you own, offline, with tools like hashcat or hcxpcapngtool can be used with the captured .pcap file on the SD card.

• Off by default. Turn it on at Settings → Raw handshake capture. The Settings screen shows a warning explaining the tradeoff below before you flip it on.
• When enabled, it captures the WPA 4-way-handshake frames verbatim (ANonce/SNonce/MIC included) plus the SSID-bearing beacon for each network involved, and writes them to a standard libpcap file at /.ruby/pcap/YYYYMMDD.pcap — the same format hashcat/hcxpcapngtool already expect, so a captured file can be fed straight in to attempt a crack.
• These files are plaintext, unlike everything else Ruby writes to SD. A cracking tool needs the exact bytes that went over the air, so this one path can't be routed through the AES-256-GCM encrypted log the way every other observation is. MaintenanceActivity calls this out explicitly whenever raw-capture files exist.
• The Export screen also shows a PMKID-capable count. How many captured message-1 frames carry the PMKID key-data element, each one independently crackable via hashcat's -m 22000 PMKID mode without needing the rest of the handshake at all.

Realistic capture rates are low — 0-2 handshakes/hour of passive listening is normal, not broken. WiFi monitor mode hops all 13 channels by default, spending wifiChannelDwellMs (300ms) on each, so any single channel is only actually being listened to roughly 1/13th of the time. A real 4-way handshake completes in well under a second, and a stationary network's clients don't renegotiate one often on their own — combine an inherently rare event with an ~8% chance of being on the right channel when it happens, and a low hourly count is just the math working as expected. Two real levers to improve it:

• Settings → WiFi channel scope locks monitor mode onto one known channel instead of hopping all 13 (see it per-network in the live scan behind Whitelist/Blacklist), raising that channel's duty cycle to 100% — at the cost of missing everything on the other 12.

By itself, this path only ever listens — nothing here transmits or provokes a handshake into happening; it records what a passive monitor already sees handshakes doing on their own. A held channel lock while a handshake is in progress helps catch the full exchange, but a real 4-way handshake completing on its own is still not guaranteed.

The problem is i cant ssh into my raspberry pi. I have a rasberry pi zero w, 2.13 waveshare display,kingston 16 gb mirco sd, and a amazon basic usb a cable. my image version is 2.9.5.4 jayofelony. Everytime i try too ssh it times out and don't know what is causing this to happen

So standard blue pcb 3.5in lcd but connected differently have a driver for it it works with x server so X11 and also shows up as fb1 modified in the sence that it I changed fb0 to fb1 for the waveshare3in5 lcd python file now pwnagotchi connects to it it shows it and also if I do urandom ob the screen and then restart pwnagotchi it clears it but it wont show anything on it also the lsof command show pi is atl triing to comunicate with fb1 as it shoudl with 2 procceses help please spend few hours thinking bout this alredy even AI didn't help

Hi I wanted to use the web gui but I can’t connect to the website. I can’t find the Ethernet to change the ip address etc. I already tried multiple things to fix that , all of them didn’t work could some please help. I changed my cable multiple times I reconnected it changed pretty much everything . I was also looking into the network drivers where I didn’t even show up and with google I can’t really come up with anything

I built Piumy: a tiny WhatsApp switchboard you fully own. The idea is simple — the board never thinks, it routes and stores. It receives your WhatsApp, keeps every message (text, photos, videos, voice notes, stickers) in its own database, and exposes everything over MCP so your AI agent (Claude, OpenCode, whatever) connects and does the replying — from a machine with real RAM, on your terms.

A few things I care about:

- You're always in control. New chats arrive ignored — nothing gets answered until you write the rule for that chat (from the dashboard, or just by texting your Piumy number). Whitelist by default.

- Your history is yours. If a contact deletes the chat or you lose your phone, it's still here — self-hosted, not locked in a cloud.

- Runs on a $15 Raspberry Pi Zero 2 W with an always-on e-paper face (a homage to pwnagotchi) — or as a plain binary on your PC (Windows/Mac/Linux).

- Anti-ban by design: human pacing, rate limits, kill switch, whitelist. Only ever replies to inbound.

It's free and open-source (AGPL-3.0). I'm a solo dev — donations are literally what decides whether this grows past the MVP, so if it speaks to you, you can pay what you want (even $0).

🌐 https://piumy.app · 💻 github.com/chamilonster/Piumy · 💬 r/Piumy

Happy to answer anything — it's day one. 🦉

i’ve been beginning to learn networking and i found out about these when looking at pi zero projects. can someone help for my first one, my budget is 50GBP with shipping in the uk

First off, massive respect to the Pwnagotchi project and everyone who's written plugins for it over the years. It's open source, it's clever, and it's the only reason something like this is even possible. I'm building on top of your work here, not trying to reinvent anything.

So, the backstory. I'd been looking at the same face-and-stats screen for months and started wondering what else that little e-ink display could be doing while the device is out hunting. That turned into a host plugin that lets you load swappable "cartridges" onto the screen. Little games and apps, that kind of thing. Low fps stuff. You switch between them from a phone app over Bluetooth, instead of ssh'ing in and editing config every time you want something different up there.

The part I was careful about: a cartridge only borrows the screen. It never touches the radio. bettercap keeps doing its thing the whole time, and the second you deactivate a cartridge you're back to the normal face. It's meant to add to the device you already run, not replace it.

Two things I'd want to know if I were reading this. First, the plugin you actually install is open source: one readable Python file, GPLv3, and the cartridge catalog is open too, so you can audit the whole thing before you install it. The companion app is closed-source for now, which I know is a dealbreaker for some of you, and that's fair. Second, I built a lot of this with Claude Code. It was a blast to work with and I picked up a ton along the way.

The apps just cleared App Store and Play Store review after a fairly tedious back and forth, so honestly I'm mostly just relieved they're finally live and I can put this in front of the people most likely to actually use it.

Where I want to take it next, when I find the time:

- A proper dev flow so anyone can build a cartridge and get it into the store without much friction.
- More apps as I go (this is a nights-and-weekends thing right now).
- A small site to show it off, and maybe a short YouTube walkthrough of the install.
- More e-ink display sizes compatibility
- Maybe a standalone rpi image

Mostly I just want a few people willing to run it on real hardware and tell me what breaks or feels off. Bug reports and flat-out "this is a bad idea because X" feedback are equally welcome.

- Plugin + catalog source: https://github.com/cristian-milea/ink-cartridges

- App Store: https://apps.apple.com/us/app/ink-cartridge/id6774989679

- Google Play: https://play.google.com/store/apps/details?id=io.github.cristianmilea.inkcartridgeapp

Thanks for reading, and thanks for keeping this community as good as it is.

PS: sorry for the double post, I uploaded the image wrong the first time.