Hei,

Jeg holder på med et gåtespill hvor oppgaven lyder som følgende:

"This script is not that safe. The username and password is embedded into the javascript function."

Problemet mitt er at jeg er svært dårlig i javascript, men har prøvd å lese meg opp på det, men får dessverre ikke til. Hele login scriptet er dette:
Såvidt jeg vet kan man gjøre følgende. Sette flro,2 til flro,1 , eller ta javascript:alert(a57492e);

Da ender man opp med: Altså hele loginscriptet er i javascript. Jeg kjører %3C%21%2D%2D%20%36%34%38%39%61%61%33%34%3A%65%48%55%78%4F%47 %45%76%65%44%6B%30%20%2D%2D%3E gjennom HEX to ASCII, og ender opp med følgende: <!-- 6489aa34:eHUxOGEveDk0 -->

Der sitter jeg fast, jeg vet ikke hvordan jeg får videre. Det er klart at det orginale brukernavnet og passordet er i funksjonen et sted, men jeg klarer ikke manipulere den slikt at jeg får riktig brukernavn/passord. Noen som kan hjelpe meg, hadde dette blitt satt stor pris på!

Spurte ikke du om dette for omtrent et år siden? Jeg kjenner i alle fall igjen det "brukernavnet" siden sist, men alt bak kolon-tegnet har endret seg. Står fortsatt på mitt om at det er snakk om et brukernavn:passord-par. Passordet virker som om det er base64-enkodet.

Når jeg så på den forrige tråden i ettertid, ble jeg flau over hva jeg hadde skrevet. Så da lagde jeg likegodt et nytt Men jeg har prøvd å sjekke om det er base64-enkodet og dessverre var det ikke det

Altså, den lille kodesnutten bare konverterer fra htmlenkoding til ASCII. Hvis du fjerner alle spørsmålstegnene (hvorfor er de der?) så ender du opp med den formen du presenterer i førsteposten din.

Om du kjører den lille hexkoden gjennom der, eller om du konverterer den manuelt, er ett fett og det gir uansett "<!-- 6489aa34:eHUxOGEveDk0 -->". Skal du derimot kjøre den gjennom funksjonen du lister over må du ikke plusse på en '%' foran, da dette allerede er med.

"eHUxOGEveDk0" *kan* være base64-enkodet og blir til "xu18a/x94". Det foran kolon *kan* være brukernavnet, og xu18a/x94 *kan* være passordet, men det er helt umulig å si når jeg ikke vet hva slags passord man vanligvis får i dette spillet ditt. Hvis passordene på tidligere levler har vært noe i samme gata så er det greit å vite. Hvordan oppgavene løses er også greit å vite. Går det mest i krypto? Er det obskure greier? Kan det hende at f.eks. posisjonene til spørsmålstegnene tilsvarer posisjoner i alfabetet som til syvende og sist sier koden? Det kan liksom være hva som helst i hele verden, og dette er litt frustrerende at du ikke sier.

Aaah, oppgavene er veldig varierende. Det er alt fra svært lette funksjoner til svært omfattende operasjoner. Jeg ser ingen spørsmålstegn i min post, så jeg skjønner ikke helt hva du mener med det. Det jeg mente med at jeg hadde prøvd base64 dekryptingen var akkurat slikt som du sa; men det funket ikke. Noen av oppgavene kan være svært obskure ja. Noen passord er helt vanlige chars, mens andre kan være helt merkelige. Det går en god del i krypto og dette regnes under krypto. Når jeg kjører det gjennom funksjonen min +er jeg ikke på %(tror jeg iallefall). Men så vidt jeg har fått høre skal dette være latterlig enkelt, jeg spurte om hjelp på #javascript @ efnet og de flirte og sa at det var så åpenbart.

Spørsmålstegnene jeg snakker om oppstår visst når jeg kopierer fra forumet, og jeg er litt usikker på hvordan de kom på plass, da posisjon og antall virket helt random. Feilen er altså på min side, og å fjerne dem fikset alt.

Det er "latterlig enkelt og åpenbart" å tråkke gjennom funksjonen som konverterer stringen g77uik til formen du oppgir. Det videre hintet er da å dekode til du sitter med <!-- 6489aa34:eHUxOGEveDk0 --> og herfra blir det litt vanskeligere.

Deler du opp det foran kolon får du "64 89 aa 34", og hverken 89 eller aa (ingenting som starter med a) er gyldige ASCII-verdier, så jeg tror ikke funksjonen din skal brukes til noe videre. Det bak kolon kan "tilfeldigvis" dekodes til gyldig ASCII gjennom base64, og personlig synes jeg dette er litt *for* tilfeldig til at du skal ignorere det.

Spørsmålstegnene var min feil, og jeg beklager. Noe må ha skjedd da jeg kopierte fra forumet, og jeg gikk da ut i fra at de var lagt til med vilje. Det er flott å vite at det ikke f.eks. er noe fast brukernavn, for da må det jaktes på både brukernavn og passord, og det må kunne antas at hintet du får (6489aa34:eHUxOGEveDk0) inneholder begge deler, sannsynligvis delt på midten med kolon-tegnet. Jeg er ganske sikker på at passordet er "xu18a/x94" og da gjenstår det å gjøre noe med "brukernavnet" (6489aa34).

Ut i fra det jeg ser er det 8 tegn alfanumerisk, og kandidater er derfor adler32, crc32 og crc32b av ulike hashingalgoritmer. Å reversere slike algoritmer er ikke mulig, og du må i beste fall brute-force. Heldigvis er alle disse algoritmene laget for å være ekstremt raske, så så lenge du har en relativt kjapp generator av forskjellige brukernavn så er det fort gjort å sjekke dette. Kan først gjøre en enkel analyse for det enkleste tilfellet i Adler-32:

Resultatet 6489AA34[16] = 1686743604[10] = A + B * 65536
A = summen av alle ascii-verdiene til bokstavene + 1 (modulo 65521) [Sum 1 + D1 + D2 ... Dn mod 65521)
B = n*D1 + (n-1)*D2 ... + Dn + n (mod 65521) hvor n er antall tegn i tekststrengen.

Siden B vokser eksponensielt med n vil den wrappe over 65521 ganske fort, mens A kan antas å være svært liten for mindre strenger. Vi kan dermed anta at A er det tallet vi må trekke fra 1686743604 for at det skal bli delelig med 65536. Dermed er A lik 43572. Hvis vi forenkler det veldig, og sier at en bokstavs ASCII-kode er ca. 100 i snitt vil brukernavnet derfor antageligvis være bortigmot 43 tegn langt. Siden dette er forferdelig langt, kan vi nok anta at B har nådd modulogrensen, og at antagelsen vår var feil. Det kan også bety at det rett og slett er feil algoritme.

Prøv brute-forcing og få f.eks. John The Ripper til å generere input til programmet ditt, så får du se hvor langt du kommer.


Vi snakket for øvrig hexadecimalt her på alt det andre, men om vi tolker det decimalt så er jeg med på tankegangen din

Dog litt rart å uttrykke et decimalt tall med hexadecimale bokstaver.

Tusen takk for hjelpen, men driver å runne mot adler-32 her, enda ikke fått riktig output. Tar 16 mill i sekundet her, men går over 2 kjerner.

Men jeg tviler i utgangspunktet på at det er en checksum funksjon.

Har testet småe, store bokstaver + tall og tegn fra 1-6 hittil, ser mørkt ut for Adler-32

Haha! Det var faktisk en checksum, some jeg ikke testet sist gang, og det var CRC-32. Denne er da løst, og jeg takker svært mye for hjelpen Dyret og Provo. Takk for at dere orket å prøve! Kp på dere begge to!

Ps. Den andre delen var ikke base64 enkodet, jeg tror den ikke var det nettop fordi det var så åpenbart

Ser ut som om jeg var for kocky, og nFF bugger seg her hos meg, kan ikke rette tråden min.

6489aa34:eHUxOGEveDk0

6489aa34 dekryptert med CRC-32 = dlV7VA Kan det være crc-32b ? Setter det på nå iallefall
eHUxOGEveDk0 dekryptert med base-64 =xu18a/x94.

Har testet alle muligheter med de nevt ovenfor, funket ikke dessverre : (
Dersom det ikke er CRC-32B eller ghash. noen som har peiling hva som er neste ?

Det var heller ikke CRC-32B som dekryptert ble: D2RwWI.

Testet med kombinasjonene nevt ovenfor.