• Делаем систему контроля и управления доступом (СКУД) для умного дома
    +2

    Может. Только не в роли метки, а просто устройства-клиента, протокол там произвольный. Для этого подойдет такой ридер, как у автора, и не подойдут самые простые, которые только Mifare (обычно именно они присутствуют во всяких ардуино-наборах всё-в-одном).


    В телефоне, разумеется, можно реализовать любую криптографию, которую только удастся придумать. С метками, например, такое проблематичнее. Но тоже можно, при желании можно сделать карточку, которая будет через AES/RSA/ECDSA аутентифицироваться.

  • Сам себе пейджинговый оператор
    0
    Миллисекунд достаточно. SDR приёмник пишет кусок спектра на диск.

    Как человек, который писал SDR-приемником кусок спектра на диск, и получал на выходе 5 гигабайт за две минуты (полоса 20 мегагерц) очень сомневаюсь, что такие приемники можно массово развернуть, а тем более хранить какую-то историю. Один день такой записи займет 3.5 терабайта, а это лишь маленький участок спектра, а спектр-то огромный.

  • Как root-права и альтернативные прошивки делают ваш android смартфон уязвимым
    0
    чревато окирпичиванием, или, по крайней мере, потерей данных, при неаккуратном изменении чего-то что нельзя менять

    Разве не будет решением загрузиться в (подписанный) рекавери и прошить обратно штатный образ ОС, не трогая данные?

  • Как root-права и альтернативные прошивки делают ваш android смартфон уязвимым
    +12
    Третий и самый сложный подход – продолжать использовать альтернативную сборку ОС, но заблокировать загрузчик используя user-settable root of trust. Это действительно сложный и затратный подход, достойный написания отдельной статьи, потому как требует самостоятельно делать сборку ОС и самостоятельно её подписывать.

    Пишите обязательно. Рут использую как минимум для файрвола (очень удобно срезать рекламу в тех местах, где доступ в интернет не предполагается в принципе, например в оффлайн-играх). Риски, связанные с открытием загрузчика (и наличием рекавери, которое смотрит в мир голым задом), в принципе понимал с самого начала, и принимал как неизбежное зло. Так что возможность закрыть загрузчик обратно со своими ключами была бы кстати.

  • У Steam довольно любопытный способ логина
    +6

    Это, скажем так, сводит всю затею к "злоумышленнику будет лень ковырять", т.е. security via obscurity.


    Думаю в случае с valve или любой другой крупной компании государев mitm уже заранее будет сконфигурирован как надо. А неуловимые Джо — они и в Африке такие. И никакой WASM не защищает от скрипта, который просто повесит глобальный хук на onkeydown. Ну и если у вас в канале сидит MITM — очевидно, он может предоставляться тем же IP, что и у клиента.

  • У Steam довольно любопытный способ логина
    +18

    Если злобный прокси может слушать канал — то он может его и менять. Ничего не мешает просто отдать клиенту немного другую версию скрипта шифрования, который чисто случайно помимо основной задачи ещё сбросит на нужный сервер нешифрованную версию пароля.


    Это именно та причина, почему если нет доверенного TLS, то последующие пляски с шифрованием полная фикция — через такой прокси троянов можно прямо в страницу напихать. Не говоря уже о том, что даже после вот этого очень шифрованного логина сессионная кука начинает летать открытым текстом

  • У программиста из США остались две попытки для открытия самоуничтожающейся флешки. Там ключ к биткойнам на $237 млн
    +1

    У меня используется конфигурация raid1 поверх dm-integrity. Убивается аж три зайца — во-первых, смерть диска не фатальна, во-вторых, криптоконтейнер бонусом (aes-gcm-random, шифрование и аутентификация), а самое главное — защита от незаметного повреждения.


    Так уж получается, что если зайти в спецификацию диска, взять оттуда bit error rate и перемножить на количество тех самых бит, получается очень грустная картина. В предельном случае не всегда гарантируется успешное чтение всего диска :)


    Потому логика тут такая — если dm-integrity при чтении видит, что хеш не совпадает — то наверх возвращается I/O error. Совсем такая же, как будто сектор физически не читается. Дальше в дело вступает raid1, который при получении такой ошибки просто читает тот же сектор с другого диска, и попутно исправляет ошибку на сбойном, записывая правильные данные. Вероятность того, что ошибки будут в одном и том же месте, очень маленькая. Еженедельный запуск raid-check не дает им накапливаться, но при этом совсем ненавязчив.


    Плюс решения в том, что оно абсолютно прозрачно для использования, и создает абстракцию надежного диска, куда можно просто класть файлы, и они там будут лежать.


    Минусы такого решения:


    • Хеши жрут ощутимое количество места, от диска на 10 маркетинговых терабайт сначала остается 9.1 реальных, а потом 8.6 за вычетом хешей.
    • Для того, чтобы гарантировать атомарность записи (иначе есть риск испортить сектор при сбое питания, когда данные уже записаны, а хеш еще нет) dm-integrity использует журналирование. Потому производительность на запись очень далека от идеала. Но для моего сценария "холодного хранения" это не проблема.
    • Если включать шифрование, неплохо бы не потерять ключи :) К счастью в силу их небольшого размера их можно хоть на граните гравировать.



    P.S.: Куда интереснее вопрос с георепликацией, чтобы пожар/потоп/маски-шоу и прочий форс-мажор не становился фатальной проблемой. Вот тут я решений, которые бы представляли похожую абстракцию "надежного диска" не знаю. Самое близкое — два инстанса minio и отдельный процесс синхронизации, при этом один инстанс становится строго мастером, а второй строго репликой.

  • Скоро будет самая беззащитная страна. Системный взгляд на проблемы информационной безопасности в России
    0
    Если человек может сам проверить, как учтён его голос, то никто не помешает потребовать это сделать в присутствии «контролёра».

    Принципиально это разрешимо, стандартный метод решения проблем паяльника (что тут, что в криптоконтейнерах) — plausible deniability. Только в одном случае открывается ложный диск, а тут вот можно "проверить", что пользователь голосовал за любого кандидата (хоть за всех сразу).


    Т.е. формулируя более строго — пользователь должен иметь возможность проверить голос, но не иметь возможности доказать.


    Другое дело, что системы с таким свойством обычно получаются довольно сложные, и я не уверен, есть ли реализации на практике.

  • Штази — одна из самых педантичных и репрессивных спецслужб мира
    +1

    Ну конкретно поднесущую несложно — надо просто "принять сигнал повторно". Примерно так работали трехпрограммные радиоточки, только вместо приема радио они получали уже готовое аудио по проводам, а потом его демодулировали.


    У ЦРУ было намного более продвинутое маскирование, когда сигнал кодировался положением импульса внутри двух "опорных", а сами пачки импульсов шли случайно. Вот тут намного менее тривиальный приемник должен быть.

  • Не «цифрой» единой: аналоговые шпионские камеры с 1861 года и по наши дни
    +1

    Там, судя по контенту, одноразовый блокнот записан, т.е. просто циферки группами по пять.

  • Шифруем по-русски, или отечественные криптоалгоритмы
    0

    Угу, оно самое.


    https://cdn.virgilsecurity.com/assets/docs/memo-on-kuznyechik-s-box.pdf


    Есть еще такое. Там упомянуты те самые ограничения и:


    The S-box π was obtained by pseudorandom search and the following properties were taken into account.

    No secret structure was enforced during construction of the S-box
  • Шифруем по-русски, или отечественные криптоалгоритмы
    0

    https://www.ruscrypto.ru/resource/archive/rc2013/files/03_shishkin.pdf


    Слайд 10, красным помечено выбранное разработчиками (например, см. предыдущие слайды — шифр представляет из себя SP-сеть, и она тоже помечена красным, ровно как и "Выбор пространства V8").

  • Шифруем по-русски, или отечественные криптоалгоритмы
    0
    какая из следующих двух последовательностей длины 10 более случайная:

    Речь таки идет о вероятности попадания в узкий класс. Какая из последовательностей длины десять более вероятна — где идет пять нулей подряд или где есть просто пять нулей в любых местах?


    Институт стандартов NIST проводит два конкурса. В первом конкурсе AES участвуют 15 алгоритмов от различных авторов со всего мира, во втором, SHA-3 — 51 алгоритм. Какова вероятность того, что в обоих конкурсах победят алгоритмы от одного и того же автора? ;)

    Ноль, конкурс прошел, команды авторов разные (пересекаются только в одном человеке).


    Sly_tom_cat


    Однако такая перестановка позволяет радикально упростить линейные и дифферинциальные методы криптоанализа.

    Такая перестановка вырождает алгоритм до линейной операции. AES точно, кузнечик вроде похож. Можно хоть 100 раундов с такой перестановкой сделать, эффект будет как у одного.


    И вот тут гораздо интереснее другое: существует ли набор метрик или тестов, который бы говорил о качестве блока перестановок в плане противостояния методам криптоанализа? Или это еще зависит от окружающего блок перестановк алгоритма?

    Существует, например, корреляционная характеристика и дифференциальная характеристика. И это, кстати, один из ответов на вопрос "почему случайный s-box не всегда хорош" — если бы DES был со случайными S-Box-ами, он был бы сильно слабее.


    И ведь вы таки снова уехали от темы. Авторы заявляют, что S-Box генерируется случайно (и заявляют, что потеряли программу, которая его генерировала), а по факту очень аккуратно попали в узкий осмысленный (!) класс перестановок.


    Ведь там не только программа на ассемблере длиной в 80 байт. Программой просто пытались получить численные оценки сложности, которыми можно меряться. Перестановка осмысленная с точки зрения математики. Случайно там оказалось дискретное логарифмирование. Случайно она отображает регулярные множества. Всего перестановок 256! ≈ 2^1684, а перестановок TKlog ≈ 2^76. Различных программ на ассемблере длиной 80 байт ≤2^640 (не все из них валидны, многие из них делают одно и то же, но да ладно).


    Масштаб удачи просто поражает. Случайно выбить событие с вероятностью порядка 10^-315 — это уметь надо.


    Т.е. более предметно рассматривать вопрос, что авторы хотели вложить в перестановку. Я лично вижу три варианта:


    • бекдор (тогда не скажут)
    • анти-бекдор, перестановка защищает от какой-то секретной атаки на блочные шифры, известной ФСБ (тогда тоже не скажут)
    • быстрая аппаратная реализация за счет регулярности (такие действительно есть). Но этот вариант маловероятный — тогда бы так и сказали, а не говорили бы, что это случайность и программу потеряли.
  • Шифруем по-русски, или отечественные криптоалгоритмы
    0
    И то что позже может быть найден достаточно короткий алгоритм формирующий эту последовательность вовсе не делает «враньем» первичный постулат о случайности создания этой перестановки.

    Разумеется, не делает. Зато длина алгоритма позволяет говорить о вероятностях.


    Есть вероятность, что они искренне случайно выбрали такую подстановку. И есть вероятность, что они просто наврали, а о реальных критериях выбора подстановки говорить не хотят или не имеют права.


    Вероятность первого оценивается математически, учитывая, что каждый сэкономленный байт влияет на эту вероятность экспоненциально, она очень маленькая. Вероятность второго предлагаю каждому оценить самостоятельно, учитывая, что даже в США был пример с DES.


    Если для вас это не так, то мне искренне жаль.

    Я предпочитаю птицу, которая ходит как утка, выглядит как утка и крякает как утка, называть уткой. Хотя заметьте, я ни разу не делал ДНК-тест этих птиц и строго говоря утверждать о принадлежности к биологическому виду не могу.


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

  • Шифруем по-русски, или отечественные криптоалгоритмы
    0
    Возможно он будет длиннее самой таблицы, но такой алгоритм всегда найдется.

    Это подразумевалось, да, из контекста первого сообщения. Имелся в виду "алгоритм короче, чем запись константой", который существует не всегда.


    Но и делать выводы о надежности алгоритмов на основе домыслов — тоже не поддерживаю.

    Потому что в криптографии действует презумпция ненадежности, вот и все. Особенно в конкурсах на стандарты. Все вышеизложенное вытекает из этого.


    Вывод, кстати, делается не на основе домыслов, а на основе факта, что авторы врут. Это, в отличие от возможного бекдора, установлено с достаточной достоверностью.


    Плюс, как я вон выше про кривые NIST привел, заменять возможно ненадежные алгоритмы — стандартная практика, даже если ненадежность не доказана (или доказана, но вычислительно недостижима).

  • Шифруем по-русски, или отечественные криптоалгоритмы
    +2

    Нет, про DES было ровно так же. Пришла NSA и сказала "ваши таблицы плохие, берите мои таблицы, они хорошие". И только спустя много лет выяснилось, почему же они были хорошие. А до этого все тоже гадали, что они в этих таблицах спрятали (но да, тогда там не смогли найти структуру, просто обмусоливали факт таблиц, хз откуда взявшихся). Но DES был очень давно и был единственным. А сейчас этих алгоритмов много, хочешь AES, хочешь Blowfish, хочешь ChaCha20-Poly1305.


    И да, криптография в основном не является точной наукой. Там точно известны способы, как делать не надо, а способы, как делать надо — эмпирические, "вроде не поломали" и "на данный момент нет известных атак". Случаи, когда у примитивов есть доказанная стойкость, немногочисленны, и в основном опираются на (недоказанную) стойкость нижестоящего примитива. Единственный шифр с доказанной абсолютной стойкостью — вообще одноразовый блокнот. Обычно доказывают стойкость режимов шифрования или подписи (OAEP, XTS) в предположении, что нижележащий шифр (RSA, AES) соответствует какой-то модели безопасности.


    "Случайно — нет алгоритма" правильно с точки зрения статистики. В среднем на случайную перестановку не найдется эффективные алгоритма, но да, есть некоторые вырожденные случаи — например, перестановка 1-2-3-4-5..., или та, что у ГОСТа. Вероятность попасть на вырожденный случай маленькая, а длина алгоритмов — как раз неплохая метрика для оценки вырожденности этого случая. Математически это называется "энтропия".


    Ресурсы исследователей ограничены, и когда ты подаешь заявку на алгоритм — никто не будет разбираться "что имел в виду автор", и никто не будет исходить из тезиса "если это пока не нашли — значит этого нет". Потому с точки зрения международной стандартизации ГОСТ рассматривается именно как интересная задача "что же там сныкали", а не как криптографический примитив. Для прекращения его рассмотрения в качестве криптографического примитива достаточно самого факта, что что-то спрятали. Потому что есть другие примитивы, где ничего не прятали, и которые можно анализировать по существу, а не тратить время на поиски бекдора или на установление его отсутствия.


    И да, я не говорю что ГОСТ плохой, я просто говорю, что при таких вводных им пользоваться никто не будет. Сфера его применения — офицеры ФСБ, которые темной ночью будут закрываться в кабинете и шифровать друг другу пакеты. Ну и все, кто от них зависит.


    Аналогично сейчас так же обмусоливают эллиптические NIST-овые кривые, говоря о том, что они в общем-то хз откуда взялись и возможно принадлежат к какому-то секретному классу слабых кривых. И именно потому есть понятие "curve rigidity" и альтернативы в виде X25519 и X488. Заметьте — и это в сторону американских кривых, никаких скреп и новичков. Абсолютно те же самые принципы. Просто криптография так работает, вся. Вот оно, выделено жирным красным цветом — абсолютно те же заявления — "непонятно как получено".


    Условно говоря, желающих жить с крокодилом немного, несмотря на то, что он вроде не кусается. Достаточно того, что зубы есть. Но да, математически наличие бекдора не доказано, если вы это хотели услышать. Другое дело, что от факта возможности, но недоказанности перспективы шифра лучше не становятся.

  • Шифруем по-русски, или отечественные криптоалгоритмы
    +2

    Если перестановка действительно случайная (как утверждают авторы) — то нельзя придумать алгоритм, который бы был по размеру меньше этой подстановки (для случайных данных самый простой способ записать их — привести как есть, константой). А тут вот получается, причем намного меньше.


    Пример — сама таблица 256 байт, самая короткая программа на C для её генерации — 134 байта, на ассемблере есть реализация в 80 байт. Вероятность, что авторы выбрали случайную таблицу, а для неё случайно нашлась программа, в три раза её короче — ну, очень небольшая, это уж точно.


    Основная претензия — авторы не говорят, зачем это нужно, и даже отрицают сам факт того, что это намеренно. Оправдание — "нууу мы тут выбрали случайную таблицу, а это оно само", что не выдерживает никакой критики, ибо класс таких таблиц очень узкий, и если оно действительно само — авторам стоит купить сотню лотерейных билетов — выиграют сотню квартир, машин, миллионов и что там еще в качестве призов предлагается.


    В криптографии так не принято, когда автор одновременно выдвигает алгоритм в качестве стандарта и скрывает внутреннее устройство. Либо крестик (т.е. объяснить аномалию), либо трусы (т.е. идти и шифровать в недрах ФСБ, там такое любят). Они бы еще бинарник обфусцированный дали и предложили стандартизировать, а что — алгоритм? Алгоритм!


    Возможно, что эта структура в таблице усиливает какие-то свойства алгоритма, а рассказать об этом не могут, т.к. раскрыть принцип формирования таблицы == раскрыть саму атаку. Такое уже было с DES, и тогда тоже все говорили о том, что возможно NSA вставила бекдор. Вопрос доверия ФСБ полагаю оставить за рамками этого комментария, лично у меня этого доверия нет. И в целом основывать защищенность на доверии одной спецслужбе — не самая лучшая идея.

  • PCB-бейдж, которого не будет, или как преодолеть все и проиграть на финише
    +1

    Ну вот, повод взять МК поёмче и таки сделать возможность заливать туда пользовательскую часть прошивки для взаимодействия с диодами и I2C бейджа. Хотя в TSSOP20 поёмче найти сложно, конечно, но вот в LQFP уже легко. Да хоть тот же 103C8T6.


    Например, комбинируя бутлоадер и скриптовый язык — по умолчанию в пользовательскую зону прошит интерпретатор, а кто хочет — может загрузчиком перешить на что-то своё.


    Поскольку основные функции типа инициализации шины и ШИМ генератора для светодиодов уже будут в основной прошивке, для нативной части там даже сильно емче не надо делать — оно и так сойдет, т.к. API есть и только прикладная логика нужна. А вот для интерпретатора может и не хватить, это да.

  • Сделай свой бейдж: Shitty Add-On не против OFFZONE
    0

    Ну конкретных идей нет, есть только абстрактные, насчет просто I2C шины и прошивки.


    1. Первое, что напрашивается — просто вывести возможность (например, через USB CDC) отправлять сырые запросы на шину, адрес-направление-буфер.
    2. Второе — воткнуть туда какой-нибудь микропитон, луа или что-то похожее, если ресурсы МК позволяют, и активировать по какому-нибудь триггеру — и пусть владелец дальше питонячит.
    3. Третье, самое хардкорное, это сделать в оригинальной прошивке функцию бутлоадера и отдать конец флеша под запись пользователю. Аналогично, по какому-то триггеру управление передается на ресет-вектор из пользовательского куска. Хотя, конечно, это имеет свои побочные эффекты — пользовательский кусок может читать основную прошивку, а при особом желании может и писать. Но если чтение не проблема, а те, кто её сам перезаписал — ССЗБ, то почему бы и нет.
  • Правительство РФ поддержало законопроект об идентификации пользователей электронной почты
    +2

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

  • Сделай свой бейдж: Shitty Add-On не против OFFZONE
    0

    А чем обусловлено отсутствие I2C-интерфейса на разъемах?

  • На чёрном рынке продают валидные сертификаты подписи исполняемого кода для обхода антивирусов
    0

    В том, что это не Domain-Validated сертификат, а значит — его выпуск требует не только владения доменом, а еще, например, юрлица.

  • Прекрасное настоящее и светлое будущее Scala
    0

    Комментарий удален

  • Как спасти принцессу, используя 8(+45) языков программирования, в пятницу
    0

    Это если слово private использовать при объявлении. А если не использовать (члены класса по умолчанию приватны) — то не получится.

  • Dropbox объяснил, почему внедряется в ядро операционной системы
    +3
    Из Docker-контейнера нельзя загрузить модуль ядра, т.к. ядро общее с хостом. Если не хочется, чтобы оно свои модулей в ядро насовало — можно запускать из-под юзера, если паранойя и тут — то из-под отдельного юзера или завернуть в SELinux, например.
  • Сноуден раскритиковал безопасность мессенджера Telegram
    +1
    Для огромных файлов разумно (и GPG/PGP так и делает, например) генерировать случайный сессионный ключ, им шифровать файл, а сам ключ уже шифровать для N устройств.
  • АНБ скомпрометировало протокол Диффи-Хеллмана?
    +1
    Там есть набор стандартных кривых, которыми (и только ими) тоже пользуются все:
    openssl ecparam -list_curves
    


    Пока, конечно, не опубликовано способа, который может ускорить вычисления закрытых ключей, сгенерированных над этими кривыми, но утверждать, что в ECDH/ECDSA совсем нет общих параметров, нельзя.
  • Повальная регистрация устройств для онлайн-банкинга отменяется
    +1
    По-моему, было бы логично если и ограничивать доступ, то не на основе IP-адресов, а на криптографического токена/смарт-карты/апплета в EMV-карте. Некопируемо и предоставляет высокий уровень безопасности.

    Лично мою паранойю давно жевала передача пароля по SMS в Сбербанке вкупе с историями о том, как мошенники заказывали перевыпуск SIM-карты и опустошали счета.
  • Пароли — это прошлый век, в дальнейшем требуются новые методы авторизации и хранения личных данных
    0
    Секретные ключи генерируются на самом токене и никогда его не покидают (токен не дает экспортировать эти ключи). Открытые же части ключей при регистрации отправляются на сервисы, которые хотят аутентификации по этому токену. При самой аутентификации токен подписывает закрытым ключем случайную строку, сервис проверяет сохраненным открытым. Единственная проблема в этом случае — утеря/выход из строя токена.
  • Comment from a drafted post.
  • Comment from a drafted post.
  • Microsoft покупает компанию-разработчика Minecraft за 2 миллиарда долларов США
    +4
    Исходники неоффициальные, в некоторых местах не деобфусцированные, но они отлично компилируются и запускаются. Набор инструментов для декомпила называется MCP, так же его использует Minecraft Forge.
  • Microsoft покупает компанию-разработчика Minecraft за 2 миллиарда долларов США
    0
    Исходники имеются, но вот легальность такого форка — просто никакая
  • Шифрованный тоннель для общения через VK (RSA + GreaseMonkey)
    +1
    2048-битный ключ — это такой огромный blob, который передать по другому (например, телефону) каналу весьма проблематично. Ключи допустимо передавать и через чат, но выводя отпечатки ключей на обоих сторонах. Тогда можно будет позвонить по тому же телефону и довольно быстро сверить эти отпечатки. Другой вопрос — если ключ используется в течении долгого времени, то где его хранить? cookies, localstorage — оба хранилища легко читаются контактовскими скриптами, а первое, кроме того, еще и на сервер VK посылается. Возможное решение — хранение шифрованного ключа в LocalStorage и запрос через функцию prompt() пароля. Но, я уверен, тут найдется еще куча приемов типа замены функций, благо JS позволяет.

    Кроме того, можно использовать долговременные ключи только для аутентификации, а сам ключ шифрования получать посредством DH/ECDH, как это делает OTR. Это немного снизит опасность похищения ключей, т.к. предыдущую переписку расшифровать все равно не получится (Perfect forward secrecy).
  • Привет, криптовалюты. Небольшая новость из прокуратуры
    0
    Новые адреса создаются еще и для того, чтобы в автоматическом режиме (например, в интернет-магазине) отслеживать, кто же тебе переслал деньги — для каждого заказа генерируется свой адрес, и отслеживаются пополнения на эти адреса.
  • Как начать майнить для начинающих
    0
    Конечно, но я и не говорил, что они не майнятся, не так ли? Факт остается фактом — далеко не каждое решение, принятое пулом, даст 50 монеток при соло-майнинге.
  • Как начать майнить для начинающих
    0
    При майнинге в пуле учитываются частичные решения — решения при пониженной сложности — надо же как-то проверить, что пользователь X работал, а не просто ждал, пока другие найдут блок. Соло-майнинг частичных решений не учитывает.
  • Визит на ферму ASICMINER-a
    +2
    Все новые транзакции включаются в блоки, которые, в свою очередь, нужно майнить. Правда, когда выработка новых монет закончится, сложность резко упадет — т.к. не все такие правильные и майнят исключительно во благо сети.
  • Новая рансомварь просит биткойны
    0
    Скорее всего, файл просто открывается в режиме записи и данные перезаписываются поверх текущих. Так что шансы асимптотически приближаются к нулю.
  • Разработка NFC приложений для Android
    0
    NFC — 13.56 мегагерц, так что врятли.