видны некоторые прямо таки детские ошибки, так сказать, за автора обидно.
Огласите весь список, пожалуйста :) Если вы пишите «ошибки», значит их много? Отсутствие автосохранения — одна из них?
Ну напрашивается же все это объединить и заставить ваш плагин сохранять данные периодически,
Замысел хороший, но сразу после появления плагина стал очевиден способ спасения данных, описанный в первой половине статьи (перенаправление выполнения на код процедуры MudDoSave из плагина), автосохранение не рассматривалось как нужная фича, без которой нельзя жить и на которую не жалко тратить время. Ну разве что против внезапного отключения электричества или BSOD-а, но таких случаев может и не было вообще.
Но идея хорошая, я подумаю над автосохранением, правда я считаю, что идеологически неверно запихивать эту функциональность в плагин Markup Dumper — это должен быть отдельный плагин, какой-нибудь OllyAutosave.
Странная проблема с недоступностью отладчика, который на отвалившемся диске, что аж пришлось свою утилиту-дампер писать… Не проще ли было установить Olly на тот диск, который у вас был живой?
Странный комментарий. Имеется в виду установить OllyDbg на живой диск заведомо, подозревая диск (на котором живёт том H:\) в нездоровости заранее? Или установить OllyDbg на другой диск уже после того, как диск с томом H:\ отвалился? Я надеюсь, что вы имели в виду второй вариант.
Если так, то вы невнимательно читали статью.
Во-первых, как я по вашему реверсил Insertname() после аппаратного сбоя, если не установил OllyDbg на другой диск? Конечно же OllyDbg был сразу же установлен на другой том другого диска из резервного хранилища, чтобы начать работы по разрешению ситуации.
Во-вторых, утилиту-дампер пришлось писать не потому, что OllyDbg стал недоступным для использования из-за отвала, а потому что был риск, что OllyDbg при подключении к полумёртвому процессу (коим был тоже OllyDbg) запнётся и завершится. А когда отладчик завершается, не вызвав перед этим DebugActiveProcessStop(), отлаживаемый процесс уничтожается вместе с процессом-отладчиком. Тогда бы я окончательно потерял спасаемые данные.
Т.е. утилита-дампер писалась ровно из тех соображений, чтобы воздействие на «коматозный» процесс было минимально инвазивным. Четыре аккуратных и точных вызова ReadProcessMemory должно было стать меньшим из возможных зол. Я даже не был уверен, что ReadProcessMemory() вообще сработает в отношении этого процесса и сможет прочесть хоть что-нибудь. Это сейчас примерно понятно, что произошло, а в тот момент не было уверенности, что адресное пространство сохранилось хотя бы частично (в Windows объект-процесс может существовать, а адресное пространство как совокупность структур PDE+PTE с одной стороны, и MMVAD с другой стороны — могут не существовать; на каких-то этапах жизненного цикла объекта-процесса это так). Кто мог в первые минуты гарантировать, что всё произошло именно из-за аппаратного сбоя, а не потому, что какие-то ядерные структуры были повреждены каким-то глючным драйвером?
Если вы внимательно читали, то видели, что сначала я собирался сдампить все закоммиченные страницы умирающего процесса, разобраться со сбоями, перезагрузиться, а потом уже в дампе находить нужное, не боясь, что вот-вот случится BSOD. Но Process Explorer не мог создать дамп, падал с ошибкой.
Причём было не удивительно, что он падал: если страница нечитаема, потому что механизм подкачки не может её подгрузить, то и ReadProcessMemory, которым пользуется любой дампер, её контент прочитать откуда-то волшебным образом не сможет. Был бы дампер, который читал не все подряд страницы. а только нужные — он бы не падал. Но нужно было знать, какие именно страницы читать, для чего и был начат реверсинг. А если знать, что читать нужно два больших блока плюс маленький кусочек с метаданными, зачем мне было искать подходящий дампер, если быстрее было написать его самому?
Продавать, чтобы Чип-и-Дип для своего хранилища использовал систему, или чтобы он её продавал радиолюбителям?
Если первое, то там масштабы такие, что не кассетницы нужны, а фидеры для pick-and-place-машин, отрезающие нужное количество деталей с катушки с лентой. А второе, то с их накрутками кто такую систему сможет себе позволить?
А отладчик — эт чтобы посмотреть как же там все на самом деле.
Но ведь IDA Pro умеет присоединяться к существующему процессу и выступать отладчиком. Зачем тогда нужна Olly?
Дело в привычке. Я тоже пользуюсь Олей лет 15, и все действия в ней делаю уже как пулемёт. А IDA Pro всегда отталкивала нездоровой атмосферой вокруг Ильфака и его отношением к поддержке и пиратству. Окей, у вас платный продукт, а я воспользуюсь бесплатным инструментом, а для того, что он не умеет, сделаю собственные инструменты — вот так я примерно всегда размышлял.
За 13 лет использования Olly, кстати, не могу припомнить прямо-таки падений-зависаний в ней. Но я ничего и не аннотирую, да
Аннотации не влияют на вероятность зависания и вылета. Правда, длинные аннотации, создаваемые плагинами в нарушение спецификации, могут провоцировать вылеты, об этом я написал.
Просто если не аннотировать, вылеты не так критичны и не воспринимаются, как маленькие трагедии.
А зависания, как я уже писал, происходят по вине win32k.sys, в основном. Например, жмёшь в Olly Ctrl+C и она зависает намертво. Смотришь Process Explorer-ом бэктрейс основного потока — там вызов SetClipboardData из OllyDbg, из неё идёт вызов user32!_NtUserSetClipboardData@12, а это лишь переходничок, делающий SYSENTER. Дальше код уже продолжается в режиме ядра. И где-нибудь там оно висит. Аннотации тут явно не причём. Тут виноваты какие-то system-wide объекты синхронизации. Тот же буфер обмена — если один процесс открыл его с помощью OpenClipboard() и завис, другие процессы сессии не могут работать с буфером обмена.
В подобных случаях не не переключался на отладку ядерной части системы — а то это могло зайти далеко. Был у меня случай, когда я реверсил «железный» музыкальный синтезатор фирмы Roland, и использовал цифровой осциллограф, управляемый с компьютера через SCPI (GPIB), чтобы программировать его на отлов нужных событий, автоматизированно захватывать их анализировать. В реализации SCPI осциллографа была найдена дыра, позволяющая получаь доступ к прошивке осциллографа. Реверс-инжиниринг синтезатора плавно перетёк в реверс-инжиниринг осциллографа. В итоге ни то, ни другое не было доведено до конца.
Спасибо. Есть ли смысл публиковать плагин Markup Dumper, обозревать его применение в контексте ведения распределённого командного реверсинга? Есть смысл публиковать статью об упомянутых ARG-файлах?
как мне кажется, было бы интеренеснее оживить
Честно говоря, мне интереснее было бы доделать собственный инструмент для отладки и реверс-инжиниринга, сделать «отладчик своей мечты», устранив все бесящие и нереализованные моменты Ольки, притащив туда вкусные и желанные фишки из IDA, и т.п.
Собственно говоря, это не эфемерная мечта: у меня уже давно (лет 14 как) лежит написанный классный и быстрый дизассемблирующий/ассемблирующий движок, который может удобно расширяться. Есть к дизассемблирующей половинке этого движка GUI-примочка, показывающая отдельную процедуру либо в плоском виде, как это делает OllyDbg (даже интерфейс скопирован один в один), либо в виде графа, как делает IDA. Есть самописный простенький отладчик (tinydbg), правда у него не графический, а совершенно дубовый текстовый интерфейс (не с использованием псевдографики в консольном окне, а именно сугубо текстовый «диалог» с отладчиком) — его единственное преимущество в том, что антиотладочные приёмы, которые основываются на слабых местах популярных отладчиков, на него не действуют, а так же тем, что любую нестандартную команду или функцию я в него могу добавить сразу же, как возникнет такая необходимость, и мне не надо будет искать нужный плагин или придумать, как ограниченным инструментарием скриптинга реализовать какую-нибудь пошаговую деобфускацию отлаживаемого процесса. Есть собственный вьювер DBG/PDB-файлов, собственный вьювер COFF.
Остаётся только объединить кучу собственных разрозненных и сырых утилит в мощный и доделанный конгломерат.
И конечно, я говорю сейчас о собственном интересе. Так сказать, с точки зрения научного интереса было бы интереснее написать собственный инструмент. Список мастхев фич сформирован уже давно.
А вот с точки зрения практической, конечно, более перспективно возраждать или поддерживать инструмент, у которго уже есть имя, репутация, комьюнити и своя экосистема, чем пробивать дорогу чему-то совершенно новому.
Как вариант, можно реализовать в виде плагина, в нем установить свой VEH обработчик и при возникновении исключения делать дамп.
Непонятно, почему автор OllyDbg не обернул все обращения из хоста в плагины в __try ... __except и сам не сделал какого-нибудь аварийного автосохранения в фильтре необработанных исключений. Даже VirtualDub имеет какой-то нестандартный top-level хендер для исключений, показывающий и контекст потока, и дизасм проблемного места, хотя, казалось бы, мультимедийной утилите такой функционал не обязателен, а вот в коде отладчика уже есть многий инструментарий для реализации подобной плюшки, но самой плюшки и вообще хоть какого-то аварийного процессинга исключений внутри самого себя — нет.
Вообще, писать подобный плагин-автодампер для себя я не вижу особого смысла. У меня есть пара утилит, упомянутых в статье: memdumper.exe и extractor.exe. В случае проблемы достаточно вызвать
memdumper 12345
extractor ./ > emerg-dump.txt
У этого подхода есть один неоспоримый плюс: спасительные утилиты находятся вне зоне поражения сошедшего с ума кода. А вот плагин-спасатель может сам оказаться повреждён, ведь он разделяет с умирающим отладчиком одно адресное пространство.
Не знаю как в первой версии, а во второй функция сохранения в udd принимает указатель на t_module
А в первой версии такой API нет вообще. Но даже если бы была, я ведь упомянул, что есть за OllyDbg грешок тихо портить UDD при сохранении.
Это уже другой уровень проблемы. Когда нет никакой документации, но есть голова, руки, приборы и страсть к реверс-инжинирингу и анализу — такая ситуация не только раззадоривает на поиск решения, но и может стать конкурентным преимуществом, потому что других людей руки опускаются или скиллов не хватает.
А вот когда к вам просто не обращаются с такими задачами, потому что у вас нет «опыта», а «опыта» нет, потому что не обращаются, и вы сидите без работы — это совершенно другая, грустная история.
С такими устройствами встаёт проблема «яйца и курицы». Допустим, вы хотите переключиться на ремонт УЗИ-аппаратов. Обращаясь к вам, вас спросят, занимались ли раньше ремонтом этой модели аппаратов. А узнав, что не занимались вообще никакими, скорее всего от обращения к вам откажутся. Вы же, попав в этот порочный круг, так никогда и не получите свой первый заказ.
Это на ширпотребной электронике вроде телефонов, телевизоров, компьютеров можно набраться «стажа» и уверенности в себе, переремонтировав сначала всю мертвую технику себе, своим друзьям и друзьям друзей.
Причём, я прекрасно понимаю, что 90% отказов в том же УЗИ-аппарате будет на уровне «в тактильной кнопке панели управления обломался и закоротил выводы подвижный контакт» или «в блоке питания пробило диод», которые по сложности и уровню знаний, требуемых для починки, вообще ничуть не сложнее типичных отказов телевизоров и мобильных телефонов.
Но вашему заказчику важен ваш опыт в ремонте именно УЗИ-сканеров. Да и вам самим может быть немного страшно впервые браться за устройство стоимостью с новый автомобиль.
Термин «замкнутая электрическая цепь», честно говоря, немного нелеп и подобен маслу масляному, потому что электрическая цепь, по которой течёт установившийся ток, — априори замкнутая (как следствие закона Кирхгофа, а точнее закона сохранения заряда).
Очень приятная статья. Я думал, я одинок в своих взглядах на то, насколько катастрофична и печальна ситуация в отрасли, но статья и одобрительные комментарии прямо подняли настроение.
К сожалению, всё сложнее и сложнее найти заказчика и работодателя, который позволил бы тебе работать правильным образом.
Всегда поражали подобные вопрошения к толпе: «зачем вы там сидите»? Наверное, у людей есть причина сидеть, раз сидят.
Я, к примеру, являюсь админом ряда тематических групп: группы для инженеров-электронщиков, группы по ремонту и обслуживанию автомобилей кое-какой марки/модели, и нескольких групп, посвящённых музыкальным исполнителям. Всё это родилось на свет задолго до того, как сложилась такая опасная политическая обстановка. Очень большой объём сил и энергии был вложен в эти группы, чтобы сделать их интересными и привлекательными. Да и сама «общественная жизнь» в этих группах стала немаловажной частью жизни, без которой будет весьма тоскливо. И вы предлагаете взять и бросить всё это?
Кроме того, если отбросить таких инициативных людей, у которых есть потребность создавать свои «уютные» и интересные местечки, а не довольствоваться чужими, для большинства социальная продолжает выполнять свою первоначальную функцию — позволять людям делиться информацией с неким предопределённым кругом лиц.
Я давно начал ловить себя на мысли, что я, время от времени, вынужден рассказывать сначала одному человеку о каком-нибудь интересном событии, случае или какой-то эпопее (например, о нетривиальной починке какой-нибудь техники, сломавшейся абсолютно не вовремя) — пересказывать историю, разбавляя текстовый рассказ чередой фотографий, а спустя день-два уже другой человек просит поделиться подробностями, и ты опять рассказываешь ту же историю, скидываешь те же фотографии. Невольно задумываешься: было бы хорошо один раз сделать рассказ+фотоотчёт и предоставить возможность его читать всем тем, кому это может быть интересно. К сожалению, я не могу использовать для этого «стену» из-за отсутствия per-post настройки приватности — приходится довольствоваться личными сообщениями с тамошней возможностью скопировать и переслать диалог некоему новому собеседнику вместе со всеми картинками и вложениями.
Огласите весь список, пожалуйста :) Если вы пишите «ошибки», значит их много? Отсутствие автосохранения — одна из них?
Замысел хороший, но сразу после появления плагина стал очевиден способ спасения данных, описанный в первой половине статьи (перенаправление выполнения на код процедуры
MudDoSaveиз плагина), автосохранение не рассматривалось как нужная фича, без которой нельзя жить и на которую не жалко тратить время. Ну разве что против внезапного отключения электричества или BSOD-а, но таких случаев может и не было вообще.Но идея хорошая, я подумаю над автосохранением, правда я считаю, что идеологически неверно запихивать эту функциональность в плагин Markup Dumper — это должен быть отдельный плагин, какой-нибудь OllyAutosave.
Странный комментарий. Имеется в виду установить OllyDbg на живой диск заведомо, подозревая диск (на котором живёт том
H:\) в нездоровости заранее? Или установить OllyDbg на другой диск уже после того, как диск с томомH:\отвалился? Я надеюсь, что вы имели в виду второй вариант.Если так, то вы невнимательно читали статью.
Во-первых, как я по вашему реверсил
Insertname()после аппаратного сбоя, если не установил OllyDbg на другой диск? Конечно же OllyDbg был сразу же установлен на другой том другого диска из резервного хранилища, чтобы начать работы по разрешению ситуации.Во-вторых, утилиту-дампер пришлось писать не потому, что OllyDbg стал недоступным для использования из-за отвала, а потому что был риск, что OllyDbg при подключении к полумёртвому процессу (коим был тоже OllyDbg) запнётся и завершится. А когда отладчик завершается, не вызвав перед этим
DebugActiveProcessStop(), отлаживаемый процесс уничтожается вместе с процессом-отладчиком. Тогда бы я окончательно потерял спасаемые данные.Т.е. утилита-дампер писалась ровно из тех соображений, чтобы воздействие на «коматозный» процесс было минимально инвазивным. Четыре аккуратных и точных вызова
ReadProcessMemoryдолжно было стать меньшим из возможных зол. Я даже не был уверен, чтоReadProcessMemory()вообще сработает в отношении этого процесса и сможет прочесть хоть что-нибудь. Это сейчас примерно понятно, что произошло, а в тот момент не было уверенности, что адресное пространство сохранилось хотя бы частично (в Windows объект-процесс может существовать, а адресное пространство как совокупность структур PDE+PTE с одной стороны, и MMVAD с другой стороны — могут не существовать; на каких-то этапах жизненного цикла объекта-процесса это так). Кто мог в первые минуты гарантировать, что всё произошло именно из-за аппаратного сбоя, а не потому, что какие-то ядерные структуры были повреждены каким-то глючным драйвером?Если вы внимательно читали, то видели, что сначала я собирался сдампить все закоммиченные страницы умирающего процесса, разобраться со сбоями, перезагрузиться, а потом уже в дампе находить нужное, не боясь, что вот-вот случится BSOD. Но Process Explorer не мог создать дамп, падал с ошибкой.
Причём было не удивительно, что он падал: если страница нечитаема, потому что механизм подкачки не может её подгрузить, то и ReadProcessMemory, которым пользуется любой дампер, её контент прочитать откуда-то волшебным образом не сможет. Был бы дампер, который читал не все подряд страницы. а только нужные — он бы не падал. Но нужно было знать, какие именно страницы читать, для чего и был начат реверсинг. А если знать, что читать нужно два больших блока плюс маленький кусочек с метаданными, зачем мне было искать подходящий дампер, если быстрее было написать его самому?
Если первое, то там масштабы такие, что не кассетницы нужны, а фидеры для pick-and-place-машин, отрезающие нужное количество деталей с катушки с лентой. А второе, то с их накрутками кто такую систему сможет себе позволить?
Да уж, стоило изобретать цифровую шину с поддержкой адресации, чтобы потом мучиться с матрицами.
Это не вам или автору камень в огород, это я просто об абсурдности ситуации.
Но ведь IDA Pro умеет присоединяться к существующему процессу и выступать отладчиком. Зачем тогда нужна Olly?
Дело в привычке. Я тоже пользуюсь Олей лет 15, и все действия в ней делаю уже как пулемёт. А IDA Pro всегда отталкивала нездоровой атмосферой вокруг Ильфака и его отношением к поддержке и пиратству. Окей, у вас платный продукт, а я воспользуюсь бесплатным инструментом, а для того, что он не умеет, сделаю собственные инструменты — вот так я примерно всегда размышлял.
Аннотации не влияют на вероятность зависания и вылета. Правда, длинные аннотации, создаваемые плагинами в нарушение спецификации, могут провоцировать вылеты, об этом я написал.
Просто если не аннотировать, вылеты не так критичны и не воспринимаются, как маленькие трагедии.
А зависания, как я уже писал, происходят по вине
win32k.sys, в основном. Например, жмёшь в Olly Ctrl+C и она зависает намертво. Смотришь Process Explorer-ом бэктрейс основного потока — там вызовSetClipboardDataиз OllyDbg, из неё идёт вызовuser32!_NtUserSetClipboardData@12, а это лишь переходничок, делающийSYSENTER. Дальше код уже продолжается в режиме ядра. И где-нибудь там оно висит. Аннотации тут явно не причём. Тут виноваты какие-то system-wide объекты синхронизации. Тот же буфер обмена — если один процесс открыл его с помощьюOpenClipboard()и завис, другие процессы сессии не могут работать с буфером обмена.В подобных случаях не не переключался на отладку ядерной части системы — а то это могло зайти далеко. Был у меня случай, когда я реверсил «железный» музыкальный синтезатор фирмы Roland, и использовал цифровой осциллограф, управляемый с компьютера через SCPI (GPIB), чтобы программировать его на отлов нужных событий, автоматизированно захватывать их анализировать. В реализации SCPI осциллографа была найдена дыра, позволяющая получаь доступ к прошивке осциллографа. Реверс-инжиниринг синтезатора плавно перетёк в реверс-инжиниринг осциллографа. В итоге ни то, ни другое не было доведено до конца.
Спасибо. Есть ли смысл публиковать плагин Markup Dumper, обозревать его применение в контексте ведения распределённого командного реверсинга? Есть смысл публиковать статью об упомянутых ARG-файлах?
Собственно говоря, это не эфемерная мечта: у меня уже давно (лет 14 как) лежит написанный классный и быстрый дизассемблирующий/ассемблирующий движок, который может удобно расширяться. Есть к дизассемблирующей половинке этого движка GUI-примочка, показывающая отдельную процедуру либо в плоском виде, как это делает OllyDbg (даже интерфейс скопирован один в один), либо в виде графа, как делает IDA. Есть самописный простенький отладчик (tinydbg), правда у него не графический, а совершенно дубовый текстовый интерфейс (не с использованием псевдографики в консольном окне, а именно сугубо текстовый «диалог» с отладчиком) — его единственное преимущество в том, что антиотладочные приёмы, которые основываются на слабых местах популярных отладчиков, на него не действуют, а так же тем, что любую нестандартную команду или функцию я в него могу добавить сразу же, как возникнет такая необходимость, и мне не надо будет искать нужный плагин или придумать, как ограниченным инструментарием скриптинга реализовать какую-нибудь пошаговую деобфускацию отлаживаемого процесса. Есть собственный вьювер DBG/PDB-файлов, собственный вьювер COFF.
Остаётся только объединить кучу собственных разрозненных и сырых утилит в мощный и доделанный конгломерат.
И конечно, я говорю сейчас о собственном интересе. Так сказать, с точки зрения научного интереса было бы интереснее написать собственный инструмент. Список мастхев фич сформирован уже давно.
А вот с точки зрения практической, конечно, более перспективно возраждать или поддерживать инструмент, у которго уже есть имя, репутация, комьюнити и своя экосистема, чем пробивать дорогу чему-то совершенно новому.
Непонятно, почему автор OllyDbg не обернул все обращения из хоста в плагины в
__try ... __exceptи сам не сделал какого-нибудь аварийного автосохранения в фильтре необработанных исключений. Даже VirtualDub имеет какой-то нестандартный top-level хендер для исключений, показывающий и контекст потока, и дизасм проблемного места, хотя, казалось бы, мультимедийной утилите такой функционал не обязателен, а вот в коде отладчика уже есть многий инструментарий для реализации подобной плюшки, но самой плюшки и вообще хоть какого-то аварийного процессинга исключений внутри самого себя — нет.Вообще, писать подобный плагин-автодампер для себя я не вижу особого смысла. У меня есть пара утилит, упомянутых в статье:
memdumper.exeиextractor.exe. В случае проблемы достаточно вызватьУ этого подхода есть один неоспоримый плюс: спасительные утилиты находятся вне зоне поражения сошедшего с ума кода. А вот плагин-спасатель может сам оказаться повреждён, ведь он разделяет с умирающим отладчиком одно адресное пространство.
А в первой версии такой API нет вообще. Но даже если бы была, я ведь упомянул, что есть за OllyDbg грешок тихо портить UDD при сохранении.
Если под рукой УЗИ-аппарат за десятки тысяч долларов?
А вот когда к вам просто не обращаются с такими задачами, потому что у вас нет «опыта», а «опыта» нет, потому что не обращаются, и вы сидите без работы — это совершенно другая, грустная история.
Это на ширпотребной электронике вроде телефонов, телевизоров, компьютеров можно набраться «стажа» и уверенности в себе, переремонтировав сначала всю мертвую технику себе, своим друзьям и друзьям друзей.
Причём, я прекрасно понимаю, что 90% отказов в том же УЗИ-аппарате будет на уровне «в тактильной кнопке панели управления обломался и закоротил выводы подвижный контакт» или «в блоке питания пробило диод», которые по сложности и уровню знаний, требуемых для починки, вообще ничуть не сложнее типичных отказов телевизоров и мобильных телефонов.
Но вашему заказчику важен ваш опыт в ремонте именно УЗИ-сканеров. Да и вам самим может быть немного страшно впервые браться за устройство стоимостью с новый автомобиль.
К сожалению, всё сложнее и сложнее найти заказчика и работодателя, который позволил бы тебе работать правильным образом.
Я, к примеру, являюсь админом ряда тематических групп: группы для инженеров-электронщиков, группы по ремонту и обслуживанию автомобилей кое-какой марки/модели, и нескольких групп, посвящённых музыкальным исполнителям. Всё это родилось на свет задолго до того, как сложилась такая опасная политическая обстановка. Очень большой объём сил и энергии был вложен в эти группы, чтобы сделать их интересными и привлекательными. Да и сама «общественная жизнь» в этих группах стала немаловажной частью жизни, без которой будет весьма тоскливо. И вы предлагаете взять и бросить всё это?
Кроме того, если отбросить таких инициативных людей, у которых есть потребность создавать свои «уютные» и интересные местечки, а не довольствоваться чужими, для большинства социальная продолжает выполнять свою первоначальную функцию — позволять людям делиться информацией с неким предопределённым кругом лиц.
Я давно начал ловить себя на мысли, что я, время от времени, вынужден рассказывать сначала одному человеку о каком-нибудь интересном событии, случае или какой-то эпопее (например, о нетривиальной починке какой-нибудь техники, сломавшейся абсолютно не вовремя) — пересказывать историю, разбавляя текстовый рассказ чередой фотографий, а спустя день-два уже другой человек просит поделиться подробностями, и ты опять рассказываешь ту же историю, скидываешь те же фотографии. Невольно задумываешься: было бы хорошо один раз сделать рассказ+фотоотчёт и предоставить возможность его читать всем тем, кому это может быть интересно. К сожалению, я не могу использовать для этого «стену» из-за отсутствия per-post настройки приватности — приходится довольствоваться личными сообщениями с тамошней возможностью скопировать и переслать диалог некоему новому собеседнику вместе со всеми картинками и вложениями.