| 1.1, DHCPep (?), 22:39, 17/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Скажите кто может оценить. Для приведённого формата хеша sha1(md5($p).$s) какой должен быть длины пароль (минимум), чтобы перебор его был невозможен например для условного гугла за год.
Соль тут я так понимаю принципиального значения не имеет. Она же лишь для исключения словаря.
А также насколько адекватно хранение хеша пароля например такого
md5(md5($p).$s)
Тут же коллизию пароля хер подберёшь, ведь там ещё и соль?
| | |
| |
| 2.2, solardiz (ok), 23:02, 17/05/2019 [^] [^^] [^^^] [ответить]
| +6 +/– |
 Подобные хеши (кое-как составленные из небольшого количества вычислений быстрых хешей, также не предназначенных для паролей) - болезнь веб-приложений 2000-х, которая постепенно начала проходить в 2010-х. Ни одним из подобных способов хешировать пароли не следует. Для паролей следует использовать специально предназначенные хеши, такие как bcrypt, scrypt, yescrypt или Argon2. В веб-приложениях на PHP 5.5+, следует использовать интерфейс password_hash(): https://www.php.net/manual/en/function.password-hash.php
Длина пароля - лишь один из его параметров, хотя и очень важный, поэтому прямо на такой вопрос не ответишь, да и для некорректно выбранной хеш-функции вопрос не имеет практического смысла.
Соль не "лишь для исключения словаря", а выполняет несколько полезных функций сразу, но тут она и правда "принципиального значения не имеет" так как подобные хеши непригодны для паролей по другим причинам.
Вопрос про коллизии тем более не актуален по ряду причин.
| | |
| |
| |
| 4.7, solardiz (ok), 02:53, 18/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Про KDF ты в целом понимаешь правильно, а в моем комментарии упустил слова "из небольшого количества вычислений".
Упомянутые тобой атаки на MD5 и SHA-1 к теме не относятся.
Про "меркнет по скорости" перед rainbow tables не так просто - тут влияет много факторов. А соль начали использовать до появления rainbow tables (1970-е vs. 1990-е), так что предназначена она была не непосредственно против них, да и сейчас несет несколько функций.
| | |
| 4.27, анон (?), 22:21, 18/05/2019 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>Конкретно по MD5, это 128-bit, что в теории больше времени жизни вселенной
да хоть 512 или 1024 бит, причем здесь биты если сам алгоритм дырявый? коллизия к твоим 128 битам на обычных процах у МД5 находиться за время.... сюрпрайз МИНУТЫ!!!
| | |
|
| 3.30, Зябор (?), 14:01, 19/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
А скажите пожалуйста. Вот я так понимаю проблема хранения хеша пароля в виде bcrypt предпочтительней в первую очередь из-за скорости вычисления, что приводит например в случае утекания базы хешей, к неподъёмному времени взлома.
Но опять же и проверка введённых пользователем регистрационных данных замедляется соответствующим образом, что например даёт путь для напряга сервера подачей потока вариантов введённых данных. Тут или городить капчи, или бороться с кол-вом коннектов в единицу времени.
А скажите насколько допустим такой например двух-этапный способ, когда например в БД хранить вариант bcrypt'а, а вместе с тем ещё хеш например substr(md5($u.$s.$p)), 0, 8) и сперва проверять md5 вариант, если он корректен, то уже делать проверку bcrypt'ом?
Или это просто дикий костыль?
| | |
| |
| 4.31, solardiz (ok), 15:38, 19/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
"bcrypt предпочтительней в первую очередь из-за скорости вычисления" - да. "к неподъёмному времени взлома" - это зависит еще и от выбора паролей.
"Тут или городить капчи, или бороться с кол-вом коннектов в единицу времени." - да, но еще нужно учесть что у сервиса и до внедрения "тяжелого" хеширования паролей почти наверняка были другие аналогичные с точки зрения риска DoS слабые места, так что чтобы не сделать сервер более уязвимым к DoS достаточно настроить хеш так, чтобы он не был медленнее обработки другого самого медленного запроса, также доступного до аутентификации. Например, переход с быстрого не-парольного хеша вроде MD5, занимавшего 1 микросекунду, на bcrypt, настроенный на время 10 ms, на типичном веб-сервисе не повысит уязвимость к DoS (зачастую найдутся и другие запросы, занимающие 10+ ms или требующие больше I/O), но замедлит подбор паролей по украденным хешам на порядки. А с DoS можно бороться отдельно, для всех типов запросов.
"сперва проверять md5 вариант, если он корректен, то уже делать проверку bcrypt'ом" - это бессмысленно, так как атакующий сделает то же самое и получит не меньшее ускорение. Быстрый хеш, даже усеченный, хранить не следует.
| | |
| |
| 5.34, Зябор (?), 18:56, 19/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Ещё один возможно глупый вопрос, по этой же теме. А вариант всё-таки хранения в БД "быстрого" хеша вдобавок к "правильному". Но этот "быстрый" если допустим формируется "чёрным ящиком"?
Я тут понимаю, что в случае "чёрного ящика" - при компроментации сервера и этот чёрный ящик становится тоже доступен атакующему. Но если пойти дальше и "чёрный ящик" сделать действительно таковым, т.е. отдельно от серверов на которых крутится сервис иметь выделенный сервер на который при регистрации/смене пароля отправляются данные для формирования этого "быстрого" хеша непонятного способа формирования, и при авторизации отправляются данные для проверки его же. И уже в случае положительного ответа - проверяется "правильный" хеш.
Ну и соответственно этот "чёрный ящик" при компроментации самого сервиса - не становится доступен атакующему и он так-же в случае отказа или кто-то вместо него условно поставил свой всегда дающий "истину" на запросы авторизации, не даёт возможности авторизации т.к. в этом случае всё равно проверяется "правильный" хеш.
Велосипед?
| | |
| |
| 6.35, solardiz (ok), 21:46, 19/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Таких случаев, чтобы не было ресурсов на хоть насколько-то медленный хеш, вычисляемый всегда, не бывает. Всегда можно, например, заменить микросекунду на миллисекунду без заметного ущерба для производительности всего сервиса. Поэтому хранить не-парольный быстрый хеш совершенно ни к чему.
Если есть ресурсы на внедрение черного ящика (и не одного - для отказоустойчивости), то тем более они есть и на медленный хеш. Эти вещи хорошо использовать вместе - см. слайды от https://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/mgp00 и далее (а можно и предыдущие тоже) и реализацию https://github.com/SUNET/VCCS. Там используется HMAC на HSM поверх вычисляемого на обычном сервере медленного хеша, хотя есть определенные преимущества (а в некоторых случаях и недостатки) использования вместо этого обратимого шифрования "черным ящиком" медленных хешей, вычисленных на обычном сервере. Мы (Openwall) консультируем по таким внедрениям, так что если интересует всерьез - обращайтесь.
Хранить и проверять еще и какой-то более "правильный" хеш, не требующий "черного ящика", при этом не следует. Это лишь снижает пользу от применения "черного ящика". Насчет "поставил свой всегда дающий "истину" на запросы авторизации" - "черный ящик" не должен отвечать да/нет (он и не может - у него нет доступа к БД), а лишь довычислять или шифровать хеши.
| | |
|
| 5.39, PnDx (ok), 11:58, 20/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
 > "сперва проверять md5 вариант, если он корректен, то уже делать проверку bcrypt'ом" - это бессмысленно, так как атакующий сделает то же самое и получит не меньшее ускорение. Быстрый хеш, даже усеченный, хранить не следует.
Утверждение неверно. И вот почему:
При *совместной* проверке обоих хэшей необходимо предоставлять вектор (строку), для которого обе проверки валидны. Т.о., атакующий должен вместо подбора первой попавшейся коллизии найти пересечение на множествах коллизий обеих функций. Которое в "плохом" сценарии вообще может оказаться единственным. Но даже в "хорошем" случае решение задачи никогда не будет легче подбора коллизии на самый "сильный" хэш из пары.
| | |
| |
| 6.40, solardiz (ok), 13:42, 20/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Предполагается, что основной хеш (в данном контексте - bcrypt) достаточно устойчив к коллизиям, чтобы это не было проблемой. Вообще, коллизии в криптографических хешах - в частности, даже те что известны для MD5 и SHA-1 - обычно не являются проблемой при использовании этих хешей для паролей. (Чтобы это стало проблемой, коллизии должны были бы проявляться в отношении реальных паролей.) Реальной проблемой является быстрота вычисления таких хешей. В контексте выше, упомянутое мной ускорение подбора через проверку сначала быстрого хеша (и пропуск вычисления медленного) - очень серьезная проблема.
| | |
| |
| 7.41, PnDx (ok), 13:47, 20/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> (Чтобы это стало проблемой, коллизии должны были бы проявляться в отношении
> реальных паролей.) Реальной проблемой является быстрота вычисления таких хешей. В контексте
> выше, упомянутое мной ускорение подбора через проверку сначала быстрого хеша (и
> пропуск вычисления медленного) - очень серьезная проблема.
Да, в случае когда за приемлемое время решается задача "подобрать все коллизии вот на эту функцию". MD5? Да, Вы правы.
| | |
|
|
|
|
|
| 2.26, анон (?), 22:19, 18/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
МД5? серьезно? да хоть обзаворачивайся в 100500 уровней.
| | |
|
| 1.3, Алиса (??), 23:56, 17/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Достаточно ли моей рабочей машины из двух Xeon E5-2690v4 и GTX 1080 Ti для подбора ключа к IP-core от Intel. Там, как понимаю, используется толи AES-128 то ли ещё какая-то подобная штука. Не очень понимаю в этих технологиях, просто хочу попробовать расшифровать исходный код, который закодирован вроде как AES-128.
| | |
| |
| 2.6, вот такая вот куйня (?), 02:13, 18/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
достоверных дырок в AES-128 никто пока не находил
лучшее что удалось это снизить сложность до 2^126
а значит если нет возможности по сторонним каналам, а только прямым перебором
то тебе понадобится ~10^38 операций, что означает что если ты сможешь делать 1 триллион операций в секунду, то тебе все еще понадобится 10^26 секунд или
3,170,979,198,376,458,650 лет
так что про мамкиного хакера было прикольно )))
| | |
| 2.8, solardiz (ok), 03:46, 18/05/2019 [^] [^^] [^^^] [ответить]
| +4 +/– | |
Эта тема почти не имеет отношения к JtR и новости, но всё же отвечу:
Зависит от того, как Intel формирует ключ. Если хорошо, то (как уже ответили другие) шансов именно подобрать ключ нет. А если плохо, то надо знать или угадать как именно (например, каким инструментом разработки, а потом изучать как тот формирует ключи). Возможно, расшифровка всё равно осуществляется где-то во время синтеза, и ключ можно перехватить на своем же компьютере, ничего не подбирая? Но даст ли расшифровка исходники или, может быть, netlist? Вопросы скорее риторические, чтобы указать ими куда копать, если правда интересно.
Некоторые конкретности по теме есть тут:
https://www.cise.ufl.edu/~teshrim/ieee-final.pdf
https://eprint.iacr.org/2017/828 "The paper was withdrawn for non-scientific reasons, and the results in this paper are correct." но статья всё равно доступна по ссылке выше
https://www.kb.cert.org/vuls/id/739007/
https://www.intel.com/content/www/us/en/programmable/documentation/mwh14099606
Мне непонятно, какой моделью угроз руководствовались авторы статьи и CERT. Если верно моё понимание, что ключ всё равно в какой-то момент оказывается в памяти компьютера, на котором работает EDA (см. "Figure 3: Work flow of the P1735 standard." в статье), то его оттуда можно просто извлечь. Авторы и CERT "не слышали" про reverse-engineering и анализ памяти приложения или же считают, что атакующие почему-то ограничатся какими-то "более этичными" или не нарушающими какие-то юридические условия способами? Странно. Но тем не менее, статья, похоже, о том как даже не прибегая к тому чтобы посто подсмотреть ключ, всё равно можно расшифровать через oracles.
| | |
| |
| 3.11, Nightfall (?), 08:33, 18/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Привет, Солар. Немного не по теме, но не расскажешь какие ОС используешь дома (для персонального, частного пользования) и почему? Ты раньше был втянут, скажем так, во взаимодействие с андеграундом, у тебя брали вью во фраке и тп. , давным давно ты даже принимал участие во всяких хакерских е-зайнах, я помню твои эксплоиты кое-где. Поддержваешь ли ты какие-нибудь связи и как оцениваешь состояние так называемой "сцены"? Как ты относишься к вирусным технологиям в мире unix/linux (эта тема малопопулярна и мало исследованна, но что называется in the wild сейчас водятся несколько достаточно интересных экземпляров)?
| | |
| |
| 4.24, solardiz (ok), 18:32, 18/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Сильно не по теме, да и я не планировал давать интервью. Это нарушение OPSEC, но думаю уже не секрет что я использую QubesOS - делал с нее доклады, показывал USB passthrough как раз для доступа к ZTEX FPGA плате из VM'ки. На серверах всё еще наша Owl с дополнениями. Пока в целом полет нормальный, но устраивает не всё, да и системы устаревают. Не исключаю уход с Linux. Мой Phrack prophile еще достаточно свежий, от 2016 года - там я отвечаю на схожие вопросы про "сцену", так что если интересно, перечитай его. Не помню, чтобы я публиковал exploit'ы в e-zine'ах. Немного публиковал их в Bugtraq. Вирусы под Unix пока in the wild не встречал - видимо, у нас и наших клиентов не настолько стандартные настройки систем. Думаю, именно разнообразие систем и настроек сдерживает распространение вирусов под Unix-подобные системы.
| | |
|
|
|
| 1.10, Аноним (10), 07:48, 18/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– | |
> что ничуть не мешает полноценному использованию GPU от NVIDIA (и даже помогает, благодаря фокусированию разработки и оптимизаций на одну реализацию каждого формата под GPU вместо двух реализаций ранее).
Максим, эта формулировка звучит по-детски, убого и непрофессионально и, пока не провели тесты, говорить о том, что the OpenCL implementation might be as fast as, or faster then the CUDA implementation on NVIDIA GPUs, рано.
// b.
| | |
| |
| 2.21, solardiz (ok), 15:46, 18/05/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Мы (разработчики) проводили тесты и мы говорим конкретно о нашей реализации в JtR. Мы не утверждаем, что CUDA чем-то еще кроме переносимости хуже OpenCL'я - это не так, в CUDA есть возможности, которых в OpenCL нет (но которые нам пока не понадобились). Мы лишь утверждаем, что сфокусировавшись на OpenCL'е мы получили результат лучше, чем получался когда мы делили наше время на разработку под CUDA и OpenCL одновременно. Кстати, такое же решение принял проект hashcat. Еще одним аргументом в пользу OpenCL (и одной из причин почему hashcat стал Open Source) является хорошо укладывающаяся в концепцию OpenCL адаптация сборки под конкретную задачу - изменение "исходного" кода для конкретных загруженных хешей в нашем случае (что делается, в особенности для descrypt). На CUDA так тоже можно делать - так делает ProgPoW - но исторически CUDA используют не так. OpenCL не мешает нам (во всяком случае, не в большей степени, чем CUDA) использовать оптимизации, специфичные для конкретных архитектур GPU (у нас там даже есть чуть-чуть inline PTX asm, то есть под NVIDIA).
| | |
|
| 1.12, Aytishnik.com (ok), 09:52, 18/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 Очень хорошая прога, выручает часто, так как иногда забываю пароли, фирм обслуживаю много, поди вспомни какой пароль пять лет назад ставил.
Вот и выручает каждый месяц. Спасибо разработчикам.
| | |
| |
| 2.14, Аноним (14), 11:18, 18/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
И не говори: поди вспомни, где поставил 12345, где 54321, а где и вовсе qweasdzxc…
| | |
| |
| 3.16, пох (?), 11:44, 18/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
блин. да у тебя вообще феноменальная память. Я такие сложные (кроме, понятно, первого, его уже выучил, кстати, как ты узнал мой пароль от всех корпоративных систем?) на бумажке к монитору клею.
| | |
|
| 2.15, Аноним (10), 11:41, 18/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Вас, батенька, уволить надо за такую безопасность. Пароли, которые подбираются за вменяемое время - это не пароли, а шутка юмора.
// b.
| | |
| |
| 3.17, пох (?), 11:48, 18/05/2019 [^] [^^] [^^^] [ответить]
| +3 +/– | |
во-первых, тебя или твоего коллегу его клиенты уже уволили - и наняли дешевого аутсорсера, как видишь. Ты ненужен, смирись. Попробуй свои силы в сдаче аллюминиевых баночек.
во-вторых, если у тебя можно безнаказанно подбирать пароли, а не все блокируется нафиг и выбегают ребята с дубинами и наручниками уже после нескольких попыток (не говоря уж о физическом доступе, который нужен для ripper) - либо это и есть админ, и все нормально, склероз не повод для дискриминации, либо уволить надо тебя, вне зависимости от того, насколько охрененно хорош твой пароль.
| | |
| |
| 4.51, InuYasha (?), 12:26, 25/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
попридржи дубину-то )
Думаешь, первый оратор реально по сети пароли подбирает? Да нет конечно.
| | |
| |
| 5.53, пох (?), 13:00, 25/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Думаешь, первый оратор реально по сети пароли подбирает? Да нет конечно.
ты будешь смеяться, но даже если не сам- то издевается над такими.
То есть это реальная и регулярная проблема обслуживающих микролавочки с полутора инвалидами - то сами в виду бардака "кто это настраивал три года назад? Вася? Вася под каток попал еще год тому, все пароли пропали!" то между их визитами кто-то еще успел "поработать".
Ну а поскольку пароли обычно не идут дальше "win123456" - то подобрать их удается за вполне конечное время (самый херовый - фио и мабила "настройщика обоев". Поскольку как его звали никто не помнит, да и номера тоже, а пароль длинный).
Причем тут "по сети"? Локально он их подбирает, скопировав юзербазку любимым линуксом.
На fpga, понятен, у таких денег не наберется, да им и не надо. В конце-концов, ненадолго выключат майнилку - и подберут на своей нвидии.
| | |
|
|
|
|
| 1.20, OpenEcho (?), 14:52, 18/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Потребление 27 ватт... офигеть, мой портативный 15 ваттный паяльник может гарантированно выбивать из любого самые сложные пароли и за очень малое время, аss rippеr называется
| | |
| |
| 2.23, solardiz (ok), 16:03, 18/05/2019 [^] [^^] [^^^] [ответить]
| +7 +/– | |
Во-первых, эти подходы имеют этические и юридические отличия.
Во-вторых, это другая модель угроз, к bcrypt (о котором были 27 ватт) обычно не относящаяся - для bcrypt обычно атакуют большое количество хешей одновременно (многих пользователей), часто с целью выявления слабых паролей, исследовательской и т.п.
В-третьих, паяльник не поможет в случае реально забытого пароля или отсутствия человека (например, умер).
| | |
| |
| 3.43, OpenEcho (?), 23:50, 20/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Во-первых, эти подходы имеют этические и юридические отличия.
solardiz, дорогой, у Вас очень плохое чувство юмора...
| | |
| 3.54, Аноним (54), 13:27, 27/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Особенно обидно, когда третье происходит непосредственно во время перебора. Как говорится, "Вскрытие показало, что больной умер от вскрытия"
| | |
|
| 2.28, анон (?), 22:30, 18/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
ну подбери своим паяльником пароль к кошельку где битки лежат
(мультисиг 4 из 5, люди в разных городах и даже странах)
велком ту же нью волд, мухахаха))
| | |
| |
| 3.44, OpenEcho (?), 01:09, 21/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> и часто вам приходилось забывать свои пароли?
Ни разу :)
Помню всегда всего один единственный мастер пароль, который открывает менеджер паролей, который хранит все остальные пароли.
| | |
|
| 2.36, Ordu (ok), 00:18, 20/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > мой портативный 15 ваттный паяльник может гарантированно выбивать из любого самые сложные пароли и за очень малое время, аss rippеr называется
Тебе не приходилось забывать пароль? Помогает ли в этом случае паяльник?
| | |
| |
| 3.45, OpenEcho (?), 01:21, 21/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Тебе не приходилось забывать пароль?
Ни разу :)
Помню всегда всего один единственный мастер пароль, который открывает мэнеджер паролей, который хранит все остальные пароли.
Лет десять пользую кросплатформеный KeepAss, а раньше юзал обычный запароленный архив с текстовыми файлами
> Помогает ли в этом случае паяльник?
Те, кто забывают СВОИ пароли, а потом брутфорсят, к ним не нужно применять паяльник, они сами себя наказали...
| | |
| |
| 4.48, пох (?), 15:47, 21/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Помню всегда всего один единственный мастер пароль, который открывает мэнеджер паролей, который
> хранит все остальные пароли.
и если навернется база - тебе и рипер уже не поможет. А если авторы чудо-менеджера окажутся не совсем честными или не совсем аккуратными - тем ребятам рипер тоже не понадобится.
Правильное решение, хвалю. Все яйца в одной корзинке.
| | |
| |
| 5.49, OpenEcho (?), 16:12, 21/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> и если навернется база - тебе и рипер уже не поможет.
Есть только две категории людей, те которые делают бэкап и те которые будут делать бэкап. Я из первой категории.
> А если авторы чудо-менеджера окажутся не совсем честными или не совсем аккуратными
> - тем ребятам рипер тоже не понадобится.
Keepass опенсоурсный, хошь в перловке, хошь в крестах, a хошь и в шарпе и народ перепроверяет честность и аккуратность
> Правильное решение, хвалю. Все яйца в одной корзинке.
Вот именно, в одной корзине, а не на стикерах прикленных к экрану и не разбросанных где попало и у кого попало, что позволяет делать уникальные пароли в 128 символов к каждому ресурсу и не забывать их
| | |
| |
| 6.50, пох (?), 16:30, 21/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Keepass опенсоурсный
и? Кому и когда это помогало? :-(
А стикер с моего экрана спереть - надо пройти несколько уровней физической безопасности, а потом еще и знать, куда вводить тот пароль (эти вещи обычно разные люди умеют). Не проще ли сразу паяльник с собой захватить, меньше ж возни?
Причем если меня около стикера нет - можешь этим паяльником др..ть себе анус - хоть удовольствие получишь. Я-то вспомнить то, чего и не знал никогда, и бэкапа при себе нет - при всем желании сотрудничать - не смогу.
Уборщица смахнула стикер в урну? Ну хрен с ним, взломаем снова. Это ж моя система, хочу - ломаю, не хочу - пароль не знаю.
| | |
|
|
|
|
| |
| 3.46, OpenEcho (?), 01:24, 21/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> На себе проверял?
Только анониму с опенета могла прийти такая идея :)
Вы правда все на себе проверяете ?
| | |
| |
| 4.52, InuYasha (?), 12:29, 25/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ну а как иначе? Прежде чем делиться, должен протестить на себе, прогнать бенчмарки, оценить эргономику, выложить видосик ))))
| | |
| |
| 5.55, OpenEcho (?), 00:34, 31/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Яша, не много на себя берешь, кидая предьявы что я кому-то, что-то должен?
Я бы преложил тебе поучаствовать в качестве взламываемого девайса для бенчмарков, но мне в отличии от тебя ничего от тебя не надо и ты мне ничего не должен, так что, обьективный бенчмарк не получится, a во вторых меня "пугают" чуваки желающие смотреть подобные сцены на видосиках, т.ч. отложим бенчмарки на добровольцах
| | |
|
|
|
|
|
