• XSS.stack #1 – первый литературный журнал от юзеров форума

Чем можно очистить словарь от мусора (ссылки, почты, хэши...)?

Отслеживать

M1les

RAM
Пользователь
Регистрация
08.02.2023
Сообщения
100
Реакции
141
Депозит
1 Ł
Собирал словарь и заметил, что часть строк представляют из себя ссылки, почты и даже несбрученные хэши. Проверять такие кандидаты нет смысла.

Созрел вопрос: какими способами можно очистить словарь из паролей от такого рода ненужных строк? Как при этом случайно не удалить нормальные пароли?
 
TOPCHEK сказал(а):
По регулярным выражениям
Можешь привести пример команды bash, которая проверяет строки на какое-то простое условие?
 
Notepad + регулярки, регулярки можешь написать через чатгпт, если размер словаря слишком большой, то юзай EmEditor. Ну или как аналогичный вариант: самопис софты)
 
leaner сказал(а):
Notepad + регулярки
Notepad++ не кушает большие файлы, лучше использовать bash утилиты, как приведено в примере выше.
leaner сказал(а):
если размер словаря слишком большой, то юзай EmEditor
Если я не ошибаюсь, EmEditor не поддерживает регулярки
 
не думаю что регулярка поможет. простой пример gayf@the.rs - это почта или нормальный пароль? а строка из тридцати двух символов a-f0-9 может быть паролем? да, может. поэтому предлагаю разбить словарь по длине: первая часть до 12 символов (быстрый брут, минимум мусора), вторая часть 13-20 символов (средний по скорости, возможен мусор) и третья часть - от 21 до 40 символов (медленный, редкие пароли, много мусора). а все остальное с длиной > 40 символов выбросить. когда нужно сбрутить максимально быстро - используются первые две части, а когда некуда спешить - третья часть.

Код: 
cat dict.txt | grep '^.\{1,12\}$' > part1.txt
cat dict.txt | grep '^.\{13,20\}$' > part2.txt
cat dict.txt | grep '^.\{21,40\}$' > part3.txt

это если что я представлял себе оффлайн брут. если надо брутить онлайн, само собой лучше изменить длину паролей, например на 6-8/9-12/13-16 (остальное выкинуть).
 
Последнее редактирование:
qazwsx123 сказал(а):
разбить словарь по длине: первая часть до 12 символов (быстрый брут, минимум мусора), вторая часть 13-20 символов (средний по скорости, возможен мусор) и третья часть - от 21 до 40 символов (медленный, редкие пароли, много мусора).
правильно ли я понял, что короткие пароли найдутся сильно быстрее чем длинные (в словаре)?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
antikrya сказал(а):
правильно ли я понял, что короткие пароли найдутся сильно быстрее чем длинные (в словаре)?
Короткие пароли до 6 знаков лучше по маске искать. Это будет на много быстрее
 
174region174 сказал(а):
Короткие пароли до 6 знаков лучше по маске искать. Это будет на много быстрее
это понятно, не понятно то что я спросил выше. имеются 2 текстовых файла, в одном пароли до 12 символов, в другом 21-40. в каком из них пароли найдутся быстрее (условимся на том что хеши будут ntlm и подходящие пароли будут в обоих файлах)? как я понял из топа, пароли длинной до 12 символов найдутся сильно быстрее, нет?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
antikrya сказал(а):
это понятно, не понятно то что я спросил выше. имеются 2 текстовых файла, в одном пароли до 12 символов, в другом 21-40. в каком из них пароли найдутся быстрее (условимся на том что хеши будут ntlm и подходящие пароли будут в обоих файлах)? как я понял из топа, пароли длинной до 12 символов найдутся сильно быстрее, нет?
читаешь между строк. писали что много мусора - медленная скорость
 
antikrya сказал(а):
это понятно, не понятно то что я спросил выше. имеются 2 текстовых файла, в одном пароли до 12 символов, в другом 21-40. в каком из них пароли найдутся быстрее (условимся на том что хеши будут ntlm и подходящие пароли будут в обоих файлах)? как я понял из топа, пароли длинной до 12 символов найдутся сильно быстрее, нет?
судя по опыту до 12 символов найдутся быстрее, люди обычно длиней не делают , в диапозоне 4-12 делают пас зачастую, но да, есть исключения и сейчас и становиться больше могу быть и по 20 символов+, так что тут логика от меньшего к большему. Цифровые пароли 10-12 символов вообще смысла хранить нету, есть условно хэши NTLM и другие слабенькие алги, их проще прогнать маской с инкрементом и перебрать все варики от 1 до 12-14, тогда есть смысл собирать цифровые пароли которые будут условно 15-50, такую длину масками уже никак. И так да, пароли которые до 12 найдутся быстрее, потому что их будет банально больше, по логике что люди больше пароли делают до 12 символов. Как очистить словарь от хэшей ? я лично беру только строки до 31 символа, остальные delete
 
Последнее редактирование:
RUB1K сказал(а):
У тебя построчно мусор? Или в одной строке есть пароль + мусор?
мусор я уже весь почистил, остался последний вопрос - как часто в паролях встречаются двоеточия и точка с запятой?
 
Последнее редактирование:
antikrya сказал(а):
мусор я уже весь почистил, остался последний вопрос - как часто в паролях встречаются двоеточия и точка с запятой?
если брать условно 1кк хэшей с рандом баз, где то процентов 5-7, но там уже зависит от базы требования и паролю, если обязалово что б спец символ был, то процент будет больше, но обычно это цифры в шифте, вот их будет много, двоеточие и запятая не удобные к набиранию как и кавычки или точка с запятой их соотвествено будет меньше
 
Последнее редактирование:
Попробуй semgrep
semgrep --config rules.yml wordlistik.txt --lang generic
rules.yml:
YAML: 
rules:
  - id: url
    pattern-regex: '(https?://|www\.)\S+'
    message: "URL detected"
    severity: ERROR
    languages: [generic]

  - id: email
    pattern-regex: '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-z]{2,}'
    message: "Email detected"
    severity: ERROR
    languages: [generic]

  - id: hash
    pattern-regex: '\b[a-f0-9]{32,64}\b'
    message: "Likely hash detected"
    severity: ERROR
    languages: [generic]
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх