mandatoryprogrammer/thermopticبروكسي HTTP خفي من الجيل التالي يخفي الطلبات بشكل مثالي بحيث تبدو وكأنها صادرة من متصفح Chrome عبر جميع طبقات المكدس التقني.
"لا أصدق ذلك، التمويه الحراري!"
هذا وكيل HTTP مصمم لتجاوز الخدمات التي تستخدم البصمات مثل JA4+ لحظر عملاء HTTP معيّنين. باستخدام هذا الوكيل، يمكنك استخدام عملاء HTTP المفضلين لديك مثل curl وتبقى بصماتك غير قابلة للتمييز بشكل سحري عن بصمات متصفح ويب حقيقي (Chrome/Chromium). كما يأتي thermoptic مع بعض الميزات الممتعة للتخفيف من البصمات المعتمدة على JavaScript. كما أنه يسهّل إجراء الكشط الهجين باستخدام متصفح ويب وعملاء HTTP منخفضي المستوى معًا.
حتى لو لم تكن على دراية ببصمات JA4+، فإذا كنت قد قمت بأي كشط من قبل، فمن المحتمل أنك تعرّضت للحظر بسببها. تستخدم خدمات شهيرة مثل Cloudflare هذه التقنيات (وخدع أخرى) لكشف استخدام عملاء HTTP «غير بشريين» لحظر الطلبات. يمكن لهذه الخدمات أيضًا استخدام هذه البصمات لكشف ما إذا كنت تبدأ جلسة بمتصفح حقيقي ثم تنتقل لاحقًا إلى عميل منخفض المستوى مثل curl. يحل thermoptic كل هذه المشكلات بتقديم بصمة متصفح «حقيقية» موحدة لجميع طلبات الكشط.
فيما يلي مثال على بصمة JA4H (HTTP) لـ curl بدون الوكيل:```
$ curl https://ja4db.com/id/ja4h/
ge11nn090000_b6a016211e8a_000000000000_e3b0c44298fc
هذا مختلف تمامًا عن البصمة التي يُنتجها Chrome عند زيارتك للرابط مباشرة:```
ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e
ومع ذلك، عندما نستخدم البروكسي لإجراء الطلب، نجد أن بصمة JA4H الخاصة بنا متطابقة بشكل سحري:``` $ curl --proxy http://thermoptic:1234 https://ja4db.com/id/ja4h/ ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e
(وينطبق الأمر نفسه على بصمة JA4 TLS الخاصة بنا أيضًا، وما إلى ذلك).
## الإعداد
لبدء بروكسي `thermoptic` الذي يُموّه حركة المرور الخاصة بك عبر مثيل Chrome معزول في حاوية على Ubuntu 22.04:
إعداد Docker العادي (يعمل على المضيفات التي لا تحتوي على بيئة تشغيل GPU):```
docker compose up --build
هذا كل شيء، الآن يمكنك تمرير حركة المرور عبره:``` curl --proxy http://127.0.0.1:1234 --insecure https://ja4db.com/id/ja4h/
Important notes:
* بشكل افتراضي يعمل الوكيل بدون مصادقة. إذا كنت تخطط لكشف الوكيل خارجيًا، فتأكد من ضبط المصادقة باستخدام متغيرات البيئة `PROXY_USERNAME` و`PROXY_PASSWORD`.
* إذا كنت لا تريد استخدام `---insecure`، فستحتاج إلى استخدام ملف CA المُنشأ الموجود في `./ssl/rootCA.crt`. يتم إنشاؤه في أول مرة تشغّل فيها `thermoptic`.
* يمكنك توصيل `thermoptic` بأي نسخة Chrome/Chromium تعمل مع علامة `--remote-debugging-port`. هذا ضروري لأنك سترغب في الإعداد والوكيل عبر بيئات أكثر شيوعًا للحفاظ على بصمتك منخفضة الظهور قدر الإمكان (مثل Chrome على Windows).
* تجاوز تكوين GPU مخصص للمضيفين الذين يعملون بـ NVIDIA ولديهم بالفعل NVIDIA runtime/toolkit الخاص بـ Docker. يحجز جهاز GPU، ويُثبّت `/dev/dri`، ويتيح لحاوية Chrome المرفوعة التبديل إلى مسار عرض NVIDIA/Vulkan. لاستخدام هذا، شغّل: `docker compose -f docker-compose.yml -f docker-compose.gpu.yml up --build`.
## الميزات
- 🕵️ [وكيل بمطابقة المتصفح](#how-does-this-cloaking-work-exactly) يعيد تشغيل الطلبات عبر جلسة Chrome حقيقية لمطابقة بصمات JA4 بايت ببايت.
- 🤝 لا يتطلب سوى القليل من التعليمات البرمجية المخصصة أو لا يتطلب أيًا منها لدمج عميل HTTP الخاص بك (مثل `curl` أو `requests` وغيرها) مع `thermoptic`، فقط [اضبط الوكيل](#setup) وسيتم التعامل مع بصماتك.
- 🪝 [إطار خطافات](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks) لأتمتة قبل الطلب/بعد الطلب/عند البدء، بحيث يمكنك تشغيل المتصفح بالكامل لحل التحديات أو التقاط العناصر الناتجة.
- 📘 يمكن رؤية مثال لخطاف حل Cloudflare turnstile في [`./hooks/onstart.js`](https://github.com/mandatoryprogrammer/thermoptic/blob/main/hooks/onstart.js).
- 🖥️ [واجهة تحكم المتصفح عبر الويب](#control-the-dockerized-chrome-browser-via-web-ui-xpra) (على `http://127.0.0.1:14111`) للتحكم في نافذة متصفح Chrome داخل Docker. مفيد لتسجيل الدخول يدويًا إلى المواقع ثم استخدام الوكيل بسلاسة لإرسال الطلبات بجلسة تسجيل الدخول الخاصة بك (وللتصحيح).
- 🔌 عيّن URI وكيل HTTP أو SOCKS خارجي عبر متغير البيئة `UPSTREAM_PROXY` في `docker-compose.yml`.
- 🛡️ فحوصات صحة مدمجة وحلقة تحكم في إعادة التشغيل لاكتشاف المتصفحات المتجمدة واستعادتها تلقائيًا دون مراقبة المشغّل المستمرة.
- ⚡ يدعم HTTP/1.1 وHTTP/2، مما يسمح بتمرير الحركة عبر أي من البروتوكولين. (_لاحظ أنه يمكنك التحدث بـ HTTP/1.1 إلى الوكيل، وقد يتفاوض Chrome المُوجَّه مع الموقع الهدف عبر بروتوكول مختلف._)
## كيف يعمل هذا التمويه بالضبط؟
* يتم إرسال طلب HTTP باستخدام عميل HTTP مثل `curl` مع تعيين `thermoptic` كوكيل.
* يحلل `thermoptic` الطلب لتحديد نوع طلب المتصفح الذي *من المفترض* أن يكون عليه بأفضل شكل (مثل: زيارة URL يدويًا؟ إرسال نموذج؟ طلب `fetch()`؟).
* يستخدم `thermoptic` [بروتوكول تصحيح أخطاء Chrome (CDP)](https://chromedevtools.github.io/devtools-protocol/) لتوجيه المتصفح وإعداد صفحة تحاكي الطلب تمامًا كما يحدث عادةً في متصفح ويب حقيقي.
* يطلق `thermoptic` الطلب عبر السياق المُحاكى ويلتقط استجابة HTTP.
* يرسل `thermoptic` استجابة HTTP مرة أخرى إلى العميل.
نظرًا لأن المتصفح يقوم فعليًا بإرسال الطلب باستخدام مجموعته الكاملة، فإن بصمات JA4 الناتجة تكون مطابقة تمامًا.
ملاحظة: نظرًا لأن许多 أنظمة WAF تستخدم بصمة JavaScript على مستوى المتصفحات، فإن `thermoptic` يكشف أيضًا عن خطافات لاستخدام المتصفح في الخطوات الأساسية لعملية الكشط. راجع [هذا القسم](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks) لمزيد من المعلومات حول ذلك.
## لماذا *هذا* النهج بدلاً من الحلول الأخرى؟
بصراحة: النهج الأخرى بها عيوب أساسية تمنعها من أن تكون حلاً عمليًا طويل الأمد لمشكلة بصمة المتصفح.
تحاول العديد من المحاولات الأخرى "للتغلب" على بصمة JA4+ للمتصفح عبر إعادة تنفيذ الطبقات المختلفة لحزمة المتصفح. هذا النهج له عدد من العيوب الخطيرة، مثل:
* يتطلب عناية كبيرة لمطابقة سلوك تنفيذ المتصفح "الحقيقي" بشكل مثالي. ونتيجة لذلك، يمكن استخدام *أي* سلوكيات غريبة أو اختلافات لتمييز هذه العملاء عن تنفيذ المتصفح "الحقيقي".
* محاولة حل المشكلة في طبقة واحدة فقط من الحزمة. يستخدم Chrome بروتوكولات متعددة لتوفير تجربة تصفح الويب. ونتيجة لذلك، حتى إذا أنشأت طبقة TLS مطابقة تمامًا، فقد تكشفك طبقة HTTP إذا لم تكن مطابقة بايت ببايت.
* نظرًا لأن المتصفحات "الحقيقية" تغير سلوكها بانتظام، تتغير بصماتها، ونتيجة لذلك تتطلب هذه الأدوات باستمرار عمل تطوير أكثر كثافة للتعويض.
على النقيض، لأن `thermoptic` يستخدم المتصفح نفسه لتنفيذ طلبات HTTP:
* كل طبقة من الحزمة مثل TCP وTLS وHTTP لا يمكن تمييزها عن المتصفح الحقيقي لأن الطلب يتم *باستخدام* متصفح حقيقي بالطريقة التي *يحدث* بها *عادةً*.
* التغييرات في سلوك المتصفح على الطبقات المختلفة تكون أقل إزعاجًا؛ فقط يجب تحديث المتصفح الذي يتحكم فيه `thermoptic` لمطابقة أحدث مجموعة بصمات.
بالطبع، لا يوجد حل بدون عيوب. راجع وثائق `DOWNSIDES.md` للحصول على قائمة مفصلة بسلبيات نهج `thermoptic`.
## الأسئلة الشائعة
### لماذا الاسم `thermoptic`؟
"Thermoptic" (اختصار "thermoptic camouflage") هو إشارة إلى التمويه الخيالي [الذي استخدمته الرائد في أنمي Ghost in the Shell (1995)](https://ghostintheshell.fandom.com/wiki/Thermoptic_camouflage). في الفيلم، يُظهر هذا التمويه قدرته على إخفاء مرتديه عبر أطياف متعددة من الاكتشاف بما في ذلك الضوء المرئي والإشعاع الحراري. وبالمثل، تحاول هذه الأداة إخفاء المستخدم عن البصمة عبر قنوات متعددة (HTTP وTLS وغيرها).
### JA4+ هي **مجموعة** بصمات! أي منها يزيّف؟
ستزيّف هذه الأداة بصمات JA4 التالية لتكون مطابقة تمامًا لمتصفح Chrome/Chromium المتصل به:
* JA4 (بصمة TLS)
* JA4H (بصمة HTTP)
* JA4X (بصمة شهادة TLS X509)
* JA4T (بصمة TCP)
### ماذا لو أردت استخدام وكيل HTTP/SOCKS خارجي آخر مع هذه الأداة؟
يقوم `thermoptic` الآن بتوجيه نسخة Chrome المتحكم بها عبر خدمة `proxyrouter` داخلية، بحيث يمكنك توجيه Chrome إلى وكلاء HTTP أو SOCKS خارجيين (بما في ذلك تلك التي تتطلب بيانات اعتماد). عيّن URI الوكيل الخارجي عن طريق تعديل قيمة `UPSTREAM_PROXY` في `docker-compose.yml` ضمن خدمة `proxyrouter`. عندما تتركه فارغًا، يتحدث Chrome مباشرة إلى الإنترنت عبر الوكيل الداخلي غير الموثق.
مثال لتعيين وكيل SOCKS خارجي:```yaml
proxyrouter:
environment:
UPSTREAM_PROXY: "socks5://username:[email protected]:1080"
انتبه إلى أن بعض الوكلاء (proxies) في الطرف العلوي يمكنهم تغيير البصمات منخفضة المستوى (مثل بيانات TCP الوصفية)، مما قد يقلل من التطابق مع متصفح سكني.
سيقوم thermoptic بتحميل المتصفح مع ملفات تعريف الارتباط التي يحددها عميلك في ترويسة Cookie. سيتم بعد ذلك تضمين هذه الملفات في الطلب بمجرد تنفيذه في سياق المتصفح. يتم ذلك لضمان ألا يتمكن الخادم من بصمة ترتيب ملفات تعريف الارتباط أو أي حيل رخيصة أخرى من هذا القبيل.
ملاحظة: ستبقى ملفات تعريف الارتباط هذه موجودة بعد الطلب أيضًا. إذا كنت ترغب في تنفيذ منطق تنظيف لملفات تعريف الارتباط، فيرجى كتابة خطاف (hook) خاص بـ thermoptic.
أجل، يدعم thermoptic الاستخدام الهجين بهذا الشكل، راجع هذا القسم لمزيد من المعلومات.
تحتاج إلى التأكد من أنك تقوم بتعيين ترويسات مثل X-Fetch-* وOrigin وReferer بشكل صحيح. إذا لم تخبر thermoptic بهذه الترويسات، فلن يتمكن من تنفيذ الطلب بالطريقة السرية المناسبة.
بدون تعيين الترويسات السياقية، سيضبط thermoptic قيمًا افتراضية قد لا تعكس بدقة ما يتوقعه موقعك المستهدف. على سبيل المثال، إذا لم تقم بتعيين ترويسة Origin، فسيضبط Origin على null، وإذا لم تقم بتعيين ترويسة Referer، فلن يرسل Referer على الإطلاق.
من مصلحتك تضمين هذه الترويسات السياقية حتى يكون طلبك في غاية السرية قدر الإمكان! لا يستطيع thermoptic قراءة أفكارك، بل يمكنه فقط قراءة طلبك :).
بشكل عام، ينطبق هذا فقط في حالة خطافات thermoptic التي تستخدم مؤقتًا متصفح الويب الكامل لاجتياز فحوصات JavaScript/مستوى المتصفح. عند استخدام هذه الخطافات مؤقتًا ووضع المتصفح الكامل، سيتعين عليك توخي الحذر حتى لا يتم بصمتك كروبوت (على سبيل المثال، تجنّب المخاطر الشائعة مثل Runtime.enable).
الاعتبارات الأخلاقية ونظرية الألعاب المعقدة هنا أكبر مما يمكن الإجابة عليه في ملف README. لا تتردد في الجدال ضد أيٍّ من هذه النقاط المبسّطة للغاية عندما تشتمني عبر البريد الإلكتروني/Twitter/Github:
لمزيد من الحديث حول سباق تسلح التجريف، أطلب منك على الأقل أن تشتري لي بيرة أولاً. لأكون صادقًا، أكره كتابة هذه المقالات الأخلاقية المملة في ملفات README الخاصة بي، لذا لا تتردد في تخيلي كطالب علم شرير يريد أن يجعل حياتك أصعب.
thermopticيتيح لك thermoptic تكوين نصوص برمجية مخصصة لتنفيذ إجراءات المتصفح عندما:
ON_START_HOOK_FILE_PATH)BEFORE_REQUEST_HOOK_FILE_PATH)AFTER_REQUEST_HOOK_FILE_PATH)يتيح لك ذلك استخدام بروتوكول تصحيح الأخطاء في Chrome للنقر وضبط ملفات تعريف الارتباط المناسبة للمواقع التي تتطلب متصفح ويب حقيقي لخطوة تحقق. يمكنك بعد ذلك استخدام وكيل thermoptic لمواصلة جلستك متخفيًا عبر نفس المتصفح.
للقيام بذلك، قم بتعديل ملف خطاف JavaScript المناسب مع الكود المخصص الخاص بك لتنسيق المتصفح بشكل مناسب عبر واجهة chrome-remote-interface الموفرة:```
// cdp is an instance of a connected browser, use it to run your browser actions
export async function hook(cdp) {
console.log([STATUS] Browser start hook called successfully!);
}
للاطلاع على مثال على التنفيذ، راجع ملف [`./hooks/onstart.js`](https://github.com/mandatoryprogrammer/thermoptic/blob/main/hooks/onstart.js) الذي [يتجاوز اختبار CAPTCHA من Cloudflare turnstile](https://github.com/mandatoryprogrammer/thermoptic/blob/main/tutorials/turnstile/cloudflare-turnstile-bypass.md) (وغيرها من فحوصات مكافحة البوت في Cloudflare).
## التحكم في متصفح Chrome المُشغَّل داخل Docker عبر واجهة الويب (Xpra)
تأتي `thermoptic` مع واجهة ويب Xpra المتاحة على `http://127.0.0.1:14111`. يتيح لك ذلك التحكم يدويًا في متصفح Chrome المُشغَّل داخل Docker بسهولة:
<img src="https://assets.kitploit.com/production/public/readmes/49068/0fa1b187f46405dda2b0db5d461619daa6a7bdad2c385cb51994e870d9054d10.png" width="100%">
هذا مفيد لأمور مثل:
* تسجيل الدخول إلى حسابك بحيث يمكنك إجراء طلبات موثّقة عبر `thermoptic` باستخدام عميل HTTP المفضل لديك مثل `curl`.
* على سبيل المثال، إذا سجّلت الدخول إلى `reddit.com` عبر المتصفح، فستكون جميع الطلبات التي ترسلها إلى Reddit عبر `thermoptic` موثّقة تلقائيًا بحسابك على Reddit!
* تصحيح أخطاء خطافات `thermoptic` المخصصة والتحقق من المشكلات المتعلقة بالمواقع.
## الإعدادات
تحدد متغيرات البيئة هذه كيفية تهيئة `thermoptic` عند تشغيله.
`HTTP_PROXY_PORT`: المنفذ الذي يجب أن يستمع عليه وكيل `thermoptic`. إذا كنت تشغّل `thermoptic` داخل Docker، فستحتاج أيضًا إلى تغيير حقل تعيين `ports` ليطابق ذلك.
`CHROME_DEBUGGING_PORT`: المنفذ الذي يتم من خلاله كشف بروتوكول تصحيح أخطاء Chrome. يُحدَّد هذا المنفذ عند تشغيل Chrome/Chromium مع ضبط علامة `--remote-debugging-port` على قيمة مثل `9222`.
`CHROME_DEBUGGING_HOST`: المضيف الذي يتم من خلاله كشف بروتوكول تصحيح أخطاء Chrome. وغالبًا ما يكون `127.0.0.1` إذا تم تشغيل المتصفح محليًا ولم يكن `thermoptic` يعمل داخل Docker. إذا كان يعمل داخل Docker، فقد تحتاج إلى استخدام `host.docker.internal`، راجع [وثائق Docker](https://docs.docker.com/desktop/features/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host) للحصول على معلومات.
`PORT`: منفذ CDP الذي ينشره حاوية Chrome إلى باقي مجموعة الخدمات. أبقِه متوافقًا مع `CHROME_DEBUGGING_PORT` حتى يستمر جسر `socat` في العمل كما هو متوقع.
`CHROME_CONTROL_PORT`: منفذ خدمة التحكم في Chrome الذي يستخدمه `thermoptic` لإدارة المتصفح (على سبيل المثال، إرسال طلبات إعادة التشغيل).
`CHROME_CONTROL_COOLDOWN_MS`: الحد الأدنى للوقت بالمللي ثانية بين محاولات إعادة تشغيل Chrome. استخدم هذا لتجنب حلقات إعادة التشغيل السريعة عند حدوث عدة إخفاقات متتالية.
`ENABLE_GUI_CONTROL`: عيِّنها على `true` لتشغيل لوحة xpra على الويب بحيث يمكنك قيادة Chrome المُشغَّل داخل الحاوية عبر زيارة `http://127.0.0.1:14111`. عطّلها للتشغيل بدون واجهة رسومية فقط.
`CHROME_SCREEN_WIDTH` / `CHROME_SCREEN_HEIGHT`: أبعاد البكسل لشاشة متصفح Chrome المُعبأ في حاوية في وضع headful.
`CHROME_ENABLE_GPU`: يتحكم في ما إذا كانت حاوية Chrome المرفقة يجب أن تحاول استخدام تسريع GPU الخاص بالمضيف. `auto` (الافتراضي) يقوم بتمكين مسار NVIDIA/Vulkan عند توفر وقت التشغيل وعقد الأجهزة المطلوبة، وإلا فإنه يعود إلى العرض البرمجي. عيِّنه على `false` لإجبار السلوك البرمجي القديم فقط.
`CHROME_PROFILE_RECOVERY`: عند الضبط على `true` (الافتراضي)، سيقوم مشغّل Chrome المرفق بمحاولة استرداد واحدة إذا توقف Chrome فورًا بنفس رمز خروج حلقة الانهيار الذي يُلاحظ في ملف تعريف مسموم (`133`). يتم نقل محتويات ملف التعريف التالف إلى `/tmp/chrome-profile-recovery/` داخل الحاوية قبل إعادة المحاولة بملف تعريف نظيف.
`PROXY_USERNAME`: اسم المستخدم المستخدم لمصادقتك على الوكيل، الافتراضي هو `changeme`. إذا لم يتم تعيينه، فإن الوكيل يعمل دون الحاجة إلى مصادقة.
`PROXY_PASSWORD`: كلمة المرور المستخدمة لمصادقتك على الوكيل، الافتراضي هو `changeme`. إذا لم يتم تعيينها، فإن الوكيل يعمل دون الحاجة إلى مصادقة.
`THERMOPTIC_CONTAINER_RUNTIME`: يشير إلى أن `thermoptic` يعمل داخل الحاوية المرفقة. اتركها مضبوطة على `true`؛ فهي تتحكم في سلوكيات مثل فحوصات الصحة المدمجة التي تكون منطقية فقط في إعداد Docker الكامل.
`HEALTHCHECK_ENDPOINT_PORT`: المنفذ الذي يكشف فيه `thermoptic` عن نقطة نهاية فحص الصحة على الويب. يستدعي عامل الصحة هذا من خلال الوكيل؛ إذا توقف عن الاستجابة، يتم إعادة تشغيل Chrome تلقائيًا لإلغاء تعليق الجلسات المتجمدة.
`HEALTHCHECK_ENDPOINT_PATH`: مسار HTTP الذي تخدمه نقطة نهاية فحص الصحة الموصوفة أعلاه. غيّره إذا كنت بحاجة إلى عنوان URL مختلف.
`ON_START_HOOK_FILE_PATH`: رمز Node مخصص لتشغيله عند بدء الوكيل. لن يبدأ الوكيل بالاستماع حتى يكتمل هذا الخطاف، راجع المثال في `./hooks/`. يوضح المثال استخدام المتصفح لتجاوز فحص JavaScript من Cloudflare قبل بدء تشغيل الوكيل.
`BEFORE_REQUEST_HOOK_FILE_PATH`: رمز Node مخصص لتشغيله قبل تمرير الطلب عبر الوكيل. يكون هذا مفيدًا إذا كنت بحاجة إلى اجتياز المتصفح لبعض الفحوصات قبل إرسال طلب HTTP لموقع ما.
`AFTER_REQUEST_HOOK_FILE_PATH`: رمز Node مخصص لتشغيله بعد تمرير الطلب عبر الوكيل. غالبًا ما يكون هذا مفيدًا لأمور مثل تنظيف ملفات تعريف الارتباط التي قام العميل بتعيينها عبر ترويسة `Cookie`.
`DEBUG`: عيِّنها على `true` عندما تصادف خطأً برمجيًا بحيث يطبع `thermoptic` تشخيصات مفصّلة قبل أن تفتح تقرير مشكلة؛ اتركها `false` أثناء التشغيل العادي.
## الأمان
لاحظ أنه في الوقت الحالي، `thermoptic` مخصص فقط للاستخدام مع عملاء HTTP تثق بهم صراحةً. وهو *ليس* مخصصًا للكشف أمام المستخدمين غير الموثوقين.
لأي ثغرات أمنية، يرجى إرسال تقرير إليّ على `mandatory@` Gmail.