Класс CSharpCodeProvider позволяет программе на C# компилировать код на C#. Обычный вопрос – «зачем». Обычные ответы:
Сегодня мы используем этот класс для удобного воспроизведения гонки двух процессов.
Читать полностью »
Уже много лет компоненты DevExpress в подписках верхнего уровня поставляются вместе с полным исходным кодом. Это очень удобно и для клиентов, которые могут воспользоваться им как справочником в вопросах, не затронутых документацией, и для тех.поддержки, которая может написать «смотрите исходный код» в случае необходимости. Более того, имеются скрипты для самостоятельной сборки компонентов. Кому-то это будет полезно для доработки компонентов под свои задачи. Но уверен, что большинство как и я использовало пересборку для получения отладочной информации. И до недавнего времени это был единственный (из бесплатных) способ ходить по коду DevExpress в отладке.
Читать полностью »
Годами я использовал Chrome DevTools, Firebug и даже Opera Dragonfly для отладки, трасировки и профилирования моего JavaScript кода. Замечу, что использовал эти замечательные инструменты не только для работы с JavaScript, но и для отслеживания событий сети, отладки CSS, работы с DOM.
Однако иногда я попадал в некие зоны отчужднения, в которых приведенные выше инструменты помочь мне не могли по определенным причинам, а хотелось бы.
GWT – отличный фреймворк. Я — Java-разработчик, и мне доводилось работать с тонкими клиентами с использованием JSP, JSF и GWT. Про JSP говорить особо нечего, технология сейчас практически вымерла, а вот в JSF-е пришлось повариться пару лет на двух проектах, и впечатления, мягко говоря, не из лучших: мешанина JSTL, HTML, JavaScript и прочего доставляет несказанное “удовольствие”, доходящее до экстаза в моменты разбора непонятного поведения какой-нибудь сложной страницы. Да, в примерах все выглядит аккуратно и просто, но реальная жизнь не такая, и JSF-страницы проекта даже среднего размера и, вроде бы, с грамотным неторопливым подходом при проектировании, с использованием шаблонов, все равно начинает “попахивать”, особенно в части читабельности. В GWT все достаточно аккуратно, ведь пишем на родном языке Java, пусть и в урезанном варианте, но того что есть более чем достаточно.Читать полностью »
На днях у меня перестал работать онлайн-банкинг моего банка. Нет, не то чтобы совсем перестал — вроде бы можно зайти и даже кое-что сделать, но вот одна из самых важных вещей (просмотр архива платежей) — просто намертво отказалась работать (а как раз было очень нужно). Выглядит это так: при открытии страницы со списком платежей браузер съедает всю доступную оперативную память и падает. В Chrome падает только текущая вкладка, а вот Firefox и IE умирают совсем. Баг воспроизводится на трёх разных PC, айпаде, в Safari под Mac OS и в Firefox под Linux. Ну это я просто так рассказываю, для того чтобы показать наивность советов техподдержки «поставить антивирус» и «перезагрузиться и зайти ещё раз». Давайте подумаем — можем ли мы что-нибудь в этой ситуации сделать?
Читать полностью »
Что такое отладчик, как им пользоваться и как он реализован, после прочтение первой и второй части статьи, вы знаете. В заключительной части статьи попробуем рассмотреть некоторые методы борьбы с отладчиком, на основе знаний о принципах его работы. Я не буду давать шаблонный набор антиотладочных приемов, благо при желании все это можно найти на просторах интернета, попробую это сделать немного другим способом, на основе некоего абстрактного приложения, у которого буду расширять код защиты от самой простейшей схемы до… пока не надоест :)
Сразу-же оговорюсь, в противостоянии приложение/отладчик, всегда победит последний :)
Но, только в том случае, если им будет пользоваться грамотный специалист, а с такими спецами бороться практически бесполезно (ну, если вы конечно не обладаете как минимум такой же квалификацией).
Правда как показывает практика, грамотные спецы не занимаются неинтересными им задачами, оставляя их на откуп начинающим реверсерам, которые еще не прогрызли свой гранит науки и могут спотыкаться на некоторых не очевидных трюках.
Вот что-то такое мы и рассмотрим, только в очень упрощенной форме.
Читать полностью »
В первой части статьи были рассмотрены некоторые нюансы работы с интегрированным отладчиком Delphi — не все конечно, но наиболее необходимые разработчику. Теперь задача выглядит несколько иначе: рассмотрим его работу изнутри на примере его исходного кода. Для того чтобы не сильно утомлять вас описанием API функций и не разжевывать все этапы отладки, описывать его работу я буду на примере класса TFWDebugerCore. Часть не особо важных моментов я опущу, при желании вы их сможете уточнить просмотрев код данного класса.
Если вы уже знакомы с работой отладчика — ничего страшного, вполне вероятно что некоторые аспекты его работы, упомянутые в статье, будут вам интересны.
Если же вы ранее никогда не сталкивались с самостоятельной реализацией отладчика, но заинтересованы в ней, то как минимум вы должны начать с данной ссылки: Debugging and Error Handling
По ней вы сможете узнать об основных аспектах отладки, как-то структурной обработке исключений, работой с отладочной информацией, минидампами. Работой с образом исполняемого файла, заголовками, секциями, картой памяти процесса, что такое RVA и VA и прочее-прочее.
Но это только если захотите разобраться во всей этой кухне.
Я же попробую описать только часть ее более простым языком, дабы у вас была точка, от которой можно было-бы оттолкнуться, если вы вдруг заинтересовались, ну и конечно, если вы реализуете защиту приложения, то вникнуть в тонкости работы отладчика вам необходимо как минимум (а иначе-то как по другому?).
В тексте статьи будет много кода, но рассматривать все параметры каждой из структур при возникновении отладочных событий я не буду, для этого есть MSDN. Остановлюсь только на необходимых для работы отладчика и попробую раскрыть некоторые нюансы, с которыми вы скорее всего столкнетесь при самостоятельной реализации движка отладки.
От вас же желательно наличие хотя-бы минимальных знаний ассемблера, т.к. без него в данной статье увы не обойтись.
Здравствуйте, уважаемые читатели!
В данном коротком посте хотелось бы поделиться опытом о том, как мы решали задачу подмены библиотеки libpthread. Такая потребность возникла у нас в ходе создания инструмента формирования модели переходов многопоточной программы, о которой мы уже рассказывали в одном из предыдущих постов — habrahabr.ru/company/nordavind/blog/176541/. Технология получилась достаточно универсальной, поэтому спешим ей поделиться с читателим. Надеемся, кому-нибудь пригодится для решения собственных задач.
Итак, начнем с описания задачи, которую решали мы. Для исследования программы на предмет наличия в ней потенциальных ситуаций взаимных блокировок нам необходимо было построить модель программы с точки зрения последовательности обращений к различным средствам синхронизации из различных потоков. Логичным и очевидным решением является «перехват» обращений к средствам синхронизации, которые в нашей системе происходили исключительно через стандартную библиотеку libpthread. Т.е. фактически, решение состоит в подмене библиотеки libpthread на некую нашу библиотеку libpthreadWrapper, которая реализует все функции, которые реализованы в оригинальной библиотеке. При этом в интересующих нас функциях (pthread_mutex_lock, pthread_mutex_unlock, pthread_cond_signal, и др.) добавляется некоторый код, который уведомляет какого-то внешнего listener-а о вызове и параметрах вызова. Реализация всех неинтересующих нас функций оригинальной библиотеки в libpthreadWrapper представляет собой просто вызов соответствующей функции из libpthread.Читать полностью »
Мне нравится Node.js, но совсем недавно я начал использовать её на серьёзных проектах. При этом я продолжил пользоваться моей любимой средой разработки*. И если для простых скриптов достаточно просто редактора, то для серьёзной разработки нужны серьёзные инструменты, в частности, дебаггер. Ничего готового для студии найти не удалось, поэтому я взял и за пару выходных сделал его сам:
Читать полностью »
Вообще-то у меня PhpStorm, но, думаю, все будет работать и в WebStorm.
Запускаем в командной строке
cd <path to Gruntfile>
node --debug-brk=64005 $(which grunt) img2base64
Где img2base64 — название нужного задания. Можно опустить этот параметр, чтобы запустились все задания.
Получаем debugger listening on port 64005
Далее в настройках WebStorm: Run → Edit configurations… → + → Node JS Remote Debug. Задаем название конфигурации (например, grunt), Host: 127.0.0.1, Debug port: 64005 (порт можно задавать любой от 1025 до 65535, главное везде один и тот же). Нажимаем OK. Задаем точку останова (breakpoint) и нажимаем кнопку Debug.
Профит!
Читать полностью »