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ó:
| Kulcs | Példa értékre | Jelentése |
| anno | 3 | Megjegyzés mód (befolyásolja a visszatérési formátumot) |
| ügyfél | te_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átum | html | Karakterlánc formátum (fontos a HTML-címkék fordításához) |
| v | 1.0 | A Google Fordító verziószáma |
| kulcs | AIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgw | API-kulcs (lásd alább) |
| logld | vTE_20200210_00 | Protokoll verzió |
| sl | de | Forrás nyelv |
| tl | hu | Célnyelven |
| sp | nmt | ML modell |
| tc | 1 | ismeretlen |
| sr | 1 | ismeretlen |
| tk | 709408.812158 | Token (lásd alább) |
| Divat | 1 | ismeretlen |
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 attribútumokat a lefordított válaszban hagyja. Ezért nem kell a teljes elemzési viselkedést utánoznunk, hanem csak a végső, lefordított karakterláncot kell kivonnunk a válaszból. Ehhez egy kis HTML címkeelemzőt építünk, 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. Ezzel a tudással most már (a függőségek telepítése után a composer szükséges fzaninotto / faker vielhuber / stringhelper segítségével ) elkészíthetjük a fordítási API szerveroldali verziójá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:
| Karakter | Karakterek kérésenként | Időtartam | Hibaarány | Költség a hivatalos API-n keresztül |
| 13.064.662 | ~250 | 03: 36: 17h | 0% | 237,78€ |
| 24.530.510 | ~250 | 11: 09: 13h | 0% | 446,46€ |
| 49.060.211 | ~250 | 20: 39: 10h | 0% | 892,90€ |
| 99.074.487 | ~1000 | 61: 24: 37h | 0% | 1803,16€ |
| 99.072.896 | ~1000 | 62: 22: 20h | 0% | 1803,13€ |
| Σ284.802.766 | ~ Ø550 | 159: 11: 37h | 0% | 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 .