Но тут все еще ни слова о том, что эти биты нельзя читать. :)
Если я правильно понимаю, что имеется в виду под trap, то это — аппаратное исключение процессора, которое возникает при арифметических операциях на некоторых «особых» значениях. Поискал вот тут на досуге — нашел alpha architecture reference manual, где описаны несколько видов этих аппаратных traps — overflow trap, underflow trap, invalid operation arithmetic trap, division by zero trap и еще кучка. Правда, насчет trap bits в данных ничего внятного найти не удалось.
Поискал в стандарте по слову trap — нашел всего 8 упоминаний. В основном — про то, что некоторые типы данных могут вызывать trap при арифметических операциях на некоторых значениях (нутром чую, что имеется в виду что-то типа аппаратного исключения при делении на ноль). Про механизм работы этих traps нет ни слова.
Но есть упоминание, что если тип данных имеет trap bits или padding bits, то сравнение таких данных побайтно (memcmp) может не сработать: [ Note: The memcpy and memcmp semantics of the compare-and-exchange operations may result in failed comparisons for values that compare equal with operator== if the underlying type has padding bits, trap bits, or alternate representations of the same value. Thus, compare_exchange_strong should be
used with extreme care. On the other hand, compare_exchange_weak should converge rapidly. — end note ]
По сути это говорит нам, что такие биты читать можно, но нельзя надеяться, что они содержат что-то осмысленное.
Мне кажется, вы перегибаете палку. Когда под структуру выделяется память (через malloc, new или объявление переменной), то стандарт гарантирует выделение куска памяти размером не менее sizeof(структура). И правила доступа ко всему этому куску будут одинаковыми — другими словами, если вы можете прочитать два значения из структуры, то вы сможете прочитать и байты выравнивания, расположенные между ними.
Сейчас вот специально перечитал стандарт C++11 (3.11 Alignment) — ни слова о том, что байты выравнивания имеют какую-то особую семантику. Можете привести пример платформы, на которой байты выравнивания чем-то кардинально отличаются от байтов самой структуры?
Вы описали состояние «укурыш подсел на измену». Для укурышей оно, может, и типично, но вот для обычных людей я что-то не наблюдаю никаких эффектов самодумания — хотя некоторые мои знакомые глубоко забурились в практики самосозерцания и медитаций.
Ээээ… Почему же нельзя? Память там вполне обычная, читабельная. union A {
struct BigStructWithAlignment a;
unsigned char b[sizeof( struct BigStructWithAlignment )];
};
Заполняем структурку в а, потом читаем байты из b — и все байты выравнивания как на ладошке. Никто запретить не может.
Другое дело, что нельзя надеяться на то, что байты выравнивания будут заполнены нулями.
Вообще-то в ОПН нет ничего «этакого», что противоречило бы человеческой природе. Помню, в далеком вьюношестве писал программки на языке Forth — там как раз обратная польская запись и стек. Мне очень даже нравилось. Все формулы довольно просто преобразовывались в ОПН (правда, слишком многоэтажных я не использовал). Главное было не запутаться, какие числа в данный момент находятся в стеке.
Это главная идея, которую, как я считаю, следовало бы перенять ...
Среда настраивается один раз — и потом в ней работают годами. Поэтому глобальная ценность всей идеи сомнительная. Или вы настройки меняете каждый день по многу раз? Зачем?
В двух словах, следует зарезервировать две кнопки: одну для курсора редактирования (каретки\caret), например F1, а другую для курсора/указателя мыши (mouse pointer), например F4
Получилось гораздо больше двух слов. ;)
Вообще же все уже придумано до нас и такая кнопка уже есть: расположена рядом с правым Ctrl.
Во-первых, как видно на рисунке в начале статьи, я предлагаю, помимо вертикальных «линеек», отображающихся во многих IDE, добавить ещё горизонтальные.
Насколько я знаю, во многих IDE есть режим свертки блоков кода: это когда рядом с блоком кода отображается крестик, а сам блок выделяется в т.ч. горизонтальными линиями. Блок можно свернуть, нажав на крестик, и аналогично развернуть. Очень помогает в анализе глубоко вложенных ифов и циклов.
Пример реализации можно посмотреть, например, в Notepad++.
Во-вторых, многие двойные операторы можно отображать как единые символы: ══ вместо ==, ≠ вместо != и т.д.
Нахрен не нужное украшательство. Поясню почему:
1. Большинство редакторов кода использует моноширинный шрифт. В таком шрифте «длинное равно» будет выглядеть почти так же, как обычное — придется приглядываться. Кроме того, укоротятся строки, в которых много двойных символов заменено на одинарный — а во многих конторах жесткий coding style, запрещающий слишком длинные строки. Будем ограничитель по правому краю лесенкой показывать? :)
2. В буфер копировать будем тоже спецсимвол или таки исходное сочетание? А если из буфера спецсимвол вставить — он будет интерпретироваться как двойной символ или как один спец? :) Придется как-то различать «легальный» спецсимвол (например, в составе строкового литерала) и «улучшенное» отображение операторов. Вплоть до того, что придется держать в памяти два варианта текста — «улучшенный» и обычный.
3. Аргумент, конечно, дурацкий, но: а потом программист, привыкший к украшательствам, откроет код в обычном редакторе и не сможет ничего сделать — непривычно, страшно, вернитевсеназад!!!11111адынадын. К сожалению, видел такое гораздо чаще, чем хотелось бы.
Поле ввода для кода, генерирующего HTML, который отображается в отдельном окошке, которое можно перемещать или прикреплять к существующим элементам среды разработки.
Вообще не понял этого фрагмента. О чем вы? Просмотр содержимого переменных во время отладки?
Я считаю, что не имеет смысла показывать много ошибок списком, а имеет смысл показывать одну наиболее точную ошибку,
Все так считают, да вот незадача: в общем случае неизвестно, какая из ошибок в списке «наиболее точная».
Как вам табуляция, скажем, в 3 с половиной символа? Или π (пи) символов?
Абсолютно бессмысленная опция, которая сделает из вашего кода кашу плавающих строчек. Я вас уверяю, моноширинные шрифты в редакторах кода используются не просто так. :)
Лично я пользуюсь операцией Undo достаточно часто с целью review\просмотреть последние сделанные в текущем файле изменения
Вызывает уважение, конечно. Примерно такое же, как уважение к бухгатлеру, копирующему файлы через ворд (открыть — сохранить как). Иногда, конечно, метод дает сбой, но в основном же работает. :)
Для того, что вы делаете, придуманы системы контроля версий. Они гораздо надежнее, чем анду-реду, и бывают встроены в IDE.
В качестве такого механизма и для совместимости с существующим поведением в большинстве текстовых редакторов, я предлагаю задействовать новое сочетание клавиш Ctrl+Shift+Y, которое сначала отменит случайное нажатие клавиши (не помещая его в Redo-стек), а затем продолжит операцию Redo.
А как отменить отмену случайного нажатия клавиши? :)
В любом случае, легче научить программиста пользоваться инструментами правильно, чем переписывать инструменты под каждый закидон, который может прийти в голову.
На чистом С еще много где нужно программировать — например, драйверы ядра писать. Или на микроконтроллерах ковыряться — интернет вещей же, вычовычо.
Но вообще статья странноватая. Взять два языка разного уровня и рассказывать, чего не хватает в низкоуровневом. Дык — коню понятно, чего не хватает: того, что добавлено в высокоуровневые языки. Думаю, в рекламке Rust все его преимущества описаны лучше и полнее, чем у товарища Федерико.
Все это прекрасные слова, но есть одно большое «но».
Чтобы создать и поддерживать такую систему отвода глаз, нужны средства, соизмеримые с созданием и поддержкой основной системы. А в госструктурах и на основное-то деньги выделяются впритык.
вы уверены, что будет работать на HFS+Filevault2 и APFS?
Я не знаю тонкостей работы FileVault2. Ключевой момент — перешифровывает ли он все содержимое раздела или только записываемые данные. Из описания сей момент не очень ясен, но могу предположить, что скорее всего шифруются только записываемые данные — т.е. предыдущее содержимое диска полностью не перетирается. Другими словами, некая уверенность есть.
APFS вряд ли кардинально отличается от других ФС в плане перезатирания предыдущего содержимого диска, так что тоже, думаю, сработает. Главное — форматировать без проверки на бэд-блоки (быстрое форматирование), иначе все перезатрет.
есть имплементации?
Не знаю. Возможно, кто-то уже делал что-то подобное. Я лично предпочитаю не прятать шифрованные файлы — пусть себе выглядят как испорченные, мало ли что с флэшкой стряслось. :)
Накидать прототипчик на основе кода, имеющегося в статье, нетрудно при желании.
А насчёт пристального изучения, просто по образу ФС отсутствие пустых блоков будет более подозрительно.
Пристальное изучение раздела на уровне секторов и пустых мест — это уже провал резидента. :)
Но вообще можно возразить. После создания ФС пустое место вовсе не обязательно должно содержать нули или один и тот же байт. Раздел ведь мог раньше содержать, скажем, рипы с блюрея — а это много-много практически рандомных байт.
Так что отмазка в стиле «а, так я на этой флэшке раньше киношки держал» — вполне себе правдоподобная. Правда, не получится старое содержимое восстановить программами-восстанавливалками, но это оч-чень косвенная улика.
(тем более, что там будет много повторяющихся блоков)
Не будет, если при шифровании подмешивать порядковый номер сектора, как я упоминал. Скажем, перед шифрованием содержимое сектора XOR'им с порядковым номером сектора на диске, потом шифруем. В результате содержимое секторов с одинаковыми данными будет различным — номера-то различаются.
Но мы можем быть совсем невезучими, и какой-то блок все же будет перезаписан.
Должен быть перезаписан не просто один блок, а все блоки с одним и тем же фрагментом зашифрованного файла. Это весьма маловероятно, особенно если копий разбросано несколько десятков по всему разделу — файловой системе придется «прицельно» размазывать файлы по всему пространству раздела. Большинство файловых систем располагают файлы достаточно компактно.
Да и в случае, если образ такой ФС попадёт кому-то на анализ, полное отсутствие пустых блоков сразу вызовет подозрение, особенно если ФС была создана недавно.
Вовсе не обязательно.
Достаточно один раз заполнить весь диск под завязку, скажем, фильмами, а потом отформатировать его — и для внешнего наблюдателя все будет выглядеть точно так же: полное отсутствие пустых блоков.
Да и — скажем честно — если флэшку кто-то изучает настолько пристально, что вручную разбирается с пустым пространством — для нашего Штирлица это уже провал. Поздно утюги на подоконнике рядами выставлять. :)
Данный метод стеганографии, вероятно, нуждается в доработке, дополнительном тестировании и расширении на более популярные файловые системы, такие как Fat32, NTFS и ext4.
Дарю простой и универсальный метод стеганографии, не зависящий от файловой системы:
— весь раздел заранее заполняем шифрованными блоками. Например, используем тот же AES, каждый 512-байтный сектор шифруется по паролю (плюс можно задействовать номер сектора, чтобы содержимое не совпадало). Для проверки правильности расшифровки сектор помещаем хэш-сумму его содержимого (сойдет и MD5) — например, в заголовок.
— скрываемую информацию записываем многократно. Каждый сектор с информацией помечаем коротеньким заголовочком (порядковый номер фрагмента зашифрованного файла, например). Так, если у нас в заголовке только номер фрагмента (4 байта) и хэш-сумма содержимого (16 байт), то полезная нагрузка одного сектора будет 512-20 = 492 байта.
Вот и все.
Теперь создаем в этом разделе файловую систему (любую) и даже пишем на нее всякую лабуду. Главное — создавать ФС без проверки секторов на предмет битости, т.к. в этом случае все секторы раздела будут перезаписаны.
Чтение — элементарно:
— читаем очередной сектор.
— расшифровываем его (пароль + номер мектора).
— проверяем хэш-сумму полученного содержимого. Если не совпала — пропускаем сектор и идем дальше.
— если совпала — дополняем расшифрованный файл полученным фрагментом (в нужном месте, понятное дело — на то у нас номер фрагмента есть).
— если все фрагменты файла получены — ура, можно прекращать чтение.
Чем короче шифруемый файл, тем больше его копий поместится в разделе, и тем выше вероятность собрать их все.
И не надо никакие битмапы искать и анализировать, не надо разбираться в особенностях конкретных файловых систем.
Если я правильно понимаю, что имеется в виду под trap, то это — аппаратное исключение процессора, которое возникает при арифметических операциях на некоторых «особых» значениях. Поискал вот тут на досуге — нашел alpha architecture reference manual, где описаны несколько видов этих аппаратных traps — overflow trap, underflow trap, invalid operation arithmetic trap, division by zero trap и еще кучка. Правда, насчет trap bits в данных ничего внятного найти не удалось.
Но есть упоминание, что если тип данных имеет trap bits или padding bits, то сравнение таких данных побайтно (memcmp) может не сработать:
[ Note: The memcpy and memcmp semantics of the compare-and-exchange operations may result in failed comparisons for values that compare equal with operator== if the underlying type has padding bits, trap bits, or alternate representations of the same value. Thus, compare_exchange_strong should be
used with extreme care. On the other hand, compare_exchange_weak should converge rapidly. — end note ]
По сути это говорит нам, что такие биты читать можно, но нельзя надеяться, что они содержат что-то осмысленное.
Сейчас вот специально перечитал стандарт C++11 (3.11 Alignment) — ни слова о том, что байты выравнивания имеют какую-то особую семантику. Можете привести пример платформы, на которой байты выравнивания чем-то кардинально отличаются от байтов самой структуры?
union A {
struct BigStructWithAlignment a;
unsigned char b[sizeof( struct BigStructWithAlignment )];
};
Заполняем структурку в а, потом читаем байты из b — и все байты выравнивания как на ладошке. Никто запретить не может.
Другое дело, что нельзя надеяться на то, что байты выравнивания будут заполнены нулями.
Среда настраивается один раз — и потом в ней работают годами. Поэтому глобальная ценность всей идеи сомнительная. Или вы настройки меняете каждый день по многу раз? Зачем?
Получилось гораздо больше двух слов. ;)
Вообще же все уже придумано до нас и такая кнопка уже есть: расположена рядом с правым Ctrl.
Насколько я знаю, во многих IDE есть режим свертки блоков кода: это когда рядом с блоком кода отображается крестик, а сам блок выделяется в т.ч. горизонтальными линиями. Блок можно свернуть, нажав на крестик, и аналогично развернуть. Очень помогает в анализе глубоко вложенных ифов и циклов.
Пример реализации можно посмотреть, например, в Notepad++.
Нахрен не нужное украшательство. Поясню почему:
1. Большинство редакторов кода использует моноширинный шрифт. В таком шрифте «длинное равно» будет выглядеть почти так же, как обычное — придется приглядываться. Кроме того, укоротятся строки, в которых много двойных символов заменено на одинарный — а во многих конторах жесткий coding style, запрещающий слишком длинные строки. Будем ограничитель по правому краю лесенкой показывать? :)
2. В буфер копировать будем тоже спецсимвол или таки исходное сочетание? А если из буфера спецсимвол вставить — он будет интерпретироваться как двойной символ или как один спец? :) Придется как-то различать «легальный» спецсимвол (например, в составе строкового литерала) и «улучшенное» отображение операторов. Вплоть до того, что придется держать в памяти два варианта текста — «улучшенный» и обычный.
3. Аргумент, конечно, дурацкий, но: а потом программист, привыкший к украшательствам, откроет код в обычном редакторе и не сможет ничего сделать — непривычно, страшно, вернитевсеназад!!!11111адынадын. К сожалению, видел такое гораздо чаще, чем хотелось бы.
Вообще не понял этого фрагмента. О чем вы? Просмотр содержимого переменных во время отладки?
Все так считают, да вот незадача: в общем случае неизвестно, какая из ошибок в списке «наиболее точная».
Абсолютно бессмысленная опция, которая сделает из вашего кода кашу плавающих строчек. Я вас уверяю, моноширинные шрифты в редакторах кода используются не просто так. :)
Вызывает уважение, конечно. Примерно такое же, как уважение к бухгатлеру, копирующему файлы через ворд (открыть — сохранить как). Иногда, конечно, метод дает сбой, но в основном же работает. :)
Для того, что вы делаете, придуманы системы контроля версий. Они гораздо надежнее, чем анду-реду, и бывают встроены в IDE.
А как отменить отмену случайного нажатия клавиши? :)
В любом случае, легче научить программиста пользоваться инструментами правильно, чем переписывать инструменты под каждый закидон, который может прийти в голову.
Но вообще статья странноватая. Взять два языка разного уровня и рассказывать, чего не хватает в низкоуровневом. Дык — коню понятно, чего не хватает: того, что добавлено в высокоуровневые языки. Думаю, в рекламке Rust все его преимущества описаны лучше и полнее, чем у товарища Федерико.
В контексте изменится основное. «Фасебук» живет за счет доходов со своего сайта.
Госструктуре сайт — до лампочки, она живет за счет бюджетных средств.
Вы приписываете мне свои собственные фантазии. Я этого не говорил.
Да-да, достали фантазеры, в каждой дырке видящие хитрую многоходовочку.
Чтобы создать и поддерживать такую систему отвода глаз, нужны средства, соизмеримые с созданием и поддержкой основной системы. А в госструктурах и на основное-то деньги выделяются впритык.
Я не знаю тонкостей работы FileVault2. Ключевой момент — перешифровывает ли он все содержимое раздела или только записываемые данные. Из описания сей момент не очень ясен, но могу предположить, что скорее всего шифруются только записываемые данные — т.е. предыдущее содержимое диска полностью не перетирается. Другими словами, некая уверенность есть.
APFS вряд ли кардинально отличается от других ФС в плане перезатирания предыдущего содержимого диска, так что тоже, думаю, сработает. Главное — форматировать без проверки на бэд-блоки (быстрое форматирование), иначе все перезатрет.
Не знаю. Возможно, кто-то уже делал что-то подобное. Я лично предпочитаю не прятать шифрованные файлы — пусть себе выглядят как испорченные, мало ли что с флэшкой стряслось. :)
Накидать прототипчик на основе кода, имеющегося в статье, нетрудно при желании.
Пристальное изучение раздела на уровне секторов и пустых мест — это уже провал резидента. :)
Но вообще можно возразить. После создания ФС пустое место вовсе не обязательно должно содержать нули или один и тот же байт. Раздел ведь мог раньше содержать, скажем, рипы с блюрея — а это много-много практически рандомных байт.
Так что отмазка в стиле «а, так я на этой флэшке раньше киношки держал» — вполне себе правдоподобная. Правда, не получится старое содержимое восстановить программами-восстанавливалками, но это оч-чень косвенная улика.
Не будет, если при шифровании подмешивать порядковый номер сектора, как я упоминал. Скажем, перед шифрованием содержимое сектора XOR'им с порядковым номером сектора на диске, потом шифруем. В результате содержимое секторов с одинаковыми данными будет различным — номера-то различаются.
Должен быть перезаписан не просто один блок, а все блоки с одним и тем же фрагментом зашифрованного файла. Это весьма маловероятно, особенно если копий разбросано несколько десятков по всему разделу — файловой системе придется «прицельно» размазывать файлы по всему пространству раздела. Большинство файловых систем располагают файлы достаточно компактно.
Вовсе не обязательно.
Достаточно один раз заполнить весь диск под завязку, скажем, фильмами, а потом отформатировать его — и для внешнего наблюдателя все будет выглядеть точно так же: полное отсутствие пустых блоков.
Да и — скажем честно — если флэшку кто-то изучает настолько пристально, что вручную разбирается с пустым пространством — для нашего Штирлица это уже провал. Поздно утюги на подоконнике рядами выставлять. :)
Дарю простой и универсальный метод стеганографии, не зависящий от файловой системы:
— весь раздел заранее заполняем шифрованными блоками. Например, используем тот же AES, каждый 512-байтный сектор шифруется по паролю (плюс можно задействовать номер сектора, чтобы содержимое не совпадало). Для проверки правильности расшифровки сектор помещаем хэш-сумму его содержимого (сойдет и MD5) — например, в заголовок.
— скрываемую информацию записываем многократно. Каждый сектор с информацией помечаем коротеньким заголовочком (порядковый номер фрагмента зашифрованного файла, например). Так, если у нас в заголовке только номер фрагмента (4 байта) и хэш-сумма содержимого (16 байт), то полезная нагрузка одного сектора будет 512-20 = 492 байта.
Вот и все.
Теперь создаем в этом разделе файловую систему (любую) и даже пишем на нее всякую лабуду. Главное — создавать ФС без проверки секторов на предмет битости, т.к. в этом случае все секторы раздела будут перезаписаны.
Чтение — элементарно:
— читаем очередной сектор.
— расшифровываем его (пароль + номер мектора).
— проверяем хэш-сумму полученного содержимого. Если не совпала — пропускаем сектор и идем дальше.
— если совпала — дополняем расшифрованный файл полученным фрагментом (в нужном месте, понятное дело — на то у нас номер фрагмента есть).
— если все фрагменты файла получены — ура, можно прекращать чтение.
Чем короче шифруемый файл, тем больше его копий поместится в разделе, и тем выше вероятность собрать их все.
И не надо никакие битмапы искать и анализировать, не надо разбираться в особенностях конкретных файловых систем.
Умом-то я понимаю, что речь о фразеологизме со значением «я понимаю вашу точку зрения», но как звучит, как звучит! :)
Интересно, откуда пришел переводчик?
youtu.be/vkSwXL3cGUg?t=25s