Невозможно ответить определенным Да или Нет.
Я предполагаю, что вы будете хранить данные в конце вашего исполняемого файла вместо сохранения состояния программы в файле конфигурации. Я также предполагаю, что вы делаете это для удовольствия , и конечный результат не должен быть идеальным.
Любой механизм подписи кода , который может быть установлен на вашей платформе, будет недоволен такими хитростями. Подписи будут действительны только в том случае, если исполняемый файл существенно не изменится. (По крайней мере, в механизме подписи кода , который я помогал реализовать , криптографическая подпись вычислялась по всему содержимому исполняемого файла - за исключением самой подписи - не только сегментов, помеченных как исполняемые файлы или данные в заголовках программы.)
Любые антивирусные механизмы, которые могут быть задействованы на вашей платформе, будут нарушать эти хитрости. Самомодифицирующийся код определенно связан с программами, пытающимися остаться скрытыми или неясными, а код, который пишет сам себе, будет вызывать сигналы тревоги в поведенческих антивирусных инструментах.
Такие инструменты, как tripwire или mtree всегда будут жаловаться на вашу программу. rpm -qa или debsums всегда будут сообщать о проблемах с вашим исполняемым файлом. Будет трудно надежно перенести эту программу с сайта на сайт.
Разрешения на стандартные исполняемые файлы в большинстве сред полностью запрещают такое поведение. Учетные записи пользователей не имеют прав на изменение большинства исполняемых файлов в системе - также могут быть написаны только исполняемые файлы , принадлежащие пользователю, который будет запускать исполняемый файл. (И даже тогда система обязательного контроля доступа , такая как AppArmor , SELinux , TOMOYO или SMACK мог бы запретить процессу запись в файл программы, если он правильно настроен. И почти любой разумный профиль безопасности запретил бы это.)
Ни один системный администратор не разрешил бы двум пользователям выполнить и записи в исполняемый файл.
У вас также есть прагматическая проблема в первую очередь найти исполняемый файл . По крайней мере, Linux предоставляет /proc/self/exe, но (a) системные администраторы могут не смонтировать его (b) системные администраторы могут не позволить большинству процессов использовать it (c) при замене исполняемого файла во время выполнения программы выполнение поиска нужного файла для изменения может быть затруднено.
Вы должны выбрать один из двух способов обновления исполняемого файла: либо изменить существующий файл (ftell(3) и fseek(3)), либо записать измененное содержимое в новый файл и замените исполняемый файл. Оба подхода проблематичны: если вы изменяете файл, у вас может быть несколько копий, выполняющихся одновременно, пытаясь записать конфликтующие правки в файл. Умное программирование может избежать огромных проблем, но весь исполняемый файл может не находиться в согласованном состоянии. Если вы замените файл, у вас может быть несколько копий, выполняющихся одновременно, и копии исполняемого диска на диске могут быть не освобождены и фактически удалены до тех пор, пока система не будет перезагружена. Вы можете иметь дюжину копий исполняемого файла программы, незаметно занимающих место на диске. Ни один из них не мог совместно использовать память во время выполнения, увеличивая нагрузку на память.
Да, можно сохранить данные конфигурации в исполняемом файле программы и даже заставить его работать в некоторых средах. Но это не качество продукции.