Лично я бы начал с ltrace программы с любым произвольным набором аргументов. Затем я бы использовал команду strings и на этом угадал, какими могут быть некоторые из скрытых литералов аргументов. (Предположим, на данный момент, что профессор не зашифровал и не запутал строки и что они появляются в двоичном виде как литералы). Затем повторите попытку с одним или двумя (или нужным номером, если номер).
Если вам повезет, программа была скомпилирована и предоставлена вам без запуска strip. В этом случае вам может помочь таблица символов. Тогда вы можете попробовать пошагово пройти программу (см. gdb руководства). Это может быть утомительно, но есть способы установить точку останова и сказать отладчику выполнить некоторый вызов функции (например, любой из стандартных библиотек) и остановиться по возвращении. Делая это несколько раз (определите, где вызывается стандартная или внешняя библиотека, установите точку останова для следующей инструкции после возврата, позвольте gdb запустить процесс через вызов, а затем проверьте, что делает код, кроме этого.
В сочетании с ltrace должно быть довольно легко увидеть последовательность вызовов strcmp() (или аналогичных). Когда вы видите строку, с которой сравнивается ваш ввод, вы можете разорвать весь процесс и повторно вызвать gdb и программу с этим одним аргументом, проследить до следующего и так далее. Или вы можете изучить более продвинутые трюки gdb и изменить вектор аргументов и перезапустить main() с нуля.
На самом деле это звучит забавно, и я мог бы попросить мою жену сделать простой бинарный файл, чтобы я мог это примерить. Также может быть создана небольшая программа для генерации двоичных файлов такого рода. Я подумываю о небольшом #INCLUDE в источниках, который предоставляет «парольную фразу» аргументов, и файл make, который выбирает от трех до пяти слов из / usr / dict / words, генерирует этот файл #INCLUDE из шаблона, затем компилирует двоичный файл, использующий эту последовательность.