Hva er hjernen til en student som lærer om dataverdenen i stand til?

God dag.

Etter å ha skrevet ferdig et annet manus i Bash, innså jeg at alt burde være helt annerledes, men alt fungerte. Jeg vil vise deg hvilke uanstendigheter og krykker jeg skrev for å løse problemet, men jeg har ennå ikke en vogn med kunnskap. Med andre ord en karikatur av programmering.

Oppgave


Noe ble nødvendig for å:

  • Viste mange rim for ordet, bortsett fra firkanter
  • Krysset de mange rimene til to ord

For hva? Vel, det er det – og det er det.
Hvem vet ikke, et firkantet rim (i vanlig språkbruk - en firkant) er to ord hvis to siste bokstaver i stavemåten faller sammen, noe som (ofte er dette det eneste) gjør dem til et rim. For eksempel er roser frostige; dekk - bil. Bruken av firkanter i moderne versifikasjon er ikke spesielt godkjent av folk, på grunn av deres primitivitet.

beslutning


Det virket for meg som om den enkleste løsningen var å skrive et skript i Bash som bruker en allerede eksisterende rimgenerator - HOST, som først og fremst velger dem etter konsonans, og ikke ved stavemåte. Hva slags VERT? For hvis du angir det virkelige navnet på nettstedet, vil de si at det er en annonse. Hvorfor ikke fortsette å bruke det? For det første, til tross for fordelen ved å velge rim basert på konsonanser, produserer han fortsatt ofte firkanter. For det andre må du fortsatt tenke med hjernen, bruke tid på å bytte mellom faner og energi på å huske gjentatte ord i lister for å finne et rim på to ord.

Får sterke rim

Hva vet jeg? Jeg vet om verktøyet wget, som laster ned siden på den angitte URL-adressen. Ok, la oss utføre forespørselen - vi får en HTML-side i en fil som heter et ord som rimer. La oss for eksempel søke etter ordet "her":

wget https://HOST/rifma/здесь

Men jeg trenger bare en liste med ord, hvordan kan jeg bli kvitt alt annet? Vi ser og ser at listen over ord er formatert, uansett hvor merkelig den måtte være, i form av en liste, og ordene er i tagger . Vel, vi har en stor nytte. tørste - la oss skrive det ned slik:

cat $word | grep '<li>' | sed -e "s%<li>%%" | sed -e "s%</li>%%" | sed -e "s/ //g" | sed -e "/^$/d" 1> $word

Først, fra word-filen, velg linjene som inneholder taggen — vi får en haug med tomme tagger og linjer med ord. Vi fjerner selve taggen og dens avsluttende - her brukes prosentsymboler i stedet for skråstreker fordi i selve taggen det er allerede en skråstrek, hvorfor? tørste forstår deg ikke litt. Og alt er bra med renter. Vi fjerner alle mellomrom fra filen, fjerner tomme linjer. Voila - en ferdig liste med ord.

For å fjerne ord som rimer med de siste bokstavene, velg de to siste bokstavene fra det opprinnelige ordet og tøm listen:

squad=${word:((${#word}-2)):2}
cat $word | sed -e "/.$squad$/d" 1> $word

Vi ser, vi prøver - alt fungerer ... så hvor er listen for ordet "lek"? Og for ordet "jeg skal"? Filen er tom! Og dette er alt fordi disse ordene er verb, og vi vet hva de gjør med de som rimer på verb. Verbrim er verre enn til og med firkantrim, fordi det russiske språket har flest verb, og alle har de samme endelsene, og derfor var de ikke i den endelige filen etter å ha sjekket endelsene.

Vi har imidlertid ikke hastverk. For hvert ord er det ikke bare rim, men også assonanser, som noen ganger høres mye bedre ut enn rim - det er derfor de er assonanser (fransk assonans, fra latin assono - jeg høres i harmoni).

Vi får assonanser

Det er her moroa begynner: assonanser vises på en egen URL, og på samme side, ved å kjøre et skript, sende en HTTP-forespørsel og motta et svar. Hvordan kan jeg si wget«Trykker du på knappen? Men ingen måte. Dessverre.

Da jeg la merke til at URL-en i linjen på en eller annen måte endret seg, kopierte jeg det som var der etter å ha byttet til assonanser og limte det inn i en ny nettleserfane – sterke rim åpnet seg. Ikke det.

I hovedsak, tenkte jeg, burde det ikke spille noen rolle for serveren om skriptet som sender forespørselen blir utført, eller om personen skriver det for hånd. Så? Hvem vet, la oss sjekke det ut.

Hvor skal jeg sende? Hva skal jeg sende? HTTP-forespørsel til server-IP, det er noe som GET... så er det noe HTTP/1.1... Vi må se hva nettleseren sender og hvor. Installere Wireshark, se på trafikken:

0040 37 5d a3 84 27 e7 fb 13 6d 93 ed cd 56 04 9d 82 7]£.'çû.m.íÍV...
0050 32 7c fb 67 46 71 dd 36 4d 42 3d f3 62 1b e0 ad 2|ûgFqÝ6MB=ób.à.
0060 ef 87 be 05 6a f9 e1 01 41 fc 25 5b c0 77 d3 94 ï.¾.jùá.Aü%[ÀwÓ.

Um... hva? Å ja, vi har HTTPS. Hva å gjøre? Lansere et MITM-angrep på deg selv? Ideelt sett vil offeret selv hjelpe oss.

Generelt, etter å ha bestemt meg for å surfe i nettleseren, fant jeg endelig selve forespørselen og adressaten. Gå:

Dialog med terminalen

telnet IP PORT
Trying IP...
Connected to IP.
Escape character is '^]'.
GET /rifma/%D0%BC%D0%B0%D1%82%D1%8C?mode=block&type=asn HTTP/1.1
Host: HOST
Accept-Language: en-US,en;q=0.5
X-Requested-With: XMLHttpRequest
Connection: close

HTTP/1.1 400 Bad Request
Server: nginx/1.8.0
Date: Sun, 03 Nov 2019 20:06:59 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 270
Connection: close

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.8.0</center>
</body>
</html>
Connection closed by foreign host.

Hei. Hehehe. Det var faktisk det jeg forventet når jeg sendte en bare HTTP-forespørsel til en HTTPS-port. Bør vi kryptere nå? Alt dette oppstyret med RSA-nøkler, så med SHA256. Hvorfor, det er det OpenSSL for slike ting. Vel, vi vet allerede hva vi skal gjøre, vi vil bare fjerne Referer- og Cookie-feltene først - jeg tror de ikke vil påvirke saken mye:

Dialog med terminalen

openssl s_client -connect IP:PORT
{Всякие ключи, сертификаты}
GET /rifma/%D0%B7%D0%B4%D0%B5%D1%81%D1%8C?mode=block&type=asn HTTP/1.1
Host: HOST
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0
Accept: text/javascript,text/html,application/xml,text/xml,*/*
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Status: 200 OK
Date: Sun, 03 Nov 2019 20:34:33 GMT
Set-Cookie: COOKIE
X-Powered-By: Phusion Passenger 5.0.16
Server: nginx/1.8.0 + Phusion Passenger 5.0.16
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Cache-Control: no-cache
Strict-Transport-Security: max-age=31536000
Content-Security-Policy: block-all-mixed-content
Content-Encoding: gzip

Hva er hjernen til en student som lærer om dataverdenen i stand til?

Hva er dette, banning på serveren? Vel, de svarte meg i det minste 200 OK, noe som betyr at informasjonskapsler og henvisningen ikke påvirker noe. Komprimering er gzip, men ved kopiering kopieres ASCII-tegn. Nøyaktig, du kan fjerne linjen Godta-koding. Alt er bra - vi får et HTML-dokument, nå med assonanser. Men her er to spørsmål: hvordan kjører jeg OpenSSL og overfører data til det ved hjelp av et skript? Og hvordan lese utdataene hvis vi etter å ha mottatt svaret forblir, som det var, i et OpenSSL "skall"? Hvis du kan finne på noe med den andre, men med den første...

Det er bra at det er det Habrhvor jeg leste om verktøyet forvente, som automatiserer prosessen med å samhandle med programmer som forventer menneskelig interaksjon. Å ha et lag er enda mer attraktivt autoforvent, genererer forvente skript basert på handlingene dine. Vel, vi lanserer det, gjør alt dette og her er det ferdige manuset. Bare han er veldig stor, og alt fordi OpenSSL viser sertifikater, nøkler og forvente venter på resultatet av alt dette. Trenger vi dette? Nei. Vi fjerner hele den første ledeteksten, og lar bare det siste linjeskiftet "r" være igjen. Vi fjerner også feltene User-Agent og Accept fra forespørselen vår – de påvirker ingenting. Så, la oss starte. Skriptet ble utført, men hvor er det dyrebare HTML-dokumentet? Forvent spiste det. For å få ham til å spytte det ut, må du sette inn:

set results $expect_out(buffer)

før slutten av skriptet - dette er hvordan utdataene til den kjørbare vil bli skrevet forvente'om kommandoen og vises på skjermen. Oppsummert, noe sånt som dette:

forventer et manus

#!/usr/bin/expect -f

set timeout -1
spawn openssl s_client -connect IP:PORT
match_max 100000
expect -exact "
---r
"
send -- "GET /rifma/%d0%b7%d0%b4%d0%b5%d1%81%d1%8c?mode=block&type=asn HTTP/1.1rHost: HOSTrAccept-Language: en-US,en;q=0.5rX-Requested-With: XMLHttpRequestrConnection: close"
expect -exact "GET /rifma/%d0%b7%d0%b4%d0%b5%d1%81%d1%8c?mode=block&type=asn HTTP/1.1r
Host: HOSTr
Accept-Language: en-US,en;q=0.5r
X-Requested-With: XMLHttpRequestr
Connection: close"
send -- "r"
set results $expect_out(buffer)
expect -exact "r
"
send -- "r"
expect eof

Men det er ikke alt! Som du kan se var forespørsels-URLen statisk i alle eksemplene, men det er URL-en som er ansvarlig for hvilket ord som vil bli assosiert med assonanser. Og så viser det seg at vi hele tiden vil søke etter ordet "%d0%b7%d0%b4%d0%b5%d1%81%d1%8c" i ASCII eller "her" i UTF-8. Hva å gjøre? Selvfølgelig, bare generer et nytt skript hver gang, venner! Ikke nå lenger autoforvent'å, og med hjelpen savner, fordi I vår nye endres ingenting bortsett fra ordet. Og lenge leve det nye problemet: hvordan kan vi intelligent oversette et ord fra kyrillisk til URL-format? Det er ikke noe spesielt for terminalen heller. Vel, det er greit, vi kan gjøre det, ikke sant? Kan:

Se hva jeg kan gjøre!

function furl {
furl=$(echo "$word" | sed 's:А:%d0%90:g;s:Б:%d0%91:g;s:В:%d0%92:g;s:Г:%d0%93:g;s:Д:%d0%94:g;s:Е:%d0%95:g;s:Ж:%d0%96:g;s:З:%d0%97:g;s:И:%d0%98:g;s:Й:%d0%99:g;s:К:%d0%9a:g;s:Л:%d0%9b:g;s:М:%d0%9c:g;s:Н:%d0%9d:g;s:О:%d0%9e:g;s:П:%d0%9f:g;s:Р:%d0%a0:g;s:С:%d0%a1:g;s:Т:%d0%a2:g;s:У:%d0%a3:g;s:Ф:%d0%a4:g;s:Х:%d0%a5:g;s:Ц:%d0%a6:g;s:Ч:%d0%a7:g;s:Ш:%d0%a8:g;s:Щ:%d0%a9:g;s:Ъ:%d0%aa:g;s:Ы:%d0%ab:g;s:Ь:%d0%ac:g;s:Э:%d0%ad:g;s:Ю:%d0%ae:g;s:Я:%d0%af:g;s:а:%d0%b0:g;s:б:%d0%b1:g;s:в:%d0%b2:g;s:г:%d0%b3:g;s:д:%d0%b4:g;s:е:%d0%b5:g;s:ж:%d0%b6:g;s:з:%d0%b7:g;s:и:%d0%b8:g;s:й:%d0%b9:g;s:к:%d0%ba:g;s:л:%d0%bb:g;s:м:%d0%bc:g;s:н:%d0%bd:g;s:о:%d0%be:g;s:п:%d0%bf:g;s:р:%d1%80:g;s:с:%d1%81:g;s:т:%d1%82:g;s:у:%d1%83:g;s:ф:%d1%84:g;s:х:%d1%85:g;s:ц:%d1%86:g;s:ч:%d1%87:g;s:ш:%d1%88:g;s:щ:%d1%89:g;s:ъ:%d1%8a:g;s:ы:%d1%8b:g;s:ь:%d1%8c:g;s:э:%d1%8d:g;s:ю:%d1%8e:g;s:я:%d1%8f:g;s:ё:%d1%91:g;s:Ё:%d0%81:g')}

Totalt har vi et skript som konverterer et ord til ASCII-tekst, og genererer et annet skript som ber om en side med assonanser fra serveren via OpenSSL. Og så omdirigerer vi utdataene fra det siste skriptet til en fil og sender det gjennom på gammeldags måte "filtre" ekstra firkanter og skriv dem til filen.

Kryss av mange. Bunnlinjen

Det er faktisk nettopp dette som gir minst problemer. Vi utfører prosedyrene ovenfor for to ord, fra de to listene sammenligner vi hvert ord med hvert ord, og hvis det blir funnet et samsvar, sender vi det ut. Nå har vi et skript som tar to ord som input og viser en liste over ord som rimer på begge, og til og med tar hensyn til assonanser, og alt dette uten å manuelt bytte mellom fire tabulatorer og huske ord "med øyet" - alt samlet, tatt med i betraktning for og forkastet automatisk. Herlig.

Hensikten med denne publikasjonen var å vise at hvis en person trenger noe, vil han gjøre det uansett. Veldig ineffektivt, skjevt, skummelt, men det vil fungere.

Kilde: www.habr.com

Legg til en kommentar