В начале половины 20-го века по большинству автомагистралей требовалась плата за проезд, а Пенсильванская магистраль была одной из первых платных автомагистралей штата, когда она открылась в 1940 году. Позже, в 1956 году, IHS. была создана, в которой федеральное правительство взяло на себя оплату 90% дорожных сборов, оставив остальные 10% на усмотрение штатов, что в конечном итоге сделало большинство автомагистралей бесплатными, какими мы их знаем сегодня.

Представляя 486,6 из 522 миль платных дорог (93,2%) в Пенсильвании и принося 214,6 млн долларов дохода в прошлом году, PA Turnpike является крупнейшей платной автомагистралью в штате как по размеру, так и по доходам. Когда я регулярно ехал из Филадельфии (где я сейчас живу и учусь в колледже) в Уилкс-Барре (мой родной город), испытание было знакомым. Возьмите билет. Проехать 100 миль. Обратный билет. Платите 12,40 долларов — это отстой. Это жизнь. Но однажды в моем путешествии меня осенило. Этот билет имеет штрих-код. Штрих-коды хранят данные. Данные могут быть спроектированы.

Эта мысль положила начало месячной задаче фотографировать мои билеты на магистраль PA Turnpike и пытаться реконструировать данные, закодированные в штрих-коде. И знаешь, что? Мне удалось — в основном. Вот как я это сделал и что это значит. Если это звучит причудливо или сложно, это не так, как вы скоро узнаете.

Шаг 1: Чтение штрих-кода

Большинство форматов штрих-кодов стандартизированы, потому что хранение данных — это не то, в чем вы хотите, чтобы все заново изобретали велосипед. После визуального сравнения распространенных стандартов я пришел к выводу, что PA Turnpike использует стандарт, известный как PDF-417. Это общий стандарт, используемый в различных правительственных документах, включая будущие водительские права Real ID и различные визы. Выяснив тип штрих-кода, я смог использовать программное обеспечение для чтения штрих-кодов онлайн, которое я обнаружил для считывания данных со штрих-кода, в результате чего были получены следующие данные:

“00 00 fa 87 58 d8 5c 24 02 01 02 a2 04 00 94 83 62 ac |~~X~\$~~~~~~~~b~ |”

Сделав вывод, что начальный «00 00» и конечный «| ~~Х~\$~~~~~~~~б~б~ |” можно было игнорировать, поскольку они представляли собой часть общей системы форматирования штрих-кода (показана слева), у нас остались желаемые данные:

fa 87 58 d8 5c 24 02 01 02 a2 04 00 94 83 62 ac

Шаг 2: реинжиниринг данных

В верхней части билетов PA Turnpike есть 8 полей. Выяснение того, какие поля соответствуют тому, что казалось идеальным местом для начала.

Во-первых, очевидно, что поля LANE, C и AX (2, 1, 2) соответствуют трем средним шестнадцатеричным цифрам. Было невозможно сказать, каково было положение LANE и AX, поскольку они хранили одни и те же значения, но после сравнения другого билета, в котором я убедился, что вошел в дорожку 3, я смог подтвердить, какое из этих трех полей какое. Что ж, это было легко… 3 поля позади, 5 осталось.

Одно было совершенно точно. Больше билетов будет иметь больше различий в данных и упростит задачу. Я искал в Интернете любые другие билеты, которые я мог найти. Хоть я и не знал их содержания, надеюсь, дополнительные примеры помогут быстрее подкрепить или опровергнуть мои теории. К сожалению, мне удалось найти в Интернете только один дополнительный билет, содержащий действительно сканируемый штрих-код, но один лучше, чем ничего.

Все билеты содержали пустое поле COLL, соответствующее 00, найденному в данных. Это оказалось бы устаревшим полем, обозначающим COLL-ектор билета. В последнее время автоматизированная вычислительная система магистрали оставила это поле неиспользованным. 4/8 — на полпути.

Однако мой оптимизм не был бы непоколебимым, поскольку более поздние области будут более сложными.

Теперь у меня было 4 личных билета (две поездки, два билета на поездку), два из которых были на выезд из Филадельфии и прибытие в Уилкс-Барре, а два других — наоборот. Я смог заметить, что 3-е поле, в которое я входил в Уилкс-Барре, всегда содержало 36, в то время как билеты, в которые я входил на магистраль из Филадельфии, всегда содержали 39. Это, на мой взгляд, не имело смысла. Уилкс-Барре - съезд 105. От Мид-Каунти до Филадельфии - съезд 20А. Однако поля коррелировали с местоположением, так что это не было простым совпадением. Я должен был бы копнуть глубже.

Как упоминалось ранее, магистраль PA Turnpike довольно старая, как и система электронных билетов. В конце 2000 года нумерация выходов изменилась с последовательной на нумерацию по расстоянию. Однако уже реализованная устаревшая система билетов не была обновлена ​​внутри, чтобы отразить это изменение. Этот PDF-файл на веб-сайте PA Turnpike обеспечивает полезный поиск старых номеров выездов и их современных аналогов. Выход Wilkes Barre 105 раньше был 36 — имеет смысл. Однако выезд из Мид-Каунти выглядит странно. В старой системе это было 25А, но теперь 39, что должно соответствовать старому номеру выхода на Кларкс-Саммит. Попробовав свою теорию на случайном билете, который я нашел в Интернете, осталось 4, соответствующих выходу из Батлер-Вэлли. Моя теория подтверждается, но отмечу некоторые странности и неточности с системой нумерации. Я не собираюсь объезжать все съезды в штате, чтобы разобраться с сопоставлением номеров, но я бы счел старые номера съездов неплохой грубой идеей. — В любом случае, это поле точно хранит точку входа (MP). — 5/8

Далее давайте посмотрим на нашу транзакцию с номером 1186. Он больше 255 (0xff), поэтому должен храниться более чем в одном байте. Преобразовывая каждое поле в десятичное число, нет ни 11, ни 86. Он должен быть закодирован как одно число из 4 символов. Преобразование 1186 в шестнадцатеричный формат дает нам 04 A2, который содержится в данных. Это, однако, обратное, но этот шаблон верен для всех билетов, поэтому он должен быть действительным. Помните об обратном шаблоне, когда пытаетесь разобраться с датой и временем. — 6/8

С двумя оставшимися полями, датой и временем, у меня осталось два пустых места в моих данных. Кажется, я на правильном пути. Теперь обычно компьютеры хранят данные в виде одного числа, представляющего количество секунд, прошедших с эпохи Unicode. Я не буду объяснять это здесь, но вот видео, если вам интересно. По сути, это одно число, подсчитывающее количество секунд с 1 января 1970 года. Но осталось 2 поля, а не одно. Удивит ли меня, возможно, устаревшая компьютерная система, созданная правительством, использующая проприетарный формат кодирования времени? -Нет. Каждое из двух оставшихся полей данных имело длину 4 байта. Предполагая, что один для месяца, один для даты и два для года (будучи больше 255), это все равно не складывается. Может быть, первое поле хранит время? Один байт для часов, 1 для минут, 1 для секунд, один для ???. Это просто не имеет смысла. Мои последние два билета были очень близки по времени друг к другу — около 14 часов. Кроме того, они оказались единственными, кто разделял определенное общее поле. Технически вторая заявка была получена на следующий день, но после преобразования в GMT с поправкой на часовые пояса (которые компьютеры обычно игнорируют внутренне) метки времени двух заявок появились в один и тот же день. Преобразование времени по Гринвичу в временную метку Unix, а затем в шестнадцатеричный формат показало, что первые четыре байта на самом деле были стандартной временной меткой Unix, сохраненной в обратном порядке. 8/8

Но как насчет последних 4 полей?

Я так и не понял, но у меня есть несколько теорий.

Теория 1) Это хэш остальных данных, чтобы гарантировать, что они не подделаны. Я пробовал хэшировать с помощью MD5, SHA1, SHA256, и цифры в данных не соответствуют части вывода хеш-функции. Это также не хэш CRC32, чего бы он ни стоил. - Не это

Теория 2) В данных хранятся пустые поля для будущего расширения, заполненные случайным шумом — маловероятно, учитывая, что устаревшее поле COLL просто оставлено пустым.

Теория 3) Это способ указать, с какого расширения магистрали пришел билет, поэтому номер MP может быть правильно спарен. - навряд ли

Теория 4) Это какой-то внутренний идентификатор отслеживания/сбора данных, такой как фотография вашего автомобиля — я считаю наиболее вероятным, но это просто предположение.

Другие мысли: отладочные данные разработчика?

Шаг 3: Выводы

Теоретически одним из очевидных вариантов использования для этого может быть создание и печать измененного штрих-кода в вашем автомобиле, наклеивание его на старый, а затем использование измененного билета для экономии денег путем изменения CLASS, AX и/или MP. , ценность. Возможно, это не сработает из-за возможных уникальных номеров транзакций, но я не собираюсь пытаться. Я не юрист, но, вероятно, это незаконно в соответствии с законами об электронном взимании платы за проезд или чем-то подобным несанкционированному использованию компьютера, поэтому не делайте этого, если не хотите нарушать закон.

Как видите, билетная система PA Turnpike намного проще, чем вы могли себе представить. Это представляет собой интересную задачу в проектировании систем, в которой одна система, используемая десятилетиями, смогла адаптироваться и по-прежнему оставаться актуальной и работоспособной сегодня. Я считаю, что жизнь системы бумажных билетов подойдет к концу в течение следующего десятилетия. PA Turnpike уже тестирует систему, в которой компьютер выставляет счета водителям в электронном виде, визуально считывая номерные знаки, не говоря уже о системе EZ-Pass, которая используется уже много лет. Попытка реконструировать эти билеты была интересной задачей и помогла отточить мои аналитические навыки и навыки обратного инжиниринга. Как видите, мир обычно не так сложен или далек, как кажется. Ведь его придумал кто-то вроде вас.

Помня об этом, я призываю Интернет помочь разгадать тайну последних четырех полей. Я знаю, что это возможно.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ. Эта статья предназначена только для образовательных целей. Использование этой статьи для мошенничества в системе магистрали штата Пенсильвания не поощряется и не поощряется.