waqur: (Default)
Поначалу подход к декомпиляции ассемблерного листинга в сишный код сводился к двум основным идеям:
– построение графа потока управления, а далее применение pattern matching в непрерывных блоках кода (так работает плагин HexRays к дизассемблеру IDA, и работает порой откровенно плохо, куда-то теряя существенные куски кода — наверное, когда не может подобрать подходящие паттерны)
– попытка "подобрать" исходный код, из которого бы порождался наперёд заданный бинарный код, путём вызова компилятора и перенаправления дальнейшего подбора в в нужную сторону, в зависимости от сопоставления выхлопа компилятора и заранее заданного бинарного кода (теоретический подход, рассматриваемый в нескольких диссерах по декомпиляции, на практике работает плохо из-за того, что во-первых, нужно точно угадать версию компилятора; во-вторых, из-за того, что такие блуждания неустойчивы с точки зрения обратной связи, и могут быстро зайти "не в те дебри"; в-третьих, компиляторы имеют тенденцию к переименованию регистров и разным другим перестановкам даже при множественной инвокации на одном и том же исходном коде — так что простым сравнением бинарного выхлопа не обойтись).

Декомпилятор FCD демонстрирует новый подход: декомпиляция через оптимизирующую компиляцию. Каждая инструкция архитектуры x86 или x86_64 преобразуется в несколько инструкций промежуточного кода LLVM-IR (включая все сайдэффекты, такие как изменения в регистре флагов), а затем для упрощения всего этого фарша применяется оптимизатор промежуточного кода из проекта LLVM.

Ну а промежуточный код LLVM-IR — это уже практически код на C. Остаётся только сформировать деревья выражений там, где были однократно используемые временные переменные.

Учитывая недавние теоретические успехи в реконструкции if-else-for-while-структур из графа потока управления, позволяющие всегда обойтись без goto, результаты работы FCD выглядят весьма неплохо, даже на фоне коммерческого HexRays.
waqur: (Default)
Одна вещь, которую я никогда не понимал в контексте теории борьбы с эксплоитами, основанными на stack corruption в коде, написанном на C/C++ и других небезопасных языках — это почему не используется расщепление стека надвое:

1. Доверенный стек: там обязательно должны быть адреса возврата из функций, параметры вызываемых функций; а также там могут быть локальные переменные, на которые не берётся указатель.

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

Не хватает регистров? Но мы ведь уже давно пишем не для 8-битных микроконтроллеров: в процессорной архитектуре x86-64 вдвое больше регистров, чем в x86, а ещё они вдвое шире. "Второй RSP" отлично поместился бы в каком-нибудь R13. Доверенный стек может быть исполняемым, недоверенный — всегда нет. Это бы решило проблемы несовместимости DEP (Data Execution Prevention) с GCC Nested Functions и всякими прочими closures из других языков. Очевидно, что глобальная оптимизация (которая называется в разных компиляторах по-разному: LTO, LTCG, IPO) могла бы существенно сократить количество случаев, когда нужен недоверенный стек.

Компиляторы и операционные системы могли бы поддерживать разные уровни параноидальности в реализации недоверенного стека:
* просто обычный стек
* стек со вставкой канареек в фрейм каждой функции
* стек со вставкой канареек после каждого объекта
* стек с чередованием отображённых и неотображённых страниц и с таким выравниванием каждого объекта, чтобы на следующем байте начиналась неотображённая страница
* полный запрет на существование недоверенного стека — подходящее решение для аэрокосмической/автомобильной/военной промышленности и медицины

Вместо этого индустрия вот уже лет десять или двадцать полагается на благие пожелания в вольной художественной форме, такие как MISRA C, или городит какие-то ASLR (которые не всегда работают), W^X, DEP, разные попытки противодействия ROP (например G-free и CFG), принудительные автоматические обновления, Rust и прочие глупости, которые проблему в общем-то и не решают, а так, царапают по поверхности.

SAM 1.3

2017-02-01 09:21 pm
waqur: (Default)
В Windows 10, начиная с Anniversary Update (10.1608), фирма Microsoft для чего-то поменяла способ шифрования хэшей в хайвах SAM.

Когда-то очень давно (во времена NT 3.51 и NT 4.0), пароли пользователей просто хэшировались алгоритмами MD4 и LMHash и в таком виде писались в хайв реестра под названием SAM.

В Service Pack 3 к NT 4.0 появилось нововведение под названием SYSKEY. Теперь хэши не просто хранились в SAM, а ещё и шифровались ключом под названием PEK. PEK генерировался случайно при установке Windows и тоже сохранялся в SAM-хайве, но не в открытом виде, а в зашифрованном. Шифрование PEK'а и хэшей происходило с помощью криптоалгоритма RC4, проверка валидности PEK'а делалась с помощью комбинации RC4 и MD5. Для расшифровки PEK нужен был ключик из хайва SYSTEM. Его в открытых источниках обычно называют SYSKEY, а Microsoft его именует Boot Key. Он хранится немного витиеватым способом (по частям в именах классов разных ключей реестра, связанных с подсистемой LSA), но извлекается без особых проблем. В общем, security through obscurity.

RC4-шифрование хэшей и PEK'ов по технологии SYSKEY просуществовало в неизменном виде во всех последующих версиях Windows (2000, XP, 2003 Server, Vista, 7, 2008 Server, 8, 8.1, 2012 Server, 10 RTM, 2016 Server), аж пока в Windows 10 Anniversary Update не произошли изменения.

Что бы вы думали? Они внедрили PBKDF2 вместо MD4, чтобы затруднить подбор паролей полным перебором на видеокартах? Перенесли вычисление Boot Key в TPM? В безопасный анклав Intel SGX? В Yubikey? Реализовали какую-то безумную систему проверки пароля с использованием zero knowledge proof, основанную на новейших достижениях криптографической мысли, таких как zk-SNARKs?

Фиг там, это же Microsoft. Они просто заменили RC4 на AES, а MD5 на SHA256 в своей security-through-obscurity схеме шифрования PEK'ов и хэшей (ну и попутно подняли версию формата данных 1.2 с 1.3, что сломало работу всяких утилиток для сброса пароля в винде, тысячи их). Разумеется, MD4 при всём при этом остался вечно живой, как Ленин.

Выглядит как формальная подготовка к какой-то правительственной сертификации. Убрать с начальственных глаз имена криптоалгоритмов и хэш-алгоритмов, к которым можно придолбаться с чисто формальной точки зрения. Ну спасибо, конечно, про RC4 мы давно догадывались, хотя в данном конкретном случае случае (SYSKEY — PEK — хэши паролей из SAM) что AES, что RC4, что XOR-наложение гаммы из линейного конгруэнтного ГПСЧ обеспечивают абсолютно идентичный уровень безопасности.
waqur: (Default)
Недавно украинский нацсовет по телерадиовещанию запретил ретрансляцию российского телеканала "Дождь" в украинских кабельных сетях. Причина: многократная телетрансляция карт, где Крым изображён как часть России.

Тут сразу поднялся вой возмущённых возгласов российских либералов. Впрочем, тот факт, что российские либералы заканчиваются там, где начинается украинский вопрос, заметил ещё пан Винниченко в 1919 году. Отдельно позабавило присоединение Пескова и Маши Захаровой к хору "гибридных либералов". Что ж, можете в ответ отключить в России ретрансляцию телеканалов Zik и Espreso.

Но лучший комментарий, который я видел по этому поводу, конечно, таков: Этот вопрос можно будет обсудить на переговорах контактных групп в Минске.
waqur: (Default)
Ни капельки не жалею, что переехал сюда с LiveJournal, надо было только сделать это раньше. DreamWidth напоминает LiveJournal 2007 года, до покупки российским СУПом, с несколькими небольшими исправлениями. После переезда — такое странное ощущение возвращения домой.

Серверы не тормозят, ничего не глючит, нет рекламы, страницы не напичканы ссылками на десятки счётчиков и сборщиков статистики на каких-то левых доменах, стили не сломаны шаловливыми кривыми ручками рассеянских погромистов. Сайтом можно пользоваться без встроенного в браузер блокировщика рекламы. Функция добавления внешнего RSS-потока на френдленту не требует покупки платного аккаунта. Никаких ограничений для бесплатных пользователей по настройке стиля журнала (можно даже хачить css). Исправлены некоторые очевидные несуразности: например, разделены функции "подписаться на записи пользователя" и "предоставить пользователю доступ к своим закрытым записям"; функция редактирования постов отделена от функции редактирования тэгов (что полезно, например, при назначении прав модерирования в сообществах). Функция редактирования своих комментариев в чужих журналах и сообществах тоже бесплатная, хотя в LiveJournal на момент ответвления DreamWidth она была платной.

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

Volume

2017-01-08 05:48 pm
waqur: (Default)
Игра Volume от Mike Bithell Games — удивительная вещь. Примитивная, почти двухмерная, графика и практически отсутствующий сюжет сполна компенсируются невероятно драйвовой игровой механикой, которая легко может затянуть вас часиков эдак на 6 (пока не пройдёте все 100 уровней, бггг). Жанр — стелс-экшн.
waqur: (Default)
Реакция украинских рэперов на назначение польского рок-музыканта Войцеха Бальчуна директором украинской железной дороги:
waqur: (Default)
В связи с переездом серверов LiveJournal в Россию, я принял решение о переносе этого блога на платформу DreamWidth: https://waqur.dreamwidth.org/

О переезде серверов LiveJournal из Калифорнии в Москву:
http://watcher.com.ua/2016/12/26/servery-livejournal-perenesly-v-rosiyu/
http://www.metafilter.com/164293/LiveJournal-represents-social-media-without-borders
http://dolboeb.livejournal.com/3079690.html

Доступ органов российской госбезопасности к персональным данным пользователей ЖЖ (который у них был с момента поглощения компании Six Apart компанией SUP) меня не особенно беспокоил, поскольку этот журнал ведётся в полностью открытом режиме. Однако сейчас появились новые риски, такие как риск потери всех данных в аккаунте и риск потери возможности уведомить своих френдов о своих новых координатах. Эти новые риски, по моим оценкам, перевешивают преимущества ЖЖ перед DreamWidth, касающиеся количества пользователей. В моём случае это стало мотивирующим фактором для переноса журнала на другую платформу.

В DreamWidth есть функция импорта всех ваших данных из ЖЖ. Вы указываете свой логин и пароль, а далее полностью автоматически переносятся записи, комментарии, профиль, юзерпики и тому подобное. У меня небольшой журнал (около 400 записей) и весь процесс занял примерно 10 минут. Пользуйтесь этим, пока есть такая возможность, ведь её легко закрыть со стороны ЖЖ.
https://www.dreamwidth.org/support/faqbrowse?faqid=127

Также свой ЖЖ можно заархивировать с помощью wget (только замените имя пользователя):

#!/usr/local/bin/bash
WGET_USER_AGENT="Mozilla/5.0 (Windows NT 6.1;\
WOW64; rv:50.0) Gecko/20100101 Firefox/50.0"
wget --recursive --no-clobber --page-requisites \
     --adjust-extension --no-iri \
     --convert-links --restrict-file-names=windows \
     --level=9999 --span-hosts \
     --retry-connrefused --waitretry=1 \
     --read-timeout=20 --timeout=15 -t 0 \
     -e robots=off "--user-agent=$WGET_USER_AGENT" \
     --accept-regex '(.*((username\.livejournal\.com)|\
(users\.livejournal\.com/username/)).*)|\
(.*\.(png|gif|jpeg|jpg))' \
     --wait 1 -- "username.livejournal.com"
waqur: (Евро)
Обозреватели Arstechica жалуются, что новейший процессор от Intel (Kaby Lake, i7-7700K) по тестам не быстрее предыдущего (Skylake, i7-6700K):
http://arstechnica.com/gadgets/2017/01/intel-core-i7-7700k-kaby-lake-review/
Он чуть лучше гонится, потому что зубную-пасту-вместо-нормального-термоинтерфейса под крышкой процессора наконец-то исправили, ну а так — то же самое.

Если кто не знает или не помнит, Intel в этом году впервые дала пас в своей знаменитой "стратегии tick-tock": переход с 14нм на более тонкий техпроцесс (tick) был задержан на год из-за технологической неготовности. Взамен были обещаны архитектурные улучшения (ещё один tock), но как видим, увы.

Картинка для привлечения внимания: Механизм трансляции виртуальных адресов в физические в процессорах Intel: 64-битный режим, гостевая ОС в условиях аппаратной виртуализации (источник).

waqur: (Евро)
После перехода Windows на UEFI-загрузку старые интерфейсы BIOS, такие как int 13h (доступ к диску) и int 10h (управление экраном), казалось бы, могут быть наконец отправлены на пенсию (кроме случаев, когда загрузка происходит в режиме совместимости и в firmware вашего компьютера активизирован модуль CSM). Для вывода текста есть console I/O protocol, для переключения видеорежимов и блитирования есть graphics output protocol, также в UEFI существуют протоколы для считывания EDID-данных с дисплея (в т.ч. родного разрешения LCD матрицы), для доступа к диску и тому подобного.

Однако все эти новые UEFI протоколы становятся недоступными после вызова ExitBootServices() в процессе загрузки платформы, в контексте UEFI-загрузчика (например, такого как BOOTMGR.EFI). Не вызывать эту функцию нельзя, потому что иначе UEFI-загрузчик не перейдёт с CPL=3 на CPL=0, т.е. не возьмёт процессор под свой полный контроль и не сможет передать управление ядру.

А ведь SVGA-драйверу Windows нужно уметь переключать видеорежимы не только во время загрузки, а ещё и например когда пользователь меняет настройки рабочего стола. Поэтому драйвер VIDEOPRT.SYS содержит полнофункциональный эмулятор процессора, с пошаговым исполнением 16-разрядных команд из обработчика int 10h (который переключает видеорежимы, получает EDID-информацию от монитора, осуществляет suspend/resume видеокарты и т.п. — всё это посредством команд IN/OUT, причём разных команд для разных моделей видеокарт; соответствующий 16-разрядный код предоставляет сама видеокарта через option rom).

Таким образом, UEFI firmware должно при инициализации платформы проинсталлировать 16-разрядный код VBE SHIM по адресу 0xC0000, защитить этот регион памяти от записи и так далее (пример, как это делается, можно посмотреть в TianoCore). Ни UEFI firmware, ни Windows никогда не переключают процессор в 16-разрядный режим для прямого выполнения этого кода, но 16-разрядный код по-прежнему остаётся обязательной частью UEFI-платформы, в роли такого себе байткода виртуальной машины.

Когда-то давно, во времена NT 4.0, Windows просто приостанавливала многозадачность, выключала страничную адресацию, запрещала прерывания и помолясь переведя процессор в 16-битный режим, делала прямой вызов BIOS(*). Очевидно, что в эпоху многоядерных процессоров (ядра которых могут активно слать IPI друг другу) и 64-битности, такой финт может закончиться летальным исходом, поэтому в современных версиях Windows драйвер минипорта VGA содержит вышеупомянутый эмулятор, откуда он и перекочевал на UEFI-платформу. В отличие от семёрки и последующих версий, виста при загрузке (во время демонстрации логотипа) ещё и переключается в адовый VGA-режим 680x480 с 16 цветами и планарной видеопамятью по адресу 0xA0000 (где плоскости переключаются через порты VGA-контроллера); редкая комбинация UEFI-прошивки и прошивки видеокарты способна выдержать такое издевательство. Ну а Windows XP/2003 отличается в этом смысле как от предыдущих, так и от последующих версий Windows — она не содержит эмулятор как NT 6.x, но и не делает прямых вызовов BIOS как NT 4; вместо этого она выполняет код VESA BIOS Extensions в режиме виртуального 8086 (т.е. задействует аппаратную эмуляцию 16-битного кода, доступную только когда процессор находится в 32-битном защищённом режиме).

FreeBSD тоже содержит эмулятор 16-битного кода BIOS в драйвере vesa(4), для той же цели — переключение видеорежимов на заранее неизвестной видеокарте после загрузки ядра. Этот драйвер работоспобен в 32-битных и 64-битных ядрах, но только в BIOS/CSM режиме (в режиме UEFI драйвер vesa недоступен, а переключение видеорежимов делается только в загрузчике через UEFI GOP протокол).

Linux не содержит такого эмулятора и может переключать видеорежимы (на заранее неизвестной видеокарте) только до загрузки ядра.




* В ту эпоху такие прямые вызовы BIOS с глобальным остановом всей системы делались отнюдь не только при переключении видеорежимов. Анекдот про Билла Гейтса, который обещает показать, что такое многозадачность в Windows, но только после того, как доформатирует дискету, взялся именно оттуда.
waqur: (Евро)
На Подоле (Андреевский спуск) недавно реконструировали театр, на средства мецената — корпорации Рошен. Теперь он выглядит так:





http://www.pravda.com.ua/news/2016/11/29/7128283/

На смену стилю "донецкое быкокко", также известному как "цыганский ампир", который мы видели в Межигорье и на даче Пшонки, приходит нечто новое: шоколадный кубизм. Возмущённые киевляне, которые говорят, что театр выглядит как коробка из-под киевского торта, просто ничего не понимают в современной архитектуре. Окна заделали, чтобы сэкономить коммунальные деньги на счетах за отопление. На втором этаже будет бутик Рошен, а на третьем — трансформаторная подстанция.
waqur: (Евро)
На фоне всего этого хэллоуина e-декларирования, мне непонятно, как правительство Гройсмана будет дальше вести переговоры о кредитах и траншах с МВФ, всемирным банком и остальными международными кредиторами. Да им просто скажут: ребята, если вы перечислите в государственный бюджет хотя-бы 10% всей этой задекларированной наличности, то сразу сможете выплатить весь государственный долг и ещё 20 лет финансировать дефицит пенсионного фонда.

Нашёлся даже депутат-шутник Мельничук, который задекларировал один триллион гривен наличными. По-моему, все эти разъяснения Национального Банка Украины о размерах монетарных агрегатов M0 и M1 были абсолютно лишними. Лучше бы глава фискальной службы Насиров пошутил в ответ, выставив депутату квитанцию на оплату 18% НДФЛ.
waqur: (Евро)
Intel S3700 200 Gb — четыре года, полёт нормальный.

Intel S3500 480 Gb — два года, полёт нормальный.

Kingston SSDNow 512 Gb — примерно через 60 дней непрерывной работы исчезает с шины SATA. Этот эффект подтверждён не менее трёх раз. После выключения-включения — появляется опять. Изоляция (возможно глючной) прошивки контроллера от TRIM-команд и поддающихся сжатию данных с помощью шифрующего слоя geli не помогает. В общем — consumer only устройство, рассчитанное на регулярный power cycling. Такое даже в не каждый ноутбук можно поставить.

Bitmessage

2016-10-15 09:36 pm
waqur: (Евро)
Bitmessage — первый шифрочятик, который способен шифровать метаданные (кому, от кого, когда, сколько байт).
https://en.wikipedia.org/wiki/Bitmessage

Технически, в DHT-сети содержится пул сообщений за последние 48 часов, зашифрованных публичными ключами. Хэш публичного ключа = сетевой адрес получателя сообщения. Приватные ключи, необходимые для расшифровки, локально хранятся у клиентов и не передаются в сеть. Для DDoS'оустойчивости применяется proof-of-work на хэшах, наподобие биткойновского.

UPD. Идея хорошая, но есть проблемы с реализацией — память течёт, и приложение периодически падает (32-битная версия) или заставляет систему грызть своп и всё равно падает (64-битная версия). Вдобавок ко всему, ещё и на Питоне. Если было написано на чистом Си — можно было бы применить Intel Inspector XE, а так хз, что там течёт — рантайм Питона, Питоновские библиотеки, или сама программа. Не наши проблемы, пусть автор сам разбирается во всём этом великолепии :)
waqur: (Евро)
Что мне не нравится в Firefox'е — это замыленные значки и шрифты при системной настройке 120 DPI (увеличенные до 125% шрифты в Windows). Поэтому, первым делом после установки этого браузера я захожу в about:config и задаю layout.css.devPixelsPerPx=1 и layout.css.dpi=96. Это решает проблему практически на 100%, за вычетом системных и контекстных менюшек, которые остаются с мелким шрифтом (на них не влияют даже настройки font.minimum-size.*).

До сегодняшнего дня я боролся с этой досадной мелочью браузерным аддоном Theme Font & Size Changer, который, кстати, весьма неприлично себя ведёт, открывая свою домашнюю страницу при каждом автообновлении. В общем, очевидно, что подобные аддоны не улучшают безопасность браузера. Сегодня этот аддон окончательно сломался, что подтолкнуло меня найти другое решение: оказывается, достаточно создать файл C:\Users\User\AppData\Roaming\Mozilla\Firefox\Profiles\...\chrome\userChrome.css с таким содержимым:
* { font-size: 15px !important; }
waqur: (Евро)
С незапамятных времён существует такая вещь, как "POSIX-семантика удаления". Это означает, что в Linux или другой Unix-подобной ОС любая программа или пользователь может удалить файл или даже каталог, одновременно открытый в другой программе. Соответствующая запись будет удалена из родительского каталога, но занятые файлом или каталогом блоки не будут освобождены на диске, покуда последний хэндл (или дескриптор) файла не будет закрыт. Разумеется, открытому файлу могут выделяться и новые блоки. Если в условиях наличия открытых хэндлов на "файлы-невидимки" произойдёт незапланированная перезагрузка, тогда такие "файлы-невидимки" будут удалены при следующем монтировании файловой системы в контексте драйвера.

У Windows NT традиционно сложные отношения с POSIX-семантикой удаления. Подсистема Win32 вроде бы поддерживает её для файлов, но только при условии, что для всех открытых хэндлов данного файла был задан share-флаг FILE_SHARE_DELETE (по умолчанию он сброшен, потому что так было в DOS). Даже в таком случае, старое имя по-прежнему возвращается функциями GetFileInformationByHandleEx() и NtQueryInformationFile(); покуда не закрыт старый, нельзя создать новый файл или каталог с тем же именем; каталог-хозяин "невидимого файла" может оказаться в "интересном положении", когда он вроде бы пуст и закрыт, но удалить или переименовать его нельзя. Учитывая вышеизложенное, можно сказать, что Win32-подсистема Windows NT в целом не поддерживает POSIX-семантику удаления. Другое дело — POSIX-подсистема: там всё удаляется так, как положено по стандарту. Ну, не совсем удаляется, а переносится в скрытый подкаталог в корневом каталоге тома с одновременной установкой FILE_FLAG_DELETE_ON_CLOSE. (Если далее произошла незапланированная перезагрузка, то вам как бы предлагается вмешаться и вручную поудалять всех потеряшек.) Я специально не изучал, как новая подсистема WSL/LXSS натягивает сову на глобус, но подозреваю, что через аналогичную задницу.

Тем временем в Linux, где хэндлы открытых файлов архитектурно привязаны не к именам, а к inode'ам, эта концепция продолжает логически развиваться. Начиная с версии ядра 3.11, "файл-невидимку" можно получить не только удалением существующего файла, а изначально: с помощью флага O_TMPFILE у системного вызова open(2). Позже, когда файл будет наполнен данными, его можно "проявить" в файловой системе через linkat(2), используя "/proc/self/fd/%d" в качестве "старого имени" и AT_FDCWD в качестве файлового дескриптора старого каталога. Ещё до "проявления", все необходимые атрибуты можно задать с помощью fchown(2), fchmod(2) и т.д. Таким образом, можно атомарно создавать заполненные файлы в файловой системе. Этот странный интерфейс не годится для POSIX, но сама концепция интересная. Недавно низкоуровневой интерфейс драйверов файловых систем в Linux был специально доработан для того, чтобы всё это стало реальностью.

Сам стандарт POSIX и его реализации тоже, конечно, содержат несуразности и глупости, даже если ограничиться только той частью, которая касается файловых систем. Так, попытка перезаписать с помощью open(2) с флагом O_CREAT и без флага O_EXCL исполняемый файл, отображённый в один из выполняющихся процессов с помощью mmap(2), порождает странную ошибку ETXTBSY (Text file busy). Во-первых, речь идёт не о текстовом файле, а о секции .text в бинарном исполняемом файле, которая традиционно содержит машинный код. Во-вторых, ошибка тривиально обходится удалением файла (unlink) и созданием нового файла на его месте. Отображение в другом процессе при этом будет ссылаться на старый файл, незавимо от того, полон или неполон новый файл и что в нём содержится. Однако, по каким-то лунным причинам open при перезаписи файла ведёт себя иначе, чем unlink + open на пустом месте.

Ещё одна забавная особенность или отклонение от ожидаемого поведения: Windows всегда реализует POSIX-семантику удаления для альтернативных потоков данных файловой системы NTFS. Например, вы можете создать текстовый файл с расширением .txt, в ADSе которого разместить DLL-ку, загрузить её с помощью LoadLibrary, и затем удалить оригинальный текстовый файл (включительно со всеми ADSками). До вызова FreeLibrary DLLка останется загруженной в виртуальную память, а место на диске — распределённым, по всем правилам POSIX-семантики, включая возможность создания другого текстового файла с тем же именем и с тем же именем ADS-потока без затрагивания "невидимого оригинала". Создать изначально невидимый ADS в Windows, к сожалению, нельзя. Передавать владение существующим ADSом между разными файлами тоже нельзя.
waqur: (Евро)
Материнская плата ASUS P10S-I отличается какой-то беспрецедентной тормознутостью в режиме CSM (16-разрядный BIOS в UEFI-системах).

Операционная система MFSBSD, которой под VMware нужно 30 секунд, чтобы загрузиться, на этой материнской плате загружается примерно полчаса. Полностью установленная FreeBSD из десяти минут, требуемых на загрузку, девять проводит в 16-разрядном режиме.

Такое ощущение, что оказался в 1996 году и загружаешь сервер с дискеты.

UPD: Оказалось, что проблема была в медленном выводе текста на консоль. В FreeBSD 11 загрузчик починили, чтобы он реже обновлял на экране эту крутящуюся палочку (twiddle), и тормоза при загрузке исчезли.
waqur: (Евро)
Некоторые сцайты любят гадить в буфер обмена — добавлять "подробнее " и ссылку на страницу при нажатии Ctrl+C, или очищать буфер обмена по тому же событию, по сути мешая копировать текст с сайта в буфер обмена.

Разумеется, эти и многие другие последствия шаловливости рук чрезмерно инициативных погромистов легко лечатся отключением JavaScript'а кнопкой, которая всегда на виду (браузерный аддон JS Switch), но всё же, это очень неудобно — каждый раз нажимать эту чёртову кнопку и перезагружать страницу.

Особенно это раздражает при копировании небольших текстов — таких как код изделия или цена — с сайтов интернет-магазинов.

Есть лучший способ — раз и навсегда отучить все сайты от загаживания буфера обмена:
about:config -> dom.event.clipboardevents.enable = false

Попутно можно отключить перехват сайтами контекстного меню, которое открывается кликом правой клавиши мыши:
about:config -> dom.event.contextmenu.enable = false

А ещё есть полезный плагин YesScript, позволяющий запрещать/разрешать JavaScript не глобально на весь браузер, а индивидуально для каждого домена. Если какой-то сайт начинает наглеть (срёт в буфер обмена, мельтешит всплывающими окнами, воспроизводит звук, рисует на фоне страницы какой-то снег и тому подобный бред) — нажимаем на значок белого свитка (который сразу чёрнеет), обновляем страницу и дело в шляпе. "Научишься плавать — тогда и воду в бассейн нальём." (c)
waqur: (Евро)
Мило, неотключаемый Windows Update из Windows 10 уже ломает работу загрузчиков других ОС в dual-boot конфигурациях (перенумеровывает разделы):
http://www.opennet.ru/opennews/art.shtml?num=44914

Иногда даже не просто перенумеровывает, а и попутно удаляет. :D
http://windowsreport.com/partition-disappears-windows-10-anniversary-update/
waqur: (Евро)
Официальная спецификация файловой системы FAT от фирмы Microsoft (когда-то бывшая доступной для скачивания с сайта microsoft.com, а сейчас циркулирующая по сети под именем fatgen103.{doc,pdf}) обозначает как "зарезервированные для Windows NT" некоторые поля и флаги дисковых структур файловой системы. Действительно, Windows NT всех версий использует их.

Недокументированные особенности файловой системы FAT, которые реализует Microsoft`овский драйвер этой файловой системы, но упускает официальная спецификация )

September 2017

S M T W T F S
     12
34567 89
10111213141516
17181920212223
24252627282930

Синдикация

RSS Atom

Автор стиля

Развернуть

No cut tags
Page generated 2017-09-21 03:25 am
Powered by Dreamwidth Studios