nějakej jinej znak ale myslim že to je jenom otázka kodování výstupu zobrazení takže pokud někdo udělá script kterej je binary-safe tak je jedno jakej znak tam je.
Jasný ale nad tím by se musel už někdo zamyslet. A to ho v první chvíli nemusí napadnout že někdo používá speciální české znaky
znaky v hesle jsou v ukladany jako nejaka varianta UTF. Zrejme zpotvorena, protoze znaky s diakritikou, ktere jsem zkousel se vzdy vycetly jako jednobytove. A ten byte je shodny z poslednim bytem z UTF tabulek (í => 237 = 0xED). Je dost mozne, ze MT problem s multibyte znaky v UTF vyresil tim, ze bere jen nejnizsi byte (koneckoncu heslo nikde nezobrazuje v citelne podobe takze se to nikdo nedozvi) a vyresil si tak nejake interni obtize s multibyte stringy tak, ze z nich ma klasicke jednobytove retezce.
Takze je pravdepodobne, ze presnou podobu znaku s diakritikou (a cehokoliv co se koduje do vice bytu) nejde spolehlive po exploitu zobrazit. Ale jako zabezpeceni je to k nicemu. Kdyz uvidim, ze v hesle je znak s kodem 233 (pridat do exploitu vypis kodu znaku v hesle je prkotina), tak se podivam do UTF tabulky znaku a zjistim, ze moc prefixu zkouset nemusim a testnu rovnou to prvni, co uvidim a tedy znak 'é'. UTF tabulka mi nabizi cca 3 dalsi moznosti, nicmene pokud mechanismus zachazeni s heslem funguje tak jak si myslim, je jedno, kterou si vyberu - hlavne, ze maji ten spravny posledni byte.
Je treba si taky uvedomit, ze roboti, co exploituji tu chybu dost pravdepodobne nepouzivaji stejny exploit v pythonu, ktery tady zkousite. Asi maji vlastni implementaci nebo tu z pythonu ale dost prekopanou. Takze spolehat na to, ze nejsou schopni precist ty znaky je dost na povazenou.
