ovcgeheugen


Reputatie 6
Badge +2
201806 17 7:09
Informatie over het geheugen van de OV-chipkaart is maar gedeeltelijk openbaar bekend.

Bij kaartautomaten van NS en andere vervoerders, en bij ophaalautomaten, kan je zonder iets op te halen uit de automaat of een centrale database een aantal gegevens zien die in ieder geval op de kaart staan:

*saldo
*producten
*transacties

Op https://community.ns.nl/in-de-trein-11/omreizen-met-een-gedwongen-overstap-48407/index9.html#post330720 staat verder nog:

Op de OV-chipkaart is een specifiek stukje geheugen aangewezen waarop altijd de laatst uitgevoerde checkin- of checkout-transactie staat. Als je je kaart bij een paal/poort aanbiedt, dan wordt dát stukje gelezen. Als er op de kaart een checkout staat, dan zal het paaltje nu een checkin gaan maken. En als er op de kaart een checkin staat, dan zal het paaltje een checkout gaan maken. Nadat de checkin of checkout is gemaakt, wordt dat stukje geheugen overschreven met de zojuist gemaakte checkin of checkout. Dus bijv:
Iemand checkt in op Den Haag. Op dat stukje geheugen staat ‘checkin op Den Haag om 0800u, 0 TE afgelegd’.
Iemand checkt uit op Sloterdijk. Op basis van het geheugen wordt de reisprijs berekend en afgerekend. Nadat de checkout is uitgevoerd staat er op het geheugen: “checkout op Sloterdijk om 0840u, 59 TE afgelegd”.
Iemand checkt in op Sloterdijjk. Op basis van het geheugen wordt overstap gegeven, want minder dan 35m sinds 0840u. In het geheugen staat: “checkin op Sloterdijk om 0841u, 59 TE afgelegd”.
Iemand checkt uit op Den Helder. Op basis van het geheugen wordt de reisprijs berekend en afgerekend, dus +76 TE ten opzichte van 59 TE reeds afgelegd. In het geheugen staat: “checkout op Den Helder om 0930u, 120 TE afgelegd”.
Hopelijk blijkt hieruit dat ‘Den Helder’ niet weet dat de reis in Den Haag is begonnen. Palen en poortjes lezen alleen dat ene stukje geheugen, wetende dat daar altijd de meest recente checkin/checkout-transactie staat, die nodig is om de afrekening te kunnen doen. En er is in dat ene stukje geheugen geen ruimte meer beschikbaar om het ‘startpunt van de reis’ in vast te leggen en te houden.

Elders op de kaart staat nog wel dat er in Den Haag is ingecheckt; immers, op de kaart staan de laatste 10 reistransacties. Maar die 10 transacties staan niet gesorteerd. Dus als het poortje in Den Helder zou moeten bepalen of de reis in Den Haag is gestart, dan zou hij alle 10 reistransacties moeten lezen en onderling evalueren, om te concluderen welke checkin het startpunt van deze reis is. Het lezen en evalueren van die 10 reistransacties zou dermate veel tijd kosten, dat de maximale transactietijd van 250 ms ruim overschreden zou worden. Dit is één van de redenen waarom het OV-chipkaartsysteem niet aangepast kan worden om GOmGO op te lossen.

Ik begrijp hieruit dat de laatste check-in of -uit twee keer op de kaart staat. Niet alleen als transactie in de transactielijst, maar ook in een apart stukje geheugen. Verder staat er ook het aantal TE.

Uit het feit dat Blauwnet in de transactielijst soms een verkeerd instaptarief schrijft, maar wel bij uitchecken het goede in aanmerking neemt (zie https://community.ns.nl/ov-chipkaart-5/blauwneteigenaardighedenindex-49257), maak ik op dat ook die informatie niet alleen in de transactielijst staat, maar ook, maar dan goed, in een apart stukje geheugen.

Ik krijg de indruk dat de in-/uitcheckapparatuur helemaal niet in de transactielijst kijkt, maar alleen in de speciale stukjes geheugen, en vervolgens, naast het bewerken van die stukjes geheugen, een nieuwe transactie in de lijst schrijft. Dat moet dan wel op een zodanige plaats dat geen van de laatste negen transacties overschreven wordt, wat niet goed verenigbaar is met de opmerking dat de transacties ''ongesorteerd'' op de kaart staan, en dat de tijd te kort is om ze allemaal te bekijken.

''Ongesorteerd'' zou onder meer erop kunnen slaan dat bij inchecken bij een treinvervoerder bepaald moet worden of dit binnen 35 minuten na het uitchecken bij een relevante treinvervoerder is, maar dat dit niet de laatste transactie hoeft te zijn, er kan bijvoorbeeld tussendoor met de metro gereisd zijn. Om niet te hoeven zoeken in de transacties zou de nodige info ook in een ander stukje geheugen moeten staan.

11 reacties

”Een eigen stukje geheugen” is een wat eenvoudige omschrijving. Feitelijk staan er indexes met pointers naar geheugenruimte in de grote sectors waar de feitelijke data staat. Een index is veel sneller lees/schrijfbaar doordat het om een veel kleinere hoeveelheid data gaat.

Wel een tricky onderwerp, laat het de TLS huisjurist maar niet zien 😪

Er staan een aantal implementaties openbaar. Een paar zaken zijn verouderd, maar in beginsel werken de ovcp’s nog steeds op deze manier. Bij de tweede moet je even specifiek het ovcp-gedeelte hebben. Voornaamste verouderde is het ontbreken van nieuwe company/subscription ID’s, haltenummers en transactiontype 4 (=inspectie/controle).

https://github.com/Huuf/OV-mfoc-GUI
https://github.com/codebutler/farebot
Reputatie 6
Badge +2
”Een eigen stukje geheugen” is een wat eenvoudige omschrijving. Feitelijk staan er indexes met pointers naar geheugenruimte in de grote sectors waar de feitelijke data staat. Een index is veel sneller lees/schrijfbaar doordat het om een veel kleinere hoeveelheid data gaat.

Wel een tricky onderwerp, laat het de TLS huisjurist maar niet zien 😪

Er staan een aantal implementaties openbaar. Een paar zaken zijn verouderd, maar in beginsel werken de ovcp’s nog steeds op deze manier. Bij de tweede moet je even specifiek het ovcp-gedeelte hebben. Voornaamste verouderde is het ontbreken van nieuwe company/subscription ID’s, haltenummers en transactiontype 4 (=inspectie/controle).

https://github.com/Huuf/OV-mfoc-GUIhttps://github.com/codebutler/farebot

201806 18 14:34
Bedankt.

Bij ”een eigen stukje geheugen” gaat het in dit verband niet zozeer om de vraag of het fysiek een vast plekje is, bij een variabel plekje kan het met een pointer inderdaad ook gemakkelijk zonder zoeken te benaderen zijn. Het gaat er meer om of bepaalde informatie op twee plaatsen staat, gecombineerd met de mogelijkheid dat door een fout in het systeem (al of niet bewust geaccepteerd omdat het omslachtig is het te corrigeren) de informatie verschillend/tegenstrijdig is, zoals ''Vol tarief'' of een instaptarief van € 10 aangeven, maar dat (gelukkig) niet toepassen.

Ik heb alvast geleerd dat onder meer het volgende het geval is/was (al is het in dit verband misschien niet zo relevant):

  • Een datum wordt opgeslagen als het aantal dagen na 1 januari 1997 (https://github.com/Huuf/OV-mfoc-GUI/blob/master/mfocGUI/OVData.cpp)
  • NS is vervoerder nummer 4 (idem)
  • check-in, check-uit en overstap zijn respectievelijk gebeurtenis nummer 1, 2 en 6 (idem)
Door de vrij lange stukken tekst en het gebruik van allerlei terminologie die niet op elkaar aansluit (dat ligt niet specifiek aan jou, er is in deze branche veel te weinig consistentie en documentatie) is het soms lastig om de precieze, concrete vraag te bepalen. Wat wil je precies uitzoeken?
  • NS is vervoerder nummer 4 (idem)

Die klopt toevallig, maar let wel op dat een aantal echt verouderd is. Keolis/Blauwnet-transacties zie je bijvoorbeeld als "DUO" verschijnen. De lijsten zijn lastig te bouwen en onderhouden natuurlijk. Ook in actiever onderhouden implementaties als Farebot missen zaken, doordat er al wat jaren niet meer (serieus) naar gekeken is.

Ik heb nog wel een hoop notities en stukken met ook recentere informatie, maar dat is erg veel en in bijna alle gevallen bedrijfsgeheim. Rondom de OV-chipkaart hanteert men nog steeds een strikt security through obscurity model. Wees een beetje voorzichtig met wat je allemaal deelt, ook als je het uit openbare informatie haalt zoals de source-code van een aantal van dit soort applicaties.

https://www.nrc.nl/nieuws/2011/09/08/brenno-de-winter-niet-vervolgd-om-hacken-ov-chipkaart-a1453107

  • check-in, check-uit en overstap zijn respectievelijk gebeurtenis nummer 1, 2 en 6 (idem)

Vertaalt naar integers inderdaad wel, en int 4 is 'inspectie', beter bekend als controle. Dat werd destijds nog niet actief gebruikt.
Reputatie 6
Badge +2
Door de vrij lange stukken tekst en het gebruik van allerlei terminologie die niet op elkaar aansluit (dat ligt niet specifiek aan jou, er is in deze branche veel te weinig consistentie en documentatie) is het soms lastig om de precieze, concrete vraag te bepalen. Wat wil je precies uitzoeken?
Niet één bepaalde kwestie, maar wat achtergrondkennis hebben. Die kan van pas komen bij genoemde tegenstrijdigheden (1. 'Vol tarief'' aangeven, maar dat (gelukkig) niet toepassen. 2. De NS-kaartautomaat laat zien dat het instaptarief bij Blauwnet € 10 is bij vrij reizen met Dal Vrij, maar Blauwnet past dat terecht niet toe. Zet Blauwnet verkeerde informatie op de kaart of maakt de NS-kaartautomaat zelf een fout; antwoord: het eerste), en bij de bovengenoemde kwestie dat maar een deel van de informatie op de kaart bij in-/uitchecken snel genoeg beschikbaar is.

Aanvulling: bij de zesuursregel voor het beginnen van een nieuwe reis (waardoor er sprake is van een ''check-in'' in strikte zin en niet van een ''overstap'', waardoor daarbij van rit naar reis niet meer werkt) bleek er verschil tussen niet-NS vervoerders wat betreft het dóórtellen van de zes uur. Wat er in dit verband door vervoerders op de kaart wordt geschreven en van de kaart wordt gelezen zou ook wel verhelderend zijn.
Puur vanuit onderzoeksoogpunt zou het erg interessant zijn om met een groep mensen opnieuw naar de verouderde software te kijken en wijzigingen te gaan maken. Ik ben alleen bang dat TLS en de vervoerders daar anders over denken.
Puur vanuit onderzoeksoogpunt zou het erg interessant zijn om met een groep mensen opnieuw naar de verouderde software te kijken en wijzigingen te gaan maken. Ik ben alleen bang dat TLS en de vervoerders daar anders over denken.
Dat lijkt mij een slecht idee voor de werkgelegenheid. 🤔 Als je een ondeugdelijk systeem vervangt door een deugdelijk systeem, heb je een stuk minder te toen. En de eventuele inhuurkrachten, die oude systemen in de lucht houden, zijn dan overbodig. Volgens mij is het uiteindelijk met die de Winter wel goed afgelopen. Maar had hij niet eerst veel gezeik omdat hij de vinger op de zere plek had gelegd?
Tsja, daar weten bepaalde huisleveranciers idd alles van 🤣

Ik doelde overigens meer op software zoals mfocGUI, de tools die het uitlezen en interpreteren van OV-chipkaart data mogelijk maken, daarmee kom je niet in het vaarwater van de grote jongens verders.
Reputatie 6
Badge +2
201806 19 21:47
Alle variabele gegevens op de ovc die het verdere verloop van een reis bepalen (waaronder het nog komende saldoverloop, afhankelijk van het verdere in- en uitchecken) zouden op elk moment bij een NS-kaartautomaat moeten kunnen worden opgevraagd. Als bij het inchecken wordt bepaald met hoeveel procent korting wordt gereisd en dit gegeven wordt dan op de kaart gezet, dan zou dit direct daarna (en later) op de kaartautomaat te zien moeten zijn op elke check-in-regel van het transactieoverzicht. Het instaptarief dat is ingehouden staat waarschijnlijk op de kaart, dat zou ook bij een NS-kaartautomaat moeten kunnen worden opgevraagd. De begintijd van de reis die voor de zesuursregel wordt bijgehouden staat waarschijnlijk op de kaart zodat bij een check-in niet diverse transacties eerder op de dag hoeven te worden uitgeplozen om te bepalen of de nieuwe check-in een check-in in strikte zin of een overstap is (zoiets duurt te lang, hebben we gehoord). Deze begintijd zou ook bij een NS-kaartautomaat moeten kunnen worden opgevraagd.

Dit betekent dus ook dat het transactieoverzicht op de 1xx en 2xx niet gebrekkiger zou moeten zijn dan dat op de 3xx, dus niet ''check-in'' zeggen als het een ''overstap'' is.
Theoretisch en praktisch is er veel mogelijk. Verschillende forumleden hebben dit, dacht ik, al aangegeven. Een koppeling met de back-end is vanuit de reiziger wenselijk. En natuurlijk hoeft die koppeling niet altijd direct in verbinding te staan met de back-end.
Reputatie 6
Badge +2
Theoretisch en praktisch is er veel mogelijk. Verschillende forumleden hebben dit, dacht ik, al aangegeven. Een koppeling met de back-end is vanuit de reiziger wenselijk. En natuurlijk hoeft die koppeling niet altijd direct in verbinding te staan met de back-end.
Dat is wat anders, ik heb het over het vollediger uitlezen van de ovc bij de kaartautomaat, en wel met toevoeging van data die nota bene nu al speciaal zo zijn georganiseerd dat ze zelfs heel snel kunnen worden uitgelezen bij in- en uitchecken.

Reageer