Fejkbiljett för Android

Koden som genererar biljetten har genomgått en större renovering ser det ut som, det lite märkliga är att det är skrivet som om man känner till hur bokstäverna ska genereras istället för att bara slumpa fram dem men tyvärr lämnas det ingen närmare kommentar om saken i koden. Hur som helst kan jag inte se nått som gör det enklare att se biljetten som falsk i den nya versionen, jag bytte dessutom till den nya just eftersom jag fick klagomål på den gamla.

/AlgoJerViA

Vad menar du med att "det är skrivet som man känner till hur bokstäverna ska genereras"? Och vad var det dem klagade på?

Var på besök i stockholm i helgen, körde med 0,2 i tunnelbanan ett par gånger, aldrig några problem, bara att åka. Stort tack för appen!

I den äldre versionen slumpas alla bokstäver men i den nya genereras bokstäverna efter en enkel algoritm. Alltså två biljetter med samma sCODE ger i den nya versionen samma resultat varje gång emedan i den gamla versionen skulle bokstäverna slumpas varje gång. sCODE är den långa raden siffror längst ner.

De klagar på biljettens äkthet, ingen som nämnt något specifikt dock.

/AlgoJerViA

Tack för svar! Men jag förstår inte riktigt: "två biljetter med samma sCODE ger i den nya versionen samma resultat varje gång emedan i den gamla versionen skulle bokstäverna slumpas varje gång". Var ser man ett mönster som följer en algoritm? I mina omatematiska ögon ser det fortfarande slumpat ut, hehe.

Detta finns inte för tråkiga iOS antar jag?

Jo, i rätt tråd.

https://www.flashback.org/t1047525

I koden, på github, eller vad det heter, gissar jag.

Har blivit nekad på den nya versionen 0.2 flera gånger nu. Spärrvakten säger att det ska stå SL som avsändare bakom som 3 siffrorna. vilket det inte gör.

Bara så alla vet

Mvh

Läs längre bak i tråden, anledningen till att det inte står SL som avsändare är pga. det programmet som hanterar dina meddelanden inte stöder detta, t.ex. om du kör em custom rom.

Okej, tack för informationen. Har någon en aning om ifall detta problem går att lösa på något annat sätt?

Menar du att du inte ser algoritmen i källkoden eller i biljetten? I källkoden ser det ut såhär i varje fall...


...och för övrigt ska man flytta } som följer direkt efter så att det är ovanför istället för att lösa problemet med force close med reducerad biljett, men åter till saken.

sCode består av 15 helt slumpmässiga siffror, det framgår inte i koden här men gNumbers är också slumpmässigt genererad och läggs till i sCode på detta sättet därför att de tre sista siffrorna är samma som numret biljetten kommer från. Sen konverteras sCode till hexadecimalt format vilket inte ändrar värde utan bara hur vi representerar värdet på sCode så att det ska passa i funktionen hexToAEOX där magin sker. Indeed...


Alltså det som händer är att den tar en hexadecimal siffra och substituerar den rakt upp och ner enligt hexAEOX listan. Alltså om den hexadecimala siffran är 0 blir det OO är den tex 5 blir det XX och siffran a blir AA.

Om det här är den äkta algoritmen och allting stämmer så är det hur bra som helst men är det inte så så finns det specialfall där de decimala och hexadecimala siffrorna slutar på samma siffra, i dessa fall givet att hexAEOX alltså inte är i korrekt ordning skulle man med blotta ögat och lite brain relativt lätt kunna se att biljetten är falsk. Detta var dock bara min första ide och det är knappast så de ser att biljetten är falsk eftersom även om det är möjligt att lära sig är det inte tillräckligt simpelt för att vanliga spärrvakter skulle orka engagera sig.

//AlgoJerViA