Omegle P2P Location Finder

Abstract

A Python network-analysis project that observes UDP peer-to-peer traffic through TShark, extracts remote IP addresses, and resolves approximate geographic locations via a local GeoIP2/GeoLite2 database. The one thing worth reporting on: it demonstrates, in a controlled setting, how much network metadata direct peer communication leaks even when the application UI shows nothing.

1. What This Is

An educational privacy-awareness project, not a people-finding tool. It wires TShark packet output into a Python process, pulls candidate remote IPs from UDP peer traffic, and looks them up against a local GeoLite2 City database. The goal is to make visible the network identifiers that direct peer-to-peer video sessions expose.

2. How It Works

The pipeline is linear: capture, parse, filter, look up, display. TShark runs as a subprocess; Python reads its stdout, extracts and normalises the remote address, then queries the local GeoIP2 database.

3. Implementation Notes

3.1 TShark subprocess integration

TShark is launched as a child process; Python reads its output line by line and extracts remote IP fields. Traffic that does not match the expected UDP peer pattern is discarded, keeping the pipeline focused.

3.2 Local GeoIP2 lookup

The GeoLite2 City database runs entirely on the local machine. No IP address is sent to a third-party geolocation API, which keeps the lookup reproducible and avoids an extra network dependency.

3.3 Privacy framing

The project is scoped to controlled, authorised test sessions. The output is explicitly approximate — GeoIP resolution gives a city-level estimate, not a physical address.

4. Constraints

• Approximate location only

  GeoIP2 resolves to a city or region. Treating the result as a precise physical location would be a misuse of the data.

• TShark dependency

  The project requires TShark installed with sufficient capture permissions. On restricted or containerised environments the subprocess may fail silently.

• No auth or session guard

  There is no built-in check that the operator is authorised to capture the traffic. The controlled-session assumption is entirely on the user.

• Single-address resolution

  Each peer IP is looked up in isolation. There is no correlation, aggregation, or temporal tracking across a multi-peer session.

5. Next

1. a. Add a session-scoped capture window and rate-limit so the script cannot log unbounded packet data.
2. b. Correlate multiple peer addresses within a single session to show how many distinct network identifiers one video call can expose.
3. c. Wrap the output in a minimal local web page so the privacy-awareness demo can be shared without exposing raw packet logs.