جوجل الترجمة API القرصنة

كجزء من Google Cloud ، تقدم Google واجهة برمجة تطبيقات Google للترجمة مع بنية تكلفة قائمة على الاستخدام. هناك أيضًا واجهة برمجة تطبيقات غير موثقة يمكن استخدامها بدون مفتاح ، ولكنها ترفض العمل بعد بضع طلبات فقط. عند استخدام وظيفة ترجمة مواقع الويب في Google Chrome ، يُلاحظ أنه يمكن ترجمة الصفحات بجودة عالية جدًا دون أي قيود ملحوظة.


يبدو أن نموذج nmt المتقدم مستخدم بالفعل هنا. ولكن ما هي واجهة برمجة التطبيقات التي يستخدمها Google Chrome داخليًا لترجمة المحتوى وهل يمكن أيضًا معالجة واجهة برمجة التطبيقات هذه مباشرةً - حتى على جانب الخادم؟ لتحليل حركة مرور الشبكة ، يوصى باستخدام أدوات مثل Wireshark أو Telerik Fiddler ، والتي يمكنها أيضًا تحليل حركة المرور المشفرة. لكن Chrome يسلم الطلبات التي يرسلها لترجمة الصفحة مجانًا: يمكن عرضها بسهولة باستخدام Chrome DevTools:

إذا أجريت ترجمة ، فقم بالقبض على طلب POST المهم إلى https://translate.googleapis.com عبر "نسخ> نسخ كـ cURL (bash)" وتنفيذه بأداة مثل Postman ، على سبيل المثال ، يمكنك إرسال الطلب مرة أخرى دون مشاكل:

معنى معلمات URL واضح أيضًا إلى حد كبير:

مفتاحقيمة المثالالمعنى
anno3وضع التعليقات التوضيحية (يؤثر على تنسيق الإرجاع)
عميلte_libمعلومات العميل (تختلف ، القيمة هي "webapp" عبر واجهة الويب الخاصة بخدمة Google Translate ، ولها تأثير على تنسيق الإرجاع وتحديد السعر)
شكللغة البرمجةتنسيق السلسلة (مهم لترجمة علامات HTML)
الخامس1.0رقم إصدار ترجمة Google
مفتاحAIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgwمفتاح API (انظر أدناه)
logldvTE_20200210_00نسخة البروتوكول
slديلغة المصدر
TLenلغة الهدف
صnmtنموذج ML
ح1غير معروف
ريال سعودى1غير معروف
tk709408.812158رمز (انظر أدناه)
موضه1غير معروف

يتم أيضًا تعيين بعض رؤوس الطلبات - ولكن يمكن تجاهلها في الغالب. بعد إلغاء تحديد جميع الرؤوس يدويًا ، بما في ذلك تلك الخاصة بوكيل المستخدم ، يتم اكتشاف مشكلة تشفير عند إدخال أحرف خاصة (هنا عند ترجمة " Hello World "):

إذا قمت بإعادة تنشيط وكيل المستخدم (والذي لا يسبب أي ضرر بشكل عام) ، فإن واجهة برمجة التطبيقات تقدم رموز UTF-8:

هل نحن موجودون بالفعل وهل لدينا جميع المعلومات لاستخدام واجهة برمجة التطبيقات هذه خارج Google Chrome؟ إذا قمت بتغيير السلسلة المراد ترجمتها (حقل البيانات q لطلب POST) من ، على سبيل المثال ، "Hello world" إلى "Hello world ! "، وصلتنا رسالة خطأ:

نترجم الآن هذا المعدل مرة أخرى داخل Google Chrome باستخدام وظيفة ترجمة موقع الويب ونجد أنه بالإضافة إلى المعلمة q ، تم تغيير المعلمة tk أيضًا (ظلت جميع المعلمات الأخرى كما هي):

يبدو أنه رمز يعتمد على السلسلة ، وليس من السهل رؤية هيكلها. عند بدء ترجمة موقع الويب ، يتم تحميل الملفات التالية:

  • ملف CSS واحد: translateelement.css
  • 4 رسومات: translate_24dp.png (2x)، gen204 (2x)
  • 2 ملف JS: main_de.js ، element_main.js

يتم تشويش ملفي JavaScript وتصغيرهما. تساعدنا أدوات مثل JS Nice و de4js الآن في جعل هذه الملفات أكثر قابلية للقراءة. من أجل تصحيحها مباشرة ، نوصي بـ Chrome Extension Requestly ، الذي ينفق الملفات البعيدة محليًا أثناء التنقل:

الآن يمكننا تصحيح الكود (يجب تنشيط CORS أولاً على الخادم المحلي). يبدو أن قسم الكود ذي الصلة لإنشاء الرمز المميز مخفي في ملف element_main.js في هذا القسم:

b7739bf50b2edcf636c43a8f8910def9

هنا يتم تجزئة النص بمساعدة بعض التحولات الطفيفة . لكن لسوء الحظ ما زلنا نفتقد قطعة واحدة من اللغز: بالإضافة إلى الحجة a (وهو النص المراد ترجمته) ، يتم تمرير وسيطة أخرى b إلى الوظيفة Bp () - نوع من البذرة التي يبدو أنها تتغير من وقت لآخر وتتضمن أيضًا يتدفق إلى التجزئة. لكن من أين أتى؟ إذا انتقلنا إلى استدعاء وظيفة Bp () ، فسنجد قسم الكود التالي:

b7739bf50b2edcf636c43a8f8910def9

يتم الإعلان عن الوظيفة Hq مسبقًا على النحو التالي:

b7739bf50b2edcf636c43a8f8910def9

هنا ترك Deobfuscater بعض القمامة. بعد أن استبدلنا String.fromCharCode ('...') بسلاسل الأحرف ذات الصلة ، قم بإزالة a () القديمة وقم بتجميع استدعاءات الوظائف [c ()، c ()] ، تكون النتيجة هي:

b7739bf50b2edcf636c43a8f8910def9

أو حتى أسهل:

b7739bf50b2edcf636c43a8f8910def9

تم تعريف الوظيفة yq مسبقًا على أنها:

b7739bf50b2edcf636c43a8f8910def9

يبدو أن البذرة موجودة في الكائن العالمي google.translate._const._ctkk ، والذي يتوفر في وقت التشغيل. لكن أين تم تعيينه؟ في الملف الآخر ، وهو ملف JS الذي تم تحميله مسبقًا main_de.js ، على الأقل يكون متاحًا أيضًا في البداية. نضيف ما يلي في البداية:

b7739bf50b2edcf636c43a8f8910def9

في وحدة التحكم ، نحصل بالفعل على البذور الحالية:

هذا يترك Google Chrome نفسه ، والذي يبدو أنه يوفر البذور كخيار أخير. لحسن الحظ ، فإن كود المصدر الخاص به (Chromium ، بما في ذلك مكون الترجمة) مفتوح المصدر وبالتالي متاح للجمهور. نقوم بسحب المستودع محليًا والعثور على استدعاء وظيفة TranslateScript :: GetTranslateScriptURL في ملف translate_script.cc في مجلد المكونات / translate / core / browser:

b7739bf50b2edcf636c43a8f8910def9

المتغير الذي يحتوي على عنوان URL محدد بدقة في نفس الملف:

b7739bf50b2edcf636c43a8f8910def9

إذا قمنا الآن بفحص ملف element.js عن كثب (بعد فك التلاعب مرة أخرى) ، فسنجد الإدخال الثابت c._ctkk - يتم أيضًا تعيين كائن google.translate وفقًا لذلك ويتم تشغيل تحميل جميع الأصول ذات الصلة (التي اكتشفناها سابقًا):

b7739bf50b2edcf636c43a8f8910def9

الآن يبقى مفتاح المعلمة قيد الدراسة (مع القيمة AIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgw). يبدو أن هذا هو مفتاح واجهة برمجة تطبيقات عام للمتصفح (والذي يمكن العثور عليه أيضًا في بعض نتائج Google ). تم تعيينه في Chromium في ملف translate_url_util.cc في مكونات المجلد / ترجمة / كور / متصفح:

b7739bf50b2edcf636c43a8f8910def9

يتم إنشاء المفتاح في google_apis / google_api_keys.cc من قيمة وهمية:

b7739bf50b2edcf636c43a8f8910def9

ومع ذلك ، يُظهر الاختبار أن استدعاءات API تعمل بنفس الطريقة بدون معلمة المفتاح هذه. إذا قمت بتجربة API ، فستستعيد رمز الحالة 200 مرة أخرى إذا نجحت. إذا وصلت بعد ذلك إلى حد ، فستحصل على رمز الحالة 411 مرة أخرى بالرسالة " تتطلب طلبات POST رأسًا بطول المحتوى ". لذلك يُنصح بتضمين هذا العنوان (الذي يتم تعيينه تلقائيًا كرأس مؤقت في Postman).

يعتبر تنسيق الإرجاع للسلاسل المترجمة غير معتاد عند وجود عدة جمل في طلب واحد. يتم تضمين الجمل الفردية بواسطة علامات i- / b-HTML:

أيضًا ، لا يرسل Google Chrome شفرة HTML بالكامل إلى واجهة برمجة التطبيقات ، ولكنه يحفظ قيم السمات مثل href في الطلب (وبدلاً من ذلك يعيّن الفهارس بحيث يمكن تعيين العلامات لاحقًا من جانب العميل):

إذا قمت بتغيير قيمة عميل مفتاح POST من te_lib (Google Chrome) على webapp ( موقع ترجمة Google ) ، تحصل على السلسلة النهائية المترجمة:

تكمن المشكلة في أنه من المرجح أن تتعرض لحد من المعدل أكثر من ذلك عبر te_lib (للمقارنة: مع تطبيق الويب يتم الوصول إلى هذا بعد 40000 حرف ، مع te_lib لا يوجد حد للمعدل). لذلك نحن بحاجة إلى إلقاء نظرة فاحصة على كيفية تحليل Chrome للنتيجة. سنجده هنا في element_main.js:

b7739bf50b2edcf636c43a8f8910def9

إذا قمت بإرسال كود HTML بأكمله إلى API ، فإنه يترك السمات في الاستجابة المترجمة. لذلك لا يتعين علينا تقليد سلوك التحليل بأكمله ، ولكن فقط استخراج الجملة النهائية المترجمة من الاستجابة. للقيام بذلك ، قمنا بإنشاء محلل صغير لعلامات HTML يتجاهل العلامات <i> الخارجية بما في ذلك محتواها ويزيل العلامات <b> الخارجية. مع وضع ذلك في الاعتبار ، يمكننا الآن إنشاء إصدار من جانب الخادم من واجهة برمجة تطبيقات الترجمة:

b7739bf50b2edcf636c43a8f8910def9

فيما يلي نتائج اختبار أولي تم إجراؤه على خمسة أنظمة مختلفة ذات نطاقات ترددية وعناوين IP مختلفة:

حرفأحرف لكل طلبالمدة الزمنيةنسبة الخطأالتكلفة عبر API الرسمية
13.064.662~25003: 36: 17 ساعة0%237,78€
24.530.510~25011:09:130%446,46€
49.060.211~25020: 39: 10 ساعات0%892,90€
99.074.487~100061:24: 37 ساعة0%1803,16€
99.072.896~100062:22: 20 ساعة0%1803,13€
284.802.766~ قطر 550Σ159: 11: 37 ساعة0%Σ 5183.41 يورو

ملاحظة: تم كتابة منشور المدونة هذا الذي يتضمن جميع البرامج النصية لأغراض الاختبار فقط. لا تستخدم البرامج النصية لاستخدامها في الإنتاج، بدلا من ذلك العمل مع الرسمي API ترجمة جوجل .

عودة