Google Translation API Hacking

A Google felhasználásalapú költségstruktúrával kínálja a Google Translation API -t a Google Cloud részeként. Van olyan dokumentálatlan API is , amely kulcs nélkül használható, de néhány kérés után nem hajlandó működni. A Google Chrome webhelyfordítási funkciójának használatakor észrevehető, hogy az oldalakat nagyon jó minőségben, észrevehető korlátozás nélkül lehet lefordítani.


Nyilván itt alkalmazzák a fejlett nmt modellt . De melyik API-t használja a Google Chrome belsőleg a tartalom fordításához, és ezt az API-t is meg lehet-e címezni közvetlenül - még a szerver oldalon is? A hálózati forgalom elemzéséhez olyan eszközök ajánlottak , mint a Wireshark vagy a Telerik Fiddler , amelyek szintén elemezhetik a titkosított forgalmat. De a Chrome még ingyen is elküldi az oldalfordításra küldött kéréseket : A Chrome DevTools segítségével egyszerűen megtekinthetők:

Ha lefordít, akkor elkapja a kulcsfontosságú POST kérést, hogy https://translate.googleapis.com a "Másolás> Másolás cURL-ként (bash)" oldalon keresztül hajtsa végre, és például egy olyan eszközben hajtsa végre, mint például a Postman , problémamentesen elküldheti a kérést:

Az URL-paraméterek jelentése szintén nagyrészt nyilvánvaló:

KulcsPélda értékreJelentése
anno3Megjegyzés mód (befolyásolja a visszatérési formátumot)
ügyfélte_libÜgyfélinformációk (változó, az érték "webapp" a Google Fordító webes felületén keresztül; hatással van a visszatérési formátumra és az árkorlátozásra)
formátumhtmlKarakterlánc formátum (fontos a HTML-címkék fordításához)
v1.0A Google Fordító verziószáma
kulcsAIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgwAPI-kulcs (lásd alább)
logldvTE_20200210_00Protokoll verzió
sldeForrás nyelv
tlhuCélnyelven
spnmtML modell
tc1ismeretlen
sr1ismeretlen
tk709408.812158Token (lásd alább)
Divat1ismeretlen

Néhány kérés fejléc is be van állítva - de ezeket többnyire figyelmen kívül lehet hagyni. Miután az összes fejlécet manuálisan törölte, beleértve a felhasználói ügynököt is , kódolási probléma merül fel a speciális karakterek beírásakor (itt a " Hello World " fordításakor):

Ha újraaktiválja a felhasználói ügynököt (amely általában nem árt), az API UTF-8 kódolású karaktereket küld:

Már ott vagyunk, és minden információval rendelkezünk ahhoz, hogy ezt az API-t a Google Chrome-on kívül használhassuk? Ha a lefordítandó karakterláncot (a POST kérés q adatmezője) megváltoztatja például a „Hello world” -ről a „Hello world ! “, Hibaüzenetet kapunk:

Ezt a módosítottat most újra lefordítjuk a Google Chrome-ban a weboldal fordító funkció segítségével, és megállapítjuk, hogy a q paraméter mellett a tk paraméter is megváltozott (az összes többi paraméter változatlan maradt):

Nyilvánvaló, hogy ez egy olyan karakter, amely függ a karakterlánctól, amelynek felépítése nem könnyen látható. A webhelyfordítás elindításakor a következő fájlok töltődnek be:

  • 1 CSS fájl: translateelement.css
  • 4 grafika: translate_24dp.png (2x), gen204 (2x)
  • 2. JS fájlok: main_de.js, element_main.js

A két JavaScript-fájl homályos és tömörített. Az olyan eszközök, mint a JS Nice és a de4js , most segítenek nekünk abban, hogy ezeket a fájlokat olvashatóbbá tegyük. Az élő hibakereséshez javasoljuk a Chrome Extension Requestly alkalmazást, amely menet közben a távoli fájlokat helyben alagutazza:

Most hibakereshetjük a kódot (a CORS- t először a helyi szerveren kell aktiválni). Úgy tűnik, hogy a token előállításához szükséges kódrész el van rejtve ebben a szakaszban az element_main.js fájlban:

b7739bf50b2edcf636c43a8f8910def9

Itt a szöveget néhány biteltolás segítségével kivonatolják. De sajnos még mindig hiányzik egy darab a puzzle: Amellett, hogy az érv olyan (ami a fordítandó szöveg), egy másik érv b jut el a funkció Bp () - egyfajta mag, amely úgy tűnik, hogy változik időről időre, és amely magában foglalja hashba folyik. De honnan származik? Ha a Bp () függvényhívására ugrunk , akkor a következő kódrészletet találjuk meg:

b7739bf50b2edcf636c43a8f8910def9

A Hq függvényt előzetesen a következőképpen deklaráljuk:

b7739bf50b2edcf636c43a8f8910def9

Itt a Deobfuscater hagyott némi szemetet; Miután lecseréltük a String.fromCharCode ('...') karaktert a megfelelő karakterláncokra, távolítsuk el az elavult a () -t, és daraboljuk össze a [c (), c ()] függvényhívásokat, az eredmény:

b7739bf50b2edcf636c43a8f8910def9

Vagy még könnyebb:

b7739bf50b2edcf636c43a8f8910def9

Az yq függvényt korábban úgy definiáltuk:

b7739bf50b2edcf636c43a8f8910def9

A mag úgy tűnik, hogy a futás közben elérhető google.translate._const._ctkk globális objektumban található. De hol van beállítva? A másik, korábban betöltött main_de.js JS fájlban legalább az elején elérhető. Az elején hozzáadjuk a következőket:

b7739bf50b2edcf636c43a8f8910def9

A konzolban valóban megkapjuk az aktuális magot:

Ez maga a Google Chrome, amely nyilvánvalóan a magot biztosítja, az utolsó lehetőség. Szerencsére a forráskódja (Chromium, a Translate komponenssel együtt) nyílt forráskódú, ezért nyilvánosan elérhető. Helyileg húzzuk meg a lerakatot , és megtaláljuk a TranslateScript :: GetTranslateScriptURL függvény hívását a translate_script.cc fájlban a components / translate / core / browser böngészőben.:

b7739bf50b2edcf636c43a8f8910def9

Az URL-t tartalmazó változó ugyanabban a fájlban keményen definiálható:

b7739bf50b2edcf636c43a8f8910def9

Ha most alaposabban megvizsgáljuk az element.js fájlt (az újbóli eltávolítás után), akkor megtaláljuk a keményen beállított c._ctkk bejegyzést - a google.translate objektum is ennek megfelelően van beállítva, és az összes releváns eszköz betöltése (amelyet már korábban felfedeztünk) elindul:

b7739bf50b2edcf636c43a8f8910def9

Most a paraméter gomb továbbra is megfontolásra (az érték AIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgw). Úgy tűnik, hogy ez egy általános böngésző API-kulcs (amely megtalálható a Google egyes eredményeiben is ). A Chromiumban van megadva a translate_url_util.cc fájlban a / translate / core / browser böngészőben.:

b7739bf50b2edcf636c43a8f8910def9

A kulcs a google_apis / google_api_keys.cc fájlban generálódik egy dummy értékből:

b7739bf50b2edcf636c43a8f8910def9

Egy teszt azonban azt mutatja, hogy az API hívások ugyanúgy működnek e kulcsparaméter nélkül. Ha kísérletet tesz az API-val, akkor sikeresen visszakapja a 200- as állapotkódot. Ha ezután belefut egy korlátba, akkor visszakapja a 411-es állapotkódot azzal az üzenettel, hogy "A POST-kérések tartalmi hosszúságú fejlécet igényelnek ". Ezért ajánlatos felvenni ezt a fejlécet (amelyet a Postman automatikusan ideiglenes fejlécként állít be).

A lefordított karakterláncok visszatérési formátuma szokatlan, ha egy kérésben több mondat van. Az egyes mondatokat az i- / b-HTML címkék határolják:

Ezenkívül a Google Chrome nem küldi el a teljes HTML-t az API-nak, hanem az attribútumértékeket, például a href-et elmenti a kérésbe (ehelyett indexeket állít be, hogy a címkék később az ügyfél oldalán hozzárendelhetők legyenek):

Ha a POST kulcs kliens értékét megváltoztatja te_lib értékről (Google Chrome) a webappon (a Google Fordítás webhelyén ) megkapja az utolsó lefordított karakterláncot:

A probléma az, hogy sokkal nagyobb eséllyel ütközik be a sebességkorlátozásba, mint a te_lib segítségével (összehasonlításképpen: a webapp alkalmazással ez 40 000 karakter után érhető el, a te_lib esetében nincs sebességkorlátozás). Ezért közelebbről meg kell vizsgálnunk, hogy a Chrome hogyan elemzi az eredményt. Megtaláljuk itt az element_main.js fájlban:

b7739bf50b2edcf636c43a8f8910def9

Ha a teljes HTML-kódot elküldi az API-nak, akkor az az attribútumokat a lefordított válaszban hagyja. Ezért nem kell a teljes elemzési viselkedést utánozni, csak a végleges, lefordított karakterláncot kell kivonni a válaszból. Ehhez építünk egy kis HTML-tag elemzőt, amely elveti a legkülső <i> címkéket, beleértve azok tartalmát, és eltávolítja a legkülső <b> címkéket. Ezt szem előtt tartva most elkészíthetjük a fordítási API szerveroldali változatát:

b7739bf50b2edcf636c43a8f8910def9

Az alábbiakban bemutatjuk az első teszt eredményeit, amelyet öt különböző rendszeren hajtottak végre, különböző sávszélességgel és IP címmel:

KarakterKarakterek kérésenkéntIdőtartamHibaarányKöltség a hivatalos API-n keresztül
13.064.662~25003: 36: 17h0%237,78€
24.530.510~25011: 09: 13h0%446,46€
49.060.211~25020: 39: 10h0%892,90€
99.074.487~100061: 24: 37h0%1803,16€
99.072.896~100062: 22: 20h0%1803,13€
Σ284.802.766~ Ø550159: 11: 37h0%5 5183,41 €

Megjegyzés: Ez az összes szkriptet tartalmazó blogbejegyzés csak tesztelési célokra készült. Ne használja a szkriptek termelési célra, hanem dolgozni a hivatalos Google Translation API .

Vissza