psc
1.0.0
ينتمي هذا المشروع - بالإضافة إلى المشروع الشقيق - إلى مجموعة أدوات مكافحة الرقابة التي تسمح بإعداد أغلفة مشفرة تعمل بكامل طاقتها وإعادة توجيه TCP/UDP في بيئات الرقابة المعادية. من المفيد أيضًا للطب الشرعي تفريغ البيانات من الأجهزة عبر UART أو adb عندما لا تتوفر وسائل أخرى.
تتم إعادة توجيه بحث DNS وجلسة SSH عبر اتصال UART إلى Pi
يسمح PSC بتشفير جلسات الصدفة e2e، قفزة فردية أو متعددة، بغض النظر عن النقل الأساسي، طالما أنه موثوق ويمكنه إرسال/استقبال البيانات المشفرة باستخدام Base64 دون تعديل/تصفية. بالإضافة إلى e2e pty الذي تتلقاه (على سبيل المثال داخل غلاف المنفذ)، يمكنك إعادة توجيه اتصالات TCP وUDP، على غرار المعلمة -L الخاصة بـ OpenSSH. يعمل هذا بشفافية ودون الحاجة إلى عنوان IP معين محليًا عند نقطة البداية. يسمح هذا للطب الشرعي ومختبري القلم بإنشاء اتصالات الشبكة على سبيل المثال عبر:
adb shell ، إذا كان OEM adbd لا يدعم إعادة توجيه TCPفقط تخيل أنه سيكون لديك جلسة شراكة بين القطاعين غير مرئية داخل جلسة الصدفة الخاصة بك، دون أن يدعم النظير البعيد الشراكة بين القطاعين العام والخاص فعليًا.
إنه يعمل على Linux، وAndroid، وOSX، وWindows، وFreeBSD، وNetBSD ، و(ربما) OpenBSD .
يتضمن PSC أيضًا دعم وكيل SOCKS4 و SOCKS5 من أجل الحصول على جلسات تصفح ويب فعلية عبر أغطية المنافذ أو عمليات الطلب الهاتفي للمودم عن بُعد.
قم بتحرير ملف Makefile ليعكس مفاتيحك المشتركة مسبقًا، كما هو محدد في الجزء العلوي من Makefile .
ثم اكتب فقط make على Linux و OSX .
في BSD تحتاج إلى تثبيت GNU make واستدعاء gmake بدلاً من ذلك.
على نظام التشغيل Windows، تحتاج إلى تثبيت cygwin وتحديد حزم gcc, gcc-g++, make و git المناسبة.
في Linux ، ستستخدم PSC محطات Unix98 الزائفة، وفي الأنظمة الأخرى ستستخدم POSIX pty's ولكن يجب أن يكون ذلك واضحًا بالنسبة لك. لقد قمت ذات مرة بإضافة دعم 4.4BSD pty و SunOS في العصر الحجري لسبب معين، لذلك قد يتم إنشاءه أو لا يتم إنشاؤه حتى مع Solaris .
وبكل فخر برعاية:
عادي وبسيط. في صندوقك المحلي، قم بتنفيذ الأمر pscl ، وقم بتمرير أي منافذ TCP أو UDP تريد إعادة توجيهها من الموقع البعيد إلى عنوان معين. على سبيل المثال:
linux:~ > ./pscl -T 1234:[192.168.0.254]:22 -U 1234:[8.8.8.8]:53
PortShellCrypter [pscl] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: set up local TCP port 1234 to proxy to 192.168.0.254:22 @ remote.
pscl: set up local UDP port 1234 to proxy to 8.8.8.8:53 @ remote.
pscl: Waiting for [pscr] session to appear ...
linux:~ >
[ UART / SSH / ... login to remote side ... ]
على الموقع البعيد (الخطوة الأخيرة) مع جلسة الصدفة، بغض النظر عما إذا كان ذلك في منفذ shell أو SSH أو تسجيل الدخول إلى وحدة التحكم وما إلى ذلك، يمكنك تنفيذ pscr :
linux:~ > ./pscr
PortShellCrypter [pscr] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: Seen STARTTLS sequence, enabling crypto.
linux:~ >
بمجرد تنفيذ pscr ، يقوم كلا الطرفين بإنشاء مصافحة تشفير ووضع بروتوكول إضافي على جلستك الحالية يكون شفافًا بالنسبة لك. يمكنك بعد ذلك الاتصال بـ 127.0.0.1:1234 على جهاز الاستقبال المحلي الخاص بك للوصول إلى 192.168.0.254:22 عبر TCP أو محلل 8.8.8.8 عبر UDP. ويعمل هذا أيضًا مع عناوين [IPv6]، إذا كان الموقع البعيد به اتصال IPv6. في الواقع، يمكنك حتى استخدامه لترجمة برنامج IPv4 إلى IPv6، نظرًا لأنك تتصل دائمًا بـ 127.0.0.1 على الجانب المحلي.
يمكنك تمرير معلمات -T و- -U متعددة. إذا فقدت المسار إذا كانت جلستك مشفرة بالفعل بواسطة e2e، فيمكنك إرسال SIGUSR1 إلى عملية pscl المحلية، وسوف يخبرك بذلك.
يعد PSC مفيدًا أيضًا إذا كنت تريد استخدام Tor من غلاف SSH بعيد، حيث يمكنك إعادة توجيه Sock5 ومنفذ DNS إلى عنوان المضيفين البعيدين 127.0.0.1 . نظرًا لأن SSH لا يقوم بإعادة توجيه حزم UDP، فعادةً ما تستخدم موصلين socat أو ما شابه ذلك للحل عبر عقدة Tor. يتمتع PSC بميزة الحفاظ على حدود مخطط بيانات UDP، بينما قد يؤدي socat عبر SSH -L إلى كسر حدود مخطط البيانات وإنشاء طلبات DNS مشوهة.
سيتم تشفير الجلسة باستخدام aes_256_ctr لـ PSK الذي تختاره في Makefile . يعد نظام التشفير هذا مرنًا، ولكن إضافة بيانات AAD أو OAD يؤدي إلى زيادة حجم الحزمة، حيث يتم احتساب كل بايت منذ ذلك الحين في الجلسات التفاعلية وبسبب تشفير Base64، يتسبب كل حرف مكتوب بالفعل في إرسال المزيد من البيانات.
يمكن استخدام جلسات UART عبر screen ولكن ليس عبر minicom على سبيل المثال نظرًا لأن minicom سينشئ نوافذ غير مرئية بخطوط الحالة ويعمل كمرشح يدمر بروتوكول PSC. يحاول PSC اكتشاف التصفية ويمكنه التعايش مع قدر معين من تشويه البيانات، ولكن في بعض المواقف لا يمكن استردادها. شيء مماثل مع tmux . يجب عليك تجنب تكديس معالجات pty مع PSC التي تعبث/تتعامل مع بياناتها الواردة أكثر من اللازم.
يجب تعيين متغير بيئة SHELL لكل من pscl و pscr حتى يتمكن PSC من معرفة الصدفة التي سيتم تنفيذها على pty. يتم تعيين SHELL في معظم البيئات افتراضيًا، ولكن في حالة عدم ذلك، يجب تنفيذ PSC مثل SHELL=/bin/bash pscl وما إلى ذلك.
يدعم pscl أيضًا إعادة توجيه اتصالات TCP عبر SOCKS4 ( -4 port ) و SOCKS5 ( -5 port ). يؤدي هذا إلى إعداد المنفذ كمنفذ SOCKS لاتصالات TCP، بحيث يمكنك على سبيل المثال تصفح الشبكات البعيدة من جلسة غلاف المنفذ دون الحاجة إلى فتح أي اتصال آخر أثناء اختبار القلم. إذا قمت بتمرير -N إلى pscl ، فإنه يمكّن تحليل اسم DNS على الجانب البعيد، بحيث يمكنك أيضًا استخدام chrome معه. لكن كن حذرًا: توجد مشكلة تتعلق بالخصوصية في المتصفحات التي تحاول حل سلسلة من أسماء DNS عند بدء التشغيل والتي لا تقع تحت سيطرتك. وأيضًا، إذا كان الجانب البعيد لديك يحتوي على إعداد DNS معطل، فقد يتم حظر غلاف الكتابة الخاص بك لعدة ثوانٍ إذا كانت حزم رد DNS مفقودة. لا توجد وظائف محلل غير متزامن جيدة قابلة للتضمين والمحمولة لذا اضطررت إلى الاعتماد على getaddrinfo() في سلسلة رسائل واحدة بسعر عمليات الحظر المحتملة لعدة ثوانٍ في حالة وجود مشاكل في DNS. ولهذا السبب يجب تمكين تحليل الأسماء بشكل صريح. يحاول pscr تقليل هذه المشكلة المحتملة من خلال ذاكرة التخزين المؤقت للبحث في DNS، لذلك في معظم الحالات يجب أن يعمل بدون ألم. إذا قمت بتمرير -X IP-address (يجب أن يكون الوسيط الأول)، فيمكنك ربط الوكيل المحلي الخاص بك بعنوان مختلف عن 127.0.0.1 ، حتى تتمكن من مشاركة الوكيل في شبكتك المحلية.
تسمح ميزات psc بإعادة توجيه اتصالات TCP أو نقاط البيانات الثنائية من/إلى الأجهزة البعيدة عبر قفزات متعددة حتى لو لم يكن من الممكن تثبيت ثنائي pscr في الموقع البعيد. يعد هذا مفيدًا جدًا لأغراض الطب الشرعي إذا لم يكن لديك أي وسيلة لتنزيل العناصر من الجهاز (والذي يمكن أن يكون هاتفًا متصلاً بـ UART على سبيل المثال) أو كنت بحاجة إلى إعادة توجيه الاتصالات دون لمس FS لعدم تدمير الأدلة الموجودة على النظام أو عندما تم تثبيت root-FS ولا يمكنك تحميل مجموعة الأدوات الخاصة بك.
هذه ميزة رائعة حقًا، حيث يمكنك رؤية اتصال TCP الخاص بك ينتقل عبر جهاز tty المحلي الخاص بك إلى صندوق بعيد دون الحاجة إلى تثبيت أي شيء عن بعد.
يعمل هذا فقط عن طريق pty punkrock المحلي وتسليم أمر الارتداد إلى pscl والذي سيتم إسقاطه على الغلاف البعيد (بدون تشغيل pscr ) وبعض سحر محرك الحالة الذي يقوم بتصفية البيانات ومعالجتها على الجانب المحلي. يتطلب هذا عادةً ضبط pty البعيد على الوضع الخام في البداية قبل إصدار الأمر الفعلي وبعض التفاصيل الأخرى التي تم تمريرها إلى -B . تنقسم الحجة إلى الأجزاء التالية:
: ، على سبيل المثال 1234: .stty -echo raw أو python -c "import tty;tty.setraw(0)" (احرص على الحصول على علامات الاقتباس بشكل صحيح، حيث يجب أيضًا اقتباس -B ) أو أي شيء مماثل.pscl ببدء إرسال البيانات لتجنب السباق بين stty الذي يحدث بالفعل وبداية cmd، على سبيل المثال يكون echo GO مثاليًا.nc 127.0.0.1 22 لارتداد المنفذ المحلي 1234 إلى خادم SSH الخاص بجهاز التحكم عن بعدpscl بإعادة تعيين حالة tty الخاصة به. سوف يقوم echo FIN بذلك. موصى به، وإلا قد تواجه مشكلة في التعرف على نهاية الأمر.; ومحاطة بين قوسين.أمثلة:
إذا كنت تريد إعادة توجيه اتصال TCP، فإن هذا المثال يتطلب تثبيت stty و nc على الجهاز، ولكن من الناحية النظرية يمكن أن يكون أي شيء آخر يقوم بما يعادله.
ابدأ جلسة محلية:
./pscl -B '1234:[stty -echo raw;echo GO;nc example.com 22;echo FIN]'
سيؤدي هذا إلى إصدار الأمر stty -echo raw;echo GO;nc example.com 22;echo FIN إلى الجهاز البعيد إذا قمت بالاتصال محليًا بالمنفذ 1234 ثم قم بإعادة توجيه أي بيانات تراها ذهابًا وإيابًا وتحديد معدل حركة المرور لذلك ولن تتجاوز سرعة الأجهزة (115200 هي السرعة الافتراضية).
عند بدء جلسة pscl، اتصل بالجهاز البعيد عن طريق UART، أو ssh -e none ... أو أيًا كان، وبمجرد حصولك على Remote Shell، اكتب أيضًا محليًا:
ssh [email protected] -p 1234 لارتداد اتصال SSH من صندوقك المحلي عبر الجهاز البعيد إلى وجهة example.com . بالطبع يُفضل متغير pscr حيث أن -B يمكنه ارتداد اتصال واحد فقط في كل مرة (على الرغم من أنه يمكنك تمرير أوامر -B متعددة لعمليات إعادة توجيه مختلفة) وهناك فرصة لتعليق الصدفة بعد جلسة TCP نظرًا لأن pty في raw -echo الصدى واعتمادًا على ما إذا كان النظير البعيد النهائي يغلق الاتصال أيضًا، فقد يتم تعليق الصدفة بعد ذلك. إذا عثرت على إشعار pscl يفيد بانتهاء الاتصال ورأيت مطالبة، فيجب عليك reset ، بحيث يمكن بدء اتصال جديد. أثناء إعادة توجيه البيانات، ستشاهد إشعارات 7 بت ASCII < و > في pscl والتي تكون محلية فقط لتسهيل تصحيح الأخطاء واكتشاف التقدم.
لاحظ أن الاتصال بالموقع البعيد يجب أن يكون نظيفًا بمعدل 8 بت، أي يجب ألا تتعامل ssh أو telnet أو UART أو أي قناة أخرى مع تسلسل الهروب (على عكس استخدام pscr ). بالنسبة لاتصالات ssh، هذا يعني أنه يجب عليك استخدام ssh -e none في جلسة pscl .
بعد ذلك، نتبع بعض الأمثلة للتعامل مع الملف الثنائي xfer حيث يشير rfile إلى الملف البعيد و lfile إلى الملف المحلي.
لبدء جلسة لإسقاط الملفات البعيدة محليًا:
./pscl -B '1234:[stty -echo raw;echo GO;dd of=rfile.bin bs=1 count=7350;echo FIN]'
حيث تحتاج إلى تحديد كمية البيانات التي يتوقعها الجانب البعيد. ستعمل أيضًا بدون (على سبيل المثال cat>... ) ولكن سيتم تعليق الجلسة بعد انتهاء الإرسال حيث أن cat تتوقع الإدخال إلى ما لا نهاية. باستخدام dd count=... سوف تحصل على مخرج نظيف وسيتم إعلامك بذلك بواسطة علامة FIN.
ثم، ssh أو أي شيء ضروري للحصول على shell على الجهاز البعيد من داخل جلسة pscl التي بدأت للتو. على المحطة الثانية محليًا:
dd if=lfile.bin|nc 127.0.0.1 1234
والذي سيتصل بمنفذ pscl المحلي 1234 ويطلق أمر التفريغ على الجانب البعيد، ويعيد توجيه البيانات الثنائية لملف lfile.bin المحلي إلى أجهزة التحكم عن بعد rfile.bin . نظرًا لقيود المعدل، قد يستغرق هذا بعض الوقت ولن تثق إلا في شاشة تقدم psc الخاصة بك في حالة انتهاء عملية النقل. سيُظهر لك الأمر dd ...|nc ... فقط الحالة المحلية التي يمكنها تناول الملفات بأكملها في ثوانٍ بسبب مخازن TCP المؤقتة المحلية بينما لا يزال الملف قيد النقل عبر pty. لذا تأكد من الضغط على Ctrl-C فقط عندما تخبرك شاشة pscl بأن الأمر قد انتهى أو ترى صدى علامة نهاية FIN يعود إليك مرة أخرى في جلسة dd ...|nc ...
وبالمثل، يمكن استخدام أوامر مماثلة لنقل البيانات الثنائية من جهاز بعيد إلى الصندوق المحلي لأغراض الطب الشرعي. مرة أخرى، ابدأ الجلسة محليًا:
./pscl -B '1234:[stty -echo raw;echo GO;dd if=rfile.bin]' أو
./pscl -B '1234:[stty -echo raw;echo GO;cat rfile.bin]'
بعد ذلك، قم بإرسال ssh إلى الجهاز البعيد للحصول على الصدفة، ثم مرة أخرى محليًا:
nc 127.0.0.1 1234|dd of=lfile.bin bs=1 count=7350
للحصول على rfile.bin بالحجم 7350، تم نسخه إلى الملف المحلي lfile.bin
إذا لم يكن stty -echo raw متاحًا على الجهاز، فسيعمل أيضًا شيء مثل python -c "import tty;tty.setraw(0)" . لاحظ أنه على الجهاز البعيد، يجب أن يكون لديك tty (وليس مجرد منفذ shell) عند استخدام أوامر الارتداد، نظرًا لأن الأمر stty لتعيين الوضع الأولي يتطلب tty حقيقيًا.
إذا تم تشغيل psc عبر اتصال تسلسلي، فقد تؤدي الأجزاء المفقودة إلى قتل كل المتعة. إذا قمت بالتشغيل بدون HW FC، فسوف تواجه في النهاية فقدان البت والاتصالات المعلقة، لا سيما أنه لا يوجد اختناق عندما يرسل الجهاز البيانات في اتجاهك عند استخدام أوامر الارتداد . يعمل تفريغ البيانات على الجهاز بشكل أفضل حيث تمر هذه البيانات عبر حدود معدل pscl .
ومع ذلك، إليك بعض النصائح التي نجحت معي في ظل الظروف التي لم يكن من الممكن فيها استخدام pscr على الجهاز وHW FC. وينطبق هذا فقط عند استخدام UARTs، حيث إنها قناة نقل قد لا يمكن الاعتماد عليها.
pscr على الجهاز حتى تتمكن من ضبط معدل تحديد البيانات التي يتم إرسالها إلى اتجاهك. نظرًا لأن الاتجاه نحو الجهاز يكون دائمًا محدودًا بالمعدل، يمكنك استخدام أوامر الارتداد لتفريغ ملف ثنائي pscr مجمع على الجهاز وبدء جلسة محدودة بمعدل ثنائي الاتجاه معه.tio -o 1 أو -o 2 لإضافة تأخيرات بين بايتات الإخراج المرسلة38400 على الرغم من أن الخط التسلسلي قد حدد 115200 )psc باستخدام -DRESPECT_UART_BUFSIZE=4096 ، ولكن هذا سيجعل الجلسة بطيئة جدًا داخل مجلد contrib ، ستجد أيضًا تصحيح tio-noprefix لتعطيل معالجة أحرف الهروب، لكن هذا التصحيح ضروري فقط للإصدارات الأقدم، حيث إن المنبع قد قبل بالفعل هذا التصحيح ودمجه. أوصي حقًا باستخدام tio عند استخدام UARTs.
عند استخدام أوامر الارتداد عبر tio ، يجب عليك إضافة إلى ملف ~/.tioconfig الخاص بك:
[default]
prefix-ctrl-key = none
الذي يعطل معالجة ESC ويمنحك قناة نظيفة 8 بت.
يمكنك إرسال SIGUSR1 إلى pscl ليخبرك ما إذا كانت الجلسة مشفرة أم لا. إذا مات pscr البعيد أو خرج دون إمكانية إرسال إشارة إلى الجزء المحلي، فسيبقى pscl في وضع التشفير وبالتالي يتعطل. في هذه الحالة، يمكنك فرض إعادة التعيين إلى وضع النص العادي عن طريق إرسال SIGUSR2 ، بحيث يمكن بدء جلسة جديدة.
اعتبارًا من الإصدار 0.64، يدعم psc مآخذ البرمجة النصية، لذلك لم تعد بحاجة إلى screen للحصول على/وضع الملفات أو تفريغ المخازن المؤقتة للصق إلى وحدة التحكم عن بعد. بدلاً من ذلك، يمكنك بدء جلستك المحلية على النحو التالي:
~ > ./pscl -S ~/psc.script_sock
يمكنك بعد ذلك المضي قدمًا واستخدامه كما كان من قبل. إذا كنت بحاجة إلى "لصق" شيء تحبه:
~ > ./pscsh -S ~/psc.script_sock -f script_/helloworld
سيؤدي هذا إلى "كتابة" محتوى script_/helloworld على وحدة التحكم. أثناء البرمجة النصية، يتم حظر stdin الخاص بـ pscl بحيث لا يختلط الإدخال المُدخل مع أي كتابة. إذا تم حذف -S في pscsh ، فسيتم استخدام ~/psc.script_sock تلقائيًا. لأسباب تتعلق بالسلامة، يجب أن تبدأ البرامج النصية بالبادئة script_ .
كمكافأة، يحتوي pscr الآن على القدرة على تشفير/فك تشفير الملفات باستخدام Base64، حتى مع أحرف CR المضمنة للراحة. وهو متوافق مع uuencode -m .
