Тотальная неудачница и убийца жёстких дисков.
#post-id: 5342-00-00
#original-date: 12.03.2015 Thu
#original-time: 12:00 AM
#original-day: 5342
#original-host: WinXP Home SP3 (Build 2600)
Есть такой текстовый редактор Dana, японский, но относительно старый, давно не обновлялся. Для хранения "закладок" в тексте, он создаёт специальный двоичный файл с номерами строк и сохраняет его рядом с самим текстовым файлом. Например, для файла Diary.TXT Дана создаёт файл Diary.TXT.#marks# и обновляет его по мере необходимости.
Посты в дайрик я пишу в Дане - у меня даже есть скрипт для облегчения вставки BB кодов и прочего (сам скрипт можно найти на моём сайте.). Поэтому я не использую для постов другие редакторы - лень портировать функционал туда. Так вот, у меня есть специальная папка в дропбоксе, в который эти файлы лежат - туда я пишу на работе, на одной домашней машине, на другой, и всё синхронизируется.
Некоторое время назад у меня нарисовалась проблема. Периодически, когда я писала новый пост и сохраняла текстовый файл с ним, сам текстовый файл успешно заливался на сервер, а вот сопутствующий файл мог висеть в статусе "Uploading" долго, по нескольку часов. Бывало, я сразу не замечала, и он так по полдня грузился. Потом происходило чудо, либо файл изменялся (становился больше, например), либо я его вообще удаляла, и синхронизация продолжалась в штатном режиме.
Файл не представляет из себя ничего особенного, весит не больше килобайта, содержит в основном нули, антивирусом не детектируется. Так что причина такого поведения мне была непонятна.
Сегодня случилось это вновь. Файл весом 50 байт завис на два часа, в то время как все остальные прекрасно гуляли туда-сюда. Тоесть я кидаю двадцать метров фотографий, попутно с другой машины прилетает DOC файл на полтора метра, и всё отлично, а в это время 50 кило отчаянно пытаются улететь на сервер.
Я решила посмотреть, что происходит. Открыла файл в двоичном редакторе (который, к слову, тоже в дропбоксе лежит), посмотрела - ничего необычного. Сохранила, чтобы обновилось время изменения - ничего не поменялось.
Потом меня посетила догадка. Вдруг это как-то связано с LAN Sync? Пошла на соседнюю машину, посмотрела логи файрволла, ничего интересного не нашла, вырубила его. Не помогло.
Тут я вдруг заметила, что висят уже два файла. К двоичному файлу присоединился текстовый конфиг двоичного редактора. Я была удивлена, ибо проблемы всегда были только с #marks# файлами.
Надо отметить, что я встречала проблему только на одной машине. Помнится, ранее я в подобных условиях отредактировала текстовый файл на другой машине, заставив измениться #marks# файл, и тот залился без проблем, а тот, что висел на первой машине, превратился в конфликтную копию. Дропбокс его переименовал, но загрузить по прежнему не смог.
Тогда я взяла и по сети перекинула #marks# файл на соседнюю машину в ту же папку. Клиент на соседней машине взялся за дело, и тоже не смог. В итоге я получила две машины с одним и тем же файлом, не пролезающим на сервер.
Я пыталась перезапускать клиент, но это не помогло. Каждый раз после индексации он начинал выгружать #marks# файл и не справлялся.
Тогда я призвала на помощь товарища, скинув ему сторонними методами #marks# файл. Тот поставил свежую версию дропбокса, подключился, закинул файл в папку, и тот сию же минуту ушёл.
В задумчивости я посмотрела на клиент дропбокса и внезапно обнаружила, что #marks# файл у меня тоже ушёл на сервер. Теперь висел только конфиг. Я немного офигела и скинула товарищу ещё и конфиг. Тот закинул его в папку, и клиент на моей машине отрапортовал, что все файлы синхронизированы.
Иными словами, где-то там, в левом аккаунте, зарегистрированном на левую почту появился файл, такой же как у меня, и мой файл немедленно оказался синхронизирован. Это не какой-то стандартный файл, его содержимое вполне уникально, но система сообразила, что есть сходства и упростила себе работу.
Напомню, что где-то там, в туре по дропбоксу на официальном сайте говорится (или говорилось), что все файлы шифруются на сервере, ключ есть только у пользователя, и никакой админ не может туда заглянуть. Понятно, что это всё враньё, но всёже.
На самом деле то, что я описала, было известно мне и ранее. Пару лет назад какиры обнаружили, что есть какой-то API вызов или ещё какой люк, а у каждого файла есть хэш, который однозначно определяет файл в системе. Где бы он ни лежал, его можно вытащить, зная хэш. Даже файлообменную сеть сделали. Юзер заливает кино к себе в дропбокс, получает хэш, выкладывает его в интернетах. Другие юзеры берут хэш, вбивают куда следует, и кино тут же материализуется у них в папках. Потом фича сломалась, лавочку прикрыли. Как оказалось, закрыли люк, но система с хэшами как была, так и осталась.
Собственно, за последнюю пару недель это второй случай, когда я лично наблюдаю весьма сомнительное поведение данного продукта. Ранее по непонятным причинам клиент шарил по всяким папкам на диске, и я лично видела это. Теперь я своими глазами увидела, что личная папка не столь уж личная.
Наверняка есть какое-то объяснение. Глючащее расширение оболочки (файлы, к которым обращался клиент, так или иначе появлялись в проводнике при этом), оптимизация с целью снизить нагрузку на сервер и каналы. Но... Учитывая героическое молчание официальных представителей, это всё как-то напрягает.
К слову, у товарища, помогшего мне в исследовании, клиент дропбокса заглядывал в папку OneDrive. А ещё, сразу же после установки, он перехватил ввод с клавиатуры, но где-то глюкнул и заблокировал любой ввод кроме мыши. Зачем дропбоксу клавиатура?
Короче, пора мазать лыжи.
#original-date: 12.03.2015 Thu
#original-time: 12:00 AM
#original-day: 5342
#original-host: WinXP Home SP3 (Build 2600)
Есть такой текстовый редактор Dana, японский, но относительно старый, давно не обновлялся. Для хранения "закладок" в тексте, он создаёт специальный двоичный файл с номерами строк и сохраняет его рядом с самим текстовым файлом. Например, для файла Diary.TXT Дана создаёт файл Diary.TXT.#marks# и обновляет его по мере необходимости.
Посты в дайрик я пишу в Дане - у меня даже есть скрипт для облегчения вставки BB кодов и прочего (сам скрипт можно найти на моём сайте.). Поэтому я не использую для постов другие редакторы - лень портировать функционал туда. Так вот, у меня есть специальная папка в дропбоксе, в который эти файлы лежат - туда я пишу на работе, на одной домашней машине, на другой, и всё синхронизируется.
Некоторое время назад у меня нарисовалась проблема. Периодически, когда я писала новый пост и сохраняла текстовый файл с ним, сам текстовый файл успешно заливался на сервер, а вот сопутствующий файл мог висеть в статусе "Uploading" долго, по нескольку часов. Бывало, я сразу не замечала, и он так по полдня грузился. Потом происходило чудо, либо файл изменялся (становился больше, например), либо я его вообще удаляла, и синхронизация продолжалась в штатном режиме.
Файл не представляет из себя ничего особенного, весит не больше килобайта, содержит в основном нули, антивирусом не детектируется. Так что причина такого поведения мне была непонятна.
Сегодня случилось это вновь. Файл весом 50 байт завис на два часа, в то время как все остальные прекрасно гуляли туда-сюда. Тоесть я кидаю двадцать метров фотографий, попутно с другой машины прилетает DOC файл на полтора метра, и всё отлично, а в это время 50 кило отчаянно пытаются улететь на сервер.
Я решила посмотреть, что происходит. Открыла файл в двоичном редакторе (который, к слову, тоже в дропбоксе лежит), посмотрела - ничего необычного. Сохранила, чтобы обновилось время изменения - ничего не поменялось.
Потом меня посетила догадка. Вдруг это как-то связано с LAN Sync? Пошла на соседнюю машину, посмотрела логи файрволла, ничего интересного не нашла, вырубила его. Не помогло.
Тут я вдруг заметила, что висят уже два файла. К двоичному файлу присоединился текстовый конфиг двоичного редактора. Я была удивлена, ибо проблемы всегда были только с #marks# файлами.
Надо отметить, что я встречала проблему только на одной машине. Помнится, ранее я в подобных условиях отредактировала текстовый файл на другой машине, заставив измениться #marks# файл, и тот залился без проблем, а тот, что висел на первой машине, превратился в конфликтную копию. Дропбокс его переименовал, но загрузить по прежнему не смог.
Тогда я взяла и по сети перекинула #marks# файл на соседнюю машину в ту же папку. Клиент на соседней машине взялся за дело, и тоже не смог. В итоге я получила две машины с одним и тем же файлом, не пролезающим на сервер.
Я пыталась перезапускать клиент, но это не помогло. Каждый раз после индексации он начинал выгружать #marks# файл и не справлялся.
Тогда я призвала на помощь товарища, скинув ему сторонними методами #marks# файл. Тот поставил свежую версию дропбокса, подключился, закинул файл в папку, и тот сию же минуту ушёл.
В задумчивости я посмотрела на клиент дропбокса и внезапно обнаружила, что #marks# файл у меня тоже ушёл на сервер. Теперь висел только конфиг. Я немного офигела и скинула товарищу ещё и конфиг. Тот закинул его в папку, и клиент на моей машине отрапортовал, что все файлы синхронизированы.
Иными словами, где-то там, в левом аккаунте, зарегистрированном на левую почту появился файл, такой же как у меня, и мой файл немедленно оказался синхронизирован. Это не какой-то стандартный файл, его содержимое вполне уникально, но система сообразила, что есть сходства и упростила себе работу.
Напомню, что где-то там, в туре по дропбоксу на официальном сайте говорится (или говорилось), что все файлы шифруются на сервере, ключ есть только у пользователя, и никакой админ не может туда заглянуть. Понятно, что это всё враньё, но всёже.
На самом деле то, что я описала, было известно мне и ранее. Пару лет назад какиры обнаружили, что есть какой-то API вызов или ещё какой люк, а у каждого файла есть хэш, который однозначно определяет файл в системе. Где бы он ни лежал, его можно вытащить, зная хэш. Даже файлообменную сеть сделали. Юзер заливает кино к себе в дропбокс, получает хэш, выкладывает его в интернетах. Другие юзеры берут хэш, вбивают куда следует, и кино тут же материализуется у них в папках. Потом фича сломалась, лавочку прикрыли. Как оказалось, закрыли люк, но система с хэшами как была, так и осталась.
Собственно, за последнюю пару недель это второй случай, когда я лично наблюдаю весьма сомнительное поведение данного продукта. Ранее по непонятным причинам клиент шарил по всяким папкам на диске, и я лично видела это. Теперь я своими глазами увидела, что личная папка не столь уж личная.
Наверняка есть какое-то объяснение. Глючащее расширение оболочки (файлы, к которым обращался клиент, так или иначе появлялись в проводнике при этом), оптимизация с целью снизить нагрузку на сервер и каналы. Но... Учитывая героическое молчание официальных представителей, это всё как-то напрягает.
К слову, у товарища, помогшего мне в исследовании, клиент дропбокса заглядывал в папку OneDrive. А ещё, сразу же после установки, он перехватил ввод с клавиатуры, но где-то глюкнул и заблокировал любой ввод кроме мыши. Зачем дропбоксу клавиатура?
Короче, пора мазать лыжи.
-
-
11.03.2015 в 18:54А я тебе даже больше скажу - я не пользовался проводником
Зачем дропбоксу клавиатура?
Ну хотя бы для того, чтобы ввести логин/пасс при начальной настройке. Но проблема в том, что даже в самом дропе клавиатура не стала работать. Такого я не видел еще никогда.
-
-
11.03.2015 в 23:18Кстати о логах! А может быть у тебя как раз и будет что-то в них? Погляди в c:\Users\%USERNAME%\AppData\Roaming\Dropbox\logs\
Может быть там и найдется ответ на эту задачку.
-
-
12.03.2015 в 08:19Ноу. Для показа иконок файлов он идёт к Shell API, а там уже всевозможные IconHandler и прочие COM радости подтягиваются. Если, конечно, у тебя не отключён показ иконок.
Ну хотя бы для того, чтобы ввести логин/пасс при начальной настройке. Но проблема в том, что даже в самом дропе клавиатура не стала работать. Такого я не видел еще никогда.
Чтобы получить логин и пароль, достаточно создать два текстбокса и кнопку. Для этого не нужно перехватывать управление клавиатурой так, что она отваливается на уровне системы. Симптом как у заглючившего кейлоггера, который вклинился в цепочку обработки сообщений клавиатуры.
Но вообще, главная интрига так и осталась нераскрытой, к сожалению. Почему файл весом в 50 байт не мог попасть на сервер в течение 2+ часов. А логов, как обычно, нет...
У меня нет вариантов. Бывает, что зашифрованные соединения странно подвешиваются, например, синхронизация Симанки в то же время начала глючит, и периодически это делает. Возможно, у Ростелекома руки кривы, и DPI вклинивается не так, как нужно. Но почему в общем потоке данных оно ухватилось именно за эти куски, которые всё равно солью разбавляются... Я БП. У меня просто нет вариантов кроме тупого сервера.
Может быть там и найдется ответ на эту задачку.
Глянула. Там текстовые файлы нулевой длины. А на работе ещё какие-то двоичные файлы, начинающиеся с сигнатуры "DropboxNNNNN". Данные не читабельны, у файлов даже расширения нет. А логгирования как у BTSync не наблюдается (то, которое по запросу).
-
-
12.03.2015 в 08:21-
-
12.03.2015 в 12:21Ты невнимательно читала мою мессагу:
диск Е, папка Install, подпапка Network. Жмякаем правую почку мыши (с) и смотрим на вывод в procmon'e...
Папка не была открыта, соответственно, ни о каких ярлыках речи быть не может. Я всего лишь вывел контекстное меню в тотале к папке E:\Install\Network.
Но. Есть у меня одна догадка. Дело в том, что набор тех папок, по которым прошвырнулся дроп, почти полностью соотвествует папкам, открытым в закрепленных вкладках тотала. Вся засада в слове "почти". Надо будет еще пару тестов сделать.
ещё какие-то двоичные файлы, начинающиеся с сигнатуры "DropboxNNNNN". Данные не читабельны
Аналогичная фигня и у меня. Плюс пара Crashlog'ов, но они пусты.
Без исходников или нормального реверс инженеринга сказать что-то определённое трудно.
Есть еще один вариант - Wireshark. Но я не шибко силен в чтении вывода пакетного анализатора
-
-
12.03.2015 в 15:08А теперь отгадай, каким образом TC (и не только он) материализует это самое контекстное меню.
/* Подсказка. На форумах FAR было эпичное расследование "Почему после вызова контекстного меню файла FAR при выходе вылетает или не закрывает консоль?" Одним из виновников оказалось расширение html2chm, которое неправильно освобождало объекты, создававшиеся библиотекой оболочки при формировании контекстного меню. */
Есть еще один вариант - Wireshark. Но я не шибко силен в чтении вывода пакетного анализатора
Там HTTPS. Плюс наверняка данные шифруются или упаковываются, что так просто не посмотреть, что и как там бегает.
-
-
12.03.2015 в 15:33Что же до https - при известном желании и он благополучно вскрыаается. Но для этого уже иные средства нужны, а не только wireshark
-
-
12.03.2015 в 16:27Вскрывается. Только нужно заставить клиент поверить, что это действительно правильный сертификат, а не филькина грамота ^^
-
-
12.03.2015 в 23:02ISA/TMG при правильной настройке с этим справляются. Другое дело, что сама настройка такой функции - не одиозная "пара кликов"
библиотека оболочки продолжает присутствовать
В рамках какого процесса? От System, что ли? Или всякие там svchost'ы (хотя это бред, службы от оболочек не зависят).
-
-
13.03.2015 в 03:27ISA видела издалека только ^^'
В рамках какого процесса? От System, что ли? Или всякие там svchost'ы (хотя это бред, службы от оболочек не зависят).
В Висте появился какой-то Desktop Manager или как-то так. До неё (и в неё тоже) были просто Shell API, живущие в Shell32.DLL. Тоесть так или иначе программы обращались либо к этой библиотеке, либо к COM объектам, имеющим отношение к оболочке (там какие-то другие библиотеки). Тоесть там не процесс, не сервис, а API.
-
-
13.03.2015 в 11:23Счастливый человек
Тоесть там не процесс, не сервис, а API.
Будем считать, что в первом приближении понял
-
-
13.03.2015 в 12:31Честно говоря, я сама не до конца вникала, что там происходит, но примерно это выглядит так.