Актуальные ссылки:

sourceforge.net
http://x64dbg.com
https://github.com/x64dbg/x64dbg
scyllahide

Документациия по отладчику - --> Link <--

Новый проект от Mr.eXoDia и др.

Features:

Open-source
Intuitive and familiar, yet new user interface
C-like expression parser
Full-featured debugging of DLL and EXE files (TitanEngine)
IDA-like sidebar with jump arrows
IDA-like instruction token highlighter (highlight registers etc.)
Memory map
Symbol view
Thread view
Content-sensitive register view
Fully customizable color scheme
Dynamically recognize modules and strings
Import reconstructor integrated (Scylla)
Fast disassembler (BeaEngine)
User database (JSON) for comments, labels, bookmarks etc.
Plugin support with growing API
Extendable, debuggable scripting language for automation
Multi-datatype memory dump
Basic debug symbol (PDB) support
Dynamic stack view
Built-in assembler (XEDParse)
View your patches and save them to disk
Built-in hex editor
Find patterns in memory






| Сообщение посчитали полезным: ff0h, Gideon Vi, nick8606, Artem_N, JKornev, DimitarSerg, daFix, Rio, n0x90, DenCoder, Maximus, ELF_7719116, exprxp, Error13Tracer, Gerpes, SDFnik, VanHelsing, marius, jangle, hello, Bronco, mushr00m, HandMill, Johnatalbi, kassane, BAHEK, zNob, mkdev, Haoose-GP, HAOSov, mr qubo, Tyrus, kurorolucifer, Relax_, esa_r, Styx, Creckerhack, RootKey, RoKZaR, CKAP, Cigan, tRuNKator, Wargrinder, morgot, BiteMoon, mak, Illuzion

хех, уже готов)

| Сообщение посчитали полезным:

ff0h
ну до готов думаю еще далеко)) но уже юзабельно,главное что они активно "пилят" его.

| Сообщение посчитали полезным:

The debugger core is based on TitanEngine
Disassembly powered by BeaEngine

Ну, я не знаю... ©

| Сообщение посчитали полезным: Ra1n0, ff0h

Ну, я не знаю...
Сообщение посчитали полезным: int
И все же я думаю, что лучше это - чем вообще ничего... (я про ОпенДбг)

| Сообщение посчитали полезным: DimitarSerg, nick8606

SReg пишет:
И все же я думаю, что лучше это - чем вообще ничего...

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

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

| Сообщение посчитали полезным:

Если там фундамент - штатный механизм(отладочный порт), то идею следует зарубить на корню.

| Сообщение посчитали полезным:

Что значит "если". Ничего другого за бесплатно, на паблик, юзабельного и не глючного ни кто не пишет.

| Сообщение посчитали полезным:

Gideon Vi

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

Системная часть должна быть в ядре реализована и быстрый интерфейс туда.

| Сообщение посчитали полезным:

Dr0p, где я хоть словом возразил? Повторюсь: то, что ты перечислил, ни кто не пишет. Или пишет, но очень медленно. По вполне понятным обстоятельствам, к стати.

| Сообщение посчитали полезным:

Ну что сказать, не плохо, удачи

| Сообщение посчитали полезным:

SReg пишет:
И все же я думаю, что лучше это - чем вообще ничего...
В таком уж случае лучше не любимая всеми вами IDA. А что касается, OpenDbg я сейчас делаю проект по автоматизации телевещания уже год, фактически учусь программировать графику на Qt (очень замороченный интерфейс у этой софтины). Проект сложный, зато после него легко смогу сделать GUI. А вот если я начну ядро изучать, вы точно никогда его не дождетесь. Кое-кто обещал помочь с ядром, остальные все "помощники" не достаточный уровень имеют для этого. Может вот Dr0p захочет запилить дровину, раз он такой эксперт в отладке (я без иронии).

А данный отладчик это чистый рип интерфейса OllyDbg.

| Сообщение посчитали полезным:

int пишет:
А данный отладчик это чистый рип интерфейса OllyDbg.
Так это же просто отлично, не ?

-----
ds

| Сообщение посчитали полезным: TLN

int пишет: Кое-кто обещал помочь с ядром, остальные все "помощники" не достаточный уровень имеют для этого.
Дык тогда и уперлось все в то, что не готовы были все компоненты отладчика, кроме ядра UI, биндинг для дизасма, частично трейсер по тем же причинам.

int пишет: Может вот Dr0p захочет запилить дровину
Если бы он еще писал на си и без фанатизма, кругом все морфить да пермутировать, а так +1.

int пишет: Проект сложный, зато после него легко смогу сделать GUI.
Так это же хорошо, а работа, никуда от нее не деться, святой дух только у попов высококалорийный.
Будет каркас, будут кодеры и бетатестеры.
Ждемс.

| Сообщение посчитали полезным:

F_a_u_s_t
Дык я как раз тебя и имел в виду (не стал указывать ник по полит. соображениям). Просто были товарищи, которые даже не смогли разобраться с исходниками Ms-Rem'а. Согласен, что кодить ядро, пока нет ничего, нет смысла. Это как делать двигатель в автомобиль, если для него нет подходящего кузова, салона, трансмиссии и колес, а делать их некому. Поэтому, когда и если будет GUI и адекватный трейсер (он в принципе адекватен, только вот без анализатора бесполезен), т.е. будет UserMode-отладчик полноценный, можно и созывать команду тогда. А дергать людей просто так мне лично не хочется. Уже пройдено и ни один раз.

DimitarSerg пишет:
Так это же просто отлично, не ?
Есть такое понятие как привычка. А еще есть такое понятие консерватизм. Привычка != удобство.

| Сообщение посчитали полезным:

int

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

> не смогли разобраться с исходниками Ms-Rem

Есчо раз, он спортил много людей своим паскалем(дельфя). Описание и использование системных механизмов, у него ничего больше небыло. Так что не вижу что он нам дал. На тот момент уже были в сети исходники ядра, далее оно было открыто в виде wrk. Если код получает список процессов через слепки в этом нет его заслуги - это системный механизм. Понятно почему он Z0mbie не нравился, впрочем как и мне.

> если будет GUI

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

> адекватный трейсер

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

| Сообщение посчитали полезным:

> Может вот Dr0p захочет запилить дровину

Она запилена под x86 в сайд моторе.

> Если бы он еще писал на си и без фанатизма, кругом все морфить да пермутировать

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

На счёт морфа вы наверно правы. У меня за года выработалась некая особая модель реализации, изменение которой кажется не годным. Так например макро %GET_GRAPH_ENTRY юзается даже там, где оно совершенно не нужно

| Сообщение посчитали полезным:

int пишет: Дык я как раз тебя и имел в виду (не стал указывать ник по полит. соображениям).
"Помирать" не собираюсь, если что.

Dr0p пишет:С современными автоматизированными визуальными средами про гуй вообще никто не думает.
На самом дели хороший гуй не такая простая задача, если конечно не такое говно, как в windbg.

Dr0p пишет:
Недавно десятую студию поставил - там ну никак компиль не может собрать модуль без 40кб говна на си.
Опять 25, никакого гуана не пихается, тред о GCC намекает.

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

| Сообщение посчитали полезным:

F_a_u_s_t

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

| Сообщение посчитали полезным:

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

Dr0p пишет:
Есчо раз, он спортил много людей своим паскалем(дельфя).
Вообще-то те исходники были на сях. Они просто приватные, никто их не выкладывал никуда и вроде пока не текло.

| Сообщение посчитали полезным:

норм отладчик будет если авторы не забросят
а по поводу ms-remа: он придумал и реализовал десятки техник и при этом он никогда не орал что он элита хотя и был ею

| Сообщение посчитали полезным: DimitarSerg

SegFault пишет:
он придумал и реализовал десятки техник
просветите нас, не знающих про десятки

PS: для меня z0mbie и 29A были интересны, ес-но в плане винды. остальное - не торт

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным: Dr0p

int

Есть ведь альтернатива железячной трассировке - в буфере код исполнять. Копируем блок в буфер, фиксим его если надо, дополняем ветвлением в наш код и передаём управление на буфер. Так в VMBE реализована трассировка. Есно некоторые инструкции нужно хардверно трейсить(сискол например). Есть конечно подводные камни, например фолт в буфере нужно корректно обработать. Самая главная проблема - нет быстрого дизасма длин. Он должен быть сугубо табличным, подобным как у авера VBA.

> просто приватные

Вот оно как

| Сообщение посчитали полезным:

ajax
зомби это классика а его преемником стал мсрем. погуглите в инторнетах куча статей мс-рема для того времени это было актуально и ново. Кстате на этом сайте есть интервью с ним http://www.cracklab.ru/int/ms_rem.php. После мс-рема никого не было все скатилось в коммерс и приваты. Ну собственно сцена с тех пор пустует. Как говорится цирк уехал а клоуны остались ( привет клерк! )

| Сообщение посчитали полезным:

А не нонсенс ли - GUI на API Windows для kernel mode debugger'а?

Вспомнился анекдот про шарящего в светлом пятне от прожектора на асфальте прохожем (потерянные ключи искал).
Когда его спутник переспросил - мол, точно здесь потерял?
- тот и говорит: - да не здесь, а там, за углом.
Спутник снова спрашивает: - а чего же здесь ищешь???
Тот ему: - а того, что туда, за угол, прожектор не достаёт.

Это я к тому, что нормальный kernel mode debugger весь целиком должен находиться в kernel-mode драйвере. Вспомните тот же Soft-ICE. (Про "удалённую отладку" я не говорю, хотя тут, похоже, речь ведётся именно о ней... )
Близок к пониманию сути проблемы Dr0p, но сделать GUI без WinAPI одному человеку тяжеловато...

| Сообщение посчитали полезным:

dosprog пишет:
но сделать GUI без WinAPI одному человеку тяжеловато...
syser китайцы запили из двух человек на с++ )) клерку конечно такое не осилить

| Сообщение посчитали полезным:

reversecode,
по моим наблюдениям, Dr0p копает в сторону "подружить" OllyDbg с kernel-mode модулем (он и не скрывает этого).
Что-ж, если ему удастся то, что он задумал, полезная вещь может выйти, пускай и с ограниченной функциональностью.

| Сообщение посчитали полезным:

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

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

| Сообщение посчитали полезным:

dosprog

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



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

reversecode

Там всё очень тривиально есчо и криво, за исключением интерфейса. Это тяжёлая тема и реализация, что то такое Great пытался сделать. Плюсы я не знаю.

> результат будет какой то двиг который сами ручками будете подгружать подкомпиливать подзапускать и все это на подпорках

В файле регедита меняется имя и он запускается. На этом вся установка и оканчивается. На счёт сборки приведу пример. Надо отследить IOCTL в каспере, девайсы, коды и буфера. Добавляется фильтр для сервиса элементарно. Если вы смотрели сурсы, то понимаете. Для этого нужен билд.

Вас не огорчает, что тэг для кода "ASM"

| Сообщение посчитали полезным:

Достаточно взглянуть на список того, что ещё предстоит реализовать:

- attach/detach debugger
- asm command
- memcpy
- pe data access
- fpu support
- mmx support
- find asm
- find memory (pattern+wildcard)
- mov [mem],#data#,size
- getremotestring
- function parameter
- help file updates
- scripting
- thread support
- tls callbacks
- inject dll
- dump memory
- dump process
- set pe data in memory
- va to offset
- offset to va
- getapiname
- float calculations
- command help
- inject asm code
- and or xor commands
- analysis
- getlasterror
- display open handles
- build howto
- step to user code
- tracing(?)
- [OPTIONAL] child processes (TitanEngine)
- display source in PDB files (source debugging)
- patching (+save)
- handle view
- window view
- debug strings
- process privileges
- loaded modules window
- strings
- references
- callstack
- stack
- heap
- functions
- TEB/TBI
- PEB/PBI
- cpu filename+thread id
- shift+f7f8f9
- log breakpoints
- fix memory breakpoints
- membp in memmap
- command va2offset (and the other way around)
- various different float calculations
- and/or/xor/cmp with internal flags (script)
- restore window position (BridgeSetting)
- follow in dump
- opcode byte split
- middle mouse click = copy addr/bytes/disasm
- DOS name fix in Qt browse dialog
- abstractTable column names
- stack window(!)
- dump window(!!!)
- tabbed GUI (workspace+dragable windows)
- LUA/Python support
- ep break options
- live comments
- [] brackets for memory operations
- custom colours
- show export table
- find all intermodular calls
- highlight register changes (only when CIP changed also)
- PAGE UP + PAGE DOWN keys in disasm
- function lines (+database) for analysis
- 'dead' bytes custom analysis
- loops lines (+database) for analysis
- enable/disable hw+mem breakpoint

-----
EnJoy!

| Сообщение посчитали полезным: