Goddag.

Da jeg var færdig med at skrive endnu et manuskript i Bash, indså jeg, at alt burde være helt anderledes, men alt fungerede. Jeg vil gerne vise dig, hvilke uanstændigheder og krykker jeg skrev for at løse problemet, men jeg har endnu ikke en vogn af viden. Med andre ord en karikatur af programmering.

Opgave

Noget blev nødvendigt for at:

• Viste mange rim for ordet, undtagen firkanter
• Krydsede de mange rim af to ord

For hvad? Nå, det er det – og det er det.
Hvem ved ikke, et firkantet rim (i almindeligt sprog - en firkant) er to ord, hvis sidste to bogstaver i stavemåden falder sammen, hvilket (ofte er dette det eneste) gør dem til et rim. For eksempel er roser frostklare; dæk - bil. Brugen af ​​firkanter i moderne versifikation er ikke særlig godkendt af mennesker på grund af deres primitivitet.

beslutning

Det forekom mig, at den enkleste løsning var at skrive et script i Bash, der bruger en allerede eksisterende rimgenerator - HOST, som primært udvælger dem efter konsonans og ikke ved stavemåde. Hvilken slags VÆRT? For hvis du angiver sidens rigtige navn, vil de sige, at det er en annonce. Hvorfor ikke fortsætte med at bruge det? For det første, på trods af hans fordel ved at vælge rim baseret på konsonanser, producerer han stadig ofte firkanter. For det andet skal du stadig tænke med din hjerne, bruge tid på at skifte mellem faner og energi på at huske gentagne ord på lister for at finde et rim på to ord.

At få stærke rim

Hvad ved jeg? Jeg kender til værktøjet wget, som downloader siden på den angivne URL. Okay, lad os udføre anmodningen - vi får en HTML-side i en fil, der er navngivet med et rimende ord. Lad os for eksempel søge efter ordet "her":

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

Men jeg mangler kun en liste med ord, hvordan kan jeg slippe af med alt det andet? Vi kigger og ser, at listen med ord er formateret, uanset hvor mærkelig den måtte være, i form af en liste, og ordene er i tags . Nå, vi har en stor nytte. sed - lad os skrive det ned sådan her:

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

Først skal du fra word-filen vælge de linjer, der indeholder tagget — vi får en masse tomme tags og linjer med ord. Vi fjerner selve tagget og dets afsluttende - her bruges procentsymboler i stedet for skråstreger fordi i selve tagget der er allerede en skråstreg, hvorfor? sed forstår dig ikke en smule. Og alt er fint med renter. Vi fjerner alle mellemrum fra filen, fjern tomme linjer. Voila - en færdig liste over ord.

For at fjerne ord, der rimer på de sidste bogstaver, skal du vælge de sidste to bogstaver fra det originale ord og rydde listen:

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

Vi kigger, vi prøver - alt virker... så hvor er listen for ordet "leg"? Og for ordet "jeg skal"? Filen er tom! Og det er alt sammen, fordi disse ord er verber, og vi ved, hvad de gør ved dem, der rimer på verber. Verb rim er værre end selv firkantet rim, fordi det russiske sprog har flest verber, og alle har de samme endelser, hvorfor de ikke var i den endelige fil efter at have kontrolleret endelserne.

Vi har dog ikke travlt. For hvert ord er der ikke kun rim, men også assonanser, som nogle gange lyder meget bedre end rim - det er derfor, de er assonanser (fransk assonans, fra latin assono - jeg lyder i melodi).

Vi får assonanser

Det er her det sjove begynder: assonanser vises på en separat URL og på samme side ved at udføre et script, sende en HTTP-anmodning og modtage et svar. Hvordan kan jeg sige wget'Trykker du på knappen? Men ingen måde. Desværre.

Da jeg bemærkede, at URL'en i linjen på en eller anden måde ændrede sig, kopierede jeg, hvad der var der efter at have skiftet til assonanser og indsatte det i en ny browserfane - stærke rim åbnede sig. Ikke det.

I det væsentlige, tænkte jeg, burde det ikke være lige meget for serveren, om scriptet, der sender anmodningen, udføres, eller om personen skriver det i hånden. Så? Hvem ved, lad os tjekke det ud.

Hvor skal man sende? Hvad skal du sende? HTTP-anmodning til serverens IP, der er noget som GET... så er der noget HTTP/1.1... Vi skal se hvad browseren sender og hvorhen. 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Ó.

Øh... hvad? Åh ja, vi har HTTPS. Hvad skal man gøre? Lancere et MITM-angreb på dig selv? Ideelt set vil offeret selv hjælpe os.

Generelt, efter at have besluttet at surfe i browseren, fandt jeg endelig selve anmodningen 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.

Hej. Hehehe. Det var faktisk, hvad jeg forventede, når jeg sendte en bare HTTP-anmodning til en HTTPS-port. Skal vi kryptere nu? Alt dette ballade med RSA-nøgler og derefter med SHA256. Hvorfor, der er OpenSSL for sådanne ting. Nå, vi ved allerede, hvad vi skal gøre, vi fjerner bare Referer- og Cookie-felterne først - jeg tror ikke, de vil påvirke sagen meget:

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

Hvad er det her, bande på serveren? Nå, i det mindste svarede de mig 200 OK, hvilket betyder, at cookies og henvisningen ikke påvirker noget. Komprimering er gzip, men ved kopiering kopieres ASCII-tegn. Præcis, du kan fjerne linjen Accepter-kodning. Alt er fint - vi får et HTML-dokument, nu med assonanser. Men her er to spørgsmål: hvordan kører man OpenSSL og overfører data til det ved hjælp af et script? Og hvordan læser man outputtet, hvis vi efter at have modtaget svaret forbliver, som det var, i en OpenSSL "shell"? Hvis du kan finde på noget med den anden, men med den første...

Det er godt, der er Habrhvor jeg læste om værktøjet forvente, som automatiserer processen med at interagere med programmer, der forventer menneskelig interaktion. At have et hold er endnu mere attraktivt autoforventning, genererer forvente script baseret på dine handlinger. Nå, vi starter det, gør alt dette, og her er det færdige manuskript. Kun han er meget stor, og alt sammen fordi OpenSSL viser certifikater, nøgler og forvente afventer resultatet af alt dette. Har vi brug for dette? Ingen. Vi fjerner hele den første prompt og efterlader kun det sidste linjeskift 'r'. Vi fjerner også felterne User-Agent og Accepter fra vores anmodning - de påvirker ikke noget. Så lad os starte. Scriptet blev udført, men hvor er det skattede HTML-dokument? Forvent spiste det. For at få ham til at spytte det ud, skal du sætte:

set results $expect_out(buffer)

før slutningen af ​​scriptet - det er sådan, outputtet af den eksekverbare vil blive skrevet forvente'om kommandoen og vises på skærmen. Sammenfattende noget som dette:

forventer et manuskript

#!/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 anmodnings-URL'en i alle eksempler statisk, men det er URL'en, der er ansvarlig for, hvilket ord der vil blive forbundet med assonanser. Og så viser det sig, at vi konstant vil søge efter ordet "%d0%b7%d0%b4%d0%b5%d1%81%d1%8c" i ASCII eller "her" i UTF-8. Hvad skal man gøre? Selvfølgelig skal du bare generere et nyt script hver gang, venner! Ikke mere autoforventning'Åh, og med hjælpen ekko, fordi I vores nye ændres intet undtagen ordet. Og længe leve det nye problem: hvordan kan vi intelligent oversætte et ord fra kyrillisk til URL-format? Der er heller ikke noget særligt for terminalen. Nå, det er okay, vi kan gøre det, ikke? Kan:

Se hvad jeg kan!

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')}

I alt har vi et script, der konverterer et ord til ASCII-tekst, og genererer et andet script, der anmoder om en side med assonanser fra serveren via OpenSSL. Og så omdirigerer vi outputtet af det sidste script til en fil og på gammeldags måde sender vi det igennem "filtre" ekstra firkanter og skriv dem til filen.

Skæring af mange. Bundlinie

Faktisk er det netop det, der giver de mindste problemer. Vi udfører ovenstående procedurer for to ord, fra de to lister sammenligner vi hvert ord med hvert, og hvis der findes et match, udlæser vi det. Nu har vi et script, der tager to ord som input og viser en liste over ord, der rimer på begge, og endda under hensyntagen til assonanser, og alt dette uden manuelt at skifte mellem fire faneblade og huske ord "ved øjet" - alt samlet, taget højde for for og kasseres automatisk. Vidunderlig.

Formålet med denne publikation var at vise, at hvis en person har brug for noget, vil han gøre det alligevel. Meget ineffektivt, skævt, uhyggeligt, men det vil virke.

Kilde: www.habr.com