Изпечатай

[Янчо]

Добър ден!
На първо място съжалявам, ако съм объркал раздела, в който да пусна темата си!

Потърсих, не знам- може би не достатъчно качествено, но не открих тема свързана с това приложение.
Че... интересува ме разбира се, ако някой е пробвал или пък има информация, Колко голям(Като размер- предполагам в Gb-ти) би бил WordList с обхват от 6-16 символа, както и всички символи:
0123456789
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
. , ; : - _ = +
или ако не може да ми се даде някаква точна информация, поне да бъда насочен към начин по, който да определя приблизителния размер без огромни разлики.
и възможно ли е след генерирането на този файл (който предполагам, че ще е доста голям) да го разделя с помощта на софтуер на няколко по малки файла, като всеки от тях примерно да съдържа определен брой редове както следва:
1.lst - от 1 до 10000 ред
2.lst - от 10000 до 20000 ред и т.н.

Още веднъж Съжалявам, ако вече има такава тема и съм я пропуснал.
Благодаря предварително!

[4096bits]

Това е въпрос на математика. Имаш списък със 45 символа, ако включиш и интервала. Поинтересувай се, какво е факториел и пермутация. Зависи и какво имаш предвит под "дума". АААААА може да е дума например. Ето например как се изчисляват възможните комбинации за ТОТО 6/49. Прилича на твоя случай, само дето е точно за 6 символа с условие, да не се повтарят. Ти ще трява да направиш същото за всяка дължина на думата от 6 до 45 символа, като включиш и комбинациите с повтарящи се символи. Някой ако разбира от математика, може и да ти каже как се пресмята. Аз съм забравил всичко 

Ето ти малко по темата:

цък
http://www.math10.com/forumbg/viewtopic.php?t=9781
http://www.math10.com/f/viewtopic.php?f=68&t=3087
http://stancho.roncho.net/HighMath3/Prob/Comb/Comb.html
http://bg.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%B1%D0%B8%D0%BD%D0%B0%D1%82%D0%BE%D1%80%D0%B8%D0%BA%D0%B0
http://u4ili6teto.bg/mod/scorm/view.php?id=2574

[neter]

Списъкът е от 70 символа - 10 цифри, 26 малки букви, 26 главни букви и 8 знака. Та... ако броим АААААА за дума, т.е. позволени са повторенията на символите, тогава броят на комбинациите с дължина 6 символа ще бъде 70^6. За да получим размера на файла, в който ще са вписани, трябва да умножим тази бройка по 7 (по 1 байт на символ плюс 1 байт за нов ред, с който да разделим комбинациите една от друга), при което получаваме 823543000000 байта, или 767 GB. И това е само за комбинациите с дължина 6 символа. Целият WordList с обхват от 6 до 16 символа ще бъде:
((70^6)×7) + ((70^7)×8) + ((70^8)×9) + ((70^9)×10) + ((70^10)×11) + ((70^11)×12) + ((70^12)×13) + ((70^13)×14) + ((70^14)×15) + ((70^15)×16) + ((70^16)×17) байта = 4 736 924.44 YB (йота байта)

Потърси други начини за brute force

П.П.: А! Забравих втората част на въпроса. За разделянето на файл на по-малки файлове можеш да използваш командата split. Разгледай помощната ѝ информация (--help), но за твоя случай ще трябва да делиш по редове, а не по байти, и ако ще са по 10 000 реда във файл, то командата ще е:

split -l 10000 голям_файл префикс_за_малките_файлове

Друг е въпросът, че според описанието на Crunch в опциите му си има разделяне на по-малки файлове, както по редове, така и по байтове.

[Acho]

И това само за латинските букви. Ако нахакаш и кирилските - познай.

[neter]

Като стана дума за кирилските (и въобще нелатинските) букви, добре е да се спомене и, че ако се намесят и те, формулата за пресмятане ще се променя в зависимост от кодировката на символите, която се ползва. Ако се добавят само кирилските букви, за препоръчване е да се използва кодировка Windows-1251 (CP1251), където тези букви са по 1 байт, също както латинските, и така файлът ще е по-малък (не, че ще стане възможен, но...). В UTF-8 те са по 2 байта. Ако обаче се добавят и други нелатински букви, тогава ще се наложи ползването на UTF-8 или друга кодировка, която съдържа всички нужни нелатински букви.
Трябва да се има предвид и, че ако се използва Windows-кият формат за нов ред (CR+LF, '\r\n', 0x0D0A), тогава за новите редове ще трябва да се брои по 2 байта, вместо по 1.

[4096bits]

  В главата си смятам и големите и малките букви, но съм сметнал само едните.

Както и да е. Мисля, че с малко повече ровене в нета, може да се намерят почти всякакви речници. Или програми за съставянето на такива.

[gat3way]

Да пазиш такъв речник от всички комбинации е пълно разхищение и безумие.

[Янчо]

Благодаря първо за отговорите...! Радвам се че срещам подкрепа и съдействие от форума.
Съгласен съм с отговора на @gat3way, че пазенето, както и създаването на такъв файл е напълно безсмислено
Особено след подробното обяснение на @neter за примерната големината на файла!
Но въпросът по- скоро беше с цел трупане на информация, а и съм на мнение, че тези работите тип - BruteForce не са основани на идеята да наблъскаш машината с безразборна информация и той да се тормози докато не свърши работата вместо тебе.. Най- малкото нещо според мене е, че дори и да създадеш подобен файл, то най- вероятно ще е нужно повече време за проверка на всичките комбинации, от колкото ще имам възможност да прекарам на компютъра през живота си Нужен си е и човешкият фактор..

Още веднъж благодаря за насоките, сметките и като цяло мненията ви! Ще се радвам, ако темата претърпи някакво развитие в бъдеще.
Поздрави!

[gat3way]

Идеята на bruteforce атаката е именно такава - това е начина да се изчерпа някакво множество кандидат-пароли. Вече колко време ще отнеме е отделен въпрос.

Това казано, генерирането и записването им във файл е безумие, не само заради това че въпросният файл може да стане много голям в зависимост от множеството. Проблемът е че четенето от този файл е много бавно, в сравнение просто с генерирането на кандидатите.

Докато съм си писал моя софтуер за трошене съм си правил доста benchmark-ове на скоростта на генериране, но точни конкретни резултати не мога да ти дам, защото не помня. На моята dev система (6-ядрен AMD FX-6100, някакъв стар 250GB SATA диск, видеокарта AMD Radeon 7970) нещата горе-долу стояха по следния начин: четенето от речника на кандидати с дължина 8 символа беше със скорост около 5 милиона кандидата в секунда (или четене от файла около 40-50MB/s, което е горе-долу нормално за буферирано четене ред по ред от файл от SATA диск). Генерирането на кандидати върху процесора (многонишково) беше от сорта на 300-400 милиона кандидата в секунда, дали не беше и повече. Върху видеокарти никога не съм имал чисто генериране на кандидат-пароли, там единствено 4 символа от паролата се генерират, останалата част се цикли върху процесора, та при това положение, скоростта на генериране на пароли е брутално голяма - десетки милиарди в секунда.

При четенето от диска може да се направи много малко - thread-ването няма да помогне особено, вероятно изчитането и пребуферирането на по-големи парчета от файла би намалило syscall-овете и би помогнало малко или много, но така или иначе за този диск sequential read-а е около 100MB/s и това е теоретичната максимална скорост - като го минеш през VFS слоя ще е доста по-бавно, но и да не беше - трудно ще докараш повече от десетина милиона кандидат-пароли изчетени от файл в секунда.

При генерирането върху CPU може доста да се направи, има доста фокуси, но ме мързеше, а и сега ме мързи да ги имплементирам, синхронизацията е безумна, въобще не съм доволен от себе си изобщо, но и там трудно ще се изкара с порядъци повече, не мисля дори че е реалистично да искам 1 милиард кандидата/секунда върху процесора.

При генерирането върху GPU много малко може да се изтиска според мен, тоя модел е следствие на толкова много натъманяване, редизайни и тестове че е трудно да се направи по кардинално по-добър начин.

Та мисълта ми е че генерирането на паролите on-the-fly спрямо четенето им от файл е с порядъци по-бързо. Вече има друг момент - самият алгоритъм който се атакува колко е тежък. Ако е прекалено тежък (примерно искаш да трошиш пароли за Truecrypt дялове), може да се окаже че няма значение дали ще ги генерираш или ще ги четеш - bottleneck-а ще ти е изчислителното време. Обратно, ако атакуващ някой простичък алгоритъм като MD5 или SHA1, тогава четенето от файл ще е огромно разхищение и напълно безсмислено начинание.

[Янчо]

Интересни насоки... даде ми доста основи за размисли
И все пак, да споделя че съм доста бос по темата, затова се извинявам за възможни некомпетентни или неточни коментари и изказвания.
А по въпроса с алгоритмите, генериращи символни низове в процеса на действие без предварителна подготовка.. бях срещнал преди няколко дни подобна тема някъде из Google с алгоритъм на следния принцип (не мога да намеря отново темата, защото забравих точно името на приложението, но отгоре- отгоре ще се опитам да обясня какво представляваше)
дължината на низа(желаната парола) се изписва, чрез оказания(букви) за видът на символите, които могат да се съдържат на точно определеното място (не съм сигурен дали се изразявам точно).
Например:
Алгоритъма, който ще налучка парола: PassWord00
Би представлявал нещо подобно на това: -u-l-l-l-u-l-l-l-d-d
Където:
-u = Uppercase
-l = Lowercase
-d = Digits
-a = All Symbols
и всяко едно указание(буква) от алгоритъмът представлява точното положение на групата от символи, които ще се въртят там.
Например:
PassWord00
-u-l-l-l-u-l-l-l-d-d
Където:
W - е 5-та подред буква от низа, а в алгоритъмът- указателя седи на 5-то подред място и означава, че там ще се въртят само главни букви...
Като, не съм сигурен за правилното изписване на на алгоритъма(дали беше с "-" или нещо друго..)
Ще се радвам, да ме насочиш по- конкретно към приложения извършващи подобни операции, да се информирам малко повече защото, както споменах съм нов в тази сфера, както и в операционната система в този неин аспект и не знам кой път да хвана.. защото има много информация по темата в интернет, а аз още нямам база за сравнения за да я отсея правилно.

[gat3way]

Това се нарича "mask attack". Предполагам си гледал формата на маската, изискван от hashcat:

https://hashcat.net/wiki/doku.php?id=mask_attack


При мен, това се разглежда като частен случай на rule атаката и описанието съответно е по-дълго, rule файла би изглеждал така:

Код:

begin
must add 1:1:ualpha
must add 3:3:lalpha
must add 1:1:ualpha
must add 3:3:lalpha
must add 2:2:num
end

[4096bits]

Гейт, такова генериране он дъ флай, колко рамец яде? В смисъл, предполага се, че паролите ще се генерират по-бързо отколкото ще е проверката, дали това е исканата парола. Или е по-удачен вариант генериране на парола > проверка и така безрой пъти, докато се приключи?

[gat3way]

Зависи как е реализирано, специално в случая с атаката с маската, не би трябвало да яде изобщо много - това е една проста рекурсия при която с такава дължина на маската надали ще се ходи много надълбоко и съответно няма да яде особено много памет за стека. Вероятно и итеративно решение е възможно и тогава сигурно ще яде още по-малко памет.

Но не знам - не съм го разписвал никога, при мен както казах такова генериране е подслучай на rule атаката и минава по общия механизъм - през "интерпретатора" и навързаните callback функции които генерират изход на база ред от гореописаното правило. Там отива повече памет, но не би трябвало да е кой знае колко.

Не е задължително (няма и смисъл) кандидатите да се буферират в случай че проверката минава по-бавно от генерацията. При това положение, проверката никога няма да "навакса" с буфера и той ще трябва да расте с времето докато не заеме цялата налична памет в един момент. Обикновено този проблем се решава или със синхронизация, или генерирането и проверката става последователно, примерно генерират се X кандидата, проверяват се, генерират се следващите X, проверяват се и така. Thread-ването на такава работа е малко сложно занятие, защото трябва да можеш да "разпределиш" генерирането и последното да става независимо от всяка нишка и без синхронизация между тях (или с възможно най-малко). Това не е лесно. С видеокартите е още по-проблемно, защото можеш да имаш няколко карти които работят с различна скорост и ако разпределиш по равно keyspace-а между картите, накрая ще чакаш най-бавната карта, докато другите стоят и мързелуват.

Дали проверката ще е по-бърза от генерацията или обратното, много зависи. Ако примерно проверката става върху видеокартата, а генерацията изцяло върху процесора, тогава в зависимост от алгоритъма, може проверката да е по-бърза от генерацията, което пак е лошо - GPU-то стои и хартисва докато чака CPU-то да му сервира следващата порция.

[4096bits]

Искаш да кажеш, че трансвера по мрежата колкото и да е бавен може да насмогне на генерирането? Малко ми е странно. Колкото и да е малък пинга, това си е много време за процесора и паметта.

Искам да питам, може ли zsh да се прекомпилира така, че да е възможно както в bash да се появи устройство /dev/tcp например?

[gat3way]

Каква мрежа?