Если изменить код но не скомпилировать его измениться ли файл exe
Обновлено: 07.07.2024
Вам когда-нибудь нужно было отлаживать или профилировать исполняемый файл (файл .exe), для которого у вас нет исходного кода или вы не можете его собрать? Тогда наименее известный тип проекта Visual Studio, проект EXE, для вас!
В Visual Studio вы можете открыть любой EXE-файл как «проект». Просто перейдите в Файл -> Открыть -> Проект/Решение и перейдите к файлу .exe . Как если бы это был файл .sln . Visual Studio откроет этот EXE-файл как проект. Эта функция существует уже давно. Она работает на всех поддерживаемых в настоящее время версиях Visual Studio, и документация по ней находится на странице Отладка приложения, которое не является частью решения Visual Studio.
Отладка
Как и в обычном проекте, вы можете начать отладку с помощью F5, которая запустит EXE и подключит отладчик. Если вы хотите отладить запуск, вы можете запустить с помощью F11, который запустит EXE и остановится на первой строке пользовательского кода. Оба эти параметра доступны в контекстном меню для проекта EXE в окне Solution Explorer, как показано ниже:
Для отладки понадобятся символы, файлы PDB, для EXE и любых DLL, которые нужно отладить. Visual Studio будет следовать тому же процессу и попытается получить символы также, как и при отладке обычного проекта. Поскольку маловероятно, что файлы PDB были распространены вместе с EXE-файлом, возможно, вы захотите найти их в сборке или, что еще лучше, на сервере символов. Дополнительную информацию и рекомендации по использованию символов можно найти в этом блоге.
Для эффективной отладки вам также понадобится исходный код, который использовался для сборки EXE, или даже для нескольких файлов, которые вас интересуют. Вам нужно найти эти файлы и открыть их в Visual Studio. Если исходный код не совпадает с исходным кодом, который был собран, EXE Visual Studio предупредит вас, когда вы попытаетесь вставить точку останова, и точка останова не будет привязана. Это поведение может быть изменено в окне Settings peek window. В окне просмотра параметров щелкните текст ссылки Must match source, а затем установите флажок, чтобы разрешить несоответствующий источник, как показано ниже. Конечно, с несоответствующим источником вы никогда не знаете, что произойдет, так что используйте это только на свой страх и риск.
Если EXE был собран с SourceLink, то информация об источнике будет включена в PDB, и Visual Studio попытается загрузить источник автоматически. Это действительно хорошая причина использовать SourceLink с вашими проектами. Даже если у вас есть локальный набор, у вас может не быть той версии, которая использовалась для сборки двоичного файла. SourceLink — ваш надежный способ убедиться, что правильный источник связан с правильным двоичным файлом.
Если вы не можете получить исходный код, у вас еще есть несколько вариантов:
Здравствуйте! Только что задался вопросом: можно ли изменить код уже скомпилированной программы(так чтобы она работала)? То есть, имея исполняемый файл, можно ли его открыть как текстовый документ и изменять(ну всё-таки исходные коды линковщиков и компиляторов есть же). Я понимаю, что после работы компилятора, си там уже не пахнет, но всё же, изучив структуру ехе файла - это можно сделать, или это полный бред?
Комментарии не предназначены для расширенной дискуссии; разговор перемещён в чат.Полностью исходный код программы конечно получить не возможно, но есть декомпиляторы которые его стараются восстановить, но получается из этого вырви-глаз и разбирать там не чего, а тем более редактировать. Насчёт редактирования ПО, это вам нужно изучить ассемблер (советую гуглить по запросу "реверс инжиниринг") и научиться таким программам как OllyDbg либо IdaPRO (платная и достаточно дороговатая) и потом уже делать патчи на те программы которые вы хотите, точнее редактировать. Но есть проблема в вашем вопросе, как вы хотите её редактировать, если просто дизайн, то вам достаточно и редактора ресурсов, которых OVER 9999+ в интернете как бесплатных(Resource Hacker), так и платных(Resource Tuner).
Через конкретно блокнот (или там Word) - нет, запорет он вам некоторые символы.
А вот hex-редактором - в принципе можно. А как, по-вашему, всякие ломалки работают? :) Именно так - меняя в нужных местах код/данные.
Только тут - как в том апокрифе со старшим Капицей, которому якобы обещали за границей 10000 марок за ремонт какой-то там установки. Он приехал, посмотрел, сказал ассистенту ударить молотком в таком-то месте - все заработало. За такую работу принимающей стороне сумма показалась слишком большой, попросили счет. Он выглядел так:
Удар молотком - 1 марка.
За то что знал, где ударить - 9999 марок.
Словом, чтоб знать, куда ударить и какие байты и как поменять - надо долго и упорно учиться :)
Поменять какие-то данные типа, чтоб не Hello world выводила, а типа Coolhacker :) - это попроще.
Все языки программирования делятся на два типа — интерпретируемые и компилируемые.
Интерпретаторы
Программируя на интерпретируемом языке, мы пишем программу не для выполнения в процессоре, а для выполнения программой-интерпретатором. Ее также называют виртуальной машиной.
Как правило, программа преобразуется в некоторый промежуточный код, то есть набор инструкций, понятный виртуальной машине.
При интерпретации выполнение кода происходит последовательно строка за строкой (от инструкции до инструкции). Операционная система взаимодействует с интерпретатором, а не исходным кодом.
Скомпилированные программы работают быстрее, но при этом очень много времени тратится на компиляция исходного кода.
Программы же, рассчитанные на интерпретаторы, могут выполняться в любой системе, где таковой интерпретатор присутствует. Типичный пример — код JavaScript. Интерпретатором его выступает любой современный браузер. Вы можете однократно написать код на JavaScript, включив его в html-файл, и он будет одинаково выполняться в любой среде, где есть браузер. Не важно, будет ли это Safari в Mac OS, или же Internet Explorer в Windows.
Компиляторы
Компилятор — это программа, превращающая исходный текст, написанный на языке программирования, в машинные инструкции.
По мере преобразования текста программы в машинный код, компилятор может обнаруживать ошибки (синтаксиса языка, например). Поэтому все проблемы забытых точек с запятыми, забытых скобок, ошибок в названиях функций и переменных в данном случае решаются на этапе компиляции.
При компиляции весь исходный программный код (тот, который пишет программист) сразу переводится в машинный. Создается так называемый отдельный исполняемый файл, который никак не связан с исходным кодом. Выполнение исполняемого файла обеспечивается операционной системой. То есть образуется, например,.EXE файл.
Примеры компилируемых языков: C, C++, Pascal, Delphi.
Препроцессинг
Эту операцию осуществляет текстовый препроцессор.
Исходный текст частично обрабатывается — производятся:
- Замена комментариев пустыми строками
- Подключение модулей и т. д. и т. п.
Компиляция
Результатом компиляции является объектный код.
Объектный код — это программа на языке машинных кодов с частичным сохранением символьной информации, необходимой в процессе сборки.
Компоновка
Компоновка также может носить следующие названия: связывание, сборка или линковка.
Это последний этап процесса получения исполняемого файла, состоящий из связывания воедино всех объектных файлов проекта.
EXE файл.
Заходим в Сервис -> Настройки -> Опции компиляции. Поверяем, стоит ли галочка напротив 2 пункта. Если стоит, то убираем ее.
Теперь откройте свою программу и запустите ее.
Откройте директорию, в которой у вас лежит исходный код программы.
Кликаем по приложению. Как вы видите, после ввода данных, окошко сразу закрывается. Для того чтобы окно не закрывалось сразу, следует дописать две строчки кода, а именно: uses crt (перед разделом описания переменных) и readkey (в конце кода, перед оператором end).
Подключаем внешнюю библиотеку crt и используем встроенную в нее функцию readkey.
Теперь окно закроется по нажатию любой клавиши.
Среда разработки включает в себя:
- текстовый редактор;
- компилятор;
- средства автоматизации сборки;
- отладчик.
На сегодня все! Задавайте любые вопросы в комментариях к этой статье. Не забывайте кликать по кнопочкам и делится ссылками на наш сайт со своими друзьями. А для того, чтобы не пропустить выход очередной статьи, рекомендую вам подписаться на рассылку новостей от нашего сайта. Одна из них находится в самом верху справа, другая — в футере сайта.
Я только начал использовать Qt Creator 3.5.0, Qt 5.4.2 с GCC на Kubuntu 15.10. Я создал новый проект, добавил окно, и в настоящее время я пытаюсь разработать новый модуль.
Однако странные вещи случаются.
Я написал отладочную строку вывода в своем шаблонном классе X. Эта строка находится в функции класса X в заголовке его модуля, например:
После сборки и запуска приложения эта строка выполняется, и «Hello1» печатается в консоли отладки по желанию. Также я могу использовать отладчик и шаг за шагом. При создании приложения компилятор практически ничего не делает, поскольку файл кода не был изменен (как и ожидалось).
При редактировании вышеприведенной строки все идет наперекосяк:
- Я изменил строку на «Hello2» и сохранил файл кода.
- Я мог видеть правильно обновленную дату / время изменения файла исходного файла, и я убедился, что файл новее, чем соответствующий объектный файл.
- При сборке проекта компилятор фактически скомпилировал отредактированный исходный файл и связал приложение, как и ожидалось. Я проверил дату / время обновленного файла объекта и дату / время исполняемого файла обновления.
- Однако при запуске приложения поведение НЕ изменилось! Выход по-прежнему «Hello1».
- При поиске в исполняемом файле с помощью бинарного редактора я все еще вижу только старую строку «Hello1». Нет другой строки, содержащей «Hello».
- После повторного выполнения вышеизложенного (изменения строки на «Hello3») все еще выводится «Hello1».
- При перестройке всего приложения или после очистки проекта изменение вступает в силу один раз.
- Проблема воспроизводима каждый раз при каждом редактировании.
- Я не мог наблюдать это с любым другим модулем, это случается только с этим одним исходным модулем, который, кажется, существенно не отличается.
- Как уже упоминалось, строка кода находится в заголовке модуля. Но изменение самого модуля ничего не меняет.
- Изменение класса X и второго модуля одновременно ничего не меняет (изменение во втором модуле вступает в силу, изменение в классе X не оказывает влияния).
- И заголовок, и модуль были правильно добавлены в файл .pro.
- Перезапуск QtCreator ничего не меняет.
- Это происходит с и без отладчика.
- Правила make-файла для модуля класса X выглядят разумно и не отличаются от правил других модулей.
Я понятия не имею, как это возможно. Может быть, я пропустил что-то очевидное. Есть идеи?
ОБНОВИТЬ:
Используя системный монитор, я мог подтвердить, что запущенный процесс использует ожидаемый исполняемый файл.
Решение
Проверьте, какой exe отладчик на самом деле работает. Это может быть еще одна копия! Посмотрите на список процессов, чтобы узнать наверняка какой EXE находится под отладчиком.
Этот общий вопрос произошел по разным причинам в моем личном опыте. Файлы копируются в область установки / размещения; окружающая среда затеняет вещи; неправильный проект настроен на «запуск»; способ запуска компонента при запуске сеанса отладки в конечном итоге приводит к неправильному файлу; неправильная конфигурация или вкус меняется; и т.п.
Правило 1: проверьте свои предположения. Вы проверили даты файлов и т. Д., Но добавили к этому проверку того, какой файл (полный путь) фактически находится под отладчиком.
Другие решения
Вы можете попробовать некоторые вещи:
Похоже, что он компилирует последнюю «версию» вашего кода и не применяет изменения по некоторым из этих причин и по другим причинам (если я подумаю, я отредактирую пост позже).
Я тоже столкнулся с этой проблемой. Я смог решить это путем очистки (в моем случае работает catkin clean ), а затем восстановить его ( catkin_make ).
К сожалению, я не смог выяснить точную причину проблемы, но, надеюсь, у кого-то более знающего есть идея.
Кроме того, моя среда разработки отличается (Ubuntu 14.04, Qmake 3.1, Qt 5.9.1, gcc 4.8.4, инструменты catkin 0.4.4, Qt Creator и т. Д.), Поэтому, очевидно, мое исправление может работать не для всех.
Проблема все еще существует в Qt 5.8:
Эта проблема продолжает возникать в Qt 5.8 с использованием clang, сборка 64-битной версии для OSX, под OSX изнутри Qt Creator. Так что это не проблема GCC.
Решение:
Мне удалось получить зависимые компиляции, чтобы правильно реагировать на изменения во вновь добавленном заголовочном файле:
- Очистка проекта
- Запуск QMake
- Восстановление всего проекта.
Проверки:
Перед тем, как выполнить вышеизложенное, я проверил файл проекта и убедился, что новый файл был указан в HEADERS раздел (это было.) Несмотря на это, Qt не будет перестраивать файл, содержащий .h файл.
Читайте также: