DEV Community: Ebrahim Shafiei

Wireshark Alternative Android

Ebrahim Shafiei — Sun, 12 Jul 2026 02:48:16 +0000

Wireshark Alternative Android

You need to debug an Android application's network behavior, but you do not want to root the phone, configure a desktop proxy, or rebuild the entire test environment around a laptop.

This tutorial shows a practical wireshark alternative android workflow using Abdal PacketView. The capture runs on the Android device through VpnService, traffic can be limited to selected applications, packets can be filtered in real time, and the final session can be exported as PCAPNG for Wireshark or tshark.

The goal is not to replace every feature in desktop Wireshark. The goal is to make the first half of the investigation easier: collect relevant Android traffic, preserve application context, and hand the capture to a mature desktop analyzer when deeper work is required.

What you will build as a workflow

By the end, you will have a repeatable process for:

Capturing Android IP traffic without root.
Limiting capture to a target application.
Filtering DNS, HTTPS, UDP, QUIC, addresses, and ports.
Identifying the Android package associated with traffic.
Saving a ZIP bundle containing PCAPNG and statistics.json.
Opening the same capture in Wireshark for deeper analysis.

Before you start

You need:

An Android device with Abdal PacketView installed.
A target application that you own or are authorized to test.
Wireshark or tshark on a desktop if you want offline analysis.
Enough storage for the capture archive.

You should also disconnect any other active VPN. Android permits only one active VPN service per user or profile, and Abdal PacketView uses VpnService to create its local capture tunnel.

Do not capture traffic from devices, accounts, or applications without authorization. Packet captures can contain sensitive metadata and, when protocols are unencrypted, sensitive payload data.

Step 1: Understand what is being captured

Abdal PacketView uses Android's supported VPN API to create a local TUN interface. After you approve the system VPN dialog, Android routes selected IP traffic through that interface.

Conceptually, the path looks like this:

Target Android app
        |
        v
Android VpnService routing
        |
        v
Local TUN interface
        |
        +--> packet metadata decoding
        +--> app attribution
        +--> live filtering
        +--> session statistics
        +--> forwarding
        |
        v
Internet

A TUN interface works at the IP layer. This means the workflow can inspect routed IPv4 and IPv6 packets, but it is not Wi-Fi monitor mode and does not capture frames from other devices on the network.

This distinction prevents a common misunderstanding. A wireshark alternative android application based on VpnService is a local device traffic analyzer, not a passive wireless sniffer.

Step 2: Select the application with App Split

Whole-device captures become noisy quickly. Before starting, open the App Split section and choose the mode that matches your test.

Use Route via Tunnel when you want only selected applications to enter the capture path. This is usually the best mode for debugging one application.

Use Bypass Tunnel when you want to capture most device traffic but exclude specific applications.

For a focused test:

Choose Route via Tunnel.
Select only the application under test.
Apply the configuration.
Return to the Capture screen.

App Split is not merely a visual filter. It controls which application traffic Android routes through the VPN interface. Display filters, used later, only control which captured packets are shown.

Step 3: Start a short capture

Tap Start and approve the Android VPN consent dialog.

Do not immediately browse through several screens or perform many unrelated actions. A useful packet capture is a controlled experiment.

Use this pattern:

Start capture.
Perform one action in the target app.
Wait for success or failure.
Return to Abdal PacketView.
Stop capture.

Examples of one-action tests:

Sign in once.
Refresh one data screen.
Upload one file.
Send one message.
Trigger one synchronization attempt.
Reproduce one API timeout.

A 20-second capture with a precise purpose is often more useful than a 20-minute capture filled with background traffic.

Step 4: Filter the packet table

Abdal PacketView documents Wireshark-style display filters for protocols, fields, comparison operators, containment, Boolean logic, and parentheses.

Start with simple filters.

Find DNS traffic

udp && port == 53

Use this when the application cannot resolve a hostname, connects to an unexpected resolver, or appears to stall before establishing a connection.

Find traffic involving a specific IP address

ip.addr == 8.8.8.8

Replace the address with the endpoint you are investigating.

Find HTTPS-related flows

https

This helps locate encrypted web traffic. It does not decrypt TLS payloads.

Combine conditions

tcp && port == 443 && frame.len > 500

Use combined conditions to reduce the table to the flows that matter.

The syntax is described as Wireshark-style, not necessarily a complete implementation of every Wireshark display-filter field and function. Treat the application's built-in help as the source of truth for supported expressions.

Step 5: Use app attribution

A capture from a phone may include traffic from several sources. Abdal PacketView documents UID-based attribution that associates connections with an application name and package name.

When reviewing a suspicious endpoint, verify the application identity instead of assuming that every packet belongs to the foreground app.

This is useful when:

Several applications use the same cloud provider.
The operating system creates background connections.
An SDK sends telemetry independently of the main API flow.
A test device contains unrelated messaging or synchronization apps.
A package contacts an undocumented endpoint.

Application attribution is one of the main reasons this workflow is more practical than a generic packet dump.

Step 6: Save the capture

Use Save Capture after the test is complete.

The documented output is a ZIP package with this structure:

Abdal_PacketView_<timestamp>.zip
├── Abdal_PacketView_<timestamp>.pcapng
└── statistics.json

The PCAPNG file stores the packet capture for Wireshark and tshark. The JSON file stores a session summary such as packet count, captured data size, duration, generation time, and active App Split mode.

The project also states that application attribution can be carried in custom PCAPNG options identified by IANA Private Enterprise Number 66033 for Abdal Security Group. PCAPNG supports custom options associated with a Private Enterprise Number, allowing Android-specific metadata to accompany standard packet data.

Step 7: Open the capture in Wireshark

Move the ZIP archive to your workstation and extract it. Open the .pcapng file in Wireshark.

At this stage, you can use the larger desktop toolset for:

Detailed protocol trees.
TCP stream analysis.
Packet timing and retransmission analysis.
Advanced display filters.
Endpoint and conversation statistics.
I/O graphs.
Exporting selected packet ranges.
TLS decryption when you have authorized session secrets.

A simple command-line verification with tshark is:

# -------------------------------------------------------------------
# Programmer       : Ebrahim Shafiei (EbraSha)
# Email            : Prof.Shafiei@Gmail.com
# -------------------------------------------------------------------

tshark -r Abdal_PacketView_<timestamp>.pcapng -c 20

To inspect DNS packets:

# -------------------------------------------------------------------
# Programmer       : Ebrahim Shafiei (EbraSha)
# Email            : Prof.Shafiei@Gmail.com
# -------------------------------------------------------------------

tshark -r Abdal_PacketView_<timestamp>.pcapng -Y "dns"

To list traffic involving a known address:

# -------------------------------------------------------------------
# Programmer       : Ebrahim Shafiei (EbraSha)
# Email            : Prof.Shafiei@Gmail.com
# -------------------------------------------------------------------

tshark -r Abdal_PacketView_<timestamp>.pcapng -Y "ip.addr == 203.0.113.10"

Replace the placeholder filename and test address with values from your capture.

Step 8: Read `statistics.json` as test context

Do not ignore the JSON file. Packet captures answer what happened on the wire, while session metadata helps explain the conditions under which the capture was created.

A conceptual structure might resemble this:

{
  "packetCount": 1240,
  "capturedBytes": 987654,
  "durationSeconds": 22,
  "appSplitMode": "route_via_tunnel",
  "generatedAt": "2026-07-12T10:30:00Z"
}

This example is illustrative. Use the actual fields generated by your installed version of Abdal PacketView rather than assuming an undocumented schema.

For bug reports, include:

The action that was performed.
The expected result.
The actual result.
The capture start and stop conditions.
The selected App Split mode.
The display filter used during review.
The PCAPNG file.
The original statistics.json file.

That creates a more reproducible diagnostic package than a screenshot of an error message alone.

What this workflow can reveal

Even when application payloads are encrypted, the capture can reveal useful behavior:

DNS queries and responses.
Destination IP addresses and ports.
TCP connection attempts and resets.
UDP and QUIC usage.
Retry patterns.
Packet sizes and timing.
Connections to unexpected infrastructure.
The Android package responsible for a flow.

For example, an application timeout may be caused by DNS failure, unreachable IPv6 routing, repeated TCP retransmissions, a QUIC fallback, or a connection to an obsolete endpoint. You do not always need decrypted payloads to identify the failing layer.

What this workflow cannot do

A technically accurate wireshark alternative android tutorial should also cover the limits.

Abdal PacketView does not turn a normal phone into a Wi-Fi monitor-mode adapter. It does not capture traffic from nearby devices. It does not automatically decrypt TLS or QUIC payloads. It does not reproduce every Wireshark dissector, graph, statistic, or expert-analysis feature on Android.

It also uses the Android VPN slot. If another VPN is active, the two services normally cannot operate simultaneously for the same user or profile.

These limitations are expected for a no-root, VpnService-based architecture.

A debugging checklist

Use this checklist for your next mobile network issue:

[ ] Confirm that you are authorized to capture the traffic.
[ ] Disconnect another active VPN.
[ ] Select the target application with App Split.
[ ] Start capture immediately before the test action.
[ ] Reproduce only one issue.
[ ] Stop capture immediately afterward.
[ ] Filter by protocol, endpoint, or port.
[ ] Verify the attributed package.
[ ] Save the ZIP archive.
[ ] Keep statistics.json with the PCAPNG file.
[ ] Continue advanced analysis in Wireshark or tshark.

Conclusion

Abdal PacketView provides a practical wireshark alternative android capture workflow for developers, QA engineers, network analysts, students, and authorized security researchers.

Its value comes from combining Android's supported VpnService and TUN model with live packet metadata, UID-based application attribution, App Split routing, familiar filters, session statistics, and PCAPNG export.

The phone handles collection and first-pass triage. Wireshark handles deep offline analysis. Instead of forcing one tool to do everything, the workflow uses each environment for what it does best.

FAQ

Does Abdal PacketView require root?

No. Its documented architecture uses Android VpnService and requires approval through the system VPN consent dialog.

Is it a full Wireshark port for Android?

No. It is an on-device packet capture and traffic-analysis tool with Wireshark-style filtering and PCAPNG export. Wireshark remains more capable for deep desktop analysis.

Can I capture only one Android application?

The App Split Route via Tunnel mode is designed to route selected applications through the capture tunnel.

What files are exported?

The documented ZIP bundle contains a .pcapng capture and a statistics.json session summary.

Project Links

GitHub: https://github.com/ebrasha/abdal-packetview

Developer

Abdal PacketView was designed and developed by Ebrahim Shafiei (EbraSha), a software developer and cybersecurity researcher focused on network analysis, security engineering, and open-source tools.

GitHub: https://github.com/ebrasha
Telegram: https://t.me/ProfShafiei
LinkedIn: https://www.linkedin.com/in/profshafiei/
X: https://x.com/ProfShafiei
Email: Prof.Shafiei@Gmail.com

Android Packet Capture Without Root Using Abdal PacketView

Ebrahim Shafiei — Mon, 06 Jul 2026 02:49:28 +0000

Android Packet Capture Without Root Using Abdal PacketView

If you have ever tried to inspect Android traffic the same way you inspect desktop traffic, you already know the pain.

On desktop, Wireshark is usually the obvious answer. On Android, packet capture often turns into a setup problem before it becomes an analysis problem. Do you root the device? Do you proxy traffic? Do you route everything through a computer? Do you accept that some UDP or non-HTTP behavior will be harder to inspect?

Abdal PacketView takes a more direct route: it performs Android packet capture on the device itself using Android VpnService and a local TUN interface. No root. No external capture server. No desktop proxy required.

Project Author, Source Code and Download

Abdal PacketView is designed, developed and maintained by Ebrahim Shafiei (EbraSha), the programmer behind the project and Head of Abdal Security Group.

This project was built to give Android users, developers, security researchers and network analysts a practical packet capture workflow directly on Android, without root access and without relying on an external capture server or desktop proxy.

The source code, latest releases, project documentation and download information are available on GitHub:

Download and Source Code: Abdal PacketView on GitHub

If you find the project useful, you can support its growth by starring the repository, sharing it with other developers, reporting issues, or contributing improvements.

What Abdal PacketView Does

Abdal PacketView is an Android network packet capture and traffic analysis tool. It captures raw IP packets locally, decodes network metadata, shows packets in a live interface, and exports captures in PCAPNG format for tools like Wireshark and tshark.

The core workflow looks like this:

Start capture
Approve Android VPN consent
Use the device normally
Inspect packets live
Apply filters
Save capture
Open PCAPNG in Wireshark or tshark

This makes it useful for:

Android developers debugging app traffic
Security researchers reviewing suspicious connections
QA engineers collecting network evidence
Network analysts inspecting mobile behavior
Advanced users learning real protocol behavior

How the Capture Works

The app uses Android VpnService to create a local TUN interface. After the user approves the VPN consent dialog, traffic can pass through that local capture path.

Conceptually, the flow is:

App traffic
  -> VpnService
  -> Local TUN interface
  -> Packet capture
  -> Metadata decoding
  -> App attribution
  -> Live table and export

This architecture is important because it avoids root access while still giving practical packet visibility. The README lists decoding support for IPv4, IPv6, TCP, UDP, and ICMP traffic.

Why This Is Useful

A proxy is not the same thing as packet capture. Proxies are excellent for some HTTP and HTTPS debugging workflows, but they do not give the same general packet-level view.

Abdal PacketView is closer to a mobile capture companion for Wireshark. It captures traffic where the traffic happens, then exports the result for deeper analysis.

The app saves captures as a ZIP package containing:

Abdal_PacketView_<timestamp>.pcapng
statistics.json

The .pcapng file is compatible with Wireshark and tshark. The statistics.json file stores session data such as packet count, captured data size, duration, generation time, and active App Split mode.

Step 1: Start a Capture

Open Abdal PacketView and go to the Capture tab. Tap Start and approve the Android VPN consent dialog.

Once capture is active, use your Android device normally. Packets appear in the live capture table as traffic is generated.

This is the key advantage of the tool: the capture happens inside the mobile workflow instead of forcing the workflow to move to a desktop setup.

Step 2: Inspect Packets

Tap a packet row to inspect decoded details. This gives you a closer look at the traffic metadata.

The app can decode common network layers and protocols listed in the README:

IPv4
IPv6
TCP
UDP
ICMP

For Android app testing, that is enough to answer many practical questions: which endpoints are contacted, what protocol is used, whether UDP is active, whether DNS-like traffic appears, and how traffic changes during a specific action.

Step 3: Use Filters

Abdal PacketView supports Wireshark-style display filters for protocols, fields, ports, packet length, and Boolean logic.

Example filters:

https
udp && port == 53
ip.addr == 8.8.8.8

This is especially helpful because Android traffic can get noisy very quickly. Filtering lets you move from “everything the device is doing” to “the exact traffic I care about.”

Step 4: Use App Split Tunnel

The app includes App Split Tunnel with two modes:

Route via Tunnel
Bypass Tunnel

Route via Tunnel is useful when you want to capture selected apps. Bypass Tunnel is useful when you want to exclude selected apps.

For example, if you are testing one Android app, you can focus on that app instead of capturing unrelated background traffic. If another app is creating too much noise, you can bypass it.

Step 5: Export for Wireshark

When you save a capture, Abdal PacketView creates a ZIP package with the PCAPNG file and statistics.json.

This export step is what makes the tool fit into a professional workflow. You can capture traffic on Android, then continue analysis in Wireshark or tshark.

The project also uses custom PCAPNG options under IANA Private Enterprise Number 66033 registered for Abdal Security Group. This is used for project-specific metadata, including app attribution context.

What Makes It Different

The strongest feature set is the combination:

No-root Android packet capture
Local VpnService and TUN interface workflow
Internet connectivity preservation during capture
IPv4, IPv6, TCP, UDP, and ICMP decoding
UID-based app attribution
App Split Tunnel modes
Wireshark-style display filters
PCAPNG export with session statistics
Kotlin and Jetpack Compose UI
Built-in Help Center and Proto Tuts+ learning content

Individually, some of these features are useful. Together, they create a serious Android packet capture workflow.

Final Thoughts

Abdal PacketView should not be described as a full Wireshark clone. That is not the right framing. Wireshark remains the deeper desktop packet analysis tool.

The better framing is this: Abdal PacketView brings practical Android packet capture to the device itself and then exports clean PCAPNG files for Wireshark and tshark.

For developers, hackers, security researchers, and network analysts who need packet-level visibility on Android without root, Abdal PacketView is a strong and practical tool.

Project Author, Source Code and Download

Abdal PacketView is designed, developed and maintained by Ebrahim Shafiei (EbraSha), the programmer behind the project and Head of Abdal Security Group.

The source code, latest releases, project documentation and download information are available on GitHub:

Download and Source Code: Abdal PacketView on GitHub

If you find the project useful, you can support its growth by starring the repository, sharing it with other developers, reporting issues, or contributing improvements.

FAQ

Does Abdal PacketView require root?

No. It uses Android VpnService and a local TUN interface.

Can I use the exported file in Wireshark?

Yes. The capture is exported as .pcapng, which is compatible with Wireshark and tshark.

Can it show which app generated a packet?

Yes. It supports UID-based app attribution with app name and package name metadata.

Is this only for security researchers?

No. It is also useful for Android developers, QA engineers, network analysts, and advanced users.

Is it a full Wireshark replacement?

No. It is better described as an Android packet capture tool that works with Wireshark-style workflows and PCAPNG export.

One Binary to Manage an SSH Tunnel Server: Abdal 4iProto Panel

Ebrahim Shafiei — Tue, 09 Jun 2026 22:49:40 +0000

Why a single binary matters for tunnel administration

If you have ever stood up an SSH tunnel server on a fresh VPS, you know the real cost is not the server—it is everything around it. You need a way to add and revoke users, cap their bandwidth, watch sessions in real time, block abusive IPs, and survive a reboot without a 12-step runbook. The usual answer is a stack: a runtime, a web framework, a database, a reverse proxy, a process manager. Each layer is one more thing that breaks at 2 a.m.

Abdal 4iProto Panel takes the opposite bet. It is a web-based management interface for the Abdal 4iProto Server—a dedicated SSH tunnel server—written in Go and compiled to a single executable with embedded resources. CSS, JS, HTML templates, and translation files all live inside the binary. There is no runtime to install, no external dependency to pin, no asset directory to ship. You drop one file on Windows or Linux, optionally register it as a service, and you have a full admin console. This article walks through how it is built and how an expert operator would actually use it.

🔗 Panel repo: https://github.com/ebrasha/abdal-4iproto-panel
🔗 Server repo: https://github.com/ebrasha/abdal-4iproto-server

The architecture in one sentence

The panel is a Go process that embeds its own web assets, persists configuration as flat JSON files, talks to the 4iProto SSH tunnel server it manages, and can run as a Windows Service or a Linux systemd unit. That is the whole shape of it—and the simplicity is the point.

Configuration lives in plain JSON, not a database engine. On first run the panel writes abdal-4iproto-panel.json:

{
  "port": 52202,
  "username": "ebrasha",
  "password": "ebrasha1309",
  "logging": true,
  "blocked_ips": [],
  "max_login_attempts": 5,
  "login_attempt_window": 300,
  "block_duration": 3600
}

For a tunnel management surface, JSON state is a defensible choice: the data set (users, blocked IPs, server config) is small, human-auditable, trivially backed up with cp, and never introduces a separate failure domain. You can inspect or diff the live state with tools you already have. Note the SSH-native footprint of the install set, too—id_ed25519 and id_ed25519.pub ship alongside the binaries, since the server is doing real SSH tunneling.

⚠️ Change ebrasha1309 immediately after first login. Defaults are for first boot, not production.

The administrative workflow

Point a browser at http://localhost:52202 (or your configured port), authenticate, and you land on a dashboard summarizing users, sessions, and traffic. From there the work is organized around the lifecycle of a tunnel deployment rather than a flat settings dump.

User provisioning is full CRUD, but the interesting part is per-user policy. Each account carries far more than a username and password: a role (admin/user), blocked domains and IPs scoped to that user, concurrent session limits and TTL, a speed cap in KB/s, a traffic quota in MB, and individual logging preferences. This is enough to run differentiated tiers—a throttled trial account and an uncapped admin account—without touching the server binary.

Server configuration is edited from the same UI: listening ports (multiple are supported), the default shell for Windows/Linux targets, the maximum authentication attempts, and even the server's advertised version signature. The panel writes these to the server's config and the change takes effect on the managed service.

Security is handled at two layers. There is straightforward IP blocking, and there is an automatic brute-force defense with a configurable attempt ceiling, a sliding time window, and a block duration. Cross the threshold inside the window and the offending IP is blocked automatically for the configured period—no manual intervention.

Monitoring is where an operator spends real time. User access logs update over Ajax without a full page reload. Traffic monitoring tracks consumption per user—session-based and cumulative—and surfaces warnings as accounts approach their quota. The sessions view reflects live state from the server: session ID, username, source IP, client version, creation time, and last-seen timestamp, with the ability to revoke a session.

The whole console is bilingual (English and Persian), responsive down to a mobile hamburger menu, and—because configuration changes can require a clean reload—the panel auto-restarts its own service after you save, so applied settings are never half-live.

The Telegram bot: a study in isolation

The feature most worth dissecting is the optional Telegram bot, which mirrors every administrative action from the web UI. Enabling it is a config flow: create a bot via @BotFather, grab your numeric ID from @userinfobot, then in Panel Configuration → 🤖 Telegram Bot tick enable, paste the token, and list admin IDs. Settings persist under a telegram_bot key:

"telegram_bot": {
  "enabled": true,
  "token": "123456789:AA...your-bot-token",
  "admins": [111111111, 222222222]
}

The security model is deliberately blunt: the bot drops every update that does not originate from an admin Telegram ID and replies with a short "not authorized" message, so an attacker cannot silently probe behavior.

What makes the bot worth studying is its concurrency design. It is not a side thread bolted onto the request handler—it is a fully isolated subsystem inside the panel process, with its own HTTP connection pool, dispatcher worker pool, asynchronous log channel, and a debounced restart queue. The explicit goal: a busy panel UI or slow disk I/O can never slow the bot down. The update pipeline:

┌─────────────────────────┐      ┌──────────────────────┐
│ Telegram getUpdates     │ ───► │ updates channel      │
│ (1 goroutine)           │      │ (cap 1024)           │
└─────────────────────────┘      └──────────┬───────────┘
                                            │
                          ┌─────────────────┼─────────────────┐
                          ▼                 ▼                 ▼
                   ┌──────────┐      ┌──────────┐      ┌──────────┐
                   │ worker 1 │ ...  │ worker N │      │ worker N │ (NumCPU*2, ≥8)
                   └────┬─────┘      └────┬─────┘      └────┬─────┘
                        │                 │                 │
                        ▼ (go r(ctx,b,u)) ▼                 ▼
                   ┌────────────────────────────────────────────┐
                   │ Per-handler goroutine                       │
                   │  → trackerMiddleware (WaitGroup +1)         │
                   │  → adminOnly                                │
                   │  → recover                                  │
                   │  → handler (sendText via HTTP/2 conn pool)  │
                   └────────────────────────────────────────────┘
                        │
                        ▼ (svc.Info/Warning/Error)
                   ┌────────────────┐
                   │ async log chan │ ──► dedicated writer ──► panelLogger
                   │ (cap 1024)     │
                   └────────────────┘

A single goroutine long-polls getUpdates and pushes into a buffered channel (capacity 1024). A worker pool sized at NumCPU*2 (floor of 8) drains it. Each update spawns a per-handler goroutine wrapped in a middleware chain: a trackerMiddleware that increments a WaitGroup for clean shutdown, an adminOnly gate, a recover so one panicking handler never takes down the pool, and finally the handler itself sending replies through the shared HTTP/2 connection pool. Logging is fire-and-forget into another 1024-cap channel drained by a dedicated writer—so logging never blocks a handler. This is textbook Go: bounded channels for backpressure, a fixed worker pool to cap concurrency, recover per goroutine for fault isolation, and a WaitGroup for graceful drain.

The command surface is registered automatically via SetMyCommands, so everything shows up in Telegram's / menu. Highlights:

Command	Description
`/start`	Start the bot; first-time users pick a language (🇬🇧 / 🇮🇷).
`/menu`, `/help`, `/cancel`	Navigation and flow control.
`/users`, `/adduser`, `/adduser_interactive`	Paginated user list; quick or step-by-step user creation.
`/server`	View/edit server config field by field.
`/blockedips`, `/blockedaccess`	Manage blocked IPs and browse blocked-access logs.
`/logs`	Browse access logs (last 20 per user).
`/traffic`, `/sessions`	Per-user traffic; list and revoke sessions.
`/restart_server`, `/restart_panel`	Restart either service, with confirmation.

Build and deploy

From source you need Go 1.21+:

git clone https://github.com/ebrasha/abdal-4iproto-panel.git
cd abdal-4iproto-panel
go build -o abdal-4iproto-panel main.go      # Linux
go build -o abdal-4iproto-panel.exe main.go  # Windows

As a service, the binary self-registers. On Windows:

abdal-4iproto-panel.exe install
abdal-4iproto-panel.exe start

On Linux with systemd:

sudo ./install-abdal-4iproto-panel.sh
sudo systemctl enable abdal-4iproto-panel
sudo systemctl status abdal-4iproto-panel

For a hands-off setup, the Abdal 4iProto Cli detects your OS/architecture, verifies SHA-256 checksums, configures ports, generates SSH keys, and registers persistent services.

FAQ

Does the panel need a database? No. State is stored in flat JSON files, which keeps deployment to a single binary and makes backups a file copy.

Can I cap individual users? Yes—per-user speed limits (KB/s), traffic quotas (MB), session limits, and TTL are all configurable.

Is the Telegram bot safe to expose? It only accepts updates from explicitly listed admin IDs and rejects everything else. Treat the token like a secret and restrict admins tightly.

Windows and Linux both? Yes—single binary per platform, installable as a Windows Service or a Linux systemd unit.

Closing thought

The design philosophy behind Abdal 4iProto Panel is that operational tooling should reduce moving parts, not add them. One binary, embedded assets, JSON state, and a concurrency model that isolates the bot from the UI—each decision trades novelty for fewer 2 a.m. surprises.

Handcrafted with passion by Ebrahim Shafiei (EbraSha) — 📧 Prof.Shafiei@Gmail.com · ✈️ @ProfShafiei

Build a Self-Hosted SSH Tunneling Server with Per-User Accounting (Abdal 4iProto)

Ebrahim Shafiei — Tue, 09 Jun 2026 22:02:29 +0000

Build a Self-Hosted SSH Tunneling Server with Per-User Accounting

If you want a self-hosted SSH tunneling server that handles bandwidth limits, session control, and brute-force protection without you scripting any of it, this walkthrough is for you. We'll set up Abdal 4iProto Server — a Go-based tunnel by Ebrahim Shafiei (EbraSha) — from build to first connection, and I'll explain the config decisions along the way so you're not just copy-pasting blindly.

Heads up: this server is part of the broader Abdal 4iProto ecosystem (https://github.com/4iProto), so there are matching clients and tools once your server is up.

What you'll have at the end

A running tunnel server with per-user speed caps, total-traffic quotas, concurrent-session limits, automatic IP blocking on failed logins, and a SOCKS5 endpoint your apps can use. Let's go.

Step 1: Prerequisites

You need:

Go 1.25.10 or higher
An SSH private key (id_rsa)
A Linux or Windows host

Step 2: Generate your host key

ssh-keygen -t rsa -b 4096 -f id_rsa

Drop the resulting id_rsa in the project directory.

Step 3: Write the server config

Create server_config.json. On Linux:

{
  "ports": [64235, 64236, 64237],
  "shell": "/bin/bash",
  "max_auth_attempts": 3,
  "server_version": "SSH-2.0-Abdal-4iProto-Server"
}

On Windows, swap the shell:

{
  "ports": [64235, 64236, 64237],
  "shell": "cmd.exe",
  "max_auth_attempts": 3,
  "server_version": "SSH-2.0-Abdal-4iProto-Server"
}

The ports array makes the server listen on several ports at once. max_auth_attempts: 3 means three strikes and the IP is auto-blocked. server_version customizes the banner.

Step 4: Define your users

Create users.json. Here's an admin and a rate-limited user:

[
  {
    "username": "ebrasha",
    "password": "change-me",
    "role": "admin",
    "blocked_domains": [],
    "blocked_ips": [],
    "log": "no",
    "max_sessions": 1,
    "session_ttl_seconds": 300
  },
  {
    "username": "user1",
    "password": "change-me-too",
    "role": "user",
    "blocked_domains": ["facebook.com", "*.facebook.com"],
    "blocked_ips": ["10.0.0.*", "172.16.*.*"],
    "log": "yes",
    "max_sessions": 2,
    "session_ttl_seconds": 300
  }
]

Key fields to understand:

role: admin gets host shell access; user is tunnel-only. Keep day-to-day accounts as user.
blocked_domains / blocked_ips: support wildcards (*.facebook.com) and ranges (10.0.0.*).
log: per-user visited-site tracking — "yes" or "no".
max_sessions: concurrent session ceiling.
session_ttl_seconds: hard session lifetime before auto-reap.

To add bandwidth control, set max_speed_kbps (e.g. 1024 = 1 MB/s, enforced via token bucket on both directions) and max_total_mb (e.g. 10240 = 10 GB total quota). Quotas are checked every 1–2 seconds, and over-quota sessions are disconnected immediately — not just refused at next login.

Step 5: Build and run

go mod tidy
go build -o abdal-4iproto-server
./abdal-4iproto-server

That's it — the server is listening.

Step 6: Connect

The quickest test is a standard dynamic-forwarding SSH client:

ssh -D 1080 username@server_ip -p 22

Now point any app at the local SOCKS5 proxy and your traffic tunnels through. On Linux you can route everything with sshuttle:

sshuttle --dns -r ebrasha@SERVER_IP:2222 0.0.0.0/0 -vv

For a GUI experience, grab the official clients: Windows and Android.

Optional: relay traffic through another host with iptables NAT

If you need a relay in front of your server, enable forwarding and NAT:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p
iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to-destination IRAN_IP
iptables -t nat -A PREROUTING -j DNAT --to-destination 4iProto_IP
iptables -t nat -A POSTROUTING -j MASQUERADE

⚠️ Gotcha: the SSH-port DNAT rule must come before the general PREROUTING rule, and confirm you have alternate SSH access before applying these — it's an easy way to lock yourself out.

What's happening under the hood

A few implementation notes worth knowing as you operate this:

Rate limiting uses a token-bucket algorithm, which smooths throughput while allowing short bursts — friendlier to interactive sessions than a hard window.
Traffic accounting flushes to traffic_<username>.json every 10 seconds, so a crash costs at most a few seconds of stats.
Failed logins go to invalid_logins.log with the attempted credentials and IP; blocked IPs persist in blocked_ips.json.
TCP and UDP forwarding are both supported, plus DNSTT for DNS tunneling on hostile networks.

The full ecosystem

Component	Repository
🔐 Server	abdal-4iproto-server
⚙️ Web Panel	abdal-4iproto-panel
💻 Windows Client	abdal-4iproto-client
📱 Android Client	abdal-4iproto-client-android
🖱️ CLI Installer	abdal-4iproto-cli
🗝️ SSH KeyGen	abdal-4iproto-server-ssh-keygen

Tip: the CLI installer automates OS/arch detection, SHA-256 verification, port config, key generation, and service registration if you'd rather skip the manual build.

🔗 Source: https://github.com/ebrasha/abdal-4iproto-server

FAQ

Do I need the GUI clients? No — any SSH client with -D dynamic forwarding works. The clients just make it nicer.

How do I cap a user's speed? Add max_speed_kbps to their users.json entry (1024 = 1 MB/s).

What happens when a user hits their data quota? They're disconnected mid-session within 1–2 seconds and refused at next login until the quota resets.

Build a Device-Wide SSH Tunnel on Android with Abdal 4iProto Android

Ebrahim Shafiei — Tue, 09 Jun 2026 20:52:46 +0000

Build a Device-Wide SSH Tunnel on Android with Abdal 4iProto
If you've ever run ssh -D 1080 and pointed your browser at a local SOCKS5 proxy, you already understand half of what this app does. The other half is the interesting part: doing it for every app on your phone, with no root, and with leak protection that actually holds up. Let's walk through it hands-on.
Abdal 4iProto Android is the Android client of the open-source Abdal 4iProto ecosystem by Ebrahim Shafiei (EbraSha). It builds a device-wide SSH tunnel on Android, routing all traffic through an encrypted connection to your own server. No third-party VPN provider, no per-app juggling.
TL;DR of the data flow
Here's the path a packet takes, start to finish:

 App → VpnService (TUN, raw IP packets)
    → hev-socks5-tunnel (native tun2socks via JNI)
    → local SOCKS5 bridge
    → SSH direct-tcpip channel (JSch)
    → your Abdal 4iProto Server → Internet

The trick is that SSH forwards TCP streams, but the OS gives you raw IP packets. The native tun2socks engine bridges that gap by turning packets into SOCKS5 connections, which then get forwarded over SSH.
Step 1: Stand up a server
This is a client, so you need the other end. Grab the server component from the ecosystem repo and get it running first. You'll need its IP/hostname, port, and an SSH username/password.
Step 2: Install and add a server
Open the app, then:

Hamburger menu → Server Management → Add Server
Enter a friendly name, your server's IP/hostname, port, username, and password
Select the server on the main screen

You can store multiple named servers and switch between them — handy if you run more than one.
Step 3: Configure before connecting
A gotcha worth flagging up front: connection options are applied at connect time, so toggle them before you tap Connect.
The ones worth knowing:

Fake-IP / FakeDNS — resolves domains on the server (remote DNS) so no real DNS query leaves your device. Turn this on to close the DNS-leak gap. With it off, you still get tunneled DNS-over-TCP.
Kill Switch — blocks all traffic if the tunnel drops unexpectedly, with no leak gap, until it reconnects or you disconnect.
Advanced Settings → Whitelist IPs / CIDR — comma-separated IPs or CIDR blocks that should bypass the tunnel.

Step 4: Per-app split tunneling (optional)
Open the Per-App Split Tun screen and pick a mode:

Route via Tunnel → only the apps you select are tunneled.
Bypass Tunnel → everything is tunneled except the apps you select.

The list is searchable and each app gets its own toggle. Apps kept off the tunnel are also exempt from the kill switch, so they keep normal connectivity.
Step 5: Connect
Tap Connect and grant the VPN permission when Android prompts. That permission is what lets the app stand up its VpnService TUN interface. Once it's up, your whole device is tunneled. Watch the real-time logs from the menu to confirm what's happening.
Tap Disconnect to tear it down.
Why it doesn't leak
Two implementation details do the heavy lifting here, and they're worth understanding if you build networking apps yourself:

The control socket is protected. The SSH connection itself is wrapped in VpnService.protect() so it doesn't get routed back into the TUN interface. Skip this and you get a routing loop that kills reconnects.
Local ranges bypass automatically. Private/LAN ranges (192.168.x.x, 10.x.x.x) skip the tunnel, so your router, printer, and any phone-hosted services keep working. On API 33+ this uses excludeRoute().

The stack, quickly

minSdk 24 (Android 7.0)  ·  compileSdk/targetSdk 36 (Android 16)
applicationId net.abdal.abdal4iproto.client  ·  versionName 5.2

Kotlin 2.2.10 · AGP 9.1.1 · Gradle 9.3.1 · KSP 2.3.5 · Java 11
UI: Jetpack Compose (Material 3), Navigation Compose 2.8.9
SSH: JSch (mwiede fork) 0.2.21
Crypto: Bouncy Castle bcprov-jdk18on 1.84  → ssh-ed25519 host keys
Coroutines: kotlinx-coroutines 1.10.2
Persistence: Room 2.7.0 (KSP)
Native: hev-socks5-tunnel (.so) tun2socks via JNI (TProxyService)

The native tun2socks engine is the deliberate performance call — packet translation stays in compiled native code instead of crossing the JNI boundary per packet in managed Kotlin.
Wrapping up
The whole design comes down to one principle: capture everything, leak nothing, and keep the trust boundary at your server. No telemetry, open source, auditable via live logs. If you've been meaning to graduate from per-app proxies to a real device-wide tunnel you actually control, this is a clean way to do it.
FAQ
Do I need root? No — it uses VpnService.
Why does my home network still work while connected? Private/LAN ranges bypass the tunnel by design.
What's the minimum Android version? API 24. Some routing features need API 33+.
Can I tunnel only specific apps? Yes — use the Per-App Split Tun screen's "Route via Tunnel" mode.

https://github.com/ebrasha/abdal-4iproto-client-android

🤵 Programmer

Handcrafted with Passion by Ebrahim Shafiei (EbraSha)

DEV Community: Ebrahim Shafiei

Wireshark Alternative Android

Wireshark Alternative Android

What you will build as a workflow

Before you start

Step 1: Understand what is being captured

Step 2: Select the application with App Split

Step 3: Start a short capture

Step 4: Filter the packet table

Find DNS traffic

Find traffic involving a specific IP address

Find HTTPS-related flows

Combine conditions

Step 5: Use app attribution

Step 6: Save the capture

Step 7: Open the capture in Wireshark

Step 8: Read statistics.json as test context

What this workflow can reveal

What this workflow cannot do

A debugging checklist

Conclusion

FAQ

Does Abdal PacketView require root?

Is it a full Wireshark port for Android?

Can I capture only one Android application?

What files are exported?

Project Links

Developer

Android Packet Capture Without Root Using Abdal PacketView

Android Packet Capture Without Root Using Abdal PacketView

Project Author, Source Code and Download

What Abdal PacketView Does

How the Capture Works

Why This Is Useful

Step 1: Start a Capture

Step 2: Inspect Packets

Step 3: Use Filters

Step 4: Use App Split Tunnel

Step 5: Export for Wireshark

What Makes It Different

Final Thoughts

Project Author, Source Code and Download

FAQ

Does Abdal PacketView require root?

Can I use the exported file in Wireshark?

Can it show which app generated a packet?

Is this only for security researchers?

Is it a full Wireshark replacement?

One Binary to Manage an SSH Tunnel Server: Abdal 4iProto Panel

Why a single binary matters for tunnel administration

The architecture in one sentence

The administrative workflow

The Telegram bot: a study in isolation

Build and deploy

FAQ

Closing thought

Build a Self-Hosted SSH Tunneling Server with Per-User Accounting (Abdal 4iProto)

Build a Self-Hosted SSH Tunneling Server with Per-User Accounting

What you'll have at the end

Step 1: Prerequisites

Step 2: Generate your host key

Step 3: Write the server config

Step 4: Define your users

Step 5: Build and run

Step 6: Connect

Optional: relay traffic through another host with iptables NAT

What's happening under the hood

The full ecosystem

FAQ

Build a Device-Wide SSH Tunnel on Android with Abdal 4iProto Android

Step 8: Read `statistics.json` as test context