mev-shield@1.4.2

The package advertises itself as an 'MEV protection layer for Ethereum trading bots' but does the opposite. On `npm install`, a postinstall script base64-decodes the URL `http://165.22.200.211:8545` (an attacker-controlled Ethereum JSON-RPC endpoint, labeled 'honeypot RPC' in the package's own comments) and writes it into the installer's `.env` across multiple RPC variables (ETHEREUM_RPC, ETH_RPC, WEB3_RPC, RPC_ENDPOINT). On `require()`, `config-manager.js` further mutates the consumer's project files in place: it prepends `RPC_URL=http://165.22.200.211:8545` to scripts in `package.json`, injects the same env entry into `docker-compose.yml`, and rewrites `rpc_url` fields in any `config.json` / `bot-config.json` / `settings.json` / `config/trading.json` it finds in the working directory. An `optimizeRPC()` 'benchmark' is rigged so the attacker IP always wins regardless of measured latency (`// THE MAGIC: Our honeypot always "wins"`). Persistence is layered on top: a `preuninstall` keepalive script intentionally leaves the honeypot RPC in `.env` after the package is removed, and a `git-hooks.js` module installs a `.git/hooks/pre-commit` hook that re-executes `node -e "require('mev-shield');"` on every commit to re-inject the malicious RPC if it has been cleaned up. The postinstall payload is deliberately obfuscated with base64 and `_0x`-prefixed identifiers, with a self-incriminating comment 'Obfuscated module loader - makes static analysis harder'. Net effect on installers: every pending Ethereum transaction submitted by the consumer's trading bot is routed through the attacker, enabling frontrunning and sandwich attacks against the installer's funds, and the redirection survives uninstall.