Слыхали? Криворукая обезьяна ака админ Архивача (не путать с Абу), у которого сайт лежал стабильно через день, умудрился проебать 90% всего контента, накопленного за 10 лет. Теперь там просто голые посты без изображений и видео. Это фиаско.
https://arhivach.top/
Олды тем временем вспоминают БАП 2008 на лурке, где статьи вообще с кэшей поисковиков восстанавливали.
> проебать 90% всего контента, накопленного за 10 лет. Теперь там просто голые посты без изображений и видео
А ты думал, что места на серверах резиновые и бесплатные? Возможно, эту аварию и создали искусственно, дабы облегчить ношу говняка.
>Место на сервере стало заканчиваться, а денег расширятья жалко
>чо делать....
>rm -rf /var/www/img/*
>ДОРОГИЕ ПОЛЬЗОВАТЕЛИ ТУТ ТАКАЯ АВАРИЯ СЛУЧИЛАСЬ, ВЫ НЕ ПОВЕРИТЕ!!!!
>чо делать....
Можно было файлы в ipfs выкинуть. Анончик сам бы всё похранил.
Тогда мог бы загодя предупредить.
>rm -rf /var/www/img/*
Что это значит?
/var/www — стандартное местоположение файлов веб-сервера, которое прописано в стандарте FHS.
Выпилить КЕМ все картинки на веб-сервере. На самом деле расположение картинок может быть каким угодно, команда указана для примера.
Зачем и главное нахуя нужно сохранять треды в таком количестве? Особенно из /b/
>Зачем и главное нахуя нужно сохранять треды в таком количестве? Особенно из /b/
Тебя, вроде, никто не заставляет ни участвовать в этом, ни смотреть на это. Так что твоё какое дело?
Блять пиздец, я в шоке. Мне всегда казалось что Архивач это настоящая непреступная твердыня, 10 лет бесперебойной работы либо с малыми перебоями а тут смерть кучи тредов с говном, вахтерами от которых у меня теплая ностальгия. Обидно конечно. Самое удивительное и обидное для меня то что никто до сих пор не выпустил достойный архиватор тредов, поддерживающий нормальный просмотр цепочек постов и сохранению фулсайз пиков+видео, знаю что что-то подобное есть в Дашчане либо другом мобильном клиенте но я айфонодебил и запускать отдельный эмулятор чтобы сохранить тред мне лень да и все нынешние эмуляторы это китайское говно с кучей зондов и рекламы в комплекте, если я какую-то сохранялку упустил напомните мне.
В жизни будут утраты с этим надо смириться. Из праха созданы прахом и станем
> Мне всегда казалось что Архивач это настоящая непреступная твердыня
Ты в интернете недавно? Все такие сервисы держатся на запасе упрямства авторов. Вот:
https://wiki.archiveteam.org/index.php/4chan
Сейм. Только я думал, что однажды админ объявит о закрытии и даст неделю на скачивание, а тут вон как вышло. Но этого стоило ожидать - он часто лежал последнее время.
> Тож было жалко много платины из нулевых хранилось
Если там не хранились пасты Карманова, то грош цена этому сайту.
>владелец умер убит чурками попал в дтп под поезд.
Чурки заперли его в машине, которую направили под колеса поезда?
>Через год копипаста имела на премодерации миллион паст сначала модеры его разгребали но потом и во все бросили а сайт был удален за неуплату теперь по этой ссылке открывается порно сайт . Тож было жалко много платины из нулевых хранилось
Наверно именно там хранилась та самая паста про болотные механизмы...
Так там от изображжений превью одни были.
>Так там от изображжений превью одни были.
Нет, полные версии. Ты с архивом двача путаешь
Во-первых, ты хоть раз ему донатил? Нет? Ну так значит это ты пидор.
Во-вторых, на картинки и видево как раз похуй, они там и так в шакальном качестве только сохранялись, главное - текст.
Ну а так конечно нужно архивировать в ипфс\торренты либо нечто еще распределенное.
>они там и так в шакальном качестве только сохранялись, главное - текст.
Они сохранялись в полном виде
> никто до сих пор не выпустил достойный архиватор тредов
уже лет 10 существует кукла( или больше). Цепочки ответов работают, картинки открываются. Цепочки вроде не сразу были, но тоже уже достаточно давно есть
Бля, ну и пидорас. Мало того, что сайт говно кривое лагучее, так ещё и инфу проебал. Как так можно блять? Ретард, сука.
Ну, хотя бы ничего не померло, и то плюс. Я уж думал, что у него там подвал с насом затопило, или крыша в гараже провалилась.
Придумай, как данные с дисков извлечь и напиши ему.
Никак не извлечь, написано же.
>>3406406
Он пишет, что затёрто несколько начальных секторов, это очень размытая формулировка. Какие именно сектора, сколько секторов, начиная с какого сектора шли служебные данные шифрования с ключами? Чем затёрто? Если однородными данными (нулями или единицами), то был призрачный шанс восстановить оригинальное намагничивание. Если там кусочек ключа отрезало, то может сбрутить можно. Информации мало.
> Если однородными данными (нулями или единицами), то был призрачный шанс восстановить оригинальное намагничивание.
> 2023,997… год.
> Число уникальных магнитных доменов, хранящих состояние одного бита записи, стремится к минимальному числу знаков.
> Производители упёрлись в предел точности при обращении с ними, стали использовать черепичную запись, чтобы хоть как-то повысить плотность, жертвуя простотой работы и некоторыми характеристиками.
> восстановить оригинальное намагничивание
Если ты директор физического или химического института или международной корпорации, у которого есть и уникальная техника, и толпа подчинённых, ты, конечно, можешь повелеть им метнуться и разобраться с диском со смешными картинками, защитив в следующие годик-другой-пятый в процессе работы парочку диссертаций по методам регистрации, анализа и интерпретации ничтожных неравномерностей полей.
> графический интерфейс к однострочнику с md5sum и grep
> человек всё равно руками должен ставить зависимости и КОМАНДОВАТЬ СТРОКОЙ
> У нас есть огромный список строк-образцов и заведомо меньший список строк для сравнения, давайте пихнём БОЛЬШОЙ в память целиком и пробежимся по нему N раз!
Дональд Кнут уже выбирает гроб, чтобы лечь в него и вертеться. Про всякие деревья и фильтры Блума я и не говорю, потому что тут они даже не понадобятся (если нет срочной задачи сделать компактнее базу хэшей).
А, не, подождите, там всего 500 МБ хэшей, не гигабайты. В чём проблема в памяти держать?..
О-хо-хо, там не просто в память копируется, там ещё из всех элементов делается питоновское множество (а зачем, если и так все хэши уникальны?), и каждый файлик по нему проверяется. Мда.
А, не, подождите, там говорится про 26 миллионов хэшей, а база почти на 32 миллиона. Уникальные выбрать не получилось, что ли?
Спроси сам, может даже помочь сумеешь
arhivach@airmail.cc
>> У нас есть огромный список строк-образцов и заведомо меньший список строк для сравнения, давайте пихнём БОЛЬШОЙ в память целиком и пробежимся по нему N раз!
Это не то, как работает хеш сет, гражданин большой знаток кнута.
> md5
Интересно, сколько фейковых файлов закинут, используя атаку коллизией
Грустно. Еще и фотохостинг radikal.ru сдох
Двачую. Только хотел посмотреть пару фап-тредов с проном, а тут такое.
> Ты с архивом двача путаешь
Раньше на архиве двача можно было смотреть полные картинки, если тред не старше 6 месяцев. Сейчас и это убрали.
Мало какие фотохостинги дожили до наших дней.
Он умер относительно недавно
А на архиваче всегда можно было полные смотреть.
На m2ch сохранили превьюшки изображений большинства тредов. Жаль, что нельзя оттуда их как-нибудь вытянуть
А я это писал до того, как программу посмотрел, удивившись, что 500 МБ внезапно разбухли в десять раз. А сейчас, попрактиковавшись, ничего странного не вижу — это просто Python, если в нём не думать над каждым действием. Даже беззаботное создание списка индексов через list(range(num_hashes)) прибавляет к используемым 500 МБ ещё примерно столько же, потому что это всё ссылки на объекты со своими объектами внутри, а не голые байтики. Что уж говорить о всяких сложно устроенных внутри структурах. Или вот встроенный sort() генерирует для каждого элемента объект-ключ для операций сравнения. Когда элементы — сложные объекты, иметь более мелкий выгодно, но вот когда это циферки, которые могут занимать меньше памяти, чем указатели на них, а уж тем более объекты, их оборачивающие, временные данные начинают занимать в два-три раза больше места. Что файлу делать mmap, когда скопированные оттуда и преобразованные данные занимают во много раз больше? Вообще, обычный read() в бинарном режиме под капотом тоже использует системный кэш и выполняется почти мгновенно после первого запуска (на моей системе), так что ничего особенного тут городить и не надо было.
Центральный вопрос: зачем использовать всякие hashtable, если у нас есть таблица хэшей, вот прямо буквально? Зачем каждый хэш хэшировать ещё раз, хранить и то, и другое, ссылки туда-сюда лепить?
Для начала отсортируем хэши, чтобы можно было пользоваться бинарным поиском прямо по готовому массиву. Удобно это было бы сделать прямо при экспорте из базы данных, но можно развлечься и написать скриптик (так, как будто это C):
https://paste.debian.net/1302875/
Памяти требует 600 с чем-то мегабайт, плюс-минус интерпретатор. Индексы используются вместо перемещения самих данных потому, что я не накопал, как неизменяемые bytes из файла без копирования переделать в bytearray (иначе на какое-то мгновение процессу требуется 500+500 МБ памяти, что на практике, конечно, фигня, но мне интересно минимумом накладных расходов обойтись). Из-за всей иерархии косвенной адресации при интерпретации, думаю, разницы не будет ни в скорости, ни в объёмах работы с памятью. Да, я посмотрел, что нормальные люди используют нормальные массивы в numpy, и что всё это можно красиво обернуть в классы с операциями доступа и сравнения, это понятно. Запись маленькими кусочками тоже не слишком удобна для дисков и файловых систем, но это уже мелочи.
Занимает такая наивная сортировка 484 МБ 16-байтовых хэшей почти полтора часа. Мда. Если сравнить время работы на разных объёмах, то зависимость мало чем отличается от линейной:
https://www.wolframalpha.com/input?i=quadratic+fit+%7B%7B1%2C+6.8%7D%2C+%7B8%2C+67%7D%2C+%7B32%2C+290%7D%2C+%7B64%2C+618%7D%2C+%7B100%2C+1058%7D%2C+%7B484%2C+5663%7D%7D
Значит, не в алгоритме дело. Скрипт запускался с -m cProfile, и допустим, 15% производительности это съело, что тоже не слишком важно.
Можно ли сделать лучше на коленке? Допустим, мы перевели хэши в текстовый формат:
xxd -ps -c 16 hashes.bin hashes.txt
Затем достали замшелую досовскую (на самом деле не досовскую) утилиту SORT:
sort /L "C" hashes.txt /O sorted.txt
Она справилась с сортировкой гигабайтного файла за три с половиной минуты — правда, не имея ограничений по дополнительным памяти и месту на диске. Ну да, технологии семидесятых и восьмидесятых годов, ещё на медленных плёночных архивах отлаженные.
Логично предположить, что и дальше можно готовыми инструментами обойтись. Типичным find … | xargs … md5sum получить список файлов-кандидатов с их хэшами, потом грепнуть одно по другому (вроде даже какие-то оптимизированные grep для отсортированных данных можно накопать), а совпадения скопировать в целевой каталог. Базу можно сжать и на лету распаковывать при чтении, она вернётся к своему исходному размеру (и даже немного меньше станет после сортировки, расположившей совпадающие начальные байты рядом). Скрипт получится не в одну строку, а в несколько, и для обычных людей, у которых не миллионы картинок, сгодится, думаю, без хитрых доработок. Проблема, конечно, в некроссплатформенности, и в том, что для нормальной работы с юникодными путями в Windows придётся делать что-то либо под Powershell, либо под оболочку под Windows Terminal и новую консоль, либо под WSL.
Возвращаемся к пистону и возвращаем данные в бинарный формат (да, мы всё ещё развлекаемся, экономя память):
xxd -r -c 16 -ps sorted.txt sorted.bin
Проверяем хэш файла с хэшами (yo dawg). Он совпадает с полученным в первом варианте, ура (CD716333B72909B4D2D9D78B62E30CB5). Вот сама отсортированная база, она ещё понадобится:
https://www.mediafire.com/file/epum672yxto5d2z/sorted.bin/file
Никто не мешает теперь написать другой скрипт, перебирающий файлы так, как описано выше, но не требующий непонятных гигабайтов памяти. Потом к нему можно приделывать и GUI, и всё на свете. Вжух, и он готов:
https://paste.debian.net/1302902/
Кладёте sorted.bin и скрипт рядом, он начинает искать (по умолчанию в текущем каталоге и ниже, но можно другой задать). Если указать место для копирования, копирует найденное туда, иначе просто выводит пути. Можно включить подсчёт. В памяти занимает не больше объёма базы хэшей, плюс хэшируемый в данный момент файл, ограниченный 100 МБ, плюс мелочь на остальную программу, пиковое потребление процесса в процесе тестирования — 605 МБ.
Только у меня есть сомнения, что расширения файлам нужны, хэш-то от них не зависит, а переименовываться по ошибке или специально они могли как угодно. Надеюсь, на сервере это обрабатывается. И ещё надеюсь, что люди будут смотреть, что собралось, перед заливкой на хостинги, потому что некоторые старенькие файлы с большой вероятностью находятся в используемых крупными фирмами проверочных базах. Кажется, многим понадобится чёрный список каталогов. Ещё можно перебор поменять, чтобы заглатывать файлы пачками (например, по целой папке), но не раздувая до списка всех существующих (у некоторых, думаю, они просто слишком большими выйдут), возможно, дискам от этого будет легче. Ну и хэшировать тогда можно в несколько потоков.
прошу к столу!
Э-э, блин, повторы считает. Сколько раз empty.gif найдёт, столько и запишет. И ещё можно было бы смену времени у всех файлов на произвольное прикрутить, но в нормальных архиваторах давно есть как раз такая функция, чтобы архив не содержал ненужных подробностей работы.
>Центральный вопрос: зачем использовать всякие hashtable, если у нас есть таблица хэшей, вот прямо буквально? Зачем каждый хэш хэшировать ещё раз, хранить и то, и другое, ссылки туда-сюда лепить?
Ты всё ещё не знаешь, как работает хеш сет.
Дам тебе подсказку:
>бинарным поиском
O(log n)
>hashtable
o(1)
У нас на всех дисках используется LUKS1. Про его техническое устройство можешь почитать здесь https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf (на русском вряд ли есть столь же подробное описание)
Суть проблемы в том, что сами данные в криптоконтейнере шифруются не с помощью вводимого пароля к криптоконтейнеру, как некоторым может показаться, а рандомными мастер-ключами, которые генерируются при создании контейнера и хранятся в специальном заголовке. Помимо этого в LUKS добавлено ещё разное, чтобы усложнить жизнь тем, кто будет пытаться взломать шифрование "в лоб".
Из-за когда давно неверно выставленного типа разделов (в те времена в gdisk ещё не был доступен тип раздела Linux LUKS, по глупости поставил Linux LVM и не вспоминал про это), какой-то софт перезаписал несколько начальных килобайт разделов, затерев часть LUKS заголовка. Сколько точно байт перезаписалось пока не могу сказать, нужно ещё провести эксперимент в аналогичных условиях и сравнить образы диска "до" и "после". По чисто визуальной оценке (глядя на байты в hex) было затёрто около 8 килобайт. К несчастью, данные о ключах в LUKS1 заголовках начинаются где-то с позиции 4 килобайт, т.е. начальные ключевые слоты вместе с данными о мастер-ключах наверняка уничтожены.
Что касается способов для взлома AES 128bit XTS "в лоб", то в случае LUKS мне такие средства неизвестны, да и в любом случае это потребует гигантских вычислительных мощностей.
Особенно обидно за shaily тред
там малолетняя пизда хвост себе в жопу анальный пихала и все пруфы к сожалению были благополучно проебаны
Это всё гундос
Вы подыметесь ? Очень надо . Или это только у меня лежит ?
Достаточно тупой вопрос, но все же. Сколько может уйти времени, если в тупую перебрать 8 килобайт HEX данных, начиная с 00 по FF?
Сделали бы временный архивач (~неделя), хочешь навсегда - плати за отдельный тред, вот тебе и помощь в энтузиастам.
Существуют ли сырцы программной части? Я кнш могу помочь на гигов эдак 360 всего ~3%, но в дальнейшем хотелось бы иметь локальное решение проекта.
>~3%
Исхожу из того, что было 4 диска по 4 тб, 3 из них похерено. 12 тб в итоге. Какой объем на самом деле у хардов, остается только гадать. Если речь идет о десятках террабайт, то процентное соотношение того, чем могу помочь, стремится к нуль целых хуй десятых.
Эхх, а в планах было столько всего скачать, но все носители в доме забиты под завязку. Жду хорошего исхода с восстановлением данных другими анонами и поиск LUKS заголовков
Пиздец, вот это я математик. Пересчитал по 26 лямов файлов. Итого вышло ~0.08%