Опубликуйте гарантированный способ получения KI из современных сим-карт и есть шанс заработать денег на безбедную жизнь до самой смерти. Таких карт которые не сложно клонировать уже лет 5 как не выпускают.
Часть между BS и MS всегда шифрована. Можно почитать про алгоритмы A5/1 и A5/2.
Да и остальные участки шифруются в случае скажем передачи SMPP или сигналки через интернет.
Then, the firmware can be modified and information such as the IMEI (International Mobile Equipment Identity) number can be changed as well as the IMSI (International Mobile Subscriber Identity) number, which allows a phone to register itself with an operator.
IMSI в мобильных терминалах не хранится.
И зачем менять IMEI? Он виден только владельцу терминала и оператору. Другой стороне он никак попасть не может. Зачем анализировать? Возможно молучить mTAN только на определенную пару IMSI-IMEI? Сомневаюсь.
For the final step, the hacker must also clone a SIM (Subscriber Identity Module) card, which Becker said is technically trivial.
Это как? Склонировать симку нетривиальная задача. Да и при условии наличия доступа к ней это маловероятно. Для прочтения Ki требуется ввести ADM код. А в новых симках встроен механизм защиты от брутфорса. О перехвате данных необходимых для регистрации в сети «из воздуха» можно только мечтать, алгоритмы достаточно стойкие.
Как раз таки и не было. CBOSSу в этом случае зачет.
Версионность реализована была на undo сегментах, это так называемая «непротиворечивость считывания». Подробнее у дяди Кайта почитать можно. Для постоянного хранения данных этот механизм не подходит. Потому что при активной записи в базу старые данные затираюся.
Кстати, аналогичная технология используется в движке InnoDB, так что MySQL это давно умет.
«Нормальная» версионность, как в Interbase, появилась в 11й версии Оракла. И пока я не слышал о крупных продуктах мигрировавших на него. Если есть — подскажите.
В версиях 9 и 10 оно работает на undo сегменах. Ясно что совсем недолго данные хранятся.
С 11й версии оно заработало нормально под названием Flashback, судя по документации, сам не проверял.
Почитать можно здесь
Возможно к этому решению стоит добавить булево поле active_version и сделать по нему btree индекс.
Не факт, но может ускорить работу с актуальными версиями.
А так, предложенная схема вполне работоспособна.
Удобно.
С другой стороны. Дали питание, подождали 15 минут, отрубилось питание. И так несколько раз за ночь с промежутком в 15 минут к примеру )) Автоматизация — палка о двух концах.
Да. Могу привести пример продукты Alcatel-Lucent.
Они сделали биллинг(!) для GSM операторов на мускле. И до определенного объема данных оно работало. Посчастливилось некоторое время поадминить эту систему.
Кстати, в таблицах с типом InnoDB было до 125*10^6 записей.
>клиент-серверную архитектуру
имел в виду соединение через сокеты
>разделение прав пользователей
Гранты на базы для различных пользователей. Очень даже используются.
Вот еще пример не простого использования мускл.
Так вот для таких целей Embedded InnoDB не подойдет
Это больше ориентировано на минималистичные приложения, на те где не требуется клиент-серверная архитектура, разделение прав пользователей, и такие сложные элементы как триггеры, хранимые процедуры и прочее.
Да и остальные участки шифруются в случае скажем передачи SMPP или сигналки через интернет.
IMSI в мобильных терминалах не хранится.
И зачем менять IMEI? Он виден только владельцу терминала и оператору. Другой стороне он никак попасть не может. Зачем анализировать? Возможно молучить mTAN только на определенную пару IMSI-IMEI? Сомневаюсь.
Это как? Склонировать симку нетривиальная задача. Да и при условии наличия доступа к ней это маловероятно. Для прочтения Ki требуется ввести ADM код. А в новых симках встроен механизм защиты от брутфорса. О перехвате данных необходимых для регистрации в сети «из воздуха» можно только мечтать, алгоритмы достаточно стойкие.
Мутно и непонятно.
Версионность реализована была на undo сегментах, это так называемая «непротиворечивость считывания». Подробнее у дяди Кайта почитать можно. Для постоянного хранения данных этот механизм не подходит. Потому что при активной записи в базу старые данные затираюся.
Кстати, аналогичная технология используется в движке InnoDB, так что MySQL это давно умет.
«Нормальная» версионность, как в Interbase, появилась в 11й версии Оракла. И пока я не слышал о крупных продуктах мигрировавших на него. Если есть — подскажите.
С 11й версии оно заработало нормально под названием Flashback, судя по документации, сам не проверял.
Почитать можно здесь
Не факт, но может ускорить работу с актуальными версиями.
А так, предложенная схема вполне работоспособна.
С другой стороны. Дали питание, подождали 15 минут, отрубилось питание. И так несколько раз за ночь с промежутком в 15 минут к примеру )) Автоматизация — палка о двух концах.
А он может корректно гаснуть по команде от УПСа?
Они сделали биллинг(!) для GSM операторов на мускле. И до определенного объема данных оно работало. Посчастливилось некоторое время поадминить эту систему.
Кстати, в таблицах с типом InnoDB было до 125*10^6 записей.
>клиент-серверную архитектуру
имел в виду соединение через сокеты
>разделение прав пользователей
Гранты на базы для различных пользователей. Очень даже используются.
Вот еще пример не простого использования мускл.
Так вот для таких целей Embedded InnoDB не подойдет