RockYou2024 анализ

У grep конечно есть еще -a опция…

И что же она выдаёт?

Да и вообще, посмотреть самостоятельно что там внутри (просмотрщиком текстовых файлов а не утилитами) ты не догадался?

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

если открыть просмоторщиком типа less то там будет бинарный мусор.

и, скажем, не любой редактор в принципе откроет файл на 145 ГБ.

например vim, просто зависает

grep с опцией -a ищет нормально пароли…

yr@E525:/mnt/expdrive$ grep -a fakepass rockyou2024.txt
!@#fakepass
!@fakepass
!fakepass
... 

посмотреть самостоятельно что там внутри (просмотрщиком текстовых файлов а не утилитами)

Сомнительно, что просмотрщик файлов переживет попытку открытия файла столь большого размера.

Могу сгенерировать ещё больший локально без всяких качаний.

ну тут как раз человеческие пароли более интересны, т.к. большинство людей пароли осмысленные использует и применяют по нескольку раз.

Для подбора в том же John the reeper этот файл полезный должен быть. проведу исследования по этому поводу.

Подсказка: сначала делаешь dd if=bigfile.txt of=smallfile.txt bs=1048576 count=1, потом открываешь в чём угодно этот отрезанный первый мегабайт. Это если задача стоит узнать что же там внутри в наглядном виде.

Насчёт того что там dbase я крайне сомневаюсь, скорее всего это ложное срабатывание какой-то сигнатуры из базы утилиты file.

А с чего ты взял что там человеческие пароли? Кто-то где-то уже писал что там вполне много явно сгенерированных паролей. И конечно никто тебе не скажет, кто их генерировал - жертвы у которых украли базу, или же сам хакер, для придания размера своему «творению».

файл определяется как БД dbase

В этом файле вообще очень много шлака. А в начале вообще идут строки из нулевых байт (\x00) на восемь мегабайт, поэтому file и ошибается. Дальше первых восьми мегабайт там ещё шлак, потом ещё немного шлака, а потом уже начинается шлак.

Лучше бери вариант 2021 года, там шлака поменьше. Такое ощущение, что 2024 сделали люди, которым просто захотелось создать инфоповод. Они взяли 2021 и налили туда строк, которые достали откуда только получилось. Возможно, там просто текст с веб-страниц или скриптов.

bs=1048576 count=1

Лол, там нулевые байты, немного разбавленные \x0a.

А с чего ты взял что там человеческие пароли? Кто-то где-то уже писал что там вполне много явно сгенерированных паролей.

ну конечно понятно, что часть паролей там будет генерированных, т.к. они могут быть с онлайн ресурсов, куда пароли могут генерироваться менеджерами паролей встроенных в браузеры или внешними программами типа того-же keepass. Я сейчас для онлайна везде генерирую пароли. Так что это норм что часть паролей там будет таких и их практически очень трудно извлечь из этой базы.

но вот поиск по fakepass сразу выдал несколько записей - сначала один или несколько спец символов - потом фраза. Я так сам пароли строю для работы например… сейчас еще так [несколько спец символов]фраза[спецсимвол]фраза|цифра

т.е. видно что пароль человеческий и спецсимволы там, которые рядом на клавиатуре.

Короче, если кому интересно, решил для дальнейшего анализа извлечь из rockyou2024.txt все пароли с помощью strings и поместить в sqlite БД для дальнейших манипуляций и анализа паролей. Потом планирую создать несколько VIEW с разными выборками для удобства экспорта в словари JtR.

на первом этапе столкнулся с интересной проблемой. sqlite3 поддерживает импорт данных с стандартного ввода. Чтобы не плодить промежуточных данных решил лить в sqlite через трубу (pipe), примерно так, предварительно создав табличку с 1 столбцом:

$ sqlite3 db_pass.sqlite3 "CREATE TABLE dt(pass TEXT);"
$ sqlite3 db_pass.sqlite3 --ascii ".import '|strings rockyou2024.txt' dt"  

на небольших файлах это работает, но, как оказалось, sqlite формирует транзакцию со всем вводом а потом разом записывает, вместо поточной записи. На 145 ГБ это не работает, sqlite закрывается с ошибкой «Error: out of memory». Причем не системный oom killer а сам, еще до заполнения свопа.

по этому пришлось набросать фильтр (на pascal естесственно) который оборачивает строки в INSERT-ы и добавляет транзакции с коммитами каждые n строк. На тестовой машине по 10 000 000 строк в транзакции работает нормально.

код фильтра такой:

program filter;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}
  Classes,
  SysUtils;

const
  START_TA = 'BEGIN TRANSACTION;';
  END_TA = 'COMMIT TRANSACTION;';
  INSERT_F_STR = 'INSERT INTO dt VALUES(%s);';
  PROCESS_AT_A_TIME = 10000000; // 10 000 000

var
  line: string;
  cnt:  QWord = 0;
begin
  //сначала открываем транзакцию
  WriteLn(START_TA);
  //читаем до конца входного потока
  while not EOF do
  begin
    readln(line);
    inc(cnt);
    writeln(Format(INSERT_F_STR, [AnsiQuotedStr(line, '''')]));
    if (cnt mod PROCESS_AT_A_TIME) = 0 then begin
      WriteLn(END_TA);
      WriteLn(START_TA);
      writeln(StdErr, format('%12d records stored.', [cnt]));
    end;
  end;
  //последнюю открытую транзакцию нужно закрыть
  WriteLn(END_TA);
  writeln(StdErr, format('Done! Overall %12d records stored.', [cnt]));
end.

имя таблицы захардкодено, хотя можно и через параметр считывать… ну и ладно.

запускаем так примерно:

$ fpc filter.pas
$ sqlite3 db_pass.sqlite3 "CREATE TABLE dt(pass TEXT);"
$ strings rockyou2024.txt | ./filter | sqlite3 db_pass.sqlite3

таким образом строки/пароли ложатся в БД, но проблема в том, что формат хранения нифга не компактный у sqlite. на менее 2 миллиардах записей оно уже заняло 40 Гб… т.е. результирующий файл будет под 300 ГБ, похуже чем просто txt :(

Может использование varchar(n) улучшило бы ситуацию? но не знаю какая максимальная длина пароля в этом файле…

короче, держу всех в курсе.

Просмотр по f3 в тотальном командире легко. А в линукс есть подобные просмотрщики?

less, more

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

символы из non-printable диапазонов вполне могут быть частью пароля, сам такие на icq ставил в эпоху трехзнаков. а вы их «почистить» хотите.

Кстати, как быстрее всего отсортировать такой файл по уникальности, если он не влазит в память? sort -u будет долго работать.

split на куски, sort-uniq по отдельности, потом морж результатов и повторить?

ну sort весь датасет в память загрузит,и если памяти меньше, то ничего не выйдет.

Я вот и залил все в Sqlite DB для этого. Файл БД занял у меня 230 Гб, что несколько увеличивает количество необходимого I/O с диском, но зато теперь можно крутить данными как угодно.

хотя тоже не все так прямо радужно. любые операции с большими массивами данных не влезающие в память требуют места на диске. По умолчанию куда-то в $(TMP) пишет, где у меня не так чтобы много свободного места и операции заканчиваются Error: disk is full.

по этому запускаю sqlite так:

$ SQLITE_TMPDIR=/путь_к_большому_диску sqlite3 db_pass.sqlite3

сейчас запустил посчитать уникальные пароли, подожду что он скажет…

SELECT count(DISTINCT pass) FROM dt; 

селект отработал и показал что в базе 9408671894 уникальных пароля, но никакого чуда при использовании БД не происходит, на данных не помещающихся в память промежуточные выборки пишутся на диск и селекты отрабатываются часами.

у меня сейчас выделен раздел в 477 ГБ, из которых 230 ГБ занимает сама БД. на select-е с distinct на всю БД - оно отъело почти все место на разделе, а попытка создать индекс по полю с паролями вообще провалилась т.к. не хватило свободного места на разделе…

Для комфортного анализа имеет смысл работать с БД частями, так чтобы и данные в БД попадали целиком в кэш диска и еще примерно столько же места оставалось в памяти под промежуточные структуры данных.

При таких раскладах, на ПК с 16ГБ оперативной памяти, размер «окна» примерно получается в 300 000 000 записей.

таким образом с помощью 33 VIEW можно охватить всю БД. если создавать VIEW следующим образом:

CREATE VIEW dt300m1 AS SELECT * FROM dt LIMIT 300000000;
CREATE VIEW dt300m2 AS SELECT * FROM dt LIMIT 300000000 OFFSET 300000000;
CREATE VIEW dt300m3 AS SELECT * FROM dt LIMIT 300000000 OFFSET 600000000;
...

тогда если брать первое «окно» то там distinct отрабатывает примерно за минуту и показывает что там 295134576 уникальных записей, т.е. почти 5 миллионов дублей.

пока что понятно следующее - в длинных паролях (более 100 символов) почти все мусор, какие-то куски документов (html и другое) и просто текста.

очень много строк с началом $2a$10 - т.е. огромное количество хешей вместо самих паролей, с другой стороны - начинать свои пароли с сигнатур известных хэшей - хороший лайфхак, т.к. из словарей такие пароли скорее всего вычистят вместе с другими хэшами ;)

ЕМНИП, more и most умеют подгружать файл по частям