Ковыряем UltraLight дальше...
ХУЙ! Тупо скопировать мерошный билет UltraLight не прокатило...
Надысь привезли пяток пустых карточек UltraLight мне для экспериментов.
Самое главное, что я хотел проверить - участвует ли заводской серийный номер (ибо кроме заводского, в каждом билете пробит еще и свой, "метрошный", который напечатан на карточке) в генерации так называемой мной "контрольной суммы". Теперь я однозначно понял -- участвует. И это плохо, ибо все, пригнетышь. Теперь остался лишь один единственный способ расковырять ультралайты -- понять принцип генерации этой "контрольной суммы" (способ с созданием эмулятора я не учитываю -- это уже другая история). Надо собрать статистических слепков билетов и начать изучение. Кому не влом, прошу тоже включиться и помочь мне. Вместе веселее.
А сейчас я поделюсь с вами информацией, которую удалось раскопать мне:
Первое, это заводской серийный номер. Он записан в первой странице. snX это байты серийного номера, ccX это контрольные суммы разных частей этой страницы (ищите в датащите), int -- "внутренняя информация", всегда и везде это 48h. Вся первая страница зашивается на заводе и ее изменение невозможно.
Дальше идут биты блокировки блокировок. Позволяют запретить устанавливать или снимать блокировки страниц или OTP. Ставятся в единицу 1 раз, а обратно никак. В метро не используются.
Дальше идет зона OTP со своим битом блокировки изменения. Бит блокировки в метро не используется. Зона ОТП используется. В билетах на какое-то кол-во поездок, с каждой новой поездкой "выжигается" часть битов в этой зоне. На примере одно- и двухпоездочного билетов: когда едем по однопоездочному, то в эту зону записываются все единицы сразу, кроме двух самых младших бит. Когда едем по двухпоездочному - после первой поездки пишется половина бит из этой зоны, причем последних двух бит опять как будто бы не существует (мне это показалось странным), т.е. пишется последний по счету бит верхней строчки и все, кроме двух последних нижней. При второй поездке единицами дописывается оставшаяся часть верхней строчки. Интересно посмотреть, как пишется в пятипоездочном. Мне кажется, что по томуже принципу - с каждой новой поездкой записывается часть бит, только более мелкая, чтоб получилось разделить все поле на пять поездок. Вообще, это очень странный подход... Зачем так сделали? Да, в трехдневных пенсионных билетах эту зону метро не трогает.
Далее пошли страницы:
В четвертой странице записан, предположительно, идентификатор московского метро (41), потом, наверное, тип билета (87), может еще что... Потом еще восьмерка. За этим всем - номер билета, который напечатан на самом билете. Причем записан интересно - начинается со второй половины(!) третьего байта, а заканчивается на первой половине третьего байта второй страницы... У этого билета номер 07B6E540. Потом идет еще восьмерка, 17 и 43. Наверное, что-то значат - надо собирать статистику, чтоб понять.
Дальше - всегда пустая страница, а за ней - два дублирующихся блока по 4 страницы. Ну, можно сказать, по 3. Четвертая - всегда пустая.
Так вот, в первой из этих трех страниц записан, предположительно, тоже какая-то инфа, зависящая от типа билета и дата продажи. Мне кажется, что дата продажи это 3F. Может это только часть ее, и какой-нить из соседних байт тоже относится к дате продажи. Скорее всего, это счетчик дней, начиная с какой-то исторической даты - только не с Рождества Христова, это точно :) Эта страница заблокирована (как и множество других) от греха подальше.
Во второй странице мы наблюдаем счетчик поездок. Причем, для поездочных билетов это счетчик оставшихся поездок, а для временного пенсионного - счетчик совершенных. Счетчик поездок занимает два байта (ну, либо первый байт в принципе пустой). А вот в следующие два пишется время последней поездки (для ограничения по времени между поездками). Считает он, скорее всего, в минутах, относительно начала дня. Это тоже надо проверять. Т.к. этот билет на одну поездку не использован -- поле для записи времени пустое. Вообще, по хорошему, вместе со временем надо бы и дату куда-то писать. Вдруг сегодня я проехал в 11:00, а завтра поеду в 11:01... Получается, что время пересечется (если дата не записана), и турникет меня не пустит. Дату я не нашел. Может, это и не время вовсе. Опять же, надо изучать статистику.
А вот в третьей странице записана жопа. Походу, это контрольная сумма. НАМ НАДО РАЗГАДАТЬ КАК ОНА СЧИТАЕТСЯ. Почему я пришел к такому выводу? Очень просто. Покупаем два билетика на одну поездку подряд. Друг от друго они будут отличаться всего двумя байтами (и то всего на два или несколько бит) -- один байт в заводском номере, один в номере метрошном. А вот эта страница будет отличаться СОВСЕМ. Т.е. никак не похожа. При попытке изменить в этой странице, или в предыдущей хотя бы один бит, валидатор в метро говорит - "плохой билет". При попытке перекатать содержимое билета один в один на пустую карточку (кроме заводского номера), тоже "плохой билет". Следовательно, в генерации этой страницы участвует и заводской серийник.
Да, сразу говорю, что игра с блокировками не помогает. Можно, например, заблокировать изменение данных в этих страницах, или в зоне OTP. При этом валидатор говорит, что билет нормальный, а турникет не пускает. Видимо, турникет пишет в билет, потом смотрит - а там нихрена не изменилось :) Вот и орет.
Так что вот так. Все мои мысли, вроде ничо не забыл. Надо начинать собирать статистику и пытаться разгадать тайну "контрольной суммы". Может, все не так уж сложно, кто знает...
У кого какие мысли? Каментим.
Надысь привезли пяток пустых карточек UltraLight мне для экспериментов.
Самое главное, что я хотел проверить - участвует ли заводской серийный номер (ибо кроме заводского, в каждом билете пробит еще и свой, "метрошный", который напечатан на карточке) в генерации так называемой мной "контрольной суммы". Теперь я однозначно понял -- участвует. И это плохо, ибо все, пригнетышь. Теперь остался лишь один единственный способ расковырять ультралайты -- понять принцип генерации этой "контрольной суммы" (способ с созданием эмулятора я не учитываю -- это уже другая история). Надо собрать статистических слепков билетов и начать изучение. Кому не влом, прошу тоже включиться и помочь мне. Вместе веселее.
А сейчас я поделюсь с вами информацией, которую удалось раскопать мне:
Первое, это заводской серийный номер. Он записан в первой странице. snX это байты серийного номера, ccX это контрольные суммы разных частей этой страницы (ищите в датащите), int -- "внутренняя информация", всегда и везде это 48h. Вся первая страница зашивается на заводе и ее изменение невозможно.
Дальше идут биты блокировки блокировок. Позволяют запретить устанавливать или снимать блокировки страниц или OTP. Ставятся в единицу 1 раз, а обратно никак. В метро не используются.
Дальше идет зона OTP со своим битом блокировки изменения. Бит блокировки в метро не используется. Зона ОТП используется. В билетах на какое-то кол-во поездок, с каждой новой поездкой "выжигается" часть битов в этой зоне. На примере одно- и двухпоездочного билетов: когда едем по однопоездочному, то в эту зону записываются все единицы сразу, кроме двух самых младших бит. Когда едем по двухпоездочному - после первой поездки пишется половина бит из этой зоны, причем последних двух бит опять как будто бы не существует (мне это показалось странным), т.е. пишется последний по счету бит верхней строчки и все, кроме двух последних нижней. При второй поездке единицами дописывается оставшаяся часть верхней строчки. Интересно посмотреть, как пишется в пятипоездочном. Мне кажется, что по томуже принципу - с каждой новой поездкой записывается часть бит, только более мелкая, чтоб получилось разделить все поле на пять поездок. Вообще, это очень странный подход... Зачем так сделали? Да, в трехдневных пенсионных билетах эту зону метро не трогает.
Далее пошли страницы:
В четвертой странице записан, предположительно, идентификатор московского метро (41), потом, наверное, тип билета (87), может еще что... Потом еще восьмерка. За этим всем - номер билета, который напечатан на самом билете. Причем записан интересно - начинается со второй половины(!) третьего байта, а заканчивается на первой половине третьего байта второй страницы... У этого билета номер 07B6E540. Потом идет еще восьмерка, 17 и 43. Наверное, что-то значат - надо собирать статистику, чтоб понять.
Дальше - всегда пустая страница, а за ней - два дублирующихся блока по 4 страницы. Ну, можно сказать, по 3. Четвертая - всегда пустая.
Так вот, в первой из этих трех страниц записан, предположительно, тоже какая-то инфа, зависящая от типа билета и дата продажи. Мне кажется, что дата продажи это 3F. Может это только часть ее, и какой-нить из соседних байт тоже относится к дате продажи. Скорее всего, это счетчик дней, начиная с какой-то исторической даты - только не с Рождества Христова, это точно :) Эта страница заблокирована (как и множество других) от греха подальше.
Во второй странице мы наблюдаем счетчик поездок. Причем, для поездочных билетов это счетчик оставшихся поездок, а для временного пенсионного - счетчик совершенных. Счетчик поездок занимает два байта (ну, либо первый байт в принципе пустой). А вот в следующие два пишется время последней поездки (для ограничения по времени между поездками). Считает он, скорее всего, в минутах, относительно начала дня. Это тоже надо проверять. Т.к. этот билет на одну поездку не использован -- поле для записи времени пустое. Вообще, по хорошему, вместе со временем надо бы и дату куда-то писать. Вдруг сегодня я проехал в 11:00, а завтра поеду в 11:01... Получается, что время пересечется (если дата не записана), и турникет меня не пустит. Дату я не нашел. Может, это и не время вовсе. Опять же, надо изучать статистику.
А вот в третьей странице записана жопа. Походу, это контрольная сумма. НАМ НАДО РАЗГАДАТЬ КАК ОНА СЧИТАЕТСЯ. Почему я пришел к такому выводу? Очень просто. Покупаем два билетика на одну поездку подряд. Друг от друго они будут отличаться всего двумя байтами (и то всего на два или несколько бит) -- один байт в заводском номере, один в номере метрошном. А вот эта страница будет отличаться СОВСЕМ. Т.е. никак не похожа. При попытке изменить в этой странице, или в предыдущей хотя бы один бит, валидатор в метро говорит - "плохой билет". При попытке перекатать содержимое билета один в один на пустую карточку (кроме заводского номера), тоже "плохой билет". Следовательно, в генерации этой страницы участвует и заводской серийник.
Да, сразу говорю, что игра с блокировками не помогает. Можно, например, заблокировать изменение данных в этих страницах, или в зоне OTP. При этом валидатор говорит, что билет нормальный, а турникет не пускает. Видимо, турникет пишет в билет, потом смотрит - а там нихрена не изменилось :) Вот и орет.
Так что вот так. Все мои мысли, вроде ничо не забыл. Надо начинать собирать статистику и пытаться разгадать тайну "контрольной суммы". Может, все не так уж сложно, кто знает...
У кого какие мысли? Каментим.