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

Беспалевное редактирование реестра?

Encommerce

(L3) cache
Пользователь
Регистрация
25.11.2022
Сообщения
235
Реакции
97
Нужно реализовать защиту от повторного запуска
В идеале, конечно, и от повторного запуска, но это второстепенно

Реестр кажется наиболее простым решением, но в тоже время может доставить множество проблем, на сколько я могу судить

Алгоритм видится так:
1. Пограмма запускается и создает ключ в HKEY_CURRENT_USER/Software
2. После окончания работы задается значение, свидетельствующие о завершении

При повторном запуске проверяется наличие этого значения
В случаее если оно есть, процесс прерывается

Выглядит костыльно, с правами юзер нельзя удалять и менять значения, на сколько могу судить
Также непонятно и отношение антивирусов к таким манипуляциям

Может не в том направлении вообще двигаюсь?

Буду очень благодарен, если кто-то даст наводку)
 
Пожалуйста, обратите внимание, что пользователь заблокирован
с правами юзер нельзя удалять и менять значения, на сколько могу судить
С правами юзера можно создавать, удалять и менять значения в ветке HKCU.

Также непонятно и отношение антивирусов к таким манипуляциям
Смотря какой ключ, но в целом не должно быть плохо оценено, куча легитимного софта это делает.

Может не в том направлении вообще двигаюсь?
Ну если тебе вообще все любые повторные запуски нужно исключить, то почему бы нет? Оставь любой уникальный артефакт в том месте, где маленькая вероятность, что пользователь его удалит, да и все.
 
Смотря какой ключ, но в целом не должно быть плохо оценено, куча легитимного софта это делает.
А могут ли быть сигнатурные детекты со временем, если не менять назвния создаваемых ключей, нпример?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
А могут ли быть сигнатурные детекты со временем, если не менять назвния создаваемых ключей, нпример?
Напрямую зависит от распространенности, наверное, имеет смысл либо менять название ключа при каждой новой сборке, или генерировать его от каких-то параметров железа или операционной системы, которые обычно не изменяются.
 
Почему не через мьютексы?
А так если ключ по каким-то причинам останется (хард резет компа, краш и т.д.), то больше софт не запустится.
 
Я так понимаю тут мьютексы не подойдут, так как ТС нужно чтоб программа больше вообще не запускалась.
От повторного запуска может защитить проверка предидущего результата работы программы.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Нужно реализовать защиту от повторного запуска
В идеале, конечно, и от повторного запуска,
?
 
Есть более простые варианты для защиты от повторного запуска:
1) Проверка на серве. Билд стучит на гейт отправляя уникальный id пк, на серве идёт проверка на наличие этого id, далее ответ билду с наличием id в бд.
2) Создание файла с определённым именем \ расширением \ датой. Про последнее, как вариант создать файл с рандомным именем в одном из директорий и программно изменить дату создания на заранее захардкоженную
3) Изменение даты своего файла (так же заранее прописанную) после завершения основных функций, почти тоже самое что и второй вариант, но уже без содания других файлов
4) Самый простой: удалить билд после выполнения основных функций

А могут ли быть сигнатурные детекты со временем, если не менять назвния создаваемых ключей, нпример?
если не шифруешь \ обфусцируешь строки, то конечно будут
 
?
Ха, шизофрения)))0)
Я хотел сказать от параллельного выполнения

Есть более простые варианты для защиты от повторного запуска:
1) Проверка на серве. Билд стучит на гейт отправляя уникальный id пк, на серве идёт проверка на наличие этого id, далее ответ билду с наличием id в бд.
2) Создание файла с определённым именем \ расширением \ датой. Про последнее, как вариант создать файл с рандомным именем в одном из директорий и программно изменить дату создания на заранее захардкоженную
3) Изменение даты своего файла (так же заранее прописанную) после завершения основных функций, почти тоже самое что и второй вариант, но уже без содания других файлов
4) Самый простой: удалить билд после выполнения основных функций


если не шифруешь \ обфусцируешь строки, то конечно будут
Проверка на стороне сервера была бы идеальным решением, но в моем случае нужна надежная проверка локально, в случае, если сервер не доступен или не используется.
Сейчас пришла мысль о том, что можно совместить эти два подхода.

Последний пункт тоже очень интересен. Не совсем понимаю, как можно удалить бинарник автоматически, не прибегая к костылям)
 
От тупого юзера или от реверсера
Я думаю от автоматического действия в этом случае, например распаковки софта, а так не знаю
 
Последний пункт тоже очень интересен. Не совсем понимаю, как можно удалить бинарник автоматически, не прибегая к костылям)
1) Создать задачу через планировщик
2) Вариант с cmd - создаёшь процесс cmd с аргументами, завершаешь основной процесс, в cmd передаёшь команду пинга на любой хост, во второй команде ставишь удаление своего файла. Получается билд отработает, запустит cmd, завершит свой процесс, cmd в это время пропингует рандомный хост, и удалит твой файл.

Написал что первое в голову пришло, есть ещё пару менее костыльных методов, но нужно вспоминать)
 
команду пинга на любой хост
дополню, например на скрипт на гитхабе, который ты можешь удалить:)
 
От кого предполагается защита? От тупого юзера или от реверсера?
Защита только от повторного выполнения при добавлении в автозапуск (вернее даже выполнение, в случае, если требуемые цели не достигнуты), на реверсеров плевать в данном случае.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Защита только от повторного выполнения при добавлении в автозапуск
Мьютекс не дает запустить 2 и больше копии программ.
Атом живет до перезапуска ОС.
 
Защита только от повторного выполнения при добавлении в автозапуск (вернее даже выполнение, в случае, если требуемые цели не достигнуты), на реверсеров плевать в данном случае.
Создавай свой ключ в ветке HKCU\Software, и в нём храни нужную конфигурацию (например, запускался ли твой билд раннее), так делает почти весь легальный софт и аверы точно будут молчать. А если задача в том, чтобы не допустить существования двух копий одновременно, используй мьютексы либо локфайлы, в случае с первыми нужно будет генерить уникальные названия для каждого хоста, дабы аверы не влепили детект.
 
переменные окружения SetEnvironmentVariable до перезагрузки, но возможно и персистентно наверное по типу как питон например создает
 


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