Google-vertaal-API Hacking

Als onderdeel van de Google Cloud biedt Google de Google Translation API met een op gebruik gebaseerde kostenstructuur . Er is ook een niet- gedocumenteerde API die zonder sleutel kan worden gebruikt, maar die weigert te werken na slechts een paar verzoeken. Bij gebruik van de websitevertaalfunctie van Google Chrome valt op dat pagina's zonder merkbare beperking in zeer goede kwaliteit kunnen worden vertaald.


Blijkbaar wordt hier al gebruik gemaakt van het geavanceerde NMT-model . Maar welke API gebruikt Google Chrome intern om de content te vertalen en kan deze API ook direct worden aangesproken - ook aan de serverkant? Om netwerkverkeer te analyseren, worden tools zoals Wireshark of Telerik Fiddler , die ook versleuteld verkeer kunnen analyseren, aanbevolen. Maar Chrome levert zelfs de verzoeken die het verzendt voor de vertaling van de pagina gratis: ze kunnen eenvoudig worden bekeken met de Chrome DevTools:

Als u een vertaling uitvoert, vang dan het cruciale POST-verzoek naar https://translate.googleapis.com via "Kopiëren> Kopiëren als cURL (bash)" en voer het uit in een tool als Postman , u kunt het verzoek bijvoorbeeld zonder problemen opnieuw verzenden:

De betekenis van de URL-parameters is ook grotendeels duidelijk:

SleutelVoorbeeldwaardeBetekenis
anno3Annotatiemodus (beïnvloedt het retourformaat)
cliëntte_libKlantinformatie (varieert, de waarde is 'webapp' via de webinterface van Google Translate; heeft een effect op het retourformaat en snelheidsbeperking)
formaathtmlTekenreeksformaat (belangrijk voor het vertalen van HTML-tags)
v1.0Versienummer van Google Translate
sleutelAIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgwAPI-sleutel (zie hieronder)
logldvTE_20200210_00Protocolversie
sldeBrontaal
tlnlDoel taal
spnmtML-model
tc1onbekend
sr1onbekend
tk709408.812158Token (zie hieronder)
Mode1onbekend

Sommige verzoekheaders zijn ook ingesteld, maar deze kunnen meestal worden genegeerd. Na het handmatig deselecteren van alle headers, inclusief die van de user-agent , wordt een coderingsprobleem ontdekt bij het invoeren van speciale tekens (hier bij het vertalen van " Hallo wereld "):

Als je de user-agent opnieuw activeert (dat kan over het algemeen geen kwaad), levert de API UTF-8-gecodeerde tekens:

Zijn we er al en hebben we alle informatie om deze API buiten Google Chrome te gebruiken? Als u de te vertalen tekenreeks (gegevensveld q van het POST-verzoek) wijzigt van bijvoorbeeld "Hallo wereld" naar "Hallo wereld ! “, We krijgen een foutmelding:

We vertalen deze gewijzigde nu opnieuw in Google Chrome met behulp van de vertaalfunctie van de website en stellen vast dat, naast de parameter q , ook de parameter tk is veranderd (alle andere parameters zijn hetzelfde gebleven):

Blijkbaar is het een token die afhankelijk is van de string, waarvan de structuur niet gemakkelijk te zien is. Wanneer u de websitevertaling start, worden de volgende bestanden geladen:

  • 1 CSS-bestand: translateelement.css
  • 4 afbeeldingen: translate_24dp.png (2x), gen204 (2x)
  • 2 JS-bestanden: main_de.js , element_main.js

De twee JavaScript-bestanden zijn versluierd en verkleind. Tools zoals JS Nice en de4js helpen ons nu om deze bestanden leesbaarder te maken. Om ze live te debuggen, raden we de Chrome Extension Requestly aan, die externe bestanden direct lokaal tunnelt:

Nu kunnen we de code debuggen ( CORS moet eerst op de lokale server worden geactiveerd). De relevante codesectie voor het genereren van het token lijkt verborgen te zijn in deze sectie in het bestand element_main.js:

b7739bf50b2edcf636c43a8f8910def9

Hier wordt de tekst gehasht met behulp van enkele bitverschuivingen . Maar helaas missen we nog een stukje van de puzzel: naast het argument a (dat is de te vertalen tekst) wordt een ander argument b doorgegeven aan de functie Bp () - een soort zaadje dat van tijd tot tijd lijkt te veranderen en dat ook omvat stroomt in hashing. Maar waar komt hij vandaan? Als we naar de functieaanroep van Bp () springen, vinden we de volgende codesectie:

b7739bf50b2edcf636c43a8f8910def9

De functie Hq wordt vooraf als volgt gedeclareerd:

b7739bf50b2edcf636c43a8f8910def9

Hier liet de Deobfuscater wat rotzooi achter; Nadat we String.fromCharCode ('...') hebben vervangen door de respectievelijke tekenreeksen, verwijder de verouderde a () en voeg de functieaanroepen [c (), c ()] samen , het resultaat is:

b7739bf50b2edcf636c43a8f8910def9

Of nog makkelijker:

b7739bf50b2edcf636c43a8f8910def9

De functie yq is eerder gedefinieerd als:

b7739bf50b2edcf636c43a8f8910def9

De seed lijkt te zitten in het globale object google.translate._const._ctkk , dat beschikbaar is tijdens runtime. Maar waar staat het? In het andere, eerder geladen JS-bestand main_de.js, is het tenminste ook aan het begin beschikbaar. Aan het begin voegen we het volgende toe:

b7739bf50b2edcf636c43a8f8910def9

In de console krijgen we eigenlijk het huidige zaad:

Hierdoor blijft Google Chrome zelf, dat blijkbaar voor het zaad zorgt, als laatste optie. Gelukkig is de broncode (Chromium, inclusief de Translate-component) open source en daarom publiekelijk beschikbaar. We halen de repository lokaal op en vinden de aanroep van de functie TranslateScript :: GetTranslateScriptURL in het bestand translate_script.cc in de map components / translate / core / browser:

b7739bf50b2edcf636c43a8f8910def9

De variabele met de URL is vast gedefinieerd in hetzelfde bestand:

b7739bf50b2edcf636c43a8f8910def9

Als we nu het bestand element.js nauwkeuriger bekijken (na opnieuw verduidelijken), vinden we de hard-set entry c._ctkk - het google.translate- object wordt ook dienovereenkomstig ingesteld en het laden van alle relevante items (die we al eerder hebben ontdekt) wordt geactiveerd:

b7739bf50b2edcf636c43a8f8910def9

Nu is de parameter sleutel blijft voor de behandeling (met de waarde AIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgw). Dat lijkt een generieke browser API-sleutel te zijn (die ook in sommige Google-resultaten te vinden is ). Het is ingesteld in Chromium in het bestand translate_url_util.cc in de map componenten / translate / core / browser:

b7739bf50b2edcf636c43a8f8910def9

De sleutel wordt gegenereerd in google_apis / google_api_keys.cc op basis van een dummy-waarde:

b7739bf50b2edcf636c43a8f8910def9

Een test toont echter aan dat de API-aanroepen hetzelfde werken zonder deze sleutelparameter. Als je experimenteert met de API, krijg je de statuscode 200 terug als je succesvol bent. Als je dan tegen een limiet aanloopt, krijg je de statuscode 411 terug met de melding " POST-verzoeken vereisen een inhoudslengte header ". Het is daarom aan te raden om deze header (die in Postman automatisch als tijdelijke header wordt ingesteld) op te nemen.

Het retourformaat van de vertaalde strings is ongebruikelijk als er meerdere zinnen in één verzoek staan. De afzonderlijke zinnen worden omsloten door de i- / b-HTML-tags:

Google Chrome stuurt ook niet de volledige HTML naar de API, maar slaat attribuutwaarden zoals href op in het verzoek (en stelt in plaats daarvan indices in zodat de tags later aan de clientzijde kunnen worden toegewezen):

Als u de waarde van de POST key client te veranderen van te_lib (Google Chrome) op webapp ( Google Translation-website ), krijg je de laatste vertaalde string:

Het probleem is dat je veel meer kans loopt om snelheidsbeperking tegen te komen dan via te_lib (ter vergelijking: bij webapp wordt dit bereikt na 40.000 tekens, bij te_lib is er geen snelheidsbeperking). We moeten dus nader bekijken hoe Chrome het resultaat parseert. We vinden het hier in element_main.js:

b7739bf50b2edcf636c43a8f8910def9

Als u de volledige HTML-code naar de API stuurt, laat deze de attributen achter in het vertaalde antwoord. We hoeven dus niet het volledige ontleedgedrag te imiteren, maar halen alleen de uiteindelijke, vertaalde string uit het antwoord. Om dit te doen, bouwen we een kleine HTML-tag-parser die de buitenste <i> -tags verwijdert, inclusief hun inhoud, en de buitenste <b> -tags verwijdert. Met dit in gedachten kunnen we nu een serverversie van de vertaal-API bouwen:

b7739bf50b2edcf636c43a8f8910def9

Hieronder volgen de resultaten van een eerste test die is uitgevoerd op vijf verschillende systemen met verschillende bandbreedtes en IP-adressen:

KarakterTekens per verzoekLooptijdFoutenpercentageKosten via officiële API
13.064.662~25003: 36: 17 uur0%237,78€
24.530.510~25011: 09: 13 uur0%446,46€
49.060.211~25020: 39: 10 uur0%892,90€
99.074.487~100061: 24: 37 uur0%1803,16€
99.072.896~100062: 22: 20 uur0%1803,13€
Σ284,802,766~ Ø550Σ159: 11:37 uur0%Σ € 5183,41

Opmerking: deze blogpost inclusief alle scripts is alleen voor testdoeleinden geschreven. Laat de scripts voor productief gebruik niet gebruiken, in plaats daarvan te werken met de officiële Google-vertaling API .

Terug