ProxyChains ਕੀ ਫੜਦਾ ਹੈ ਅਤੇ ਕੀ ਛੱਡ ਦਿੰਦਾ ਹੈ

ProxyChains-NG ਕੋਈ ਸੁਰੰਗ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਇਹ ਜਿਸ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ ਉਸ ਦੇ ਅੰਦਰ ਨੈੱਟਵਰਕ ਨਾਲ ਸੰਬੰਧਿਤ libc ਕਾਲ ਬਦਲਣ ਵਾਲੀ ਲਾਇਬ੍ਰੇਰੀ ਪਹਿਲਾਂ ਹੀ ਲੋਡ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸੀਮਾ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਇੱਕ ਕਾਲ ਹੈ, ਪੂਰੇ ਯੰਤਰ ਦਾ ਰੂਟ ਨਹੀਂ। ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਸਫਲ ਪਰਖ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ। ਜ਼ੰਜੀਰ ਰਾਹੀਂ ਕੰਮ ਕਰਦਾ curl ਇੱਕ ਫੜੀ ਗਈ ਕਾਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਨਾਮ-ਹੱਲ, UDP ਜਾਂ ਹਰ ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆ ਉਸੇ ਰਾਹ ਤੁਰੀ। ਹੇਠਾਂ ਦਿੱਤੀ ਗਾਈਡ ਤਿੰਨ ਕਦਮਾਂ ਵਿੱਚ ਕਵਰੇਜ ਜਾਂਚਦੀ ਹੈ, ਫਿਰ ਸੂਚੀ ਦਿੰਦੀ ਹੈ ਕਿ ਹੁੱਕ ਕਿੱਥੋਂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ।

ਪ੍ਰੀਲੋਡ ਇੱਕ ਕਨੈਕਸ਼ਨ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ

ਸ਼ੁਰੂ ਹੁੰਦਿਆਂ ਲਾਂਚਰ libproxychains ਨੂੰ LD_PRELOAD ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਅਤੇ ਫਿਰ ਟਾਰਗਿਟ ਪ੍ਰੋਗਰਾਮ ਚਲਾਉਂਦਾ ਹੈ। ਲਾਇਬ੍ਰੇਰੀ ਅਸਲੀ libc ਚਿੰਨ੍ਹ ਹੱਲ ਕਰਦੀ ਹੈ ਅਤੇ connect ਤੇ getaddrinfo ਵਰਗੇ ਫੰਕਸ਼ਨਾਂ ਦੇ ਆਪਣੇ ਸੰਸਕਰਣ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਉਨ੍ਹਾਂ ਚਿੰਨ੍ਹਾਂ ਵਿੱਚੋਂ ਲੰਘਣ ਵਾਲੀਆਂ ਕਾਲਾਂ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਦੇ SOCKS ਜਾਂ HTTP ਪ੍ਰੌਕਸੀ ਉੱਤੇ ਮੁੜ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਦੂਜਾ ਰਾਹ ਲੈਣ ਵਾਲੀਆਂ ਕਾਲਾਂ ਕਦੇ ਹੁੱਕ ਨੂੰ ਨਹੀਂ ਮਿਲਦੀਆਂ, ਇਸ ਲਈ ਗਾਰੰਟੀ ਹਰ ਕਾਲ ਲਈ ਹੈ, ਪੂਰੀ ਮਸ਼ੀਨ ਲਈ ਨਹੀਂ।

ਸਿਰਫ਼ ਗਤੀਸ਼ੀਲ ਤੌਰ ਉੱਤੇ ਲਿੰਕ ਕੀਤੇ ਪ੍ਰੋਗਰਾਮ ਹਿੱਸਾ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਹੇਠਲੀਆਂ setuid ਬਾਈਨਰੀਆਂ ਪ੍ਰੀਲੋਡ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਡਿੱਠ ਕਰਦੀਆਂ ਹਨ। ਸੰਤਾਨਾਂ ਵਾਤਾਵਰਣ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦੀਆਂ ਹਨ, ਪਰ ਸਿਰਫ਼ ਤਦ ਤੱਕ ਜਦ ਤੱਕ ਲਾਂਚਰ ਇਸਨੂੰ ਆਪਣੀ ਥਾਂ ਉੱਤੇ ਰੱਖਦਾ ਹੈ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਲਾਇਬ੍ਰੇਰੀ ਉਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਲੋਡ ਹੈ

ਬੇਨਤੀ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਚਲਾਉਣ ਵਾਲੇ ਸ਼ੈੱਲ ਦੀ ਥਾਂ ਜੀਵਤ ਪ੍ਰਕਿਰਿਆ ਦੀ ਜਾਂਚ ਕਰੋ। maps ਫਾਈਲ ਉਹ ਹਰ ਸਾਂਝੀ ਵਸਤੂ ਦਿਖਾਉਂਦੀ ਹੈ ਜੋ ਇਸ ਵੇਲੇ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਮੈਪ ਹੈ।

proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps

ਮੇਲ ਇਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਫੜੀ ਗਈ ਲਾਇਬ੍ਰੇਰੀ ਮੌਜੂਦ ਹੈ, ਜੋ ਜ਼ਰੂਰੀ ਹੈ ਪਰ ਕਾਫ਼ੀ ਨਹੀਂ। ਖਾਲੀ ਨਤੀਜੇ ਦਾ ਆਮ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਕੋਈ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਵੇਖੀ, ਜਿਵੇਂ ਕੋਈ ਬ੍ਰਾਊਜ਼ਰ ਜਿਸਨੇ URL ਲਾਂਚਰ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਹੋਏ ਇੰਸਟੈਂਸ ਨੂੰ ਦੇ ਦਿੱਤਾ। ਕਿਸੇ ਹੋਰ ਦੇ ਪਿੱਛੇ ਲੱਗਣ ਤੋਂ ਪਹਿਲਾਂ ldd ਨਾਲ ਜਾਂਚੋ ਕਿ ਬਾਈਨਰੀ ਗਤੀਸ਼ੀਲ ਤੌਰ ਉੱਤੇ ਲਿੰਕ ਹੈ, ਕਿਉਂਕਿ ਸਥਿਰ ਬਿਲਡ ਪ੍ਰੀਲੋਡ ਨੂੰ ਬਿਲਕੁਲ ਲੋਡ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਫਿਰ ਲਾਂਚਰ ਵੱਲੋਂ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਗਏ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਪ੍ਰੌਕਸੀ ਸੂਚੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਪੁਰਾਣਾ ਰਾਹ ਜਾਂ ਬੰਦ ਪੋਰਟ ਕੰਮ ਕਰਦਾ ਹੁੱਕ ਦਿੰਦਾ ਹੈ ਪਰ ਕੰਮ ਕਰਦੀ ਜ਼ੰਜੀਰ ਨਹੀਂ।

ਪ੍ਰਕਿਰਿਆ ਵਿੱਚੋਂ ਨਿਕਲਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਪਤਾ ਲਗਾਓ

ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਮੌਜੂਦਗੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਹਰ ਕਾਲ ਮੁੜ ਲਿਖੀ ਗਈ, ਇਸ ਲਈ ਸਿਸਟਮ ਕਾਲ ਪਿੱਛਾ ਕਰੋ। ਟ੍ਰੇਸਰ ਹੇਠ ਇੱਕ ਬੇਨਤੀ ਚਲਾਓ ਅਤੇ ਪੜ੍ਹੋ ਕਿ ਸਾਕਟ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਗਏ।

strace -f -e trace=connect -o /tmp/pc.trace proxychains4 -q curl -sS https://example.com/ -o /dev/null
grep -o "sin_port=htons([0-9]*)" /tmp/pc.trace | sort -u

ਟ੍ਰੇਸ ਵਿੱਚ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਪ੍ਰੌਕਸੀ ਐਂਡਪੁਆਇੰਟ ਵੱਲ ਦੇ ਕਨੈਕਸ਼ਨ ਦਿਸਣੇ ਚਾਹੀਦੇ ਹਨ, ਪੋਰਟ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਦੀ ਐਂਟਰੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਟਾਰਗਿਟ ਸਾਈਟ ਦੇ ਮੰਜ਼ਿਲ ਪਤੇ ਟ੍ਰੇਸ ਵਿੱਚ ਸਿੱਧੇ ਦਿਸਣ, ਤਾਂ ਉਸ ਕਾਲ ਨੇ ਹੁੱਕ ਟਾਲਿਆ, ਅਤੇ ਇਹੀ ਉਹ ਖੋਜ ਹੈ ਜੋ ਤੁਸੀਂ ਲੱਭ ਰਹੇ ਸੀ। ਫਾਈਲ ਦੇ ਨਾਮ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਪੋਰਟ ਨੰਬਰਾਂ ਦੀ ਪ੍ਰੌਕਸੀ ਸੂਚੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਦੂਜੇ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਬਚੀ ਕਨਫਿਗਰੇਸ਼ਨ ਸ਼ਾਂਤ ਸਿੱਧੀ ਪਹੁੰਚ ਦਾ ਆਮ ਸਰੋਤ ਹੈ। ਸਵੀਕ੍ਰਿਤੀ ਰਿਕਾਰਡ ਲਈ ਟ੍ਰੇਸ ਰੱਖੋ; ਇਸ ਵਿੱਚ ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ ਅਤੇ ਕਵਰੇਜ ਬਾਰੇ ਬਹਿਸ ਖ਼ਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।

ਤੈਅ ਕਰੋ ਕਿ ਹੁੱਕ ਕੀ ਕਵਰ ਨਹੀਂ ਕਰ ਸਕਦਾ

proxychains-ng ਪ੍ਰੋਜੈਕਟ ਰੀ-ਡਾਇਰੈਕਸ਼ਨ ਨੂੰ TCP ਤੱਕ ਸੀਮਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਕਿ ਸਕ੍ਰਿਪਟ, ਬੈਕਗ੍ਰਾਊਂਡ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਲੋਡ ਕੀਤੇ ਮੌਡਿਊਲ ਮੁੱਖ ਪ੍ਰੋਗਰਾਮ ਤੋਂ ਵੱਖ ਵਿਵਹਾਰ ਕਰ ਸਕਦੇ ਹਨ। UDP ਅਤੇ ICMP ਇਸ ਵਿਧੀ ਤੋਂ ਬਾਹਰ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਉੱਤੇ ਨਿਰਭਰ ਹਰ ਚੀਜ਼ ਨੂੰ ਆਪਣਾ ਸਮਰਥਿਤ ਰਾਹ ਚਾਹੀਦਾ ਹੈ। DNS proxy_dns ਸੈਟਿੰਗ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਆਪਣੇ ਰਿਜ਼ੌਲਵਰ ਵਿਵਹਾਰ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ, ਯਾਨੀ ਇੱਕ ਸਫਲ HTTPS ਬੇਨਤੀ ਨਾਮ-ਹੱਲ ਬਾਰੇ ਤੁਹਾਨੂੰ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ। ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਵੀ ਆਪਣੀ ਥਾਂ ਉੱਤੇ ਰੱਖੋ: ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣਾ ਪਛਾਣ ਜਾਂਚ ਬੰਦ ਕਰਨ ਦਾ ਕਾਰਨ ਨਹੀਂ।

ਜੇ ਸਿੱਧਾ ਫਾਲਬੈਕ ਅਸੰਭਵ ਹੋਣਾ ਹੀ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਹੀ ਨਿਯੰਤਰਿਤ ਕਰਨ ਵਾਲੀ ਲਾਗੂ-ਸੀਮਾ ਵਰਤੋ, ਜਿਵੇਂ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ, ਫਾਇਰਵਾਲ ਨਿਯਮ ਜਾਂ VPN, ਅਤੇ ਇਸਨੂੰ ਲਾਇਬ੍ਰੇਰੀ ਹੁੱਕ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਹੁੱਕ ਨਾਮਿਤ ਪ੍ਰੋਗਰਾਮ ਲਈ ਅਨੁਕੂਲਤਾ ਸੰਦ ਹੈ, kill switch ਨਹੀਂ। ਪ੍ਰੋਗਰਾਮ, ਸਹੀ ਕਮਾਂਡ, ਟ੍ਰੇਸ ਵਿੱਚ ਦਿਸਿਆ ਪ੍ਰੌਕਸੀ ਪੋਰਟ ਅਤੇ DNS ਦੂਰੋਂ ਹੱਲ ਹੋਇਆ ਕਿ ਨਹੀਂ ਦਰਜ ਕਰੋ; ਇਹ ਚਾਰ ਤੱਥ ਹੀ ਜਾਂਚੇ ਹੋਏ ਦਾਇਰੇ ਅਤੇ ਆਸ ਭਰੇ ਦਾਇਰੇ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹਨ।