Re: Cracking Strings from URLs
Rich <[email protected]>
| Newsgroups | comp.misc |
|---|---|
| Organization | A noiseless patient Spider |
| Message-ID | <[email protected]> |
Computer Nerd Kev <[email protected]> wrote: > Computer Nerd Kev <[email protected]> wrote: >> Rich <[email protected]> wrote: >>> Computer Nerd Kev <[email protected]> wrote: >>>> Computer Nerd Kev <[email protected]> wrote: >>>>> I've got long strings like this from URLs (percent-encoded >>>>> characters have been decoded): >>>>> >>>>> SdADygkIiM8ED8ZK/ZfkxwbHEgOXnsgKzQcYtq2j3L1HN6OYvET8PwvO2gpCCv4Bp4vIGLwLFN3dDQABOjWT0gVI/EtBlNUIObwLFNnU90IK/gCs2QQzBzhEz8sNAAdBPpmM+T0KRgudx88HxzsFnpjGQs8PBp+fEAvQCgCZnsdKzQz+lpbIBPj7CQ== >>>>> >>>>> I believe they might be encrypted strings containing one or more >>>>> known fields, probably including a known ten digit number >>>>> (1409518286 in that case). They might also be hashes, but I think >>>>> it's unlikely. >>>> >>>> I got a copy of the PHP code. Turns out it's a "transposition >>>> cipher" which adds different numbers to the ASCII value of each >>>> character in sequence. >>> >>> Also called the Ceasar cipher: >>> >>> https://en.wikipedia.org/wiki/Ceasar_Cipher >> >> Almost, but unlike the description there, the number of shifted >> positions varies for each character in the encrypted string, since >> the shift length depends on the ASCII value of each character in the >> password. That means you couldn't simply shift the whole string all >> the possible lengths until the string "1409518286" was found in the >> result. Instead you'd have all the possible combinations of >> independently shifted characters = 128 (ASCII character set) to the >> power of the number of characters in the string. In this case >> 128^182 = 3.25e+383, which is ridiculous, but some shortcuts would > ^^^^^^^ > First thing I need to do is learn how to count characters in a > string (well actually I did, but forgot them number before I typed > it). Should've been: > > 128^188 = 1.43e+396 > > But it's base64 encoded, so if you don't know that, then multiply > that number by the number of different possible byte/character > encodings you'd have to try as well. If there isn't a smarter > approach. Any cryptographer worthy of that label *should* recognize base64 on sight. Really, any half decent programmer, esp. any half decent programmer on Linux/Unix systems, should recognize base64 and uuencode output immediately on sight, given how commonly both were used on Unix systems.