Что делать с рабочими приложениями? Смена контейнера предлагает полную выгрузку памяти.
Контейнер — он только для данных телеграмм, очевидно же.
Другие приложения туда пускать не нужно.
Ну да ну да, стороннему сервису еще полный контроль над смартфоном. Лег сервер — пока смартфон?
Это как бы мой намек на то, что проблема не решается оффлайн с коротким пином.
Что не есть хорошо.
Придумайте свой способ быстрой регистрации/авторизации, которая быстро уйдет в массы, и любой человек разберется за 30 секунд как поставить/авторизоваться и начать общаться — все будут только рады.
В этом и проблема. Настоящая privacy недоступна для масс.
А всякие говномессенджеры занимаются говномаркетингом.
Вы со мной поспорить хотите?
Со мной спорить не нужно, я в телеграмм не работаю.
Почти готовое решение — хранить все данные фейкового аккаунта в TrueCrypt контенере, а все данные настоящего — в hidden volume.
Пин — это пароль на контейнер, первый или второй.
plausible deniability и вот это все.
Остается проблема с коротким пином, который легко перебрать, если вся функциональность проверки пина работает оффлайн.
Отсюда вывод — проверка пина должна быть онлайн.
Сервер по запросу с пином выдает пароль, которым расшифровывается TrueCrypt контенер (фейковый или hidden).
Сервер борется с перебором, ограничивая количество паролей в день.
Но вы так не будете делать, вам же надо тупо от пограничника скрывать.
Чтобы скрыть от пограничника, достаточно записать в настройки два разных пина и не париться.
А вот если пограничник может получить доступ к файлам и настройкам, начинается совсем другой разговор.
Вообще сама идея привязки аккаунта к номеру телефона — это уже трешъ.
Я на 100% уверен, что юристы MS прописали в договоре всякие оговорки на случай форс-мажоров.
И внезапная смена юрисдикции у кусочка земли (а также последовавшие за этим санкции) — это несомненно те самые форс-мажоры.
Поэтому корень проблемы надо искать именно там, а не заниматься казуистикой на хабре.
Интересно, есть ли возможность атаки на драйверы файловой системы путем динамической подмены данных на диске?
Ведь когда разрабатывают драйвер, то поидее делают некоторые допущения о корректном поведении носителя информации, что позволяет оптимизировать алгоритмы.
Ну например, не делает потому, что он программист, а не программист + предприниматель.
Таким образом, еще раз.
Труд программиста способен приносить бизнесу много денег.
Вывод?..
ТС приводит некоторое утверждение — программисту легко уволиться со скучной работы и начинать поднимать реальное бабло, работая на себя.
Так ведь из этого вытекает, что труд программиста недооценен :)
Ну, если бы вы в таблице еще биты передвинули, то биты оказались бы в том порядке, в каком они идут на канальном уровне.
То есть, b0 и b1 были бы первыми.
И это имело бы дополнительный дидактический смысл.
Право-лево — это все вкусовщина. Я видел как справо-налево, так и слева-направо.
Важно именно то, какая степень двойки будет стоять при данном бите при переводе в число.
Вобщем, лучше бы вы называли биты как на картинке из вики, меньше было бы путаницы.
Ибо никаких оснований у вашей перенумеровки бит, кроме вкусовщины, нет :)
Моя фраза «так как мы не можем прочитать байт частично, мы всегда читаем его целиком»
относилась к проблеме «Little-endian vs big-endian» в памяти PC.
Вопрос последовательности передачи битиков каждого байта на канальном уровне — это уже не «Little-endian vs big-endian» в памяти PC, а какая-то другая проблема.
Уверен, что у нее есть свое имя в среде инженеров, но это совершенно отдельный вопрос от программирования.
Программисты не знают, что там на канальном уровне.
Вообще, если подумать, раз network byte order нужен для того, чтобы сравнивать получаемые по сети числа по первым байтам (первым — значит старшим), то тогда логично предположить, что в каждом байте старшие биты тоже идут первыми на канальном уровне.
Тогда можно сравнивать вообще по первыи битам.
Это все правильно, но в статье речь идет о представлении MAC адреса в памяти PC.
Это представление как-то там соответствует последовательным битикам на канальном уровне,
пикам на осциллографе, whatever.
Но я не знаю, как, и знать не хочу в данный момент, ибо мы все равно в конечном счете обсуждаем представление в памяти PC.
Итого.
В статье на ВИКИ говорится, что младшие биты b0 и b1 зарезервированы под U/M и G/L.
Окей, топикстартер приводит картинки из ВИКИ с битами b0 и b1, но почему-то называет их старшими (7 и 8 с начала).
Мне это не понятно, об этом и вопрос.
Little-endian vs big-endian — это про то, как два (или более) соседних байта byte0 byte1 формируют целое число: byte0 + byte1*256 или же byte1 + byte0*256.
Когда разговор идет об одном единственном байте, никаких Little-endian vs big-endian нет, так как мы не можем прочитать байт частично, мы всегда читаем его целиком.
Остановите этот шарик, я сойду.
Контейнер — он только для данных телеграмм, очевидно же.
Другие приложения туда пускать не нужно.
Это как бы мой намек на то, что проблема не решается оффлайн с коротким пином.
Что не есть хорошо.
В этом и проблема. Настоящая privacy недоступна для масс.
А всякие говномессенджеры занимаются говномаркетингом.
Вы со мной поспорить хотите?
Со мной спорить не нужно, я в телеграмм не работаю.
Пин — это пароль на контейнер, первый или второй.
plausible deniability и вот это все.
Остается проблема с коротким пином, который легко перебрать, если вся функциональность проверки пина работает оффлайн.
Отсюда вывод — проверка пина должна быть онлайн.
Сервер по запросу с пином выдает пароль, которым расшифровывается TrueCrypt контенер (фейковый или hidden).
Сервер борется с перебором, ограничивая количество паролей в день.
Но вы так не будете делать, вам же надо тупо от пограничника скрывать.
Чтобы скрыть от пограничника, достаточно записать в настройки два разных пина и не париться.
А вот если пограничник может получить доступ к файлам и настройкам, начинается совсем другой разговор.
Вообще сама идея привязки аккаунта к номеру телефона — это уже трешъ.
Но мы докажем всему миру, что нормальность — понятие растижимое в широких пределах!
И внезапная смена юрисдикции у кусочка земли (а также последовавшие за этим санкции) — это несомненно те самые форс-мажоры.
Поэтому корень проблемы надо искать именно там, а не заниматься казуистикой на хабре.
UPD. Сразу пошел слив кармы.
МУХАХАХАХА.
nvd.nist.gov/vuln/detail/CVE-2018-12930
Ведь когда разрабатывают драйвер, то поидее делают некоторые допущения о корректном поведении носителя информации, что позволяет оптимизировать алгоритмы.
На экваторе «плотность погрешности» нулевая, в при приближении к полюсу она стремится к бесконечности.
Таким образом, еще раз.
Труд программиста способен приносить бизнесу много денег.
Вывод?..
Так ведь из этого вытекает, что труд программиста недооценен :)
Там ниже DNS rebinding в модемах.
А тут про TLS сертификаты.
Можно почитать хабр и собрать себе exploit chain :)
То есть, b0 и b1 были бы первыми.
И это имело бы дополнительный дидактический смысл.
Право-лево — это все вкусовщина. Я видел как справо-налево, так и слева-направо.
Важно именно то, какая степень двойки будет стоять при данном бите при переводе в число.
Вобщем, лучше бы вы называли биты как на картинке из вики, меньше было бы путаницы.
Ибо никаких оснований у вашей перенумеровки бит, кроме вкусовщины, нет :)
Таки пишут, что в Ethernet byte order — BE, а bit order — LE.
www.linuxjournal.com/article/6788
относилась к проблеме «Little-endian vs big-endian» в памяти PC.
Вопрос последовательности передачи битиков каждого байта на канальном уровне — это уже не «Little-endian vs big-endian» в памяти PC, а какая-то другая проблема.
Уверен, что у нее есть свое имя в среде инженеров, но это совершенно отдельный вопрос от программирования.
Программисты не знают, что там на канальном уровне.
Вообще, если подумать, раз network byte order нужен для того, чтобы сравнивать получаемые по сети числа по первым байтам (первым — значит старшим), то тогда логично предположить, что в каждом байте старшие биты тоже идут первыми на канальном уровне.
Тогда можно сравнивать вообще по первыи битам.
Отсюда, возможно, идет путаница у ТС.
Это представление как-то там соответствует последовательным битикам на канальном уровне,
пикам на осциллографе, whatever.
Но я не знаю, как, и знать не хочу в данный момент, ибо мы все равно в конечном счете обсуждаем представление в памяти PC.
Итого.
В статье на ВИКИ говорится, что младшие биты b0 и b1 зарезервированы под U/M и G/L.
Окей, топикстартер приводит картинки из ВИКИ с битами b0 и b1, но почему-то называет их старшими (7 и 8 с начала).
Мне это не понятно, об этом и вопрос.
Когда разговор идет об одном единственном байте, никаких Little-endian vs big-endian нет, так как мы не можем прочитать байт частично, мы всегда читаем его целиком.