Допустим программа использует TLS callback для своих целей (защиты от исследователя и т.к.).
Если этот TLS callback создан статически, то обнаружить его не составляет труда. (Что делает сама callback функция - это другое дело...)
А вот если TLS callback функции создаются динамически статической callback функцией или в процессе исполнения программы подгружается динамическая библиотека, создающая callback функции, то как быть в таком случае?
Пока единственное известное мне решение - это остановка на system entry breakpoint in ntdll.dll с последующей трассировкой через процесс создания этого самого динамического callback_а.
Путь этот довольно громоздкий и не самый элегантный.
Может быть кто-нибудь подскажет что-то лучшее?

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

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

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

А вообще, что это за динамическое создание callback? Насильное вписывание tls callback в память?
Хз как вообще это будет работать на многих системах.. Но все равно, можно но же просто перебрать все модули на Entry Point (не на System Entry Breakpoint) и проанализировать их tls в памяти на предмет callback.

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

plutos
можно заюзать в TLS колбеке некоторые возможности сис лоадера, котрые приведут к EP но уже после выполнения почти любого кодеса, я не видел юзермодных отладчиков это ловящих. К примеру взять FastPebLockRoutine+RtlAcquirePebLock в колбеке TLS, но там есть тонкости. [Раньше использовал когда -то в одном крипторе но с чеком на wow, актуально и по ныне вроде, проходит AV-эмуляцию, которую же отлаживают на тех же отладчиках].

-----
продавец резиновых утёнков

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