- Автор темы
- Добавить закладку
- #21
Еще забыл добавить, никто не мешает как и говорилось в статье для некоторых групп файлов увеличить объем шифрования - это не критично скажется на общей производительности если делать с умом.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Статья Ransomware - все по взрослому или оптимизация работы (конкурс 2020)
Всё вышесказанное было по теме. А ты мямлишь про какой-то флуд. Словом, не умеешь воспринимать критику, но сам же критикуешь, даже когда не знаешь о чем речь. Смешно даже.
- Автор темы
- Добавить закладку
- #23
Слушай не надоедай, то что тебе на понравились сиськи - это не критика, а твои извращенные фобии. Смешно позориться флудя в чужой теме дабы насрать в отместку.
Дико извиняюсь что влажу. Но как ты говоришь критика про «сиськи» высосана из пальца. Техническая несостоятельность статьи - вот где критика уместна, все остальное вкусовщина. В правилах есть запрет на сиськи? Нет? Ну и все
тема сисек не раскрыта =(
ЗЫ интересная тема
ЗЫ интересная тема
- Автор темы
- Добавить закладку
- #26
Должна остаться интрига, не все же мне за вас делать (но я подумаю, может и сделаю)
А по поводу шифрования «полосами» что думаешь? Ну то есть засплитить файл на n равных кусков, и каждый второй/третий пятый десятый кусок шифровать. Оверкилл, выходит?
- Автор темы
- Добавить закладку
- #28
Да, хорошая идея, но имеет недостаток, длинна полос должна быть не шибко маленькой, чтобы брут был не возможен и плотность поло должна быть, чтобы не восстановили, потому что если уж без хидера смогут восстановить то мое мнение полосы должны быть плотнячком, отсюда мы упремся опять в производительность. Просто опять же из опыта, шифрование хидера более чем достаточно, стоит лишь учесть некоторые избранные файлы.
Ну вот про баланс между надежностью/скоростью мне и интересно. Каков самый оптимальный вариант. Есть какие нибудь исследования на эту тему?
- Автор темы
- Добавить закладку
- #30
каждый сам выбирает, из опыта опять же, мне больше всего понравился вариант AES+RC4(без блочным), RC4 хоть и кажется тяжелым, но он помогает смыть блочность AES и для брута надо будет снять с начало весь RC4. 16кб или больше каждый может выбрать сам, можно даже сделать эту длинну исходя из размера файла, к примеру сделать %.
- Автор темы
- Добавить закладку
- #31
Вот еще идея родилась - сделать можно полосами AES, а RC4 накрыть все полосы как единую цепь данных и реверсировать перед шифрованием RC4, тогда будет невозможным расшифровать одну полосу не собрав все полосы вместе.
А что думаешь по поводу общей организации работы локера? Что лучше? Офлайн, онлайн? Почта/админка/другие способы? Интересно конечно насколько вообще нужно мариновать и как тщательно общаться с жертвой, для того чтобы прошла оплата и передача ей ключа. Или этот момент можно миновать, рассчитывая на то, что если надо - все равно заплатит.
Поддерживаю стало тоже интересно отпишите кто в теме где % выше.
На счет сисек даже не чего
- Автор темы
- Добавить закладку
- #34
Спать уходил
Офлайн - имеет недостатки, это надо генерировать для каждого стаба свой индивидуальный ключ, а это время и не всегда возможно.
Онлайн - более надежный с точки зрения хранения ключа, но не всегда может быть инет, к примеру внутренние корпоративные сети.
Каждый сам выбирает, но онлайн менее геморный (мое мнение).
По поводу оплаты - забудьте про почты! только админка (и желательно не на пхп, чтобы не ломанули), админку рекомендую класть в тор. Так же к ней использовать альтернативные доступы через тор-гейты, через шелл-гейты.
Оплата через онлайн чат более прибыльнее, но не рассчитано на массовость - устанете со всеми нытиками говорить, подходит для мелких прогрузов, проще организовать (не надо онлайн оплату делать, руками проверите).
Админка с автооплатой намного удобнее, автономна, организация более сложна.
Но и там и так надо шифровать ключи, которые храните в базе! Сам сервак должен быть абузным по мере возможности, или к примеру саму базу хранить на другом серваке, а то сам саппорт и сольет весь баланс.
Мариновать не стоит, НО стоит сделать ограничение на перриод выплаты, к примеру неделя, а то многие кладут болт на потом, а потом как правило через месяц сервак закрывают(по собственному желанию) и человек просто не сможет выкупить.
Тут сугубо мое мнение и оно не является последней инстанцией.
немного не по теме, но спрошу здесь, ты не пробовал делать compile-time aes(расшифровка и последующая зашифровка уже в ран-тайме само собой)?
обычно большинство людей хватает максимум на ксор в компайл-тайме, но я нашел этот реп https://github.com/bormand/ct_aes, там у него еще есть aes на макросах на C, сам до конца не разобрался, но интересна тема хорошего шифрования обычных строчек в бинарнике, чтобы ксор не брутили
обычно большинство людей хватает максимум на ксор в компайл-тайме, но я нашел этот реп https://github.com/bormand/ct_aes, там у него еще есть aes на макросах на C, сам до конца не разобрался, но интересна тема хорошего шифрования обычных строчек в бинарнике, чтобы ксор не брутили
- Автор темы
- Добавить закладку
- #36
Не понял вопроса, т.е. что именно имеешь ввиду?
aes или любое другое более криптостойкое чем xor шифрование строк во время компиляции, чтобы их не было в бинарнике, я не знаю на каком ЯП ты сидишь, но мой вопрос касается в основном С++
- Автор темы
- Добавить закладку
- #38
Т.е. если я правильно понял, ты хочешь чтобы в бинарнике строки не были в открытом состоянии и ты хочешь их шифровать. А что мешает написать парсер и перед компиляцией все строки щифровать и в рантайме их дешифровывать - я так делаю. Я на всех ЯП пишу.
ничего не мешает, но т.к. библиотека для шифрования будет использована, было бы удобнее если бы в ней сразу был режим работы во время компиляции, в теории это возможно, пойду разбираться.
то же самое что "не пишите на шарпе, он декомпилируется"
а что тогда? go? ruby? нода ебучая?
php как был актуальным, так и останется еще долгое время