techchipnet/ip-changer

This repository is a small Linux automation tool, not a multi-tier application. Its architecture is centered on a shell-script runtime plus a systemd service that repeatedly forces outbound traffic through Tor to rotate the apparent IP address.

1. Core purpose

The system automates IP rotation at a user-defined interval. The main runtime behavior is: start Tor, periodically request a new Tor circuit/identity, and verify the resulting public IP change.

2. Main artifacts in the repo

• change_tor_ip.sh: the core long-running script that performs the IP-change loop.

• change-tor-ip.service: the systemd unit that keeps the script running in the background.

• setup.sh: installation/setup path for deploying the service.

• ip-changer.sh: an alternate “run without installation” entry point, used directly from the repo.

3. Execution model

The project is shell-script driven and runs on Linux with sudo privileges. There is no compiled binary, daemon framework, database, or web frontend. The service boundary is systemd, which manages lifecycle, autostart, and background execution.

4. Runtime flow

User selects an interval during setup. The setup path installs/places the script, configures the service, and enables it. At runtime, systemd starts change_tor_ip.sh, which then loops on the configured interval and triggers IP rotation through Tor.

5. Interaction with Tor

Tor is the key external subsystem. The scripts depend on the local Tor service and on Tor’s ability to establish new circuits/identities. The repo’s architecture assumes Tor is installed and available on the host machine rather than embedded in the application.

6. IP verification path

The README lists curl, xxd, and fq as prerequisites, so the scripts likely use command-line HTTP requests and text processing to check the current public IP and to detect when a new exit node has taken effect. That makes the external IP-check service part of the data flow.

7. Service management boundary

change-tor-ip.service is the operational control point. It determines how the script is started, whether it restarts, and how it behaves under systemd. The README’s instructions for status/start/stop/disable imply the service is the intended long-lived deployment mode.

8. Installation vs. direct run

There are two supported paths: a direct execution path via ip-changer.sh, and a persistent deployment path via setup.sh plus systemd. Both paths appear to converge on the same core logic in change_tor_ip.sh, but they differ in lifecycle management.

9. Configuration boundary

The only user-facing configuration explicitly mentioned is the interval for IP changes. That setting is likely baked into the service definition or written by the setup script into the runtime script/service unit. This is the main configurable input to the system.

10. Operational dependencies

The architecture depends on Linux distribution packaging and init/service management, but not on any cloud service or backend. The supported distros listed in the README indicate the scripts are designed to be portable across common systemd-based Linux environments.

11. Security and network considerations

The tool routes traffic through Tor for anonymity, but the README notes that exit nodes can be blocked and performance can be slower. This means network reliability and website filtering are external constraints on the architecture, not internal failures.

12. High-level diagram view

A good architecture diagram would show: user → setup script or direct launcher → systemd service → core IP-rotation shell script → local Tor service → external IP-check endpoint. The system’s main state is the running service and the timing interval; its only external dependencies are Tor and command-line utilities.