М.Двач / Программы

Двач.hk не отвечает.
Вы видите копию треда, сохраненную 4 мая 2024 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.

13 Кб, 1295x62
Архивач.топ больше не топ Windows 10: Chromium based 24 дек, 19:50 3404417 В конец треда | Веб

Ахахахахаха
Слыхали? Криворукая обезьяна ака админ Архивача (не путать с Абу), у которого сайт лежал стабильно через день, умудрился проебать 90% всего контента, накопленного за 10 лет. Теперь там просто голые посты без изображений и видео. Это фиаско.

https://arhivach.top/

Ответы044250457604757048980542105436056040702507447209182261725690

Android: Mobile Safari 2 24 дек, 20:11 2 3404425

>>3404417 (OP)
Олды тем временем вспоминают БАП 2008 на лурке, где статьи вообще с кэшей поисковиков восстанавливали.

Linux: Firefox based 3 25 дек, 04:11 3 3404573

Ну проебали и проебали, любую информацию нужно держать распределенно. Особенно цифровая информация проебывается очень легко и навсегда. Даже пресловутые торренты не панацея, хотя при определенной координации довольно надожгая вещь. Вон на русрекере некоторым раздачам под 12 лет. Ты ведь об этом хотел поговорить?

Windows 10: Chromium based 4 25 дек, 04:58 4 3404576

>>3404417 (OP)
> проебать 90% всего контента, накопленного за 10 лет. Теперь там просто голые посты без изображений и видео
А ты думал, что места на серверах резиновые и бесплатные? Возможно, эту аварию и создали искусственно, дабы облегчить ношу говняка.

Ответы04819

Linux: Firefox based 5 25 дек, 14:31 5 3404757

>>3404417 (OP)
>Место на сервере стало заканчиваться, а денег расширятья жалко
>чо делать....
>rm -rf /var/www/img/*
>ДОРОГИЕ ПОЛЬЗОВАТЕЛИ ТУТ ТАКАЯ АВАРИЯ СЛУЧИЛАСЬ, ВЫ НЕ ПОВЕРИТЕ!!!!

Ответы0477904820

Linux: Firefox based 6 25 дек, 15:51 6 3404779

>>3404757
>чо делать....
Можно было файлы в ipfs выкинуть. Анончик сам бы всё похранил.

Windows 10: Chromium based 7 25 дек, 18:35 7 3404819

>>3404576
Тогда мог бы загодя предупредить.

Windows 10: Chromium based 8 25 дек, 18:37 8 3404820

>>3404757
>rm -rf /var/www/img/*
Что это значит?

Ответы0482204826

Android: Mobile Safari 9 25 дек, 18:49 9 3404822

>>3404820
/var/www — стандартное местоположение файлов веб-сервера, которое прописано в стандарте FHS.

Windows 10: Chromium based 10 25 дек, 19:00 10 3404826

>>3404820
Выпилить КЕМ все картинки на веб-сервере. На самом деле расположение картинок может быть каким угодно, команда указана для примера.
Зачем и главное нахуя нужно сохранять треды в таком количестве? Особенно из /b/

Ответы04896

Android: Mobile Safari 11 25 дек, 21:46 11 3404869

С одной стороны исчезновение тредов нытья потных двачеров большая потеря, с другой забвение информации это благо

Windows 10: Firefox based 12 25 дек, 23:02 12 3404896

>>3404826
>Зачем и главное нахуя нужно сохранять треды в таком количестве? Особенно из /b/
Тебя, вроде, никто не заставляет ни участвовать в этом, ни смотреть на это. Так что твоё какое дело?

Windows 10: Chromium based 13 25 дек, 23:07 13 3404898

>>3404417 (OP)
Блять пиздец, я в шоке. Мне всегда казалось что Архивач это настоящая непреступная твердыня, 10 лет бесперебойной работы либо с малыми перебоями а тут смерть кучи тредов с говном, вахтерами от которых у меня теплая ностальгия. Обидно конечно. Самое удивительное и обидное для меня то что никто до сих пор не выпустил достойный архиватор тредов, поддерживающий нормальный просмотр цепочек постов и сохранению фулсайз пиков+видео, знаю что что-то подобное есть в Дашчане либо другом мобильном клиенте но я айфонодебил и запускать отдельный эмулятор чтобы сохранить тред мне лень да и все нынешние эмуляторы это китайское говно с кучей зондов и рекламы в комплекте, если я какую-то сохранялку упустил напомните мне.

Ответы0490104912049160554507026

Android: Mobile Safari 14 25 дек, 23:11 14 3404901

>>3404898
В жизни будут утраты с этим надо смириться. Из праха созданы прахом и станем

Windows XP: Firefox based 15 25 дек, 23:41 15 3404912

>>3404898
> Мне всегда казалось что Архивач это настоящая непреступная твердыня
Ты в интернете недавно? Все такие сервисы держатся на запасе упрямства авторов. Вот:
https://wiki.archiveteam.org/index.php/4chan

Windows 10: Chromium based 16 25 дек, 23:52 16 3404916

>>3404898
Сейм. Только я думал, что однажды админ объявит о закрытии и даст неделю на скачивание, а тут вон как вышло. Но этого стоило ожидать - он часто лежал последнее время.

Android: Mobile Safari 17 26 дек, 00:01 17 3404918

Когда-то была копипаста ру которая хранила копипасты даже паблик был. Потом паблик забросили а в след и сайт говорят владелец умер убит чурками попал в дтп под поезд. Через год копипаста имела на премодерации миллион паст сначала модеры его разгребали но потом и во все бросили а сайт был удален за неуплату теперь по этой ссылке открывается порно сайт . Тож было жалко много платины из нулевых хранилось

Ответы0491904946

Windows 10: Chromium based 18 26 дек, 00:03 18 3404919

>>3404918
> Тож было жалко много платины из нулевых хранилось
Если там не хранились пасты Карманова, то грош цена этому сайту.

Windows 10: Chromium based 19 26 дек, 02:48 19 3404946

>>3404918
>владелец умер убит чурками попал в дтп под поезд.
Чурки заперли его в машине, которую направили под колеса поезда?
>Через год копипаста имела на премодерации миллион паст сначала модеры его разгребали но потом и во все бросили а сайт был удален за неуплату теперь по этой ссылке открывается порно сайт . Тож было жалко много платины из нулевых хранилось
Наверно именно там хранилась та самая паста про болотные механизмы...

Windows 10: Chromium based 20 26 дек, 21:24 20 3405208

А ему писал кто-нибудь с предложением помощи?

Linux: Яндекс браузер 21 27 дек, 18:02 21 3405421

>>3404417 (OP)
Так там от изображжений превью одни были.

Ответы05435

Windows 10: Chromium based 22 27 дек, 19:03 22 3405435

>>3405421
>Так там от изображжений превью одни были.
Нет, полные версии. Ты с архивом двача путаешь

Ответы07027

Linux: Firefox based 23 27 дек, 19:08 23 3405436

>>3404417 (OP)
Во-первых, ты хоть раз ему донатил? Нет? Ну так значит это ты пидор.
Во-вторых, на картинки и видево как раз похуй, они там и так в шакальном качестве только сохранялись, главное - текст.

Ну а так конечно нужно архивировать в ипфс\торренты либо нечто еще распределенное.

Ответы05464

Windows 10: Chromium based 24 27 дек, 21:27 24 3405464

>>3405436
>они там и так в шакальном качестве только сохранялись, главное - текст.
Они сохранялись в полном виде

225 Кб, 996x626
Windows 10: Chromium based 25 28 дек, 08:06 25 3405545

>>3404898
> никто до сих пор не выпустил достойный архиватор тредов
уже лет 10 существует кукла( или больше). Цепочки ответов работают, картинки открываются. Цепочки вроде не сразу были, но тоже уже достаточно давно есть

Android: Mobile Safari 26 28 дек, 10:54 26 3405604

>>3404417 (OP)
Бля, ну и пидорас. Мало того, что сайт говно кривое лагучее, так ещё и инфу проебал. Как так можно блять? Ретард, сука.

Windows 10: Chromium based 27 30 дек, 18:38 27 3406381

139 Кб, 1036x886141 Кб, 1032x832

Собственно вот.

Ответы06400065600665107016

Windows 10: Firefox based 28 30 дек, 19:40 28 3406400

>>3406381
Ну, хотя бы ничего не померло, и то плюс. Я уж думал, что у него там подвал с насом затопило, или крыша в гараже провалилась.

Ответы06406

Windows 10: Chromium based 29 30 дек, 20:23 29 3406406

>>3406400
Придумай, как данные с дисков извлечь и напиши ему.

Ответы0652806560

Windows 10: Firefox based 30 31 дек, 00:52 30 3406528

>>3406406
Никак не извлечь, написано же.

Android: Mobile Safari 31 31 дек, 06:26 31 3406560

>>3406381
>>3406406
Он пишет, что затёрто несколько начальных секторов, это очень размытая формулировка. Какие именно сектора, сколько секторов, начиная с какого сектора шли служебные данные шифрования с ключами? Чем затёрто? Если однородными данными (нулями или единицами), то был призрачный шанс восстановить оригинальное намагничивание. Если там кусочек ключа отрезало, то может сбрутить можно. Информации мало.

Ответы0663906835

Windows XP: Firefox based 32 31 дек, 14:22 32 3406639

>>3406560
> Если однородными данными (нулями или единицами), то был призрачный шанс восстановить оригинальное намагничивание.

> 2023,997… год.
> Число уникальных магнитных доменов, хранящих состояние одного бита записи, стремится к минимальному числу знаков.
> Производители упёрлись в предел точности при обращении с ними, стали использовать черепичную запись, чтобы хоть как-то повысить плотность, жертвуя простотой работы и некоторыми характеристиками.
> восстановить оригинальное намагничивание

Если ты директор физического или химического института или международной корпорации, у которого есть и уникальная техника, и толпа подчинённых, ты, конечно, можешь повелеть им метнуться и разобраться с диском со смешными картинками, защитив в следующие годик-другой-пятый в процессе работы парочку диссертаций по методам регистрации, анализа и интерпретации ничтожных неравномерностей полей.

Windows 10: Chromium based 33 31 дек, 14:29 33 3406646

Напоминает когда гугл удалили великий сервис Вопросы и Ответы, там правда всё спланированно, но нахуя.

Windows XP: Firefox based 34 31 дек, 14:44 34 3406651

>>3406381
> графический интерфейс к однострочнику с md5sum и grep
> человек всё равно руками должен ставить зависимости и КОМАНДОВАТЬ СТРОКОЙ

> У нас есть огромный список строк-образцов и заведомо меньший список строк для сравнения, давайте пихнём БОЛЬШОЙ в память целиком и пробежимся по нему N раз!
Дональд Кнут уже выбирает гроб, чтобы лечь в него и вертеться. Про всякие деревья и фильтры Блума я и не говорю, потому что тут они даже не понадобятся (если нет срочной задачи сделать компактнее базу хэшей).

Ответы0666106837

Windows XP: Firefox based 35 31 дек, 15:00 35 3406661

>>3406651
А, не, подождите, там всего 500 МБ хэшей, не гигабайты. В чём проблема в памяти держать?..

О-хо-хо, там не просто в память копируется, там ещё из всех элементов делается питоновское множество (а зачем, если и так все хэши уникальны?), и каждый файлик по нему проверяется. Мда.

Ответы06675

Windows XP: Firefox based 36 31 дек, 15:32 36 3406675

>>3406661
А, не, подождите, там говорится про 26 миллионов хэшей, а база почти на 32 миллиона. Уникальные выбрать не получилось, что ли?

Windows 10: Chromium based 37 31 дек, 20:04 37 3406835

>>3406560
Спроси сам, может даже помочь сумеешь
arhivUV'achANUSairmM5AailPUNCTUMcy,Bc

Windows 10: Firefox based 38 31 дек, 20:06 38 3406837

>>3406651
>> У нас есть огромный список строк-образцов и заведомо меньший список строк для сравнения, давайте пихнём БОЛЬШОЙ в память целиком и пробежимся по нему N раз!
Это не то, как работает хеш сет, гражданин большой знаток кнута.

Ответы07720

Android: Mobile Safari 39 1 янв, 03:18 39 3407016

>>3406381
> md5
Интересно, сколько фейковых файлов закинут, используя атаку коллизией

Windows 7: SeaMonkey 40 1 янв, 05:07 40 3407025

>>3404417 (OP)
Грустно. Еще и фотохостинг radikal.ru сдох

Ответы07068

Windows 7: SeaMonkey 41 1 янв, 05:09 41 3407026

>>3404898
Двачую. Только хотел посмотреть пару фап-тредов с проном, а тут такое.

Windows 7: SeaMonkey 42 1 янв, 05:11 42 3407027

>>3405435
> Ты с архивом двача путаешь
Раньше на архиве двача можно было смотреть полные картинки, если тред не старше 6 месяцев. Сейчас и это убрали.

Ответы07418

Android: Mobile Safari 43 1 янв, 11:44 43 3407068

>>3407025
Мало какие фотохостинги дожили до наших дней.

Ответы07110

Android: Mobile Safari 44 1 янв, 15:06 44 3407110

>>3407068
Он умер относительно недавно

Windows 10: Chromium based 45 2 янв, 19:42 45 3407418

>>3407027
А на архиваче всегда можно было полные смотреть.

Windows 7: Chromium based 46 2 янв, 20:46 46 3407447

>>3404417 (OP)
На m2ch сохранили превьюшки изображений большинства тредов. Жаль, что нельзя оттуда их как-нибудь вытянуть

Ответы07453

676 Кб, 2560x1440
Windows 10: Chromium based 47 2 янв, 20:54 47 3407453

>>3407447
Браток, всё можно.

Windows XP: Firefox based 48 3 янв, 15:37 48 3407720

>>3406837
А я это писал до того, как программу посмотрел, удивившись, что 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 МБ.

Только у меня есть сомнения, что расширения файлам нужны, хэш-то от них не зависит, а переименовываться по ошибке или специально они могли как угодно. Надеюсь, на сервере это обрабатывается. И ещё надеюсь, что люди будут смотреть, что собралось, перед заливкой на хостинги, потому что некоторые старенькие файлы с большой вероятностью находятся в используемых крупными фирмами проверочных базах. Кажется, многим понадобится чёрный список каталогов. Ещё можно перебор поменять, чтобы заглатывать файлы пачками (например, по целой папке), но не раздувая до списка всех существующих (у некоторых, думаю, они просто слишком большими выйдут), возможно, дискам от этого будет легче. Ну и хэшировать тогда можно в несколько потоков.

прошу к столу!

Windows XP: Firefox based 48 3 янв, 15:37 48 3407720

>>3406837
А я это писал до того, как программу посмотрел, удивившись, что 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 МБ.

Только у меня есть сомнения, что расширения файлам нужны, хэш-то от них не зависит, а переименовываться по ошибке или специально они могли как угодно. Надеюсь, на сервере это обрабатывается. И ещё надеюсь, что люди будут смотреть, что собралось, перед заливкой на хостинги, потому что некоторые старенькие файлы с большой вероятностью находятся в используемых крупными фирмами проверочных базах. Кажется, многим понадобится чёрный список каталогов. Ещё можно перебор поменять, чтобы заглатывать файлы пачками (например, по целой папке), но не раздувая до списка всех существующих (у некоторых, думаю, они просто слишком большими выйдут), возможно, дискам от этого будет легче. Ну и хэшировать тогда можно в несколько потоков.

прошу к столу!

Показать весь текст
Ответы0775807839

Windows XP: Firefox based 49 3 янв, 17:30 49 3407758

>>3407720
Э-э, блин, повторы считает. Сколько раз empty.gif найдёт, столько и запишет. И ещё можно было бы смену времени у всех файлов на произвольное прикрутить, но в нормальных архиваторах давно есть как раз такая функция, чтобы архив не содержал ненужных подробностей работы.

Windows 10: Firefox based 50 3 янв, 19:50 50 3407839

>>3407720
>Центральный вопрос: зачем использовать всякие hashtable, если у нас есть таблица хэшей, вот прямо буквально? Зачем каждый хэш хэшировать ещё раз, хранить и то, и другое, ссылки туда-сюда лепить?
Ты всё ещё не знаешь, как работает хеш сет.
Дам тебе подсказку:
>бинарным поиском
O(log n)
>hashtable
o(1)

Windows 10: Chromium based 51 5 янв, 21:58 51 3408599

бумп

Windows 10: Chromium based 52 11 янв, 22:18 52 3410674

Наша проблема очень похожа на описанное здесь https://unix.stackexchange.com/questions/706070/restore-a-luks-partition-that-was-overwritten-by-pvcreate, но там у человека контейнер типа LUKS2, и при определённых умениях, как видно из комментария, можно восстановиться за счёт использования второго заголовка. В случае же LUKS1 шансы совсем невелики.

У нас на всех дисках используется 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 мне такие средства неизвестны, да и в любом случае это потребует гигантских вычислительных мощностей.

Ответы2559725678

Windows 10: Chromium based 53 5 фев, 04:52 53 3420918

>>3404417 (OP)
Особенно обидно за shaily тред
там малолетняя пизда хвост себе в жопу анальный пихала и все пруфы к сожалению были благополучно проебаны

Linux: Firefox based 54 5 фев, 11:21 54 3420981

А зачем вообще было ставить luks? Типа чтобы гэбня не увидела ЦП которое итак в публичном доступе было? Или что?

Windows 10: New Opera 55 8 фев, 19:10 55 3422617

>>3404417 (OP)
Это всё гундос

Ответы24804

Windows 10: Chromium based 56 14 фев, 02:41 56 3424804

>>3422617
щто

260 Кб, 496x494
Linux: Chromium based 57 15 фев, 19:32 57 3425597

>>3410674
Вы подыметесь ? Очень надо . Или это только у меня лежит ?

68 Кб, 622x434
Windows 10: Firefox based 58 15 фев, 23:09 58 3425678

>>3410674
Достаточно тупой вопрос, но все же. Сколько может уйти времени, если в тупую перебрать 8 килобайт HEX данных, начиная с 00 по FF?

Ответы25798

Android: Mobile Safari 59 15 фев, 23:15 59 3425686

А нужен ли он вообще в таком виде?
Сделали бы временный архивач (~неделя), хочешь навсегда - плати за отдельный тред, вот тебе и помощь в энтузиастам.

Windows 10: Firefox based 60 15 фев, 23:21 60 3425690

>>3404417 (OP)
Существуют ли сырцы программной части? Я кнш могу помочь на гигов эдак 360 всего ~3%, но в дальнейшем хотелось бы иметь локальное решение проекта.

Ответы25694

Windows 10: Firefox based 61 15 фев, 23:28 61 3425694

>>3425690
>~3%
Исхожу из того, что было 4 диска по 4 тб, 3 из них похерено. 12 тб в итоге. Какой объем на самом деле у хардов, остается только гадать. Если речь идет о десятках террабайт, то процентное соотношение того, чем могу помочь, стремится к нуль целых хуй десятых.
Эхх, а в планах было столько всего скачать, но все носители в доме забиты под завязку. Жду хорошего исхода с восстановлением данных другими анонами и поиск LUKS заголовков

Ответы25713

Windows 10: Firefox based 62 16 фев, 00:34 62 3425713

>>3425694
Пиздец, вот это я математик. Пересчитал по 26 лямов файлов. Итого вышло ~0.08%

Windows 10: Firefox based 63 16 фев, 12:19 63 3425798

>>3425678
Ладно, я прикинул писю к носу и понял, что перебор 8кб займет больше времени, чем существует вселенная

Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 4 мая 2024 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.

« /s/В начало тредаВеб-версияНастройки/a//b//mu//s//vg/Все доски

Пользуетесь скринридером — пишите, что можно улучшить.
Host-Food.ru — надёжный хостинг от 12 руб/мес | Free DNS
Зеркала М.Двача: m2ch.hk, m2ch.lib, m2chfapiswfw2wcakptqp4o6ltgchvjuxfab7urxlduraomtlnhw5xad.onion