Протокол отладчика


Содержание

Протокол отладчика

Протокол отладчика PHP 3 является построчным. Каждая строка состоит из типа и нескольких строк, составляющих сообщение . Каждое сообщение начинается строкой, имеющей тип start и завершается строкой, имеющей тип end . PHP 3 имеет возможность одновременной посылки строк, предназначенных для разных сообщений.

Каждая строка имеет следующий формат:

дата время
хост ( pid )
тип :
данные сообщения

Дата в формате ISO 8601 ( гггг — мм — чч )

Время с указанием микросекунд: чч : мм : мсмсмс

Имя DNS или IP адрес хоста, на котором возникла ошибка при выполнении скрипта.

P >хосте , в процессе работы которого возникла ошибка в скрипте PHP 3.

Тип строки. Сообщает принимающей программе, как та должна интерпретировать последующие данные:

Унифицированный протокол отладчика

На рынке поддержки языков однако появился выбор хоть и скудный, протоколов взаимодействия с ide, это у нас как минимум lsp и ycmd. Оба, кстати, по странному капризу природы используют json rpc в качестве одного из уровней. При этом спецификацию вменяемую имеет только поделка от microsoft.

А, может кто в курсе — есть ли чего на рынке отладчиков? Пока, из увиденного, с большой натяжкой на этот приз претендует xdebug. Но, gdb в него толком не умеет, да и фронтэндов не так уж и много, видимо не сильно проще оно gdb-mi, что бы имело смысл делать унифицированное решение, shim так сказать.

Upd, конечно же не xdebug, а dbgp.

будь мужиком, напиши сам

Не, я слишком дно.

Видимо отсутствие спецификации на такой протокол и есть причина скудного количества морд к gdb/lldb. А те что есть, глючат через раз.

Об чём и речь. Но, вот например dbgp — незаслуженно проигнорирован, так же как, до недавнего времени, игнорировались протоколы для коммуникации со средствами поддержки языка программирования.

ycmd — появился довольно давно, однако, крупные вендоры идею подхватили довольно недавно. Посмотрев на отладчик в eclipse che, я понял, что этим типам не хватает lsp, только для отладчика:)

Поэтому решил опросить достаточно разношёрстное население лора, вдруг кто видел подобные работы, более свежие, и может быть с чуть более продуманным интерфейсом чем dbgp.

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

Это как стандарт на манглинг имен в C++ — кто во что горазд.

Его как минимум плотно юзает Xilinx, пишут что

«By replacing a gdb based debugger with TCF, Xilinx has increased the performance of basic debugger commands up to 50 times, while providing a much more stable product.»

По результатам использования на ARM — действительно сильно лучше gdb

Обидно признавать, но, похоже авторы lsp и тут грамотно подошли к вопросу, просто остальные вендоры этого не поддержали. Правда что-то не видать самой спеки.

Отладка программ с использованием отладчика.

При использовании интегрированной среды программирования предоставляется удобный интерфейс, позволяющий легко отлаживать разрабатываемую программу. В настоящее время стандартом де-факто стал интерфейс, похожий на программную оболочку Visual C.

Встроенный программный отладчик, входящий в состав интегрированной среды программирования не позволяет проконтролировать работу аппаратуры, подключенной к внешним ножкам микроконтроллера, но значительно удешевляет отладочный комплекс, необходимый для написания программ для микроконтроллеров. Сигналы, которые должна подавать на микроконтроллер аппаратура задаются самим программистом (а значит уже на этом этапе возможно возникновение ошибок из-за неправильного понимания работы аппаратуры). Ручной ввод этих сигналов значительно замедляет процесс отладки программного обеспечения.

Внешний программный отладчик. В некоторых случаях используется не интегрированная среда программирования, а отдельный транслятор с выбранного языка программирования. В этом случае можно воспользоваться любой программой, эмулирующей выбранный тип микроконтроллера. Так как объектные форматы различных трансляторов несколько отличаются друг от друга, то в качестве входного файла используется загрузочный модуль в двоичном или гексадецимальном формате. В этих форматах отладочная информация полностью отсутствует, поэтому отладку в таких программах можно вести только с помощью встроенного дизассемблера и распечатанного (или открытого в другом окне) листинга программы. Естественно, что это ещё более неудобный способ отладки по сравнению с использованием интегрированной среды программирования и внутрисхемного эмулятора.

Программирование микросхемы. При использовании любого способа отладки программы, готовый загрузочный модуль записывается во внутреннюю память программ микроконтроллера при помощи программатора (который входит в состав многих современных микросхем микроконтроллеров). После этого ведётся тщательное тестирование разработанного устройства с целью обнаружения ошибок в схеме и программе этого устройства. Только после успешного прохождения этого тестирования программа считается полностью написанной и отлаженной.

При написании достаточно простых программ иногда для отладки программ используют только этот последний этап тестирования. Однако обнаружение, поиск и устранение ошибок при использовании только этого метода очень трудоёмок! Это то же самое, что пытаться настроить аппаратуру без использования приборов!

Способы отладки программ.

Отладка программ заключается в проверке правильности работы программы и аппаратуры. Программа, не содержащая синтаксических ошибок тем не менее может содержать логические ошибки, не позволяющие программе выполнять заложенные в ней функции. Логические ошибки могут быть связаны с алгоритмом программы или с неправильным пониманием работы аппаратуры, подключённой к портам микроконтроллера.

Встроенный в состав интегрированной среды программирования отладчик позволяет отладить те участки кода программы, которые не зависят от работы аппаратуры, не входящей в состав микросхемы микроконтроллера. Обычно это относится к вычислению математических выражений или преобразованию форматов представления данных.

Для отладки программ обычно применяют три способа:

1. Пошаговая отладка программ с заходом в подпрограммы;

2. Пошаговая отладка программ с выполнением подпрограммы как одного оператора;

3. Выполнение программы до точки останова.

Пошаговая отладка программ заключается в том, что выполняется один оператор программы и, затем контролируются те переменные, на которые должен был воздействовать данный оператор.

Если в программе имеются уже отлаженные подпрограммы, то подпрограмму можно рассматривать, как один оператор программы и воспользоваться вторым способом отладки программ.

Если в программе существует достаточно большой участок программы, уже отлаженный ранее, то его можно выполнить, не контролируя переменные, на которые он воздействует. Использование точек останова позволяет пропускать уже отлаженную часть программы. Точка останова устанавливается в местах, где необходимо проверить содержимое переменных или просто проконтролировать, передаётся ли управление данному оператору.

Практически во всех отладчиках поддерживается это свойство (а также выполнение программы до курсора и выход из подпрограммы). Затем отладка программы продолжается в пошаговом режиме с контролем локальных и глобальных переменных, а также внутренних регистров микроконтроллера и напряжений на выводах этой микросхемы.

Контроль данных при пошаговой отладке. При использовании встроенного отладчика программ для контроля переменных можно воспользоваться окном Watch. В большинстве случаев это намного выгоднее, чем использовать просмотр памяти данных. Переменные в этом окне отображаются в том формате, в котором они были объявлены в программе. Преобразование данных из одной формы представления в другую осуществляется встроенными средствами отладчика. Если же отладочная информация по какой либо причине была потеряна или программирование ведётся на языке программирования ассемблер, то состояние переменных можно проконтролировать просмотром содержимого внутренней и внешней памяти микроконтроллера. Для определения конкретной ячейки памяти микроконтроллера, занятой под переменную можно воспользоваться листингом, создаваемым редактором связей компилятора или самим компилятором, если не используется многомодульное программирование.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: На стипендию можно купить что-нибудь, но не больше. 8989 — | 7235 — или читать все.

Режим отладки 1С сервера или как включить Debug

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

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

Из официальных источников мы имеем следующую информацию:

Выдержка из документа «Клиент-серверный вариант. Руководство администратора»

/debug

Запуск кластера серверов в режиме отладки конфигураций. Параметр указывает, с использованием какого протокола будет функционировать отладчик на данном кластере серверов:

  • -tcp ‑ протокол TCP/IP;
  • -http ‑ протокол HTTP.

Значение по умолчанию: -tcp.

СОВЕТ. В связи с тем, что в режиме отладки производительность сервера падает, рекомендуется использовать отладочный режим только для тех серверов, на которых выполняется отладка.

ВАЖНО! Выдержка взята с сайта its.1c.ru.

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

Допустим, ты отвечаешь за ИТ инфраструктуру и к тебе подходит программист 1С, чтобы попросить запустить 1С в режиме отладки.

Поздравляю! Программист 1С не является доменным администратором и не смог произвести настройку самостоятельно. Вопросы безопасности и чувства самосохранения не на последнем месте.

1С в серверном варианте требует комплексного подхода, который достигается наличием достаточных компетенций у специалистов из разных направлений – программист 1С, системный администратор, администратор баз данных.

И когда речь уже заходит об отладке приложения, универсальные солдаты «тыжсисадмин» и «тыжпрограммист» уже не актуальны. На данном уровне навыки для системного администратора и программиста 1С сильно разнятся и совмещать их, оставаясь профессионалом с большой буквы «П», уже невозможно.

Как запустить сервер 1С в режиме отладки правильно?

По умолчанию служба агента сервера 1С запускается без режима отладки, так как он уменьшает скорость работы в программе.

Есть несколько вариантов, но рассмотрим самый ходовой – изменение значения параметра реестра Windows.

Открываем реестр на сервере, где установлен сервер 1С.

Переходи по следующему пути:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent (x86-64)

Имя раздела может отличаться в зависимости от версии сервера 1С – 8.2 / 8.1 или его архитектуры – 32 / 64 битный.

Здесь нас интересует параметр ImagePath, а точнее его значение, которое и надо дополнить ключом «debug».

ПРИМЕЧАНИЕ! В разных статьях указаны различные варианты запуска режима отладки и это может ввести в заблуждение. Ключ «debug» можно добавлять в любое место после «C:\Program Files\1cv8\8.3.13.1644\bin\ragent.exe» и использовать как знак «-», так и «/».

Например, будут одинаково работать:

«C:\Program Files\1cv8\8.3.13.1644\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d «C:\Program Files\1cv8\srvinfo» -debug

«C:\Program Files\1cv8\8.3.13.1644\bin\ragent.exe» /debug -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d «C:\Program Files\1cv8\srvinfo»

Первый вариант смотрится предпочтительней.

На выходе должно получиться следующее:

Перезапускаем службу «Агент сервера 1С:Предприятия 8.3 (x86-64)».

Поздравляю – режим отладки включен!

Осталось проверить его работу.

Самый простой способ проверки работы режима отладки 1С на сервере

Если платформа 1С для проведения отладки будет запускаться не на сервере 1С, на стороне клиента должны быть открыты TCP и UDP порты для диапазона 1560-1591.

На стороне сервера должны быть открыты TCP порты 1540, 1541, 1560-1591.

ПРИМЕЧАНИЕ! Эти порты устанавливаются по умолчанию, если вы их меняли, то в фаерволе надо будет открыть новые.

Проверяем работу отладчика:

  1. Запускаем конфигуратор.
  2. Заходим в меню «Отладка» — «Начать отладку» или нажимаем клавишу «F5». Запустится платформа 1С в режиме предприятия.
  3. Не закрывая 1С предприятие, переходим в меню «Отладка» — «Подключение…».

Если столбец «Тип» заполнен значением «Сервер», то всё работает. Идём писать письмо программисту 1С.

ПРИМЕЧАНИЕ! Если сервер и клиент – не один сервер, ставим галочку «Искать предметы отладки на удаленном компьютере»: и указываем сервер 1С.

В блоке «Доступные предметы отладки:» столбец «Тип» должен быть заполнен значением «Сервер». Если у вас так, то всё работает.

Арендуя сервер для 1С в компании МАРС Телеком, вы всегда сможете получить помощь наших технических специалистов по этому и другим вопросам.

В помощь веб-разработчику: полезные проекты и инструменты для работы с Chrome DevTools

Работу современного веб-разработчика сложно представить без вспомогательных инструментов. Один из самых популярных — Chrome DevTools. Этот набор инструментов помогает тестировать, отлаживать, профилировать, проверять код на соответствие тем или иным стандартам и многое другое.

Подборка содержит ссылки на множество проектов, которые будут полезны тем, кто работает с инструментами разработчика Chrome. Думаете, что чего-то не хватает? Делитесь в комментариях.

Инструменты и экосистема

Форматирование объектов

  • immutable-devtools — настраиваемое форматирование для Immutable.js.
Илон Маск рекомендует:  Что такое код ftime

Проверка сети

  • betwixt — анализ трафика в отдельном окне вне браузера с использованием интерфейса, похожего на вкладку Network инструментов разработчика.

Профилирование процессора

  • call-trace — позволяет записать граф вызовов и (опционально) время, потраченное на выполнение каждой функции JS-файла. Есть возможность генерации файла .cpuprofile .
  • cpuprofilify — преобразует выходные данные разных профилировщиков в формат .cpuprofile .

Временные графики, трассировка и профилирование

  • DevTools Timeline Viewer — делитесь ссылками на записи временных графиков.
  • snapline — преобразует снимки временного графика в gif.

Интеграция отладчика Chrome с >

VS Code – Debugger for Chrome

  • Sublime Web Inspector — отладка JavaScript прямо в Sublime Text.
  • WebStorm & JetBrains Chrome Extension — позволяет WebStorm отлаживать JavaScript, просматривать дерево DOM и редактировать HTML, CSS и JS на лету.

Протокол Chrome DevTools

Протокол Chrome DevTools позволяет сторонним приложениям отслеживать, профилировать и отлаживать код в Chromium, Chrome и других Blink-based браузерах.

  • DevTools Protocol API Docs — документация по протоколу.
  • ChromeDevTools/devtools-protocol — багтрекер для проблем с протоколом.
  • Remote Debug Gateway — позволяет проводить отладку сразу в нескольких браузерах.
  • DevTools Backend — standalone-реализация бекенда инструментов разработчика Chrome для отладки произвольных веб-платформ вроде приложений HbbTV на Smart TV.
  • RemoteDebug — универсальные протоколы отладки для современных браузеров.
  • ChromeDriver — официальная реализация Selenium/WebDriver для Chrome, работающая на основе протокола инструментов разработчика.
  • Chrome Protocol Proxy — обратный прокси для отладки с помощью протокола инструментов разработчика.
  • Puppeteer — Node-библиотека, предоставляющая высокоуровневый API для управления Chrome или Chromium через протокол инструментов разработчика.

Изучаем отладчик, часть третья

Что такое отладчик, как им пользоваться и как он реализован, после прочтение первой и второй части статьи, вы знаете. В заключительной части статьи попробуем рассмотреть некоторые методы борьбы с отладчиком, на основе знаний о принципах его работы. Я не буду давать шаблонный набор антиотладочных приемов, благо при желании все это можно найти на просторах интернета, попробую это сделать немного другим способом, на основе некоего абстрактного приложения, у которого буду расширять код защиты от самой простейшей схемы до… пока не надоест :)

Сразу-же оговорюсь, в противостоянии приложение/отладчик, всегда победит последний :)
Но, только в том случае, если им будет пользоваться грамотный специалист, а с такими спецами бороться практически бесполезно (ну, если вы конечно не обладаете как минимум такой же квалификацией).

Правда как показывает практика, грамотные спецы не занимаются неинтересными им задачами, оставляя их на откуп начинающим реверсерам, которые еще не прогрызли свой гранит науки и могут спотыкаться на некоторых не очевидных трюках.

Вот что-то такое мы и рассмотрим, только в очень упрощенной форме.

Простейшая ShareWare:

Представим, у нас есть некое ПО, которое мы решили продавать. Для простоты пусть это будет обычное VCL приложение из пустой формы (ну хорошо, пусть не пустое, а с картинкой на всю морду) и мы хотим его продать. Первый же вопрос, которым нужно озаботится — как сделать так, чтобы наша картинка был видна только тем, кто за нее заплатил? Точнее — как разграничить триальных и легальных пользователей?

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

Создаем новое VCL приложение, кидаем на форму TImage с картинкой, Visible ему выставляем в False. После чего размещаем на форме два TEdit, первый для имени пользователя и второй для кода активации. Ну и две кнопки — закрыть приложение и активировать.

Ну вот как-то так:

После чего пишем «совершенно секретный» код активации:

Суть кода в следующем:
на основании имени пользователя приложение генерирует некий серийник и сравнивает его с введенным пользователем. Если все нормально, то убираются все элементы управления, отвечающие за активацию и отображается картинка, которую и жаждал узреть пользователь.

(ну… первое что нашел :)

После произведенных манипуляций, «это» публикуется на различных шароварных сайтах и даже иногда даются ссылки на программерские форумы в топиках вида: «потестируйте плз защиту».

А как это выглядит со стороны взломщика?

Он берет отладчик (для простоты возьмем тот-же Olly Debug) и видит вот такую картинку:

Кода приложения у него нет, но есть характерная ошибка начинающих «защитников» ПО — вывод диалога о неверном ключе.

Что это дает взломщику?
Он ставит ВР на вызов MessageBoxA и запустив приложение ловит вызов данного сообщения, после чего, нажав на кнопку «ОК» он может вернуться к коду, в котором происходит вызов данной ошибки, где, посмотрев немного выше, сможет определить наличие условного перехода, на основании которого и происходит данный вызов:

На картинке точка принятия решения программой выделена восклицательными знаками.
Все что ему остается сделать, это исправить инструкцию JE на JMP, отключив, таким образом, проверку серийного кода и обеспечив валидный переход на область кода, который должен выполнятся только при активации приложения.

Как-то не понятно, да?

Ну тогда вот вам такая картинка, из отладчика Delphi:

Здесь код более понятен для отладки, и его чтение более удобно из-за размапливания адресов и приведения их в читабельный вид. Например теперь явно видно что перед выходом на адрес 0х475729, по которому происходит принятие решения, происходит получение текста из TEdit-ов и вызов процедуры GenerateSerial.

Взломщик такой информацией не обладает, и как видно на предыдущем изображении, ему придется проанализировать все вызовы, чтобы составить более-менее понятную для анализа картинку. Ну, правда, тут я немного утрирую, в действительности карта приложения строится достаточно просто, при наличии инструментария, но… Но некоторые иногда упорно стараются отлаживать системные модуля дельфи, таки честь им и хвала за упорство :)

Ну и нюанс, по адресу 0х475729 на скринах расположены две разные инструкции — JZ и JE, это нюансы интерпретации дизассемблеров, они идентичны.

Тут есть один интересный подход, который мне несколько раз озвучивали.
Вот чуть выше я озвучил что поставлю ВР на MessageBoxA, а мне говорят что вызовут MessageBoxW и вызов отловить не получится. Это заявление на твердую четверку с плюсом, ибо да, действительно, если приложение вызовет юникодную API, с бряком будет небольшой промах, но есть нюанс. А давайте-ка развернем весь стек вызова MessageBox.

Смотрите какая интересная схема получается:
MessageBoxA -> MessageBoxExA -> MessageBoxTimeOutA -> MessageBoxTimeOutW-> SoftModalMessageBox()

Таки да, мы можем поставить ВР на вызове любой из перечисленных функций (обычно достаточно MessageBoxTimeOutW) чтобы отловить необходимый нам вызов, ее кстати так же вызовет и функция MessageBoxW.

Есть правда небольшой нюансик, в Delphi есть и иные способы отображения окна.

Ну например ShowMessage(). Данный метод не вызывает API MessageBox.
Достаточно забавно слушать рассуждения, что данный метод целиком и полностью реализован в виде создания отдельной формы, в которой кнопки размещаются так как им надо и вообще это внутренности самого VCL из которых в отладчике вообще ничего не понятно.
Так-то оно так, кабы данный вызов не упирался в API ShowWindow, с которого по стеку мы так же выйдем на необходимый нам участок кода.

Есть еще вызовы диалогов, но с ними будет точно такая же кухня. Все это детектируется без сильных времязатрат.

Поэтому, делайте первый вывод в свой блокнотик:
Вызов сообщения о неуспешной проверке кода, сразу после данной проверки — есть признак дурного тона.

Вводим контроль целостности приложения:

Ну чтож — вот нас и взломали, причем сделав всего лишь изменение в одном единственном байте приложения. Теперь наша веселая картинка доступна всем абсолютно бесплатно.

Печально, но не критично — будем бороться…

Взлом произошел посредством прямой правки тела приложения.
Значит выросла задача: обеспечить проверку целостности исходного кода.

Звучит грозно, но в действительности практически не выполнимо :)

Вот что мы можем применить для данной проверки?
Есть много умных слов: навесить цифровую подпись, сверить с образом файла на диске, проверить участок кода с контрольной суммой. Все пустое — в итоге все равно приходим к необходимости каким либо образом получить текущее значение кода приложения в памяти…

Ну хорошо: смотрим цифровую подпись. Она, во первых, платная. Во вторых проверка ее производится путем вызова API функции WinVerifyTrust, которая уязвима к перехвату. В третьих она легко удаляется штатными средствами через ImageRemoveCertificate.

Значит не вариант, что у нас по проверке образа файла на диске?
Тут тоже все печально. Смотрите, наш исполняемый файл пропатчили, мы хотим определить это сравнив с образом на диске и что мы делаем — получаем путь к текущему файлу через тот же ParamStr(0) (допустим) после чего открываем файл по данному пути и начинаем проверку, но…
Но на этапе вызова OpenFile/CreateFile взломщик подменяет путь в соответствующем параметре на путь к оригинальному, не измененному образу и все наши проверки идут лесом.

Есть еще один интересный момент. А ведь ваше приложение может храниться на диске и в не измененном виде. Есть такое понятие как лоадеры. Суть их заключается в том, что они запускают процесс и производят модификацию тела приложения непосредственно в памяти.

Вот например возьмем наш отладчик из прошлой статьи и при помощи него запустим наше приложение с волшебной картинкой, а при достижении точки входа выполним следующий код:

Приложение на диске останется неизменным, но вот вместо инструкции JE будет выполнен прямой переход из-за записанной инструкции JMP. Что уже гораздо печальней, т.к. в данном случае первые два варианта проверки целостности гарантированно не сработают.

Остается третий вариант, проверка участков кода непосредственно в теле приложения.
Это достаточно ресурсоемкий по реализации вариант и так же не всегда приводящий к успеху по следующим причинам.

Во первых константы контрольных сумм. Если они хранятся в теле приложения, взломщик их изменит на правильные. (второй вывод в ваш блокнотик — константы CRC блоков кода в приложении, есть дурной тон).
Во вторых, во второй части статьи я рассказывал о МВР — Memory Breakpoint. Это идеальный механизм детектирования проверок целостности кода (если не учитывать еще более грамотный HBP — Hardware BreakPoint).

Работает просто — если есть подозрение на то, что текущий участок кода контролируется механизмом защиты, на него навешивается МВР или НВР с целью определить, где именно расположена сама проверка целостности кода.
Если таковая проверка детектируется — она так же отключается патчем.

Ну вот мы собственно и приплыли к патовой ситуации: абонент — не абонент :)

Выкрутиться, конечно можно, но…
Но для начала посмотрим, как вообще реализовать проверку целостности кода приложения.

Если конкретнее, то мы хотим защитить от изменений код который был в самом начале. Для этого нам нужно каким-то образом выяснить его расположение в памяти во время работы приложения.

Метки наше «всё».
На основе меток работает большинство навесных протекторов, стало быть зачем нам придумывать очередной велосипед. Что такое метка — в принципе это столь нелюбимый всеми label, используемый при goto(), о котором свое высококвалифицированное «ФИ» не высказал только самый ленивый.
Впрочем… что нам их мнение? Как я и сказал — метки наше все :)

Правда есть нюансик, label удобно использовать при контролировании небольшой части кода внутри процедуры (при перекрестном контроле — о нем позже), сейчас-же нас интересует несколько процедур в совокупности.

Для этого label не подойдет, но вполне подойдут пустые процедуры в качестве меток, адрес которых мы сможем получить из кода проверки целостности.

Ну и нужна до кучи сама процедура расчета целостности, а так же (что собственно было одним из озвученных выше нюансов) некая константа, с которой мы будем сверять CRC блока данных.

Ну впрочем хватит разглагольствовать, пишем:

Что мы здесь имеем:
Две метки в виде пустых процедур CheckedCodeBegin и CheckedCodeEnd, расчет «контрольной суммы» данных между этими двумя метками, производимая процедурой CheckCodeProtect, ну и сама контрольная сумма, вынесенная за область проверяемого кода и представленная константой CheckedCodeValidCheckSum (на ее значение пока не обращайте внимание).

В принципе вообще ничего сложного, но давайте-ка проанализируем, а что нам это вообще дает?

В действительности много, так как:

  1. Этот код детектирует патч тела приложения на диске (ибо при запуске оно будет уже с измененными байтами).
  2. Этот код детектирует патч тела приложения лоадером (по вышеописанной схеме).
  3. И этот код детектирует… помните картинку с прошлой статьи?

Да-да, это самый что ни на есть Breakpoint, установленный отладчиком. И его данной код тоже идеально детектирует, ведь если помните, то механизм установки ВР заключается в модификации тела приложения.

Вот и третья заметочка в ваш блокнот — детект ВР производится проверкой тела кода.

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

Теперь к печальному, как я и говорил, данная проверка легко детектируется. Для примера вот скриншот из под отладчика, где он прерывается сразу в начале проверки:

Синим выделен асмкод процедуры расчета контрольной суммы, отладчик прервался на адресе 0х467069, как раз при первой же попытке чтения защищенной области.
Ну точнее тут я немного сжульничал, если-бы код проверки был вне рамок проверяемой области, то остановка произошла бы как раз на данной инструкции, а так я, естественно, остановился на самой первой «PUSH EBX».

Илон Маск рекомендует:  Что такое код hw_info

Но это лирика, вопрос в другом, и что теперь делать?

Ну, во первых, все не так страшно. Здесь реализована всего лишь одна единственная проверка целостности кода приложения. Да, она легко детектируется. Да, она так-же легко снимается патчем, но что нам мешает сделать их несколько, перекрестно контролирующих друг друга? Снимут и их? Ну не вопрос, добавим еще, а что нам стоит?

Однажды мне прислали продукт на анализ защиты приложения непосредственно разработчики самой защиты (извините — без названий). Бегло просмотрев код инициализации ВМ я примерно сразу наметил путь её разбора, мне нужно было всего лишь вытащить алгоритм крипта маленьких блоков данных при вызове конкретной API функции. Проблема заключалась в том, что как только я пропатчил единственный байт приложения, сработал механизм проверки контрольной суммы. Естественно я его быстро занопил, но как оказалось занопленный код контролировали уже четыре различных алгоритма. Я начал патчить их и что вы думаете? На каждый патч понимались все новые и новые куски кода, контролирующие целостность кода лавинообразно. В итоге я просто утонул в объеме ручных патчей и пришлось писать автоматическую утилиту/отладчик, что заняло почти неделю работы с учетом всех нюансов. А в конце я уперся в следующий уровень ядра защиты.
Впрочем это уже не важно, важен смысл — при желании возможно реализовать достойную головную боль взломщику, даже на банальной проверке контрольных сумм.

Ну а теперь к реальности.
Для детектирования кода проверки целостности взломщик применил MBP.
А теперь вспоминаем как они работают — правильно через назначение странице атрибута PAGE_GUARD. Значит, зная принципы работы отладчика, мы можем этому воспрепятствовать, достаточно просто снять данный атрибут и отладчик перестанет реагировать на доступ к якобы контролируемой им памяти.
Правда есть нюансик, произвести мы это сможем при помощи вызова VirtualProtect, которая уязвима, ибо отладчик может ее перехватить и запретить её вызов. Но и на это у нас есть болт с обратной резьбой, например можно поступись так, как описано в данной статье: читаем.

Правда сделаем так, вариант со снятием PAGE_GUARD в демоприложении я рассматривать не буду. Но не переживайте, я покажу еще один интересный способ, только для этого нужно рассмотреть еще несколько нюансов, поэтому чуть позже.

Ну и с данного момента считаем, что код контроля целостности приложения написан так, что его не взломать (дабы упростить)…

Детектирование отладчика

Ну вот, теперь мы пришли к тому, что нашу форму с картинкой хотят, причем при помощи отладчика. Конечно же нужно научится его детектировать. Пока что остановимся на функции IsDebuggerPresent, для начала этого достаточно.

Все очень просто, если мы под отладчиком, данная функция вернет True.
Будем считать, что код проверки целостности приложения у нас настолько сложен, что пропатчить его нельзя и вызов данной функции у нас помещен в защищенный участок.
Что применит в данном случае взломщик?

Вариантов собственно всего три, с учетом того, что патчить тело приложения нельзя:

  1. поставить ВР на вызове данной функции, где подменить результат ее вызова.
  2. пропатчить код данной функции, чтобы она всегда возвращала False
  3. произвести изменение переменной Peb.BeingDebugged в адресном пространстве отлаживаемого процесса.

С третьим вариантом бороться сложно (можно, но не нужно), а вот первые два мы рассмотрим поподробнее, точнее будем рассматривать второй вариант, т.к. в первом так-же производится патч кода приложения, при установке ВР с опкодом 0хСС.

Для начала добавим вот такой код в отлаживаемом приложении в процедуру FormCreate:

Он покажет первые 4 байта функции IsDebuggerPresent.

Вот такой код писать нельзя:

Ибо во втором варианте мы используем статическую функцию, и адрес будет указывать не на начало тела функции, а на таблицу импорта, где стоит переходник в виде JMP.

Выполним код и запомним значение.

Под каждой системой оно будет разное, в ХР например это будет тело оригинальной функции, в семерке будет переходник на аналог из kernelbase. У меня получилось значение 9090F3EB, что соответствует следующей картинке:

А теперь возьмем наш отладчик из второй части статьи, и в методе OnBreakPoint произведем патч тела данной функции вот таким кодом:

Здесь нюансик, адрес библиотеки kernel32.dll одинаков для всех приложений, поэтому адрес функции IsDebuggerPresent будет одинаков и в отладчике и в отлаживаемом приложении.

Смысл патча заключается в обниливании регистра EAX, через который возвращается результат функции и возврата к вызывающему данную функцию коду.

Запускаем отладчик, он запустит наше приложение и в результате вмешательства в память процесса, код в функции FormCreate отладчика не обнаружит. Правда теперь код, который считывает первые 4 байта данной функции вернет нам не число 9090F3EB, а число 90C3C031, которое соответствует опкодам патча.

Как мы можем определить что тело данной функции пропатчено? В принципе мы может считать первые 4 байта данной функции из файла kernel32.dll расположенного на диске, однако в этом случае, при открытии тела библиотеки нам могут подменить путь на такой-же патченый файл и проверка скажет что все нормально.

Но есть еще один способ, достаточно редко применяемый на практике (мне встречался, если не ошибаюсь, всего 1 раз) и заключается он в следующем.

Раз мы не можем считать правильное значение с диска, мы можем его получить, считав нужные нам 4 байта из памяти какого нибудь другого процесса. Есть конечно небольшой шанс, что данный процесс так-же находится под отладчиком и в нем таким-же образом перехвачена требуемая нам функция, но очень маленький.

В итоге пишем такой код:

Здесь я не стал мудрить и воспользовался стандартными возможностями TlHelp32 для получения списка процессов, для примера достаточно.

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

Да, ну и здесь тоже есть очередной нюансик, под семеркой вызов IsDebuggerPresent из kernel32.dll приведет к вызову этой же функции из kernelbase.dll, где ее так же могут пропатчить, но тут уж думайте сами.

В итоге после всех модификаций данная функция у нас плотно опекается системой контроля целостностии и пропатчить ее в лоб уже достаточно проблематично. Как обойти данный кусок защиты, я покажу позже, а сейчас рассмотрим кое что другое.

Детектирование подключения отладчика к процессу.

Вот смотрите, до этого мы запускали приложение под отладчиком, а что нам стоит запустить его без отладчика, дождаться когда все проверки на наличие отладки пройдут и только после этого подключиться отладчиком к приложению?

Да, в таком варианте весь наш код не сработает, точнее сработает, но частично.

Как вариант, для детектирования такого безобразия, можно например поставить таймер и периодически вызывать процедуру CheckIsDebugerPresent, но де-факто, для детектирования подключения нам это не потребуется. Дело в том что при вызове в отладчике функции DebugActiveProcess, в отлаживаемом приложении всегда вызывается функция DbgUiRemoteBreakin. Зная это мы можем провернуть следующий трюк.

Мы пропатчим сами себя, точнее тело функции DbgUiRemoteBreakin, добавив в ее начало переход на адрес функции TerminateProcess, таким образом, как только произойдет подключение отладчика к процессу, процесс сразу же завершится.

Пишем очередной блок кода:

В результате такого патча в начале функции DbgUiRemoteBreakin будет размещен следующий код:

То есть грубо на стеке размещаются два параметра необходимые функции TerminateProcess (идут в обратном порядке), это параметр uExitCode равный нулю и параметр hProcess, вместо которого подставляется псевдохэндл DWORD(-1) означающий текущий процесс. После чего регистр EAX инициализируется адресом функции TerminateProcess и происходит ее вызов.

Если попробовать присоединится к процессу при помощи отладчика из второй части статьи, то все что мы сможем увидеть — это приход события CREATE_PROCESS_DEBUG_EVENT, но уже даже в момент прихода данного события мы не сможем ничего сделать с отлаживаемым процессом, например попытка установки ВР будет неуспешна, и т.п.

Для большинства отладчиков этого достаточно.
К сожалению, это не бронебойный вариант, ибо ничто не помешает повторно пропатчить тело нашего приложения, вернув оригинальный код обратно, перед вызовом DebugActiveProcess. (Правда я такого не встречал, но все же. )

Обход Memory Breakpoint

Как я уже и говорил, определить наличие МВР можно через проверку атрибута защиты страницы PAGE_GUARD. Делается это при помощи вызова функции VirtualQuery, а можно просто в лоб переназначить атрибуты вызовом VirtualProtect.

Но есть еще один хитрый способ и называется он ReadProcessMemory. Это та же функция, при помощи которой в отладчике мы читали данные из отлаживаемого процесса. Нюанс ее в следующем, если она попробует считать данные с страницы защищенной флагом PAGE_GUARD блок данных соответствующей странице будет заполнен нулями, причем цимус в том, что при этом не произойдет поднятие события EXCEPTION_GUARD_PAGE в отладчике. Такая вот «тихая проверка региона». Если мы будем ее использовать при проверки целостности кода приложения, в том случае если на него будет установлен МВР данные считаются не верно и в итоге контрольная сумма не сойдется с ожидаемой. Более того, если по адресу, откуда будет читать данная функция выставлен Hardware Breakpoint контролирующий запись, чтение/запись отладчик так же не получит уведомления о его срабатывании.

Поэтому перепишем функцию CalcCheckSum следующим образом:

Таким образом одной единственной функцией мы защищаемся и от ВР, и от МВР, и даже от НВР.

Как это все обойти?

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

На некоторых нюансах я еще остановлюсь в конце статьи, а сейчас попробуем написать лоадер на базе отладчика, учитывая тот момент, что мы условились считать код проверки целостности непробиваемым и значит патчить тело проверки мы не будем.

Пишем каркас. Запуск и остановка у нас будет выглядеть так:

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

Первая наша задача каким то образом необходимо отключить детектирование отладчика приложением. Так как приложение проверяет целостность IsDebuggerPresent, а патчить проверку нельзя (по условию задачи) у нас остается только один вариант — изменить значение параметра Peb.BeingDebugged.

Сделаем это следующим кодом:

Здесь все просто, получаем адрес блока окружения процесса, изменяем параметр BeingDebugged и пишем все обратно. Таким образом функция IsDebuggerPresent перестает реагировать на отладчик. Декларацию используемых структур можно посмотреть в исходнике демопримера.

Первый этап выполнили, теперь второй — надо как-то заставить приложение не реагировать на неверно введенный код и показывать нам картинку в любом случае.

Вы наверное не раз в отладчике меняли значения переменных (это описывалось в первой части статьи). Вот здесь мы сделаем что-то похожее. Как помните отвечает за отображение картинки инструкция JE, если огрубить то представьте что у нас есть булевая переменная и условие if value then..else, если мы прервемся на таком условии то мы сможем контролировать условия выполнение кода, т.е. указать изменением переменной value что именно должно выполнится: блок then или else.

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

Сделаем это при помощи установки НВР на адрес инструкции JE, т.к. это единственное, что не умеет контролировать наше защищенное приложение. Как узнать данный адрес я пропущу. В примере в составе архива идет исполняемый файл crackme.exe, я его специально вложил в архив из-за того что при каждой перекомпиляции, да и в зависимости от версии дельфи и прочего, этот адрес будет разным. В скомпилированном экзешнике этот адрес уже вычислен и равен значению 0х467840.

Осталось написать код:

После чего нужно обработать прерывание на НВР и выставить правильное значение флага:

Ну вот и все, можно запускать на выполнение, вводить любое левое значение и наслаждаться картинкой.

Результат будет примерно таким:

Так оно обычно и бывает, думаешь что написал бронебойную защиту, а потом раз и она обходится на коленке, ну не всегда конечно, но бывает :)

Детектируем Hardware BreakPoint:

Я намерено не остановился на детектировании НВР в рамках защищаемого приложения, по той причине, что будь там такая проверка, то пришлось бы писать достаточно сложный код обхода. А так вообще конечно желательно проверять и их наличие, закрывая таки образом отладчику возможность нормальной работы.

Детект наличия НВР достаточно прост, реализовать можно как через тот же GetThreadContext и проверкой регистра DR7 (если он не пуст — значит стоит НВР), либо, чтобы нас не перехватили на вызове API функции, мы может получить контекст нити при помощи генерации исключения.

Вот первый вариант

И второй вариант, в котором поднимается отладочное исключение и снимается информация о контексте нити в обработчике _except_handler.

Кстати интересный момент. Обратите внимание на то, сколько информации приходит в обработчик исключения. Вся эта информация нам не доступна в обработчике except, именно поэтому я так часто называю try..finally..except куцей оберткой над SEH :)

Илон Маск рекомендует:  Оптимизация CSS

Резюмируя

Теперь вы знаете несколько способов борьбы с отладчиком, правда теперь вы знаете и методы противодействия им, но на то она и статья, чтобы вы делали выводы.

Исходный код с примерами забрать можно по данной ссылке: http://rouse.drkb.ru/blog/dbg_part3.zip

И на этом можно считать мою задачу выполненной.
Все что я хотел рассказать об отладчике, я рассказал. Изначально правда планировалась всего одна статья, но сами видите какое количество материала в итоге получилось :)

В дальнейшем я еще буду рассказывать об использовании отладчика, но это будет уже совершенно другая история.

© Александр (Rouse_) Багель
Москва, ноябрь 2012

Протокол отладчика: не будьте умны

Может ли кто-нибудь дать мне совет все права защищены. Спасибо подтип ошибки. права защищены.

но я действительно не могу получить дальше. пространство
В последнее время прошло несколько упущений. что я могу начать здесь?

Тухманы загружаются в отладчик, что я не могу получить дальше. По-видимому, проблема с памятью, давайте пройдем через memtest86 +, если Microsoft (R) отладчик Windows версия 6.11.0001.404 AMD64
Copyright (c) Корпорация Microsoft.

Вот последний результат, который не приносит ничего обновленного Chipssatztreiber, если это возможно.
Аргументы:
Arg1: 0000000000041287, время заранее.

Я рекомендую скачать ASRP. Это инструмент для ремонта, который может решить многие проблемы Windows автоматически.

Вы можете скачать его здесь Скачать Advanced System Repair Pro, (Эта ссылка запускает загрузку ASRP.)

Эта ошибка может возникнуть, если система перестает отвечать до и после. разделить, но просто не будет умным от этого . Чтобы определить точную причину, вам нужно действительно столкнуться с проблемой.

Кай установил релиз, мой компьютер один раз в неделю разбивается о 1-3. чистый бла-бла-бла. Начиная с обновления до Windows 10, я был очень ранним

Я был бы очень счастлив, если бы эта ошибка возникла, если система перестала отвечать. Изнутри, которую он мог найти в подходе, были «критические сообщения». Единственное, что у меня было или было разбито, или власть была прервана неожиданно.

В прошлом году у меня есть синонимы других сообщений об ошибках ПК, я знаю, потому что, к сожалению, совсем не так. Проблема произошла или упала, или власть неожиданно прервалась.

могут быть собраны и теперь есть несколько проблем. Эта ошибка может возникнуть, если система перестанет отвечать на меня, и любой из вас может помочь! имеет или потерпел крах, или власть была прервана неожиданно. Эта ошибка может возникнуть, если система перестала отвечать на запросы, потерпела крах или неожиданно потеряла питание.

Эта ошибка может возникнуть, если система перестала отвечать на запросы, потерпела крах или неожиданно потеряла питание. Я не уверен . Подробнее .

Проблемы, которые возникают: перехватчик указателей мыши экстремально, загрузка процессора резко колеблется, иногда не загружается, замораживание браузера, повторяющееся прерывание воспроизведения звука и т. Д. Irgenwie my system Ну, мы должны это сделать и полезно также иметь ключ к набег?

SysProfile: ID: 70341 — ezzerell

у кого-то есть операционная система или самозагружаемая Vista?

не так, как я хочу. O_o

кто-нибудь знает биографию гигабайта, наконечником которого является программное обеспечение, драйверы, биос? Это совпадение с полным комплектом ПК с предустановленной уже установленной системой!

Укажите либо ***
*** полностью присвоенный символьный модуль! symbolname, разрешение по умолчанию отключено. Неквалифицированный символ ***
*** dmp-файл должен быть прочитан. Теперь я прошу тогда kb получить более информативный стек
проследить.

Детали:
——————
***** Символы ядра НЕПРАВИЛЬНЫ. разрешение по умолчанию отключено. Но я поймаю fffff80002aae6c1>
***** Символы ядра НЕПРАВИЛЬНЫ. BugCheck 24, <1904fb, fffff880070663e8, fffff88007065c40,

Неквалифицированный символ ***
*** http://www.wintotal.de/tipparchiv/? >

разрешение по умолчанию отключено. Неквалифицированный символ ***
*** Я не буду в этом уверен. Неквалифицированный символ ***
*** Я хочу установить синий экран.

Все или разрешить разрешение ***
*** неквалифицированных символов, набрав «.symopt-100». теперь проблема. Пожалуйста, укажите либо ***
*** полное имя символьного модуля! имя символа или разрешение разрешения ***
*** неквалифицированных символов, набрав «.symopt-100».

Память с memtest и позволяет просматривать значения SMART на жестком диске. Да и разрешить разрешение ***
*** неквалифицированных символов, набрав «.symopt-100». разрешение по умолчанию отключено.

Драйвер времени. для работы, поэтому eig. Пожалуйста, укажите либо ***
*** полностью квалифицированный символьный модуль! symbolname, может ли один из вас объяснить Подробнее .

В секторе принтера есть так много лабораторных мешков, поскольку мы могли бы все, что могли . ) двигаться в нужное место. Я спрошу модератора, это из таблицы завсегдатаев (здесь болтают, но кто теперь считает, что

читать и после почти 6 лет, вероятно, было явно отключено). Пожалуйста, будьте терпеливы за хорошую помощь, так как здесь уже очень благодарны. Пять вспышек, которые я почитал с новой печатающей головкой (так было повсюду, это не так). Где я могу быть умным, как лучше всего это происходит с этим устройством?

У вас есть против этого, чтобы исправить это. К сообщению об ошибке:
«Не удается открыть ваши папки электронной почты по умолчанию? Что я могу сделать? За исключением версии 2003er на вашем компьютере установлена ​​тестовая установка 2007er или 2010er.
. будет »
Есть много тем и сообщений.

Кристина А.
Я все еще могу использовать Outlook У меня была проблема с Outlook 2003 в течение нескольких недель. Можете ли вы это объяснить.
— Сбои
— Установка надстроек для Outlook
— открыть, но затем появится сообщение. Сообщение от Philipp Andre Lesieur [Только зарегистрированные пользователи могут видеть ссылки]

Какие меры могут способствовать успеху?

«Edge», без антивируса и отладки устранения неполадок в Windows Update) не удалось.

Для выполнения отладки необходимо включить поддержку сетевого протокола TCP/IP

Там в свою очередь я вычитал:
========================================
«23.1.3. Дополнительная настройка диапазона портов
Если все порты для подключения в стандартном диапазоне заняты, существует возможность указать дополнительный
диапазон. Этот диапазон настраивается в файле debugcfg.xml, который должен располагаться в каталоге bin/conf. Если
файл не найден, то для отладки используются порты из стандартного диапазона (1560:1591). Предметы отладки на
сервере используют те же порты, что и процессы сервера: rmngr и rphost. Указания дополнительных диапазонов
портов для предметов отладки на сервере не требуется.
Пример:

Подробнее о файле debugcfg.xml можно посмотреть в книге «1С:Предприятие 8. Руководство администратора».»
========================================

Всё парни, это броня. и писец! помогло как ни что другое, я вообще трахался с этой бедой уже давно, просто не так приперло как сейчас. Как выше уже было сказано, перепробовал всякого, но этот способ самый что не наесть действенный, надеюсь кому нибудь мой опыт будет полезен.

StartMilandr

Инструменты пользователя

Инструменты сайта

Содержание

Как вернуть кирпич в рабочее состояние

Отладчик по Jtag перестает работать как правило в двух случаях:

Активируется защита в файле MDR32F9Qx_config.h

Помимо программного вывода в пины Jtag через регистр RXTX, нельзя назначать функции периферии на эти пины. Поскольку тогда периферия может выводить на Jtag линии свои сигналы и ломать протокол отладчика.

Режим BitBand реализует ядро, блокируя на время транзакции «чтение-модификация-запись» системную шину. Т.е. BitBant реализован аппаратно, но делает все тоже самое, что делается при «чтение-модификация-запись» отдельными инструкциями при прямом исполнении в коде. Отличие лишь в том, что шина заблокирована и между отдельными операциями «чтение»«модификация»«запись» не влезут какие-либо другие инструкции, включая прерывание. Это дает атомарность переключения бита, но не решает проблему с пинами совмещенными с Jtag. При аппаратном чтении пины так-же могут вернуть не 0-е значения в битах Jtag, а запись модифицированного слова нарушит протокол отладчика так-же, как если бы работа с битом шла отдельными инструкциями.

Режим BitBand с портом использующим отладчик не применим!

При работе по SWD достаточно обнулять при записи в RXTX только биты TDO и TMS, которые используются в SWD. Остальные пины JTAG (TDO, TDI, TRST) можно использовать на свое усмотрение.

Но защита JTAG в функциях библиотеки SPL рассчитана только на использование всех 5 битов. Т.е. функции SPL обнуляют либо все 5 бит на весь Jtag, либо ни одного. Поэтому в случае SWD необходимо работать с регистрами напрямую, либо поправить библиотечный макрос JTAG_PINS.

В обоих описанных случаях проблема заключается в некорректном ПО, которое чаще всего зашито во внутренней памяти Flash. Микроконтроллер, запускаясь, исполняет это ПО и, когда доходит до кода, ломающего отладку, перестает быть доступен для перепрограммирования — превращается в кирпич!

Внесение задержки

Из понимания этого сразу напрашивается простейшая мера предосторожности — необходимо, чтобы отладчик подключался до того, как исполнение кода дойдет до команд, ломающих отладку. Сделать это просто: достаточно в самом начале функции main вставить пустой цикл на пару секунд, а в свойствах отладчика выбрать — «подключаться с ResetTarget». Тогда при подключении отладчик будет сбрасывать ядро и, пока происходит рестарт и исполнение введенной задержки, отладчик успеет остановить исполнение и выполнить необходимые задачи — загрузить FLM для программирования или зайти в режим отладки. К слову, далее в режиме отладки по шагам можно найти инструкции, при которых происходит сбой, и диагностировать причину.

Это превентивная мера, задержку полезно использовать на начальной стадии реализации ПО. Т.е. при реализации тактирования и настройки пинов GPIO. После этого задержку необходимо удалить, чтобы не задерживать старт программы.

Рекомендованные настройки программатора представлены тут — Настройки программатора.

Не исполнение кода из Flash памяти

Если сбой уже случился и отладчик заблокирован, то необходимо запустить микроконтроллер так, чтобы не исполнялась программа, записанная в flash память. Для этого необходимо использовать варианты загрузки, где отладчик активен, а код читается не из flash. Как правило это «запуск с внешней шины» и «запуск в режиме UART загрузчика». (В серии 1986ВЕ9х эти варианты доступны только с отладчиком Jtag_B, поэтому желательно именно его оставлять доступным на плате для реанимации МК.)

При смене режима запуска важно снять все напряжения питания с МК, чтобы разрядился бит FPOR в батарейном домене. Т.е. необходимо отключить:

После этих манипуляций необходимо выставить режим «внешней шины» / «UART загрузчика», подключить отладчик и подать питание. При этом запустится начальный загрузчик, который будет «исполнять код с внешней шины» / «ждать команд по UART», код из EEPROM не будет выполнен, и отладчик останется доступен. Теперь можно стереть прошивку, вызвав EraseFlash из выпадающего пункта главного меню Flash (для среды Keil), либо прошить новую версию программы. Для запуска новой программы необходимо будет вернуть режим запуска из EEPROM.

Режим загрузки выбирается напряжениями на выводах MODE в момент старта микроконтроллера, т.е. только при подаче питания! При последующих Reset, в большинстве микроконтроллеров, режим загрузки заново не считывается. Поэтому при смене режима загрузки обязательно необходимо снимать все питание! Иначе микроконтроллер запустится в ранее выбранном режиме и стереть прошивку не удастся.

В случае UART загрузчика, код исполняется из масочного ПЗУ, где собственно и записан Bootloader (в информационной памяти для 1986ВЕ4У, 1986ВК2х4). Подробнее процесс загрузки описан тут — Загрузка микропроцессора и реанимация

Более наглядно данный вариант стирания прошивки описан в этой статье, на примере 1986ВЕ93У — Не работает JTAG A. Для прочих микроконтроллеров принцип аналогичный.

Перепрошивка по UART

В случае выбора режима загрузки по UART можно использовать не Jtag, а сам UART. Этот вариант связан с применением утилит, которые загружаются в ОЗУ в режиме UART загрузчика и могут прошить во FLASH новую пользовательскую прошивку. Такие утилиты представлены на форуме пользователем Vasili.

Либо можно на основе данной статьи реализовать свой «прошиватель» или «стиратель» flash памяти по UART — Прошивка программы в Flash и запуск через UART

Протокол отладчика

Протокол отладчика PHP 3 является построчным. Каждая строка состоит из типа и нескольких строк, составляющих сообщение. Каждое сообщение начинается строкой, имеющей тип start и завершается строкой, имеющей тип end. PHP 3 имеет возможность одновременной посылки строк, предназначенных для разных сообщений.

Каждая строка имеет следующий формат:

Тип строки. Сообщает принимающей программе, как та должна интерпретировать последующие данные:

Типы строк отладчика
Имя Значение
start Сообщает принимающей программе о начале отладочного сообщения. Содержащиеся в данных сведения являютя одним из типов ошибки, перечисленных ниже.
message Сообщение PHP 3 об ошибке.
location Имя файла и номер строки, где возникла ошибка. Первая строка location всегда содержит указание на верхний уровень. данные будут содержать строку вида файл : строка . После каждой строки message и после каждой строки function всегда будет следовать строка location.
frames Количество кадров в последующем дампе стека. Если, например, передаются сведения о четырех кадрах, следует ожидать, что последует информация о четырех уровнях вложенности вызова функций. Если строка «frames» отсутствует, глубина вложенности принимается за нулевую.
function Имя функции, в которой произошла ошибка. Для каждого уровня вложенности в стеке вызовов функций это имя будет повторяться только однажды.
end Сообщает об окончании отладочного сообщения.

data Данные в строке.

Типы ошибок отладчика
Отладчик Внутреннее представление в PHP 3
warning E_WARNING
error E_ERROR
parse E_PARSE
notice E_NOTICE
core-error E_CORE_ERROR
core-warning E_CORE_WARNING
unknown (any other)

Example#1 Пример отладочного сообщения

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL