сайт Друзей
В Большой звёздный зал на полнокупольную программу «Космическая книга странствий» приглашает ребят и их родителей в новогодние праздники Нижегородский планетарий им. Г. М. Гречко . Лунные кратеры,
Компьютеры и интернет
Кто пользовался хоть раз в жизни картами РОЛ, откликнетесь!
Возможна скупка использованных карт РОЛ.
Пожалуйста, прочтите до конца!!!
Если у Вас есть использованные карты РОЛ (любые: 5RU, 10RU, 20RU) не спешите их выкидывать! Пришлите, их номера и коды мне на почту dnox@mail.ru или оставьте сообщение здесь. В сообщении укажите:
- серию (над ней обычно стоит надпись "код активации", состоит из 10 цифр)
- код карты (то, что находилось под защитным слоем, указан справа от серии через тире, 4 записи по 5 цифр)
- номер карты (находится в одном из углов карты, состоит из 6 цифр)
Какая Вам с того выгода:
- В случае достаточного количества использованных карт, РОЛ будет взломан (необходимо примерно 100 карт, каждая карта приближает к этому, поэтому даже если Вы можете сказать номер только одной карты - это уже очень много)
- Вы получите поистине дешевый (или даже вовсе бесплатный) доступ к интернету. (ОБЕЩАЮ)
- Поможете мне и себе.
ЕСЛИ ВЫ ПРИШЛЕТЕ НОМЕР И КОД ИСПОЛЬЗОВАННОЙ (ранее активированной) КАРТЫ, У МЕНЯ НЕ ПОЯВИТСЯ НИКАКОЙ ВОЗМОЖНОСТИ НАНЕСТИ ВАМ КАКОЙ-ЛИБО ВРЕД (использовать карту повторно, получить доступ к интернету за ваш счет - НЕВОЗМОЖНО)
Спасибо всем, кто откликнется!
Пожалуйста, прочтите до конца!!!
Если у Вас есть использованные карты РОЛ (любые: 5RU, 10RU, 20RU) не спешите их выкидывать! Пришлите, их номера и коды мне на почту dnox@mail.ru или оставьте сообщение здесь. В сообщении укажите:
- серию (над ней обычно стоит надпись "код активации", состоит из 10 цифр)
- код карты (то, что находилось под защитным слоем, указан справа от серии через тире, 4 записи по 5 цифр)
- номер карты (находится в одном из углов карты, состоит из 6 цифр)
Какая Вам с того выгода:
- В случае достаточного количества использованных карт, РОЛ будет взломан (необходимо примерно 100 карт, каждая карта приближает к этому, поэтому даже если Вы можете сказать номер только одной карты - это уже очень много)
- Вы получите поистине дешевый (или даже вовсе бесплатный) доступ к интернету. (ОБЕЩАЮ)
- Поможете мне и себе.
ЕСЛИ ВЫ ПРИШЛЕТЕ НОМЕР И КОД ИСПОЛЬЗОВАННОЙ (ранее активированной) КАРТЫ, У МЕНЯ НЕ ПОЯВИТСЯ НИКАКОЙ ВОЗМОЖНОСТИ НАНЕСТИ ВАМ КАКОЙ-ЛИБО ВРЕД (использовать карту повторно, получить доступ к интернету за ваш счет - НЕВОЗМОЖНО)
Спасибо всем, кто откликнется!
Ничего у тебя не получится. Не ты первый я думаю. Да к тому же с какого х роловцам придумывать какую-то закономерность кодов карт? Генерируются случайным образом и запоминаются в базе данных. Вот и все. Единственное что ты можешь - так это полным перебором пройтись, но учитывая сколько там символов.... Удачи!
Darrien, я не первый, но именно поэтому у меня получится. Наверняка есть те, у кого получилось, но - это же золотая жила - поэтому они не афишируют свои имена и знания. И уж, конечно, не вешают программ типа "Бесплатный генератор РОЛ". Что касается генерирования случайных последовательностей и запоминания таковых в базе данных. ЭТо не совсем так, по крайней мере, у РОЛа. Тем более, что все случайные последовательности - псевдослаучайные:) КАЖДЫЙ ГЕНЕРАТОР СЛУЧАЙНЫХ ЧИСЕЛ ГЕНЕРИРУЕТ ИХ ПО НЕКОТОРОЙ ВПОЛНЕ ОПРЕДЕЛЕННОЙ ФУНКЦИИ. (это истина, а потому большими буквами) Есть так называемые равномерно распределенные последовательности.... Но не будем вдаваться в подробности.. Просто, поверь, это возможно и это будет так.
Тебе тоже удачи!
С уважением.
п.с. если у тебя использованные карты, напиши инфу о них, пожалуйста.
Тебе тоже удачи!
С уважением.
п.с. если у тебя использованные карты, напиши инфу о них, пожалуйста.
Offspring сказал(а):
ЭТо не совсем так, по крайней мере, у РОЛа.
ЭТо не совсем так, по крайней мере, у РОЛа.
А как, как у РОЛа? Жутко ж интересно :-)
Тем более, что все случайные последовательности - псевдослаучайные:) КАЖДЫЙ ГЕНЕРАТОР СЛУЧАЙНЫХ ЧИСЕЛ ГЕНЕРИРУЕТ ИХ ПО НЕКОТОРОЙ ВПОЛНЕ ОПРЕДЕЛЕННОЙ ФУНКЦИИ. (это истина, а потому большими буквами)
Ага. Например, аппаратный ГСЧ, использующий в качестве источника энтропии разницу между временем прилёта частиц распада радиоактивного элемента :)
Да даже банальный /dev/random под линуксом берёт чисто случайные данные для своего пула. Ну, например, CRC от последнего IP-пакета, переданного по сети - чем не источник энтропии :) ? Четыре младших бита от него, один младший бит от звука, идущего с микрофона, пару бит от поксоренных последних десяти букв, набранных на клавиатуре да младший бит от количества миллисекунд между двумя последовательными нажатиями клавиш - вот и истинно случайный байт готов, не поддающийся никакому криптоанализу :)
Имею предложение - обсудить математические аспекты "взлома" карточек провайдера (а именно - реверс-инжининга алгоритма валидации номеров этих карточек) и перспективы этого дела.
В частности, ты писал "П.п.с. Если ВЫ не верите, что возможно взломать, я готов вас переубедить, поверьте, успехи уже есть. Почти разгадано, как формируется серия."
Расскажи поподробнее, как, по-твоему, хотя бы приблизительно выглядит алгоритм валидации У КАКОГО-НИБУДЬ ГИПОТЕТИЧЕСКОГО ПРОВАЙДЕРА, и каких данных тебе не хватает для уточнения этого алгоритма.
А пока попробую я сам вывести некоторые мысли.
Рассмотрим некоторую систему валидации кодов для доступа к каким-то услугам, причём с равным количеством или качеством предлагаемых услуг - скажем, 5 единиц чего-то, 10 единиц чего-то и 20 единиц чего-то.
Положим, у нас есть эмпирическая информация, что следующие коды валидны для получения доступа к 20 единицам какого-то товара/услуги: 5231125028-16027-36711-14705-03968 и 5231125032-14996-45111-32309-24665.
Можно уже сделать какие-нибудь выводы?
Начнём с первого вопроса: сколько бит информации содержит запись кода вообще? Одна компонента из десяти десятичных цифр, 4 компоненты по пять десятичных цифр, всего 30 десятичных цифр. Результат может принимать 10^30 различных значений. Для записи в двоичной системе, соответственно, нужно log_2 10^30 бит, или ~99.66 бит - округлим до 100 бит.
Думаем дальше. Можно хотя бы приблизительно оценить количество валидных кодов в этой системе (из чего выведем отношение количества валидных кодов к количеству невалидных кодов)?
Смотрим на первую десятизначную компоненту кода. Некоторые подозрения вызывает то, что в двух известных нам кодах эти компоненты весьма близки (хотя именно это вызывает некоторые дополнительные сомнения ввиду того, что уж слишком близки друг к другу случайно попавшиеся коды). Можно было бы предположить, что эта компонента изменяется последовательно во всех кодах и уникально идентифицирует код. Тогда, в таком случае данная система кодирования позволяет выпустить до 10^10 (10 миллиардов) карточек, не меняя систему кодирования и валидации).
Реалистична ли такая оценка? При оценочной интернет-аудитории достаточно крупного города в 100 000 человек (источники информации называть не буду - сами догадаетесь) и среднем потреблении услуг, скажем, в одну 20-единичную карточку в день на человека, городу надо в день 100 000 таких карточек. Положим, провайдер услуг обслуживает около 50 городов - в месяц потребление карточек будет порядка 5 000 000 карточек. Пусть даже мы ошиблись, скажем, в два раза, и провайдер обслуживает больше городов, и в среднем одному человеку надо больше одной 20-единичной карточки в месяц - сомнительно, чтобы мы ошиблись больше, чем в два раза. Так что пусть даже потребление карточек клиентами провайдера услуг в два раза больше, чем наша оценка - всё равно потребление карточек будет всего около 10 000 000 (10 миллионов) карточек в месяц.
Достаточно много, правда? Но даже несмотря на это, используемая система кодирования в случае, если каждая карточка однозначно идентифицируется 10-значным компонентом кода, позволит продержаться 1000 месяцев (10 миллиардов карточек разделить на 10 миллионов карточек в месяц). Или 83 года. Неплохо, в принципе, реалистично. За 83 года или визирь умрёт, или ишак, так что систему будет поменять полезно в любом случае - если провайдер услуг сам столько просуществует...
Итак. Мы имеем 10^10 валидных кодов из 10^30 кодов всего. Это значит, что на один валидный код приходится (10^20 - 1) невалидный код - или что среди каждых 10^20 кодов есть в среднем только один валидный.
Что можно предположить дальше?
Можно подумать, каким образом производится валидация кода.
В принципе, есть два возможных варианта. Первый - существует некоторая функция, позволяющая выяснить, валиден ли код, зная только сам код. Второй - существует некоторый механизм проверки валидности кода по коду, требующий дополнительных внешних данных - например, таблицы всех валидных кодов. Понятно, что наиболее сложный для реверс-инжиниринга случай - второй. Оценим для начала, вероятен ли он.
Пусть у нас есть 10^10 валидных 10^30-значных кодов, и провайдер услуг решает хранить их полный список на сервере, чтобы затруднить взлом. Наиболее сложным для взлома - а значит, наиболее вероятно используемым - является вариант, когда оставшиеся неключевые компоненты (суммарно дающие 20 десятичных знаков) генерируются для хранения на сервере абсолютно случайным способом. В таком случае, провайдер может использовать следующую схему хранения данных: таблицу с количеством элементов до 10^10, хранящую только эти 20 случайно сгенерированных десятичных знаков. Для валидации в таком случае он берёт код, делит его на первую 10-значную компоненту (i) и 20-значный остаток (j), после чего находит в своей таблице i-ый 20-значный элемент (j') и сверяет его с элементом j из кода.
Какие могут быть у провайдера проблемы с реализацией такой системы защиты? Скажу сразу - вполне очевидно, что если провайдер технологически потянет такое решение, то он наверняка именно его и реализует, ибо это сразу обесценит все попытки "взламывать" его коды - т.к. взламывать по сути нечего, вся "взламывабельная" информация генерировалась случайным образом - да наверняка не поддающимся хоть какому-то анализу псевдослучайным, как алгоритмы в большинстве компьютеров, а чисто случайным, с применением специального оборудования.
Прежде чем продолжим анализировать таблицу, вспомним, что мы до сих пор рассматривали только код либо валидный, либо невалидный, и не учитывали, что код должен ещё хранить информацию, услуге какого типа он соответствует - на 5, 10 или 20 единиц. Есть опять же три варианта: либо эта информация (в log_2 3 бита, т.е. в 1.58 бита, или примерно в 2 бита) хранится в первой десятичной компоненте, уникально идентифицирующей карточку (например, в остатке от деления номера карточки на три - 0 соответствует 5 единицам, 1 соответствует 10 единицам и 2 соответствует 20 единицам - а может быть, каким-то чуть более сложным алгоритмом), либо - для бОльшего маскирования алгоритма, но в то же время упрощения труда "взломщика"- в оставшейся 20-значной компоненте, либо - где-то на сервере в базе данных.
Вернёмся к табличному способу валидации кодов.
Итак, могут ли быть проблемы вообще с хранением и доступом к таблице из 10^10 элементов, хранящей 20 десятичных знаков?
Сразу небольшой анализ - для хранения 20 десятичных знаков нужно log_2 10^20 ~66.44 бита, или примерно 67 бит.
Есть несколько наиболее вероятных вариантов, которые мог выбрать провайдер.
Вариант первый - провайдер хранит каждый код как неинтерпретированное байтовое значение (т.е., 20 знаков кода он хранит как 20 байт). Глупый способ, конечно - неэкономно. Зато очень быстро интерпретировать. Но даже если и так, провайдеру надо всего лишь хранить 20 байт на каждый из 10^10 уникальных идентификаторов. Всего то 20*10^10 = 2 * 10^11 байт. Пусть даже ещё 1 байт для хранения типа доступа к услуге (5, 10, 20 единиц) - хотя для его хранения достаточно двух бит. Пусть даже ещё 3 slack-byte-а - для того, чтобы для каждой карточки хранилась запись в "круглые" 24 байта - провайдеру для хранения всей базы понадобится 2.4 * 10^11 байт. Пользуясь правилом производителей винчестеров "один мегабайт равен 1 000 000 байт, один гигабайт равен 1 000 000 000 (10^9) байт" получим, что для хранения базы в худшем случае понадобится (2.4 * 10^11) / (10^9) "винчестерных гигабайт". И мы получим жуткое число 240. 240 гигабайт.
Если кто-то не понял - для того, чтобы сгенерировать 20-значные "отзывы" к кодам случайным образом и хранить их прямо на валидационном сервере, делая тем самым любую попытку "взлома алгоритма валидации" бессмысленной (т.к. алгоритм валидации заключается в сравнении 20-значного "отзыва" с эталоном, хранящимся исключительно на сервере и сгенерированным абсолютно случайным способом, и не подразумевает возможности проверить валидность карточки или подобрать неизвестный заранее валидный номер без доступа к валидационному серверу - который любым достаточно умным админом закрыт от доступа из внешнего мира) провайдеру с месячным оборотом до 10 миллионов 20-долларовых карточек (умножайте сами) в худшем случае понадобится пойти к ближайшему поставщику оборудования и купить за примерно 180 долларов 250-гигабайтовый винчестер (за эти деньги он будет 7200, с кэшем в 8 мегабайт и SATA). Или два - для RAID-а. Или даже больше. Да даже если провайдер захочет разместить всё это на SCSI RAID-е, и сразу залить на весь получившийся дисковый массив сразу всю 83-летнюю базу (а не пополнять её по мере надобности), понадобится всего лишь 240-гигабайтовый объём...
Такие смешные цифры наглядно демонстрируют глупость попыток "взлома карточек" (т.к. разумный провайдер может обесценить их покупкой 250-гигабайтового дискового массива). Тем более эти попытки глупы, если провайдер разумен достаточно, чтобы не хранить 20 десятичных цифр как 24 байта, когда для хранения самих цифр достаточно 67 бит. Ведь если хранить их побитово, да ещё добавить два бита на тип услуги, да ещё даже добавить 1 slack bit, то для хранения одного отзыва понадобится только 70 бит, что меньше, чем изначальные 24 байта (192 бит) в 2.74 раза и уменьшит требуемый размер дискового массива до 87.5 "винчестерных гигабайт" (а если slack bit-ов будет 11, и размер записи будет "круглые" 80 бит, то дисковый массив понадобится ровно на 100 "винчестерных гигабайт"). А если провайдер ударится в оптимизацию и решит из 67 значащих бит 20-тисимвольного "отзыва" карточки 2 бита выделить под хранение уровня доступа (5, 10, 20 единиц) и 1 бит оставить как контрольный, то оставшиеся 64 бита, подтверждающие валидность карточки будут ровно в 3 раза меньше "взятых с горкой" изначально 24 байт, и дисковый массив понадобится всего лишь в красивые 80 гигабайт.
Ну что, ни у кого ещё не 1. пропало желание разбираться во взломе карточке, 2. (к scroll-у) притворяться, что продаёшь действительно генератор валидных кодов карточек ROL-а и верить в свою безнаказанность (а то некий небезызвестный vacuum надолго запомнился этому форуму сначала своими кулхацкерскими постами, а затем судебным "прессрелизом" по поводу суда над ним)?...
Домашнее задание читателям: рассчитать, сколько бит информации нужно получить некоему реверс-инженеру, чтобы для 10-тидесятичносимвольного кода научиться подбирать 20-десятичносимвольный "отзыв" хотя бы с 50-процентной вероятностью для случая, когда валидность пары "ключ-отзыв" проверяется некоторой функцией, принимающей на вход только эту пару.
В частности, ты писал "П.п.с. Если ВЫ не верите, что возможно взломать, я готов вас переубедить, поверьте, успехи уже есть. Почти разгадано, как формируется серия."
Расскажи поподробнее, как, по-твоему, хотя бы приблизительно выглядит алгоритм валидации У КАКОГО-НИБУДЬ ГИПОТЕТИЧЕСКОГО ПРОВАЙДЕРА, и каких данных тебе не хватает для уточнения этого алгоритма.
А пока попробую я сам вывести некоторые мысли.
Рассмотрим некоторую систему валидации кодов для доступа к каким-то услугам, причём с равным количеством или качеством предлагаемых услуг - скажем, 5 единиц чего-то, 10 единиц чего-то и 20 единиц чего-то.
Положим, у нас есть эмпирическая информация, что следующие коды валидны для получения доступа к 20 единицам какого-то товара/услуги: 5231125028-16027-36711-14705-03968 и 5231125032-14996-45111-32309-24665.
Можно уже сделать какие-нибудь выводы?
Начнём с первого вопроса: сколько бит информации содержит запись кода вообще? Одна компонента из десяти десятичных цифр, 4 компоненты по пять десятичных цифр, всего 30 десятичных цифр. Результат может принимать 10^30 различных значений. Для записи в двоичной системе, соответственно, нужно log_2 10^30 бит, или ~99.66 бит - округлим до 100 бит.
Думаем дальше. Можно хотя бы приблизительно оценить количество валидных кодов в этой системе (из чего выведем отношение количества валидных кодов к количеству невалидных кодов)?
Смотрим на первую десятизначную компоненту кода. Некоторые подозрения вызывает то, что в двух известных нам кодах эти компоненты весьма близки (хотя именно это вызывает некоторые дополнительные сомнения ввиду того, что уж слишком близки друг к другу случайно попавшиеся коды). Можно было бы предположить, что эта компонента изменяется последовательно во всех кодах и уникально идентифицирует код. Тогда, в таком случае данная система кодирования позволяет выпустить до 10^10 (10 миллиардов) карточек, не меняя систему кодирования и валидации).
Реалистична ли такая оценка? При оценочной интернет-аудитории достаточно крупного города в 100 000 человек (источники информации называть не буду - сами догадаетесь) и среднем потреблении услуг, скажем, в одну 20-единичную карточку в день на человека, городу надо в день 100 000 таких карточек. Положим, провайдер услуг обслуживает около 50 городов - в месяц потребление карточек будет порядка 5 000 000 карточек. Пусть даже мы ошиблись, скажем, в два раза, и провайдер обслуживает больше городов, и в среднем одному человеку надо больше одной 20-единичной карточки в месяц - сомнительно, чтобы мы ошиблись больше, чем в два раза. Так что пусть даже потребление карточек клиентами провайдера услуг в два раза больше, чем наша оценка - всё равно потребление карточек будет всего около 10 000 000 (10 миллионов) карточек в месяц.
Достаточно много, правда? Но даже несмотря на это, используемая система кодирования в случае, если каждая карточка однозначно идентифицируется 10-значным компонентом кода, позволит продержаться 1000 месяцев (10 миллиардов карточек разделить на 10 миллионов карточек в месяц). Или 83 года. Неплохо, в принципе, реалистично. За 83 года или визирь умрёт, или ишак, так что систему будет поменять полезно в любом случае - если провайдер услуг сам столько просуществует...
Итак. Мы имеем 10^10 валидных кодов из 10^30 кодов всего. Это значит, что на один валидный код приходится (10^20 - 1) невалидный код - или что среди каждых 10^20 кодов есть в среднем только один валидный.
Что можно предположить дальше?
Можно подумать, каким образом производится валидация кода.
В принципе, есть два возможных варианта. Первый - существует некоторая функция, позволяющая выяснить, валиден ли код, зная только сам код. Второй - существует некоторый механизм проверки валидности кода по коду, требующий дополнительных внешних данных - например, таблицы всех валидных кодов. Понятно, что наиболее сложный для реверс-инжиниринга случай - второй. Оценим для начала, вероятен ли он.
Пусть у нас есть 10^10 валидных 10^30-значных кодов, и провайдер услуг решает хранить их полный список на сервере, чтобы затруднить взлом. Наиболее сложным для взлома - а значит, наиболее вероятно используемым - является вариант, когда оставшиеся неключевые компоненты (суммарно дающие 20 десятичных знаков) генерируются для хранения на сервере абсолютно случайным способом. В таком случае, провайдер может использовать следующую схему хранения данных: таблицу с количеством элементов до 10^10, хранящую только эти 20 случайно сгенерированных десятичных знаков. Для валидации в таком случае он берёт код, делит его на первую 10-значную компоненту (i) и 20-значный остаток (j), после чего находит в своей таблице i-ый 20-значный элемент (j') и сверяет его с элементом j из кода.
Какие могут быть у провайдера проблемы с реализацией такой системы защиты? Скажу сразу - вполне очевидно, что если провайдер технологически потянет такое решение, то он наверняка именно его и реализует, ибо это сразу обесценит все попытки "взламывать" его коды - т.к. взламывать по сути нечего, вся "взламывабельная" информация генерировалась случайным образом - да наверняка не поддающимся хоть какому-то анализу псевдослучайным, как алгоритмы в большинстве компьютеров, а чисто случайным, с применением специального оборудования.
Прежде чем продолжим анализировать таблицу, вспомним, что мы до сих пор рассматривали только код либо валидный, либо невалидный, и не учитывали, что код должен ещё хранить информацию, услуге какого типа он соответствует - на 5, 10 или 20 единиц. Есть опять же три варианта: либо эта информация (в log_2 3 бита, т.е. в 1.58 бита, или примерно в 2 бита) хранится в первой десятичной компоненте, уникально идентифицирующей карточку (например, в остатке от деления номера карточки на три - 0 соответствует 5 единицам, 1 соответствует 10 единицам и 2 соответствует 20 единицам - а может быть, каким-то чуть более сложным алгоритмом), либо - для бОльшего маскирования алгоритма, но в то же время упрощения труда "взломщика"- в оставшейся 20-значной компоненте, либо - где-то на сервере в базе данных.
Вернёмся к табличному способу валидации кодов.
Итак, могут ли быть проблемы вообще с хранением и доступом к таблице из 10^10 элементов, хранящей 20 десятичных знаков?
Сразу небольшой анализ - для хранения 20 десятичных знаков нужно log_2 10^20 ~66.44 бита, или примерно 67 бит.
Есть несколько наиболее вероятных вариантов, которые мог выбрать провайдер.
Вариант первый - провайдер хранит каждый код как неинтерпретированное байтовое значение (т.е., 20 знаков кода он хранит как 20 байт). Глупый способ, конечно - неэкономно. Зато очень быстро интерпретировать. Но даже если и так, провайдеру надо всего лишь хранить 20 байт на каждый из 10^10 уникальных идентификаторов. Всего то 20*10^10 = 2 * 10^11 байт. Пусть даже ещё 1 байт для хранения типа доступа к услуге (5, 10, 20 единиц) - хотя для его хранения достаточно двух бит. Пусть даже ещё 3 slack-byte-а - для того, чтобы для каждой карточки хранилась запись в "круглые" 24 байта - провайдеру для хранения всей базы понадобится 2.4 * 10^11 байт. Пользуясь правилом производителей винчестеров "один мегабайт равен 1 000 000 байт, один гигабайт равен 1 000 000 000 (10^9) байт" получим, что для хранения базы в худшем случае понадобится (2.4 * 10^11) / (10^9) "винчестерных гигабайт". И мы получим жуткое число 240. 240 гигабайт.
Если кто-то не понял - для того, чтобы сгенерировать 20-значные "отзывы" к кодам случайным образом и хранить их прямо на валидационном сервере, делая тем самым любую попытку "взлома алгоритма валидации" бессмысленной (т.к. алгоритм валидации заключается в сравнении 20-значного "отзыва" с эталоном, хранящимся исключительно на сервере и сгенерированным абсолютно случайным способом, и не подразумевает возможности проверить валидность карточки или подобрать неизвестный заранее валидный номер без доступа к валидационному серверу - который любым достаточно умным админом закрыт от доступа из внешнего мира) провайдеру с месячным оборотом до 10 миллионов 20-долларовых карточек (умножайте сами) в худшем случае понадобится пойти к ближайшему поставщику оборудования и купить за примерно 180 долларов 250-гигабайтовый винчестер (за эти деньги он будет 7200, с кэшем в 8 мегабайт и SATA). Или два - для RAID-а. Или даже больше. Да даже если провайдер захочет разместить всё это на SCSI RAID-е, и сразу залить на весь получившийся дисковый массив сразу всю 83-летнюю базу (а не пополнять её по мере надобности), понадобится всего лишь 240-гигабайтовый объём...
Такие смешные цифры наглядно демонстрируют глупость попыток "взлома карточек" (т.к. разумный провайдер может обесценить их покупкой 250-гигабайтового дискового массива). Тем более эти попытки глупы, если провайдер разумен достаточно, чтобы не хранить 20 десятичных цифр как 24 байта, когда для хранения самих цифр достаточно 67 бит. Ведь если хранить их побитово, да ещё добавить два бита на тип услуги, да ещё даже добавить 1 slack bit, то для хранения одного отзыва понадобится только 70 бит, что меньше, чем изначальные 24 байта (192 бит) в 2.74 раза и уменьшит требуемый размер дискового массива до 87.5 "винчестерных гигабайт" (а если slack bit-ов будет 11, и размер записи будет "круглые" 80 бит, то дисковый массив понадобится ровно на 100 "винчестерных гигабайт"). А если провайдер ударится в оптимизацию и решит из 67 значащих бит 20-тисимвольного "отзыва" карточки 2 бита выделить под хранение уровня доступа (5, 10, 20 единиц) и 1 бит оставить как контрольный, то оставшиеся 64 бита, подтверждающие валидность карточки будут ровно в 3 раза меньше "взятых с горкой" изначально 24 байт, и дисковый массив понадобится всего лишь в красивые 80 гигабайт.
Ну что, ни у кого ещё не 1. пропало желание разбираться во взломе карточке, 2. (к scroll-у) притворяться, что продаёшь действительно генератор валидных кодов карточек ROL-а и верить в свою безнаказанность (а то некий небезызвестный vacuum надолго запомнился этому форуму сначала своими кулхацкерскими постами, а затем судебным "прессрелизом" по поводу суда над ним)?...
Домашнее задание читателям: рассчитать, сколько бит информации нужно получить некоему реверс-инженеру, чтобы для 10-тидесятичносимвольного кода научиться подбирать 20-десятичносимвольный "отзыв" хотя бы с 50-процентной вероятностью для случая, когда валидность пары "ключ-отзыв" проверяется некоторой функцией, принимающей на вход только эту пару.
Honeyman,
О да! Респект! Вот это разрулил. Я даже не полинился прочитать все и понять :)
Может быть эти "оптимисты" наконец-то поймут и прекратят спамить тут всякой ерундой.
О да! Респект! Вот это разрулил. Я даже не полинился прочитать все и понять :)
Может быть эти "оптимисты" наконец-то поймут и прекратят спамить тут всякой ерундой.
:)) А я вот не и не понял особо. В принципе поверил последнему абзацу и совершенству математических функций, которые используют "дурачки-провайдеры"... :))
А еще я знаю, что все темы о взломе РОЛа и генераторах номеров постятся сюда уже с полгода одним и тем же человеком. На деле же таким образом распространяются трояны. Кстати, Оффспринг мне представляется новым обличьем скролла.
Народ! Не теряйте времени на прочтение подобных уловок. Если Вам предлагают "взломать" карточки или купить их по великой дешевке, или выслать что-то куда-то, бегите сразу, не читая.
А еще я знаю, что все темы о взломе РОЛа и генераторах номеров постятся сюда уже с полгода одним и тем же человеком. На деле же таким образом распространяются трояны. Кстати, Оффспринг мне представляется новым обличьем скролла.
Народ! Не теряйте времени на прочтение подобных уловок. Если Вам предлагают "взломать" карточки или купить их по великой дешевке, или выслать что-то куда-то, бегите сразу, не читая.
:)) А я вот не и не понял особо.
Могу особо ленивым огласить краткое содержание - чтобы создать систему, способную обслуживать количество карточек, достаточную для 80 лет функционирования провайдера, принципиально неломаемую (т.е. с невозможностью создания алгоритма, без ведома провайдера не то что подбирающего новые валидные коды карточек - да хотя бы проверяющего по коду, валиден ли он или нет) и с вероятностью угадать пароль примерно 1 / 100 000 000 000 000 000 000, провайдеру достаточно всего-навсего заиметь винчестер на 80 гигабайт и материнку с чипом TPM (для истинно случайной генерации "отзывов" на коды) :)
Honeyman сказал(а):
1 / 100 000 000 000 000 000 000, провайдеру достаточно всего-навсего заиметь винчестер на 80 гигабайт и материнку с чипом TPM (для истинно случайной генерации "отзывов" на коды) :)
1 / 100 000 000 000 000 000 000, провайдеру достаточно всего-навсего заиметь винчестер на 80 гигабайт и материнку с чипом TPM (для истинно случайной генерации "отзывов" на коды) :)
А если создавать запас не на 80 лет, а всего на один скользящим графиком, удаляя использованные пары серия-номер по мере надобности? Вероятность повторения будет такая же, как и возможность взлома системы...
Тогда вся база вообще скромно поместится в уголке сервера авторизации.
Ты ведь не думаешь, что они выпустили в обращение карты на 80 лет вперед? :)
А если создавать запас не на 80 лет, а всего на один скользящим графиком, удаляя использованные пары серия-номер по мере надобности? Вероятность повторения будет такая же, как и возможность взлома системы...
Ну естественно - я же писал "Да даже если провайдер захочет разместить всё это на SCSI RAID-е, и сразу залить на весь получившийся дисковый массив сразу всю 83-летнюю базу (а не пополнять её по мере надобности)" :)
Тогда вся база вообще скромно поместится в уголке сервера авторизации.
По сравнению с хранением логов доступа по каждой из карточек, база самих номеров карточек вообще мизер :)
Меня больше другое интересует - даже если провайдер не хранит информацию по кодам карточек на сервере, а проверяет начальную валидность (ещё до проверки, остались ли деньги на карточке) некоторой функцией только от кода карточки - сколько данных нужно получить, чтобы пытаться подбирать код хотя бы с какой-то реалистичной вероятностью (а не 1 / 10^30) ?...
Honeyman
Скорее всего нет никакой проверки на начальную валидность (типа номер - функция от серии). Номер - либо правильный (_и_ ссылается на предоплаченную стоимость одного из 3 номиналов), либо нет. Без вариантов.
Или же проверка существует, но тогда теряется смысл существования онлайновых баз. И в этом случае - я лично не сомневаюсь - алгоритм достаточно стойкий, чтобы выполнить свою функцию, т.е. обеспечить взломоустойчивость системы на период равный или больший ее (системы) срока эксплуатации.
Учет собственно "денег" ведется в разрезе эккаунтов. Совсем другая система с другой системой защиты - рандомным 8-значным паролем.
Намек на единственный (ИМХО) способ взлома Рола. В х65 серии телефонов сименс ввели новую систему защиты. Для загрузки лоадера требуется т.н. бут-пароль. Пароли телефонов индивидуальны, и хранятся в онлайновой базе сименса, доступной только сервисам.
И как поступили наше-немецкие умельцы? Думаешь стали вычислять алгоритм, ломать сервер сименса? Не-а. Используя дыру в ява-машине,сделали мидлет, подменяющий бут-код на более "покладистый". И все. Никакого реверс-инжиниринга. :)
Меня больше другое интересует - даже если провайдер не хранит информацию по кодам карточек на сервере, а проверяет начальную валидность (ещё до проверки, остались ли деньги на карточке) некоторой функцией только от кода карточки - сколько данных нужно получить, чтобы пытаться подбирать код хотя бы с какой-то реалистичной вероятностью (а не 1 / 10^30) ?...
Скорее всего нет никакой проверки на начальную валидность (типа номер - функция от серии). Номер - либо правильный (_и_ ссылается на предоплаченную стоимость одного из 3 номиналов), либо нет. Без вариантов.
Или же проверка существует, но тогда теряется смысл существования онлайновых баз. И в этом случае - я лично не сомневаюсь - алгоритм достаточно стойкий, чтобы выполнить свою функцию, т.е. обеспечить взломоустойчивость системы на период равный или больший ее (системы) срока эксплуатации.
Учет собственно "денег" ведется в разрезе эккаунтов. Совсем другая система с другой системой защиты - рандомным 8-значным паролем.
Намек на единственный (ИМХО) способ взлома Рола. В х65 серии телефонов сименс ввели новую систему защиты. Для загрузки лоадера требуется т.н. бут-пароль. Пароли телефонов индивидуальны, и хранятся в онлайновой базе сименса, доступной только сервисам.
И как поступили наше-немецкие умельцы? Думаешь стали вычислять алгоритм, ломать сервер сименса? Не-а. Используя дыру в ява-машине,сделали мидлет, подменяющий бут-код на более "покладистый". И все. Никакого реверс-инжиниринга. :)
Honeyman сказал(а):
<...> провайдеру достаточно всего-навсего заиметь винчестер на 80 гигабайт и материнку с чипом TPM (для истинно случайной генерации "отзывов" на коды) :)
<...> провайдеру достаточно всего-навсего заиметь винчестер на 80 гигабайт и материнку с чипом TPM (для истинно случайной генерации "отзывов" на коды) :)
Так делать провайдер не станет. Способ кодирования для чипов TPM известен.
Так делать провайдер не станет. Способ кодирования для чипов TPM известен.
Кого в данном случае волнует *кодирование* чипами TPM, когда в них есть великолепный и высоконадёжный генератор истинно случайных чисел?...
Или у вас есть сведения о небезопасности использования ГСЧ в TPM? Есть информация, что он не случайный, а всё-таки псевдослучайный? Это уже очень интересно - дайте ссылки, если есть, а то я начал чесать голову на предмет покупки следующей материнки с TPM ;)
Но применительно к нашим бар^H^H^Hпровайдерам, в любом случае TPM не единственный вариант. Даже если провайдер узнает про ненадёжность ГСЧ в TPM, на рынке нынче много самого специфического оборудования... К примеру, гугль почти сразу выдал мне www.comscire.com/Home/ ...
Некто под ником Скролл мне не знаком. Кроме этого, с его деятельностью я ознакомился с Ваших слов. Ваши самые смелые предположения относительно меня ("Оффспринг мне представляется новым обличьем скролла"), к сожалению, не имеют реальной основы.
Я призываю ТОЛЬКО поучаствовать в сборе сведений об использованных картах РОЛа. Призывы к тому, чтобы другие не теряли времени на прочтение "подобных уловок" следует публиковать вне данного обсуждения.
Я призываю ТОЛЬКО поучаствовать в сборе сведений об использованных картах РОЛа. Призывы к тому, чтобы другие не теряли времени на прочтение "подобных уловок" следует публиковать вне данного обсуждения.
к сожалению, не имеют реальной основы.
Более чем возможно. Беру свои слова обратно.
Оставляю лишь то, что коды все равно не будут вскрыты. Интересно только, с какой целью собираются использованные карты - попытки расшифровки или другой целью? Будем надеяться, что первое.
Darrien сказал(а):
<...> и прекратят спамить тут всякой ерундой.
<...> и прекратят спамить тут всякой ерундой.
Если это так, то Вы поддерживаете своими сообщениями спам.
Honeyman сказал(а):
Положим, у нас есть эмпирическая информация, что следующие коды валидны для получения доступа к 20 единицам какого-то товара/услуги: 5231125028-16027-36711-14705-03968 и 5231125032-14996-45111-32309-24665.
Можно уже сделать какие-нибудь выводы?
Положим, у нас есть эмпирическая информация, что следующие коды валидны для получения доступа к 20 единицам какого-то товара/услуги: 5231125028-16027-36711-14705-03968 и 5231125032-14996-45111-32309-24665.
Можно уже сделать какие-нибудь выводы?
Для наглядности - первые две цифры серии (52) - номер региона (Нижний Новгород), шестая цифра соответствует номиналу карты 20RU - 2.
Номиналу 10RU - 1, а 5RU - 5.
Заметьте, кроме всего прочего, что шесть (!) цифр после 52 повторяются.
Разумеется, основываясь только на двух картах, выводы делать сложно.
Поделитесь лучше методами, которыми пользуетесь для анализа. Всё равно ведь они далеко не секретные, ага :) ?
Надеюсь, это что-то более математически продвинутое, чем "смотреть на карточки и пытаться обнаруживать общности"?
(В сторону) Нейросетку, нейросетку на них!..
Правда, нейросетке наверняка были бы нужны не только номера валидных карточек, но и номера невалидных карточек... а Offspring их ведь наверняка не собирает...
Надеюсь, это что-то более математически продвинутое, чем "смотреть на карточки и пытаться обнаруживать общности"?
(В сторону) Нейросетку, нейросетку на них!..
Правда, нейросетке наверняка были бы нужны не только номера валидных карточек, но и номера невалидных карточек... а Offspring их ведь наверняка не собирает...
Honeyman сказал(а):
Поделитесь лучше методами, которыми пользуетесь для анализа. Всё равно ведь они далеко не секретные, ага :) ?
Надеюсь, это что-то более математически продвинутое, чем "смотреть на карточки и пытаться обнаруживать общности"?
(В сторону) Нейросетку, нейросетку на них!..
Поделитесь лучше методами, которыми пользуетесь для анализа. Всё равно ведь они далеко не секретные, ага :) ?
Надеюсь, это что-то более математически продвинутое, чем "смотреть на карточки и пытаться обнаруживать общности"?
(В сторону) Нейросетку, нейросетку на них!..
Хех. Ежели упрощенно полагать природу мозга нейросетевой, то первое предположение ("смотреть на карточки и пытаться обнаруживать общности") примерно аналогично предложению "в сторону".
Правда, нейросетке наверняка были бы нужны не только номера валидных карточек, но и номера невалидных карточек... а Offspring их ведь наверняка не собирает...
За этим то добром дело не встанет.
Другое дело, что и нейросетка, разумеется, смысла в /dev/random особого не найдет, хотя и вполне способна хорошо проиллюстрировать имеющиеся в коде неслучайности, типа кодированного достоинства карты, и тому подобного.
Хех. Ежели упрощенно полагать природу мозга нейросетевой, то первое предположение ("смотреть на карточки и пытаться обнаруживать общности") примерно аналогично предложению "в сторону".
Имянно!
Но у компьютера есть одно существенное преимущество. У него рандом рандомнее =)))
За этим то добром дело не встанет.
Сделали бы на ROL-е открытый доступ к валидационному серверу, не дёргающий админа по каждой неправильной попытке завалидировать карточку - нейросетка была бы совсем рада. Это ж можно не только одну итерацию по имеющимся карточкам проводить, а самостоятельно пытаться учиться...
Honeyman сказал(а):
Имянно!
Но у компьютера есть одно существенное преимущество. У него рандом рандомнее =)))
Имянно!
Но у компьютера есть одно существенное преимущество. У него рандом рандомнее =)))
Зато вычислительная мощя еденицы массы куда как выше, нежели в случае компа.
Сделали бы на ROL-е открытый доступ к валидационному серверу
Хм. А разве этого доступа там еще нет? Вот в ВТ, например, есть -- ихняя статистика, в которой, на сколько я заметил, вполне допустимо ошибаться. По крайней МЕРЕ, вот только что ошибся и зеленые человечки не прибежали.
а самостоятельно пытаться учиться...
Чему учиться то? Ну покажет она еще некоторые неслучайности в серии. И шо? Порядок случайности в данных (если не полагать супротивника клиническим идиотом) всё равно будет существенно выше, нежели необходимо для уверенного подбора.
Соглашусь принять и невалидные карточки:) *только именно в виде карточек:))*
Методы анализа именно таковы - обнаруживать общности. Это, пожалуй, главный метод. Обнаружить общности человеку, не увлеченному числами и математикой в целом, достаточно проблематично. Однако нахождение общностей для одержимых математиков - дело интересное и менее затруднительное.
Что касается нейросетей, то вот уж кто-кто, а они никогда не справятся с этой задачей, а вернее справятся, но лишь приблизительно. Нейросеть будет выдавать "приблизительно верный ответ", тогда как действительно верные ответы будут лежать в некоторой окрестности. Короче, программку написать - и то достовернее будет:)
Методы анализа именно таковы - обнаруживать общности. Это, пожалуй, главный метод. Обнаружить общности человеку, не увлеченному числами и математикой в целом, достаточно проблематично. Однако нахождение общностей для одержимых математиков - дело интересное и менее затруднительное.
Что касается нейросетей, то вот уж кто-кто, а они никогда не справятся с этой задачей, а вернее справятся, но лишь приблизительно. Нейросеть будет выдавать "приблизительно верный ответ", тогда как действительно верные ответы будут лежать в некоторой окрестности. Короче, программку написать - и то достовернее будет:)
короче темка то старая, но все же вякну, есть у мя две карточки, первые номера, т.е. номера открытой части кода совпадают, зато то что под защитным слоем - код разный... Карты покупал последовательно только в их офисе на Покре... с тех пор много воды утекло - бесполезно...
У МЕНЯ НЕ ПОЯВИТСЯ НИКАКОЙ ВОЗМОЖНОСТИ НАНЕСТИ ВАМ КАКОЙ-ЛИБО ВРЕД
Угу, только потом кто-то купит уже активированую карточку, и этим "кто-то" может быть кто угодно
P/S/ IMHO Всё это фигня
Raf_Atreides сказал(а):
Угу, только потом кто-то купит уже активированую карточку, и этим "кто-то" может быть кто угодно
Угу, только потом кто-то купит уже активированую карточку, и этим "кто-то" может быть кто угодно
Это правда. Покупатель уже активированный карты потеряет свои деньги.
Уфф.... Насколько терпения хватило.
05438 5230215009 21295-26487-30160-59972
01108 5230515023 26950-18274-31062-22000
07101 5230215043 07481-41438-28900-24904
00080 5230515002 19884-51548-09596-56144
04645 5230715093 26238-13683-06676-52060
013210 5231115065 19570-46162-28028-00599
010978 5231115020 19029-28887-28677-56303
001793 5240315036 03726-12856-18499-52123
000419 5240315009 21034-05987-05046-55551
003228 5240315065 24040-31669-25463-63335
Развлекайся. ;)
05438 5230215009 21295-26487-30160-59972
01108 5230515023 26950-18274-31062-22000
07101 5230215043 07481-41438-28900-24904
00080 5230515002 19884-51548-09596-56144
04645 5230715093 26238-13683-06676-52060
013210 5231115065 19570-46162-28028-00599
010978 5231115020 19029-28887-28677-56303
001793 5240315036 03726-12856-18499-52123
000419 5240315009 21034-05987-05046-55551
003228 5240315065 24040-31669-25463-63335
Развлекайся. ;)
Если у тебя есть еще использованные карточки, я бы с удовольствием приобрел (купил) их. Тебе от них пользы никакой, а так, глядишь, прибыль:)
Предлагаю со своей стороны скупку, потому что писать инфу о них действительно терпения не хватит:)
Предлагаю со своей стороны скупку, потому что писать инфу о них действительно терпения не хватит:)
Offspring сказал(а):
Если у тебя есть еще использованные карточки, я бы с удовольствием приобрел (купил) их. Тебе от них пользы никакой, а так, глядишь, прибыль:)
Предлагаю со своей стороны скупку, потому что писать инфу о них действительно терпения не хватит:)
Если у тебя есть еще использованные карточки, я бы с удовольствием приобрел (купил) их. Тебе от них пользы никакой, а так, глядишь, прибыль:)
Предлагаю со своей стороны скупку, потому что писать инфу о них действительно терпения не хватит:)
Рола у меня еще есть где-то столько же, сколько уже показал. Есть много других. :)
Не хватало мне еще торговать ушами от мертвого осла. :) Отдам затак. Токо попозднее, ок?
Завсегда пожалуйста.
03278 5221115026 11599-34239-10424-64835
02539 5230955051 12050-11826-19360-64365
02736 5230955055 29891-63217-29209-58161
03592 5230955072 26208-40851-10404-25660
04039 5230515081 18679-13471-15458-23275
002535 5240615051 14302-35171-06659-60487
004259 5240315086 30351-40552-22385-46271
008498 5240315170 21748-30288-11731-34769
003178 5240855064 22204-03054-00293-28346
004262 5231155086 21633-09286-31915-65144
008236 5240215005 08215-08454-26883-49855
009234 5240855185 11743-37410-25843-11639
03278 5221115026 11599-34239-10424-64835
02539 5230955051 12050-11826-19360-64365
02736 5230955055 29891-63217-29209-58161
03592 5230955072 26208-40851-10404-25660
04039 5230515081 18679-13471-15458-23275
002535 5240615051 14302-35171-06659-60487
004259 5240315086 30351-40552-22385-46271
008498 5240315170 21748-30288-11731-34769
003178 5240855064 22204-03054-00293-28346
004262 5231155086 21633-09286-31915-65144
008236 5240215005 08215-08454-26883-49855
009234 5240855185 11743-37410-25843-11639
Если у тебя есть еще использованные карточки, я бы с удовольствием приобрел (купил) их. Тебе от них пользы никакой, а так, глядишь, прибыль:)
Предлагаю со своей стороны скупку, потому что писать инфу о них действительно терпения не хватит:)
Предлагаю со своей стороны скупку, потому что писать инфу о них действительно терпения не хватит:)
Что-то это выглядит как подстава!
При всем уважениии к пытливому уму: пока вы будете тратить свое ценное время и совершенствовать алгоритм приближая его к реальному, сотрудника РОЛа просто его сменят.
Это как ситуация с оверклокерами (где-то читал): пока они часами меняют тайминги и проч. увеличивая производительностиь системы на 3 процента, их сосед купив дополнительный модуль DDR добивается увеличения производительности на 20%.
Хоят некоторые удовольствие от процесса получают
Это как ситуация с оверклокерами (где-то читал): пока они часами меняют тайминги и проч. увеличивая производительностиь системы на 3 процента, их сосед купив дополнительный модуль DDR добивается увеличения производительности на 20%.
Хоят некоторые удовольствие от процесса получают
