burrowers/garbleيقوم بتشويش بنيات Go من خلال تغليف سلسلة أدوات Go، واستبدال المعرّفات ومسارات الحزم وبيانات الموضع بقيم تجزئة (hashes)، وإزالة معلومات التصحيح والبناء.
go install mvdan.cc/garble@latest # or @master
قم بتشويش كود Go من خلال تغليف سلسلة أدوات Go. يتطلب Go 1.27 أو أحدث.
garble build [build flags] [packages]
تدعم الأداة أيضًا garble test لتشغيل الاختبارات بكود مشوّش،
وgarble run لتشويش وتنفيذ برامج بسيطة،
وgarble reverse لإلغاء تشويش النصوص مثل تتبعات المكدس،
وgarble bug لتقديم تقرير خطأ معبأ مسبقًا.
شغّل garble -h لعرض جميع الأوامر والخيارات المتاحة.
إنتاج ملف تنفيذي يعمل بنفس جودة البناء العادي، لكنه يحتوي على أقل قدر ممكن من المعلومات حول الكود المصدري الأصلي.
الأداة مصممة لتكون:
cmd/go، لدعم الوحدات والتخزين المؤقت للبناءتغلّف الأداة الاستدعاءات إلى مترجم وموصل Go لتحويل بناء Go، من أجل:
-literals-tinyتشوّش الأداة جميع الحزم المدعومة التي يتم بناؤها، بما في ذلك وقت التشغيل القياسي.
تُستثنى الحزمتان غير المدعومتين runtime/cgo وcrypto/internal/fips140.
يتبع تشويش وقت التشغيل أهداف GOOS/GOARCH المدعومة في Go؛ لا تحتفظ Garble
بقائمة معماريات مسموح بها أضيق.
لاحظ أن أوامر مثل garble build ستستخدم إصدار go الموجود في
$PATH الخاص بك. لاستخدام إصدارات مختلفة من Go، يمكنك استخدام GOTOOLCHAIN.
سؤال شائع هو لماذا نحتاج إلى مُشوّش كود لـ Go، وهي لغة مُترجمة. تتضمن ملفات Go التنفيذية كمية مدهشة من المعلومات حول المصدر الأصلي؛ حتى مع إزالة معلومات التصحيح وجداول الرموز، تبقى العديد من الأسماء والمواضع في مكانها من أجل التتبعات والانعكاس والتصحيح.
تتطلب بعض حالات استخدام Go مشاركة ملف Go التنفيذي مع المستخدم النهائي. إذا كان الكود المصدري للملف التنفيذي خاصًا أو يتطلب شراءً، فقد يساعد تشويشه في ردع الهندسة العكسية.
حالة استخدام مشابهة هي مكتبة Go التي يكون مصدرها خاصًا أو مشترى. نظرًا لأنه لا يمكن استيراد مكتبات Go في شكل ثنائي، ولأن إضافات Go لها عيوبها، يصبح مشاركة الكود المصدري المشوّش خيارًا. انظر #369.
يمكن أن يساعد التشويش أيضًا في جوانب لا علاقة لها بالترخيص على الإطلاق.
على سبيل المثال، يمكن لخيار -tiny تصغير الملفات التنفيذية بنسبة 15%،
على غرار الممارسة الشائعة في Android لتقليل أحجام التطبيقات.
كما ساعد التشويش بعض مطوري المصادر المفتوحة على التعامل مع
فحوصات مكافحة الفيروسات التي تتعامل بشكل خاطئ مع ملفات Go التنفيذية على أنها برمجيات خبيثة.
يؤدي استخدام خيار -literals إلى استبدال التعبيرات الحرفية مثل النصوص
بتعبيرات أكثر تعقيدًا، تُحل إلى نفس القيمة في وقت التشغيل.
تُستبدل أيضًا النصوص الحرفية المحقونة عبر -ldflags=-X بهذا الخيار.
هذه الميزة اختيارية، لأنها قد تسبب تباطؤًا اعتمادًا على الكود المُدخل.
لا يمكن تشويش القيم الحرفية المستخدمة في التعبيرات الثابتة، لأنها
تُحل في وقت الترجمة. يشمل ذلك أي تعبيرات جزء من تعريف const، على سبيل المثال.
لاحظ أن هذه العملية يمكن عكسها بجهد كافٍ؛ انظر #984.
مع خيار -tiny، تُزال معلومات أكثر من ملف Go التنفيذي.
تُزال معلومات الموضع بالكامل، بدلًا من تشويشها.
يُزال كود وقت التشغيل الذي يطبع الذعرات والأخطاء القاتلة ومعلومات التتبع/التصحيح.
كما تُحذف العديد من أسماء الرموز من أقسام الملف التنفيذي في وقت الربط.
بشكل عام، يمكن أن يجعل هذا الملفات التنفيذية أصغر بنحو 15%.
مع هذا الخيار، لن تُطبع أي ذعرات أو أخطاء وقت تشغيل قاتلة على الإطلاق، لكن
لا يزال يمكن التعامل معها داخليًا باستخدام recover كالمعتاد.
لاحظ أن هذا الخيار يمكن أن يجعل تصحيح الأعطال أصعب، حيث سيخرج الذعر ببساطة
من البرنامج بأكمله دون طباعة تتبع مكدس، وتُزال مواضع الكود المصدري
والعديد من الأسماء.
وبالمثل، فإن garble reverse غير مفيد عمومًا في هذا الوضع.
انظر: CONTROLFLOW.md
يجب أن يستغرق garble build حوالي ضعف الوقت الذي يستغرقه go build، لأنه يحتاج إلى
إكمال عمليتي بناء. البناء الأصلي، ليكون قادرًا على تحميل الكود المُدخل والتحقق من أنواعه، ثم البناء المشوّش.
تشوّش Garble حزمة واحدة في كل مرة، على غرار كيفية ترجمة Go لحزمة
واحدة في كل مرة. يتيح ذلك لـ Garble دعم ذاكرة التخزين المؤقت للبناء في Go بشكل كامل؛ يجب أن تعيد استدعاءات
garble build التزايدية بناء وتشويش الكود المعدّل فقط.
لاحظ أن أول استدعاء لـ garble build قد يكون بطيئًا نسبيًا،
حيث يتعين عليه تشويش كل حزمة للمرة الأولى. هذا مشابه لمسح
GOCACHE باستخدام go clean -cache وتشغيل go build من الصفر.
تستفيد Garble أيضًا من ذاكرتها المؤقتة الخاصة لإعادة استخدام العمل، على غرار GOCACHE في Go.
تكون افتراضيًا في دليل تحت دليل ذاكرة التخزين المؤقت لمستخدمك،
مثل ~/.cache/garble، ويمكن وضعها في مكان آخر عن طريق تعيين GARBLE_CACHE.
تمامًا مثل Go، فإن عمليات بناء garble حتمية وقابلة لإعادة الإنتاج بطبيعتها.
لهذا فوائد كبيرة، مثل تخزين عمليات البناء مؤقتًا والقدرة على استخدام
garble reverse لإلغاء تشويش تتبعات المكدس.
افتراضيًا، ستشوّش garble كل حزمة بطريقة فريدة، والتي ستتغير إذا تغير مُدخل بنائها: إصدار garble، أو إصدار Go، أو الكود المصدري للحزمة، أو أي معامل بناء مثل GOOS أو -tags. هذا افتراضي معقول لأن تخمين تلك المُدخلات صعب جدًا.
يمكنك استخدام خيار -seed لتوفير بذرة عشوائية خاصة بك للتشويش.
يمكن أن يساعد إعادة استخدام نفس البذرة في إنتاج نفس تشويش الكود،
مما قد يساعد عند تصحيح الأخطاء أو إعادة إنتاج المشكلات.
كما يمكن أن يساعد تدوير البذرة بانتظام ضد الهندسة العكسية على المدى الطويل،
وإلا يمكن للمرء النظر إلى التغييرات في كيفية تشويش المكتبة القياسية في Go
لتخمين متى تغيرت إصدارات Go أو garble عبر سلسلة من عمليات البناء.
لاستخدام بذرة مختلفة دائمًا لكل بناء، استخدم -seed=random.
لاحظ أنه يجب توخي الحذر الشديد عند استخدام بذور مخصصة:
إذا فُقدت قيمة -seed المستخدمة في بناء ما، فلن يعمل garble reverse.
يمكن تحسين معظم هذه الأمور مع الوقت والجهد. الغرض من هذا القسم هو توثيق أوجه القصور الحالية لهذه الأداة.
لا تُشوّش الطرق المُصدَّرة أبدًا في الوقت الحالي، لأنها قد تكون مطلوبة بواسطة الواجهات. هذا المجال قيد العمل؛ انظر #3.
لا توجد طريقة مدعومة لاستبعاد تشويش مجموعة مختارة من الملفات أو الحزم. في أغلب الأحيان، قد يرغب المستخدم في فعل ذلك للالتفاف حول خطأ؛ يرجى تقديم تقرير بالخطأ بدلًا من ذلك.
تُهيَّأ برامج Go حزمة واحدة في كل مرة، حيث تُهيَّأ الحزم المستوردة دائمًا قبل مستورديها، وإلا فتُهيَّأ بالترتيب المعجمي لمسارات استيرادها. نظرًا لأن garble تشوّش مسارات الاستيراد، فقد يتغير هذا الترتيب المعجمي بشكل عشوائي.
إضافات Go غير مدعومة حاليًا؛ انظر #87.
تتطلب Garble وجود git لترقيع الموصل. يمكن تجنب ذلك بمجرد أن يدعم go-gitdiff
الترقيعات غير الصارمة.
واجهات برمجة مثل runtime.GOROOT
وruntime/debug.ReadBuildInfo
لن تعمل في الملفات التنفيذية المشوّشة. يمكن أن يؤثر هذا على
تحميل المناطق الزمنية، على سبيل المثال.
نرحب بالمساهمين الجدد. إذا كنت ترغب في المساهمة، انظر CONTRIBUTING.md كنقطة بداية.
يرجى تقديم مشكلة قبل إرسال PR، سواء كان تقرير خطأ أو طلب ميزة، حتى نتمكن من الاتفاق على المشكلة وحلها أولًا.
