Добрый день!
Решил пуститься во все тяжкие, спасибо Bad_guy и его курсу.
Запускаю процесс хакер, запускаю интересующую меня программу, нахожу свою прогу, лезу в свойства=>потоки.
Вываливается информация типа: wow64cpu.dll!TurboDispatchJumpAddressEnd+0x536 и много чего еще...
Вопрос в следующем: вот эти все функции относятся к моей программе или
меня должны интересовать только функции типа "моя программа"+****h или "моя программа"!функция,
а остальные dll ее не касаются? Как трактовать эту информацию и отсеять ненужное?
Заранее благодарен.

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

GudBoy пишет:
остальные dll ее не касаются?

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

-----
Give me a HANDLE and I will move the Earth.

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

plutos пишет:
почитай про структуру windows
Большое спасибо за быстрый ответ, хотелось бы уточнить вот какой момент:
Как мне кажется, самописная программа может вызвать виндовую функцию обратившись к тем же самым dll.
А если так, то они по идее при запуске программы тоже могут подгружаться в память и ждать своего звездного часа.
Если допустить такой вариант, как будет выглядеть такой вызов в оперативке?
Я к тому, что "наша программа" по идее является родительской для виндовой функции.
А как это будет выглядеть в оперативке? "Наша программа".dll.вин_функция ?

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

если вы хотите заниматься RE серьезно, то уделите время и заложите базу. После того, как вы прочтете что-то капитальное, ваши вопросы (по крайней мере большинство простых) отпадут сами собой.
А в данный момент вы сильно забежали вперед и вокруг темнота. Это вполне естественно и тут нет ничего обидного: все где-то начинают.
Но, чем больше времени вы потратите на изучение основ, тем легче вам будет "в бою".

--> Windows via C/C++, Fifth Edition by Jeffrey Richter<--

--> mark russinovich windows internals <--
Ну и assembly language, в сети туториалов море, я бы посоветовал --> Iczelions Win32 Assembly Tutorials <--

GudBoy пишет:
"Наша программа".dll.вин_функция ?

"наша программа" не будет иметь dll extension, если только она не задумана нами с самого начала как dll.
Скорее всего, это будет "our_program.exe" или "our_program.dll" (если пишем dll).
Если мы хотим использовать не нами написаную функцию, а функцию, написаную за нас программистами микрософта, то мы должны динамично подгрузить длл, в которой эта функция находится.
Пример:
Address Hex dump Command Comments
00401D80 |. FF15 54A04000 CALL DWORD PTR DS:[<&KERNEL32.IsDebuggerPresent ; [KERNEL32.IsDebuggerPresent]

Мы вызываем функцию "IsDebuggerPresent" из системной библиотеки KERNEL32.dll (this dll is loaded by default, others require special code to be loaded)

if "our_program.exe" contains "our_function()", => "our_program.our_function".

-----
Give me a HANDLE and I will move the Earth.

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

GudBoy

> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x536 и много чего еще...

Это интерфейс между ядерными вызовами в различных режимах, это тем более тебе не нужно.

-----
vx

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

GudBoy пишет:
Как трактовать эту информацию и отсеять ненужное
Потоки может создать любой модуль(библиотека), если тебя интересуют только свои потоки, то смотри программа.exe+адрес или !функция (если есть отладочная инфа).
Если программа однопоточная, то будет только один главный поток программа.exe EntryPoint (его создает и запускает загрузчик PE).
Конкретно wow64.dll это часть прослойки для работы 32-битных приложений на 64-битной системе, ее потоки тебе вряд ли нужны.
GudBoy пишет:
А как это будет выглядеть в оперативке
У каждого потока есть свой отдельный стек, когда вызывается какая-то функция процессору нужно знать куда вернуться после того как функция исполнится, поэтому перед передачей управления вызываемой функции, он сохраняет адрес возврата (зачастую инструкцией call), а затем после выполнения вызываемая функция передаст управление по адресу возврата (зачастую инструкцией retn).
Чтобы посмотреть цепочку адресов возврата потока можно кликнуть дважды на поток, но стоит учитывать ограниченность такой информации.
Во первых это снимок в один конкретный момент, например если функция уже вернулась, то информации о ней не будет.
Во вторых информация о функции будет только если она что-то вызывает, иначе ее адрес возврата не положится в стек.
Чтобы получить больше инфы о вызовах можно юзать монитор API, там будет полноценное логирование вызываемых API функций.

-----
В облачке многоточия

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

Уффф...!!! Спасибо всем откликнувшимся. Многое стало понятным.
Надеялся, что дела обстоят несколько проще, да не тут то было. Ну, тем интереснее...
Осталось почитать про ассемблер, PE-файлы, подучить winAPI, системные библиотеки,
инструменты исследователя, желательно освоить С/С++, Delphi, англицкий подтянуть
Успокаивает, что всего этого не по много, штук по 500
Пойду подтягивать матчасть...

Добавлено спустя 26 минут
plutos пишет:
мы должны динамично подгрузить длл, в которой эта функция находится.
Вот я по простоте душевной и думал, что можно подсмотреть неугодные модули во время работы программы в оперативке,
а потом как то вычистить их в коде. Единственно, не учел, что модули могут подгружаться динамически и в оперативке их сразу можно и не обнаружить.

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

А какие именно модули и чем вам не угодили?

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

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

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

_MBK_ пишет:
А какие именно модули и чем вам не угодили?
В моем конкретном случае - это запросы серийников железа (и не только) для формирования HWID.
Все антиотладочные примочки.

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

GudBoy пишет:
освоить С/С++, Delphi, англицкий подтянуть
Только в обратном порядке..

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

GudBoy пишет:
В моем конкретном случае - это запросы серийников железа (и не только) для формирования HWID.
Все антиотладочные примочки.
Тогда однозначно юзайте API-монитор, просмотр стека вряд ли чем-то поможет.
Если нужно узнать детально что происходит, то только анализ, статический можно через IDA Pro, динамический через X64Dbg, для обоих нужны некоторые знания реверса (зависит от типа защиты).
GudBoy пишет:
инструменты исследователя, желательно освоить С/С++, Delphi, англицкий подтянуть
Не зацикливайтесь на получении кучи навыков, они должны приобретаться по пути.
Английский не строгая необходимость, инфы и на русском полно.
На дельфи не тратьте время, C++ легко его переплюнет.

-----
В облачке многоточия

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

Boostyq пишет:
Не зацикливайтесь на получении кучи навыков
Пока проблему вижу в следующем: начинаешь читать "с чего начать?" к примеру - начинаешь начинать. По ходу этих начинаний натыкаешься на какую-нибудь "подробнее вот об этом самом тут...",
как примерный ученик переходишь на "тут...." и окунаешься в дебри на тему далекую от "с чего начать?". И вроде бы нужно все, а по факту сконцентрироваться на чем то одном не получается. Какую тему не тронь, везде нужны доп. знания на смежную тему. И так по кругу. Ссылок, литературы уйма, но пока их все освоишь, опля... а архитектура 64 уже устарела. Не даром же пишут, что у начинающего крякера уже должны быть навыки распаковки и борьбы с протекторами. Уже без этого никак. Это не винрар по книжке ломануть старой версии, не запакованный. Требования к новичку растут с каждым днем...
Я не жалуюсь, так... мысли в слух... решил пожалеть себя маленько

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

GudBoy пишет:
сконцентрироваться на чем то одном не получается
Потому что это невозможно сделать, у любой темы очень много референсов, изучать нужно необходимое для решения конкретной задачи, остальное факультативно.
GudBoy пишет:
архитектура 64 уже устарела
Не думаю что это произойдет скоро, куча кода работает на этой архитектуре.
Если вендоры сделают вдруг новую архитектуру и дропнут поддержку x86, то переход будет очень болезненный, если вообще будет востребован.
С начала создания и до сих пор они почти всегда сохраняли обратную совместимость, именно поэтому x86 это один большой костыль.
К тому же знания о любой архитектуре помогут в изучении новых, а x86 сейчас одна из наиболее актуальных архитектур.

-----
В облачке многоточия

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

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

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

GudBoy

> Какую тему не тронь, везде нужны доп. знания на смежную тему. И так по кругу.

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

> архитектура 64 уже устарела.

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

> должны быть навыки распаковки и борьбы с протекторами.

А что это.. обычно это набор тулз.

-----
vx

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

difexacaw пишет:
Смайлик бы какой поставил..
Все исключительно с улыбкой
Впрочем - это совсем другая история. Про потоки начали, а сейчас понесло нас куда то...
Всем спасибо, что откликнулись

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

plutos пишет:
--> mark russinovich windows internals <--
Нашел книгу руссиновича на русском языке: 7 издание 2018 г. "Внутреннее устройство Windows"
К сожалению только 1 часть на 900 страниц примерно. 2-я часть этой книги в переводе пока недоступна, насколько я понял.

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

GudBoy пишет:
К сожалению только 1 часть на 900 страниц примерно. 2-я часть этой книги в переводе пока недоступна, насколько я понял.
Так на 942 странице как раз заключение, какая еще вторая часть О_о
И если бы она и была, ты вначале прочти первую часть, а не занимайся сбором коллекции.

-----
В облачке многоточия

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

Boostyq пишет:
какая еще вторая часть О_о

Windows Internals, Part 2 (7th Edition) (Developer Reference)

by Mark E. Russinovich , Andrea Allievi, et al. | Jul 16, 2020

Boostyq пишет:
И если бы она и была, ты вначале прочти первую часть

Agreed!

-----
Give me a HANDLE and I will move the Earth.

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

Boostyq пишет:
И если бы она и была, ты вначале прочти первую часть, а не занимайся сбором коллекции
Именно этим я сейчас и занимаюсь, в смысле не сбором коллекции, а изучением 1 части книги.
plutos дал ссылку на англицкий вариант, я счел нужным поделиться на форуме находкой на русской языке. Хотел торент прикрепить, не знаю можно ли на форуме.
Так или иначе, если сами не найдете, пишите в личку.

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