• Dragi članovi, prochitajte OVU vest u vezi nove teme!
  • Molimo vas sve da pročitate PRAVILA FORUMA i da se istih pridržavate.
  • Secret Level Discord server je LIVE! Za više informacija kliknite OVDE

Random/Free Discussion Thread

pouzdan je prodavac. Ja nisam skoro porucivao posto jedno vreme je ukinuo japansku postu, ali je sad vratio.
Gledaj samo da vrednost paketa ne bude veca od 50$ i tezina veca od 2kg i ne bi trebalo da bude problema.
 
nelex said:
Ova naša policija znači uleteli kao da hapse Eskobara

View attachment 11782




U suštini napravio je skriptu koja random (ili semi-random ako je provalio neki šablon) generiše PFR broj računa i vreme generisanja PFR-a. I onda je verovatno napravio više aplikacija više botova koji su slali to non stop (ili koliko već dozvoljavaju po minutu). Mnogo ljudi igra ovu igru, ali većina ljudi ne igra, tako da možeš da ubodeš račune koji nisu poslati i već dodati na ovaj način (ovako generišuši random račune i nadajući se da ćeš da ubodeš neki račun koji već nije dodat).
U suštini, mislim da ako nije provalio neki šablon, mislim da je mnogo malo ako je uopšte uspeo nešto da pogodi. Ali verovatno su ga provalili po broju zahteva i onda su odlučili da izvedu ovakav upad u njegov stan - kao da je Kevin Mitnik lično. Odlučili su da nad njim demonstriraju silu i pokažu ljudima da se takve stvari neće tolerisati.
View attachment 11783View attachment 11784
Click to expand...
Sorry na resurrectu...
Ali sto PFR nije samo Guid (ili nesto slicno)?
Koliko mi se cini prvih 10 karaktera kombinacija 36 znakova, a poslednjih n su samo cifre, to je znacajno vise od 16 bytes u Guid-u.
Sta se tacno dobija ovim formatom nije mi jasno? Pogotovo ako bi morao biti unique, a neko je mogao da ga pretpostavi?
Vidim da u osnovnoj varijanti dobijas PFR od servera, ali imas i offline varijante gde generises PFR broj lokalno bilo sa dedicated uredjajem ili softverski.
Da nije u PFR-u zapakovana jos neka informacija? Ali, opet i dalje zasto nije Guid + jos nesto sto ne mozes pretpostaviti?
 
@Teoreticar,
Pa jel imas neku teoriju zasto nije Guid?

Увод - СУФ Подршка

Ово је званична корисничка документација за еФискализацију и Систем за управљање фискализацијом.
tap.sandbox.suf.purs.gov.rs tap.sandbox.suf.purs.gov.rs

Dakle, PFR je u formatu

7AF4D923-E3B30A31-234

Gde je (copy paste sa linka iznad)
  • 7AF4D923– јединствени идентификатор безбедносног елемента који захтева потписивање (фискализацију) рачуна.
  • E3B30A31 - јединствени идентификатор безбедносног елемента који је потписао (фискализовао) рачун.
  • 234 – укупан број фискалних рачуна који су издати са овом комбинацијом јединствених идентификатора безбедносног елемента. Овaj број се увећава за 1 сваки пут када се изда нови рачун са истом комбинацијом ЈИД-ова.
Prva prednost nekorišćenja GUID-a je što na ovaj način možeš u režimu bez interneta (lokalno) nezavisno da generišeš PFR u odnosu na režim kada koristiš server. Ono šta će se razlikovati je ovaj drugi deo (u sredini). I kada dođe do sync-a biće sve ok. Ovo takođe garantuje da oba režima mogu nezavisno sa ili bez interneta da generišu PFR-ove i da budu sigurni da neće doći do duplikata. Što kod običnog GUID-a je moguće (napomena: kod nekog GUID-a baziranog na vremenu bi možda moglo, ali onda imate ne sećam se beše koliko bitova na kraju u jednoj milisekundi dok se ne dodje do duplikata, ali pitanje da li bi to bio problem uopste).
Takođe, na ovaj način, korišćenjem ovakvog ID-a, moguće je raditi analizu podataka i videti neke navike potrošača/obveznika i utvrditi moguće malverzacije. Jer po ID-u vidite koja firma je izdala račun, koji uređaj itd. Ne trebaju vam maltene nikakve druge informacije. Isto tako, kao što je moguće neke UUID-GUID-e sortirati po vremenu (jedini ispravni način generisanja ID-a btw :D), tako i ovaj ID možeš urediti/sortirati po uređaju/firmi(pravnom licu) recimo.

E sad, zašto je odlučeno da bude baš ovaj format ne znam, možda su videli negde u svetu gde je već radjeno pa kopirali. Mogli su da naprave i neki svoj ID u nekom drugačijem redosledu. Ali meni ovo ima smisla šta su uradili.

I da se vratimo na ovu nagradnu igru i ovog hakera.
U suštini, ako recimo analiziraš Maksi/Lidl/Idea ili ne znam neki veliki market, pokupiš račune iz nekoliko dana, možeš skapirati nekoliko stvari. Prvo, videćeš ovaj prvi deo koji je, tj. ID tog uređaja (fiskalne kase) koji se neće menjati. Drugo, videćeš ovaj srednji deo, ID bezbednosnog elementra (sa servera) koji se verovatno ređe menja pa možeš da vidiš obrasce kako i kad se menja. I ovaj poslednji deo, da vidiš dokle se stiglo u tom danu sa izdatim računima. Sve što ti preostaje je da ovaj poslednji deo brute force-uješ u kombinaciji sa vremenom kada je izdat račun. Takodje, ovo se može sve ubrzati ako nadjete neku dovoljno veliku radnju koja radi u lokalu izdavanje računa (nije zakačana na net), tipa u nekom planinskom selu kada je ski sezona ili tako nešto (ili ako znate neku radnju koja radi bez interneta izdavanje računa). Jer onda ovaj deo u sredini je takodje uvek isti jer se koristi lokalni bezbednosni element. Za vreme i broj izdatih računa (ovaj deo na kraju PFR-a), to se može smisliti neki algoritam koji će pametnije nagađati to i da nije čist brute force, tako bi drastično povećao šanse (tipa ako je u 20:00 bilo 1500 izdatih računa tj. ovaj broj na kraju je 1500, znaš da ako gađaš/nagađaš u 20:15 ne može biti ništa ispod 1500 već samo iznad).

I sada ostaje samo da se vidi koliko requesta u minutu/satu/danu (rate limit) je imala poreska za prijavu računa za ovu nagradnu igru. I odatle se može izračunati i verovatnoća pogadjanja. Verovatno je probao, video da je neka normalna šansa da će pogoditi račune, i samo je pustio skriptu.
 
Last edited:
nelex said:
  • 7AF4D923– јединствени идентификатор безбедносног елемента који захтева потписивање (фискализацију) рачуна.
  • E3B30A31 - јединствени идентификатор безбедносног елемента који је потписао (фискализовао) рачун.
Click to expand...
Prvih n karaktera i drugih n karatera je vrlo cesto isti broj.

nelex said:
Prva prednost nekorišćenja GUID-a je što na ovaj način možeš u režimu bez interneta (lokalno) nezavisno da generišeš PFR u odnosu na režim kada koristiš server.
Click to expand...
Guid (i alternative) su napravljene bas zato da mozes da generises na lokalu i da (skoro) sigurno budes siguran da ce taj broj (set karatera) biti jedinstven.
Sansa za Guid Collision-om je izrazito mala.

stackoverflow.com

Is it safe to assume a GUID will always be unique?

I know there is a minute possibility of a clash but if I generated a batch of 1000 GUIDs (for example), would it be safe to assume they're all unique to save testing each one? Bonus question An o...
stackoverflow.com stackoverflow.com

here are an enormous number of GUIDs out there. To quote Douglas Adams's Hitchhiker's Guide to the Galaxy:

"Space," it says, "is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is. I mean you may think it's a long way down the road to the chemist, but that's just peanuts to space, listen…"
Click to expand...
And since there are about 7×1022 stars in the universe, and just under 2128 GUIDs, then there are approximately 4.86×1015—almost five quadrillion—GUIDs for every single star. If every one of those stars had a world with a thriving population like ours, then around each and every star, every human or alien who had ever lived would be entitled to over forty-five thousand GUIDs. For every person in history at every star in the universe. The GUID space is at the same level of hugeness as the size of the entire universe. You do not need to worry.
Click to expand...
Ovo mi je omiljen odgovor na Stack-u


Ono šta će se razlikovati je ovaj drugi deo (u sredini). I kada dođe do sync-a biće sve ok. Ovo takođe garantuje da oba režima mogu nezavisno sa ili bez interneta da generišu PFR-ove i da budu sigurni da neće doći do duplikata. Što kod običnog GUID-a je moguće (napomena: kod nekog GUID-a baziranog na vremenu bi možda moglo, ali onda imate ne sećam se beše koliko bitova na kraju u jednoj milisekundi dok se ne dodje do duplikata, ali pitanje da li bi to bio problem uopste).
Click to expand...
Guid ne radi ovako. Guid jeste baziran na vremenu i na mac adresi + random.


Ali, cak i da dodje do kolizije, problem uopste nije toliko veliki da bi opravdao ovu komplikaciju. Naveo sam i u originalnom postu da mozes koristiti jos nesto pored random guid-a, tu moze da bude npr maticni broj firme, broj prodavnice, kase i slicno.
Cak i da se napravi sistem da mozes imati n istih PFR brojeva - bolje da ti kad ukucas 1 PFR broj prikaze 2 racuna, nego da mozes da pogodis tako sto radis autoincrement :)
A, postoji i puno paterna za resavanje kolizije. Recimo mozes napraviti linked listu. Imas i dalje unique PFR kad snimas u neko skladiste imas jos jednu kolonu/polje new id, i pod tim new id snimis sledeci racun sa istim PFR-om.


Takođe, na ovaj način, korišćenjem ovakvog ID-a, moguće je raditi analizu podataka i videti neke navike potrošača/obveznika i utvrditi moguće malverzacije. Jer po ID-u vidite koja firma je izdala račun, koji uređaj itd. Ne trebaju vam maltene nikakve druge informacije. Isto tako, kao što je moguće neke UUID-GUID-e sortirati po vremenu (jedini ispravni način generisanja ID-a btw :D), tako i ovaj ID možeš urediti/sortirati po uređaju/firmi(pravnom licu) recimo.
Click to expand...
Ali zasto bi radio analizu podataka na osnovu id-a? Cela sustina da je doslo do malverzacije bas zato sto koriste podatak u samom Id!
Kad imas autoincrement id uvek imas problem njegovog generisanja. Mozes ga generisati samo i samo na 1 masini! Ne mozes imati distribuirani sistem koji generise autoincrement zbog CAP theorem.

en.wikipedia.org

CAP theorem - Wikipedia

en.wikipedia.org en.wikipedia.org

Ne mozes biti 100% siguran, da ce u distribuiranom sistemu da radi autoincrement. Otisao bi cak korak dalje, mislim da ces znacajno lakse napraviti haos ako bi pravio autoincrement u distribuiranom sistemu, nego sa automatskim generisanjem Guid-a.


Ima nacina da se guid generise sequentionalno (mada onda se vise ne zove guid). Kad dodajes novi red gde ti je Guid u clustered index, operacija je O(log n). Ako dodajes neki sekuencialni, operacije ce biti O ( 1 ). To je rekao bi jedini benefit. Ali, problem sa tim algoritmima je sto ti vreme uzima vise bitova i povecava se sansa za koliziju. I takodje, kako ces sinhronizovati sve satove kad generises taj guid distribuirano? Ima nacina, ali to je problem za sebe. Inace zanimljivo, mislim da se Microsoft (koji i koristi Guid) i Azure uopste ne oslanjaju na sat kao sto to radi AWS i Google.

aws.amazon.com

Manage Amazon EC2 instance clock accuracy using Amazon Time Sync Service and Amazon CloudWatch – Part 1 | Amazon Web Services

This two-part series discusses the measurement and management of time accuracy on Amazon EC2 instances. Part 1 covers the important concepts related to system and reference time. Part 2 covers the mechanism of measure, monitor, and maintain accurate system time on EC2 instances. A large and...
aws.amazon.com aws.amazon.com
developers.google.com

Public NTP | Google for Developers

A free, global time service that you can use to synchronize to Google's atomic clocks.
developers.google.com developers.google.com

Ne bi se slozio da trebamo da imamo ID koji mozes sortirati po firmi.
Opet, ako to radis, imas O(log n) problem prilikom snimanja.
Ako imas bazu, koja stvarno moze da primi velik broj redova, nece raditi tako sigurno. Pre ces definisati id firme u tom slucaju da bude partition key. Tako mozes siriti bazu vertikalno, a ne samo horizontalno.

U suštini, ako recimo analiziraš Maksi/Lidl/Idea ili ne znam neki veliki market, pokupiš račune iz nekoliko dana, možeš skapirati nekoliko stvari. Prvo, videćeš ovaj prvi deo koji je, tj. ID tog uređaja (fiskalne kase) koji se neće menjati. Drugo, videćeš ovaj srednji deo, ID bezbednosnog elementra (sa servera) koji se verovatno ređe menja pa možeš da vidiš obrasce kako i kad se menja. I ovaj poslednji deo, da vidiš dokle se stiglo u tom danu sa izdatim računima. Sve što ti preostaje je da ovaj poslednji deo brute force-uješ u kombinaciji sa vremenom kada je izdat račun. Takodje, ovo se može sve ubrzati ako nadjete neku dovoljno veliku radnju koja radi u lokalu izdavanje računa (nije zakačana na net), tipa u nekom planinskom selu kada je ski sezona ili tako nešto (ili ako znate neku radnju koja radi bez interneta izdavanje računa). Jer onda ovaj deo u sredini je takodje uvek isti jer se koristi lokalni bezbednosni element. Za vreme i broj izdatih računa (ovaj deo na kraju PFR-a), to se može smisliti neki algoritam koji će pametnije nagađati to i da nije čist brute force, tako bi drastično povećao šanse (tipa ako je u 20:00 bilo 1500 izdatih računa tj. ovaj broj na kraju je 1500, znaš da ako gađaš/nagađaš u 20:15 ne može biti ništa ispod 1500 već samo iznad).
Click to expand...

Cak i da prihvatim da je guid losije resenje (a mislim da nije), nisam siguran da je ovo sto sada imamo dobro. (Ocigledno nije kad je neko mogao da pogodi sledeci id).

Koliko vidim po tome sto si okacio, Id uredjaj se sastoji od 8 karaktera sa 36 kombinacija po karakteru? Mrzi me da racunam tacno ali to je 32-64? bit-a. 6 bita po karakteru? To uopste nije malo. 281,474,976,710,656? Zasto svaka masina nema n id-jeva, pa ih koristis random? Mogli bi generisati id masine na isti nacin, na koji se generise npr CD Key. To bi drasticno smanjilo sansu za malverzacijom.

Zasto je drugi element fiksiran? Ovo mi deluje kao PS hack gde su zaboravili da ukljuce random generator, vec non stop generise iste brojeve. Koliko sam ja razumeo, ako nisi povezan na internet, moras lokalno generisati taj srednji broj. Ali zasto ne generises lokalno svaki put taj broj, nego koristis isti? Kase valjda moraju biti spojene na taj uredjaj/software?

I trece, opet ne razumem pored PFR broja koji je sigurno bar 128bit-a, ako bi sve ostalo isto, zasto samo na kraju nisu dodali jos jedan random 16bitni broj npr - to je 65,536 kombinacija. To nikako ne bi mogao brute forceovati.



This was fun.
 
You must log in or register to reply here.
Back
Top Bottom