Если вы выложили исходники шифровальщика на GitHub — вызвали в полицию, ключевая опасность в том, что ситуацию могут трактовать как создание/распространение вредоносного ПО, даже если вы считали это «исследованием», «учебным примером» или «пруфом концепции». В этот момент важно не спорить «по понятиям», а сразу выстроить защиту по процессуальному порядку: кто вас вызывает, в каком статусе, что именно проверяется и какие доказательства уже собраны.
Самая частая ошибка — прийти «просто поговорить», отдать телефон «на минуту», подписать объяснение без замечаний и в итоге получить изъятие техники, доступ к аккаунтам, экспертизу и формирование версии следствия об умысле. По делам о вредоносных программах решает не ваша репутация в чате, а квалификация действий, формулировки, цифровые следы и допустимость доказательств.
Кратко по сути: Выложил исходники шифровальщика на GitHub — вызвали в полицию
- Вызов может быть в рамках проверки сообщения о преступлении или уже по возбужденному делу; ваш статус (свидетель/подозреваемый) критичен.
- Публикация кода сама по себе не всегда равна преступлению, но риск ст. 273 УК РФ возникает, если код функционально вредоносен и направлен на несанкционированное воздействие.
- Следствие будет искать признаки умысла: описание репозитория, readme, коммиты, релизы, инструкции, переписки, донаты, обсуждения обхода защит.
- Обычно назначают компьютерно-техническую экспертизу и пытаются привязать автора к конкретным последствиям или подготовке к ним.
- Первые действия (объяснения, согласия на осмотр, выдача паролей) задают траекторию: их сложно «отыграть назад».
Тактика и стратегия в ситуации: Выложил исходники шифровальщика на GitHub — вызвали в полицию
Стратегия строится вокруг трех осей: квалификация, умысел, доказательства. По квалификации важно отделить исследовательский/учебный код от «вредоносной программы» в смысле уголовного закона: анализируется функционал, возможность причинения вреда, наличие обхода защит, механизмы закрепления/самораспространения, шифрование без согласия пользователя. По умыслу — ваша позиция защиты должна быть согласованной и проверяемой: цель публикации, контекст, ограничители, предупреждения, отсутствие инструкции по криминальному применению, отсутствие корыстной мотивации. По доказательствам — контролируем допустимость доказательств: как изымали устройства, как снимали копии, кто и как получал доступ к аккаунтам, соблюден ли процессуальный порядок осмотра и выемки, не подменены ли данные.
Точки контроля: фиксируем основания вызова и предмет проверки, подаем ходатайства об участии адвоката, ставим вопрос о корректной экспертизе (вопросы эксперту, исходные данные, целостность образов), заранее готовим объяснения так, чтобы не создавать самооговор и не «дарить» следствию формулировки об умысле. Всегда держим в голове презумпцию невиновности: доказывать должны не вы.
Нормативное регулирование и правовые институты
По таким историям обычно рассматривают ответственность за создание, использование и распространение вредоносных программ для ЭВМ (статья 273 УК РФ) и сопутствующие составы, если следствие видит несанкционированный доступ, вмешательство в работу систем или подготовку к атаке. Процессуально все начинается с проверки сообщения о преступлении, далее — возбуждение дела, производство следственных действий, назначение экспертиз. Ключевые институты: статус участника (свидетель/подозреваемый/обвиняемый), право не свидетельствовать против себя, судебный контроль по жалобам на действия дознания и следствия, а также правила относимости и допустимости цифровых доказательств (логов, дампов, переписок, данных облаков).
Как это работает на практике
Сценарий 1: Репозиторий «для учебы» без релиза
Ситуация: выложили исходники, но не собирали бинарники и не давали инструкций. Риск/ошибка: на допросе сказать «это настоящий шифровальщик, работает на Windows» и описать, как обходить защиту. Верное решение: нейтрально фиксировать исследовательский контекст, акцентировать отсутствие целей криминального применения, попросить адвоката и не обсуждать технические детали без понимания, какие вопросы включат в экспертизу.
Сценарий 2: Есть readme с инструкцией и примером использования
Ситуация: в описании — «как запустить» и «как отключить антивирус». Риск/ошибка: удалить репозиторий после вызова, что могут трактовать как сокрытие следов. Верное решение: не предпринимать действий, которые выглядят как уничтожение доказательств; через адвоката собрать и сохранить копии своей же публикации, контекст коммитов, переписку, показать предупреждения/ограничители и добиваться корректной квалификации и оценки умысла.
Сценарий 3: Форк/контрибьют в чужой проект
Ситуация: вы не автор, но делали правки или собирали релизы. Риск/ошибка: «я просто помогал, не знаю, что это» при наличии коммитов, обсуждений и задач. Верное решение: четко разграничить роль лица в преступлении: что именно делали, какие части кода, с какой целью; пресечь попытку «повесить» на вас авторство, требовать установления источника, а не предположений.
Типичные ошибки в данной ситуации
- Явка без адвоката и дача подробных объяснений «в дружеском формате».
- Передача телефона/ноутбука и паролей «для проверки», согласие на осмотр без понимания объема.
- Подписание протоколов без замечаний о времени, участниках, носителях, способе копирования данных.
- Самовольное удаление репозитория, переписок, логов, что выглядит как уничтожение следов.
- Попытка «договориться» с заявителем/потерпевшим через сообщения, которые потом приобщат к делу.
- Конфликтная тактика в полиции: провоцирует жесткие меры и расширение проверки.
Что важно учитывать для защиты прав
По делам об IT и вредоносном коде исход часто решают: а) техническая экспертиза и корректность поставленных вопросов; б) цепочка сохранности цифровых данных (как получены, кем копированы, где хранились); в) сопоставление аккаунтов и личности (кто именно имел доступ); г) доказанность умысла на причинение вреда или распространение инструмента для вреда. Защита выстраивает позицию защиты так, чтобы каждое утверждение проверялось документами: история коммитов, лицензия, дисклеймеры, issue-трекер, отсутствие извлечения выгоды, отсутствие связи с конкретными атаками. Если следствие использует скриншоты и «распечатки», поднимаем вопрос об их допустимости и первоисточнике.
Практические рекомендации адвоката
- Уточните, кто вызывает и в каком статусе: требуйте повестку/официальное уведомление и предмет вызова.
- До явки не обсуждайте детали по телефону и в мессенджерах; не пишите объяснений «в черновиках» для отправки.
- Идите с адвокатом: он зафиксирует процессуальные нарушения, задаст рамки вопросов, заявит ходатайства.
- Ничего не подписывайте, не прочитав: вносите замечания в протокол, требуйте копии.
- Не давайте добровольно пароли и доступ к аккаунтам без оценки рисков; любые «добровольные» действия должны быть осознанны.
- Соберите пакет контекста: ссылки на репозиторий, историю изменений, дисклеймеры, научные/учебные цели, переписку по разработке, подтверждения отсутствия монетизации.
- Если изымают технику — добивайтесь процессуально корректного копирования, описания носителей, опечатывания и постановки вопросов эксперту.
Вывод
Когда вы выложили исходники шифровальщика на GitHub и вас вызвали в полицию, задача — не «доказать, что вы хороший», а юридически правильно управлять квалификацией, доказательствами и трактовкой умысла. Ранняя защита часто решает, будет ли это проверка с отказом в возбуждении дела, переквалификация на менее тяжкий эпизод или полноценное обвинение.
Какая у вас ситуация: вы автор кода, сделали форк или просто публиковали пример для учебы — и что именно указано в повестке/сообщении о вызове?
Информация актуальна по состоянию на май 2026.