Declare и FreeLibrary, или еще раз о вызовах DLL

[jangle]

Пример рабочего кода сможешь выложить?

Эм... Пример рабочего кода чего? LdrLoadDll()? Могу, часа через четыре, как до дома доберусь. Впрочем, если нет сорцев винды, можешь поглядеть в ReactOS, они очень похожи (но только похожи !!!). Если же ты про весь метод, то нет, не выложу.

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

[Twister]

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

Нотификации модулей и пополнения списка PEB_LDR_DATA там нет, это нужно писать.

[jangle]

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

Внедрить в собственный процесс можно?

Нотификации модулей и пополнения списка PEB_LDR_DATA там нет, это нужно писать

Так и не понял. Зачем это нужно...

[Twister]

Внедрить в собственный процесс можно?

Можно. Я же сказал - длл настраивается "у себя", а потом в настроенном виде копируется в чужой процесс (не с каждой длл такое можно провернуть). Копировать нам ничего никуда не надо, надо заюзать первую часть алгоритма.

Так и не понял. Зачем это нужно...

Чтобы ты мог юзать GetModuleHandle(), чтобы DllMain получала нотификации. Если это не нужно, то приведенного мной кода тебе будет вполне достаточно. Но тогда назревает резонный вопрос - а нафига в этом случае вообще dll нужна? Разве только что только затем, чтобы юзать чужой код не таская его "рядом"...

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

[jangle]

Можно. Я же сказал - длл настраивается "у себя", а потом в настроенном виде копируется в чужой процесс (не с каждой длл такое можно провернуть). Копировать нам ничего никуда не надо, надо заюзать первую часть алгоритма.

Какой-то пэпилац получается. Он действительно будет надежно летать во всех версиях Windows? Что-то сомнительно...

Чтобы ты мог юзать GetModuleHandle(), чтобы DllMain получала нотификации. Если это не нужно, то приведенного мной кода тебе будет вполне достаточно. Но тогда назревает резонный вопрос - а нафига в этом случае вообще dll нужна? Разве только что только затем, чтобы юзать чужой код не таская его "рядом"...

Наверное чтобы не я мог юзать GetModuleHandle, а чтобы DLL смогла получить GetModuleHandle? А то без этого, она не сможет найти свои ресурсы... Так с этим и так вроде проблем нет.. И DllMain тоже получает сообщения.
Короче понятно, что у тебя за способ. И он не самый лучший. Внедрять DLL в процесс всегда менее надежно, чем просто обрабоать ее импорт и получить указатели на функции в DLL. Ведь в этом случае, экзешник и dll "намертво" сплавлены друг-с другом, и наружу ничего не показывается. А значит нет даже потенциальных проблем с безопастностью, ограниченными правами юзеров, антивирусами и т.д.

[Twister]

Какой-то пэпилац получается. Он действительно будет надежно летать во всех версиях Windows? Что-то сомнительно...

Тебя напугали незнакомые функции? Это NativeAPI + самописный RTL. Будет ли работать полезная нагрузка сплоета где-нибудь, кроме XP - не знаю, надо тестировать. Будет ли работать настройка релоков и импортов - гарантированно. Еще раз тебе говорю, код написан действительно профессионалом. Слово RkU тебе о чем-нибудь говорит? Впрочем, ты можешь не верить на слово и проверить сам...

Наверное чтобы не я мог юзать GetModuleHandle, а чтобы DLL смогла получить GetModuleHandle?

Нет, любая нормальная библиотека не нуждается в вызове GetModuleHandle, ибо он приходит ей в DllMain в самом начале. Именно для того это нужно, чтобы ты, вызвав эту функцию, нашел свою библиотеку у себя же в АП. Ну или кто-то другой нашел

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

Вот тут я начинаю понимать, что ты малость не понял кода и того, что он делает (или вообще не смотрел). Третий раз повторяю - тебе не нужно ничего никуда внедрять, это не касается темы топика. Юзай MapLibrary() из oXueTb.dpr и радуйся жизни - она возьмет сохраненный внутри твоего же exe код dll, настроит релоки и импорты. Все!

[jangle]

Какой-то пэпилац получается. Он действительно будет надежно летать во всех версиях Windows? Что-то сомнительно...

Тебя напугали незнакомые функции? Это NativeAPI + самописный RTL. Будет ли работать полезная нагрузка сплоета где-нибудь, кроме XP - не знаю, надо тестировать. Будет ли работать настройка релоков и импортов - гарантированно. Еще раз тебе говорю, код написан действительно профессионалом. Слово RkU тебе о чем-нибудь говорит? Впрочем, ты можешь не верить на слово и проверить сам...

Ну на линейке 9x/ME точно работать не будет... И зачем использовать Native API? если в данном случае достаточно Win32 функций, чтобы твой код работал от Win95 вплоть до Win7

Нет, любая нормальная библиотека не нуждается в вызове GetModuleHandle, ибо он приходит ей в DllMain в самом начале. Именно для того это нужно, чтобы ты вызвав эту функцию нашел свою библиотеку у себя же в АП. Ну или кто-то другой нашел

Я видел кучу библиотек использующих GetModuleHandle. Да и кто при написании DLL может запретить использовать эту функцию?

[Twister]

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

Ну на линейке 9x/ME точно работать не будет...

Какая к чёрту 9x? Ты еще DOS вспомни и скажи, что и там работать не будет.

Я видел кучу библиотек использующих GetModuleHandle. Да и кто при написании DLL может запретить использовать эту функцию?

А это уже явная попытка уцепиться за последнее возможное... Ну видел ты кучу таких библиотек. И что, по твоему это говорит о компетентности их авторов? Как раз-таки наоборот, ибо в msdn английским по белому написано, что в DllMain приходит база образа. Не побоюсь выразиться в стиле Хакера: только полный идиот или полный нуб (новичок) будет вызывать GetModuleHandle для того, чтобы получить свою же базу dll. И я даже обосную почему именно так выразился: библиотеку, как и любой другой файл, можно переименовать. А теперь представь, что в коде у тебя зашито GetModuleHandle('my_cool_dll.dll'), а загружена она с именем broke_off_man.dll. Что произойдет?

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

[jangle]

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

Да нет никакого флуда, все обсуждается строго по теме топика. Да и потом в спорах рождается истина.

Какая к чёрту 9x? Ты еще DOS вспомни и скажи, что и там работать не будет.

Согласен к черту 9x. Но в то же время, MS не гарантирует, что NativeAPI будет тем-же в следующих версиях Windows. Поэтому есть ненулевой риск, что в Windows 8 твоя программа не заработает. А хороший софт, иногда очень долго живет. Мне приходилось видеть 16-разрядные Win приложения (для полиграфии) настолько удачные, что ими пользуются до сих пор.

А это уже явная попытка уцепиться за последнее возможное... Ну видел ты кучу таких библиотек. И что, по твоему это говорит о компетентности их авторов? Как раз-таки наоборот, ибо в msdn английским по белому написано, что в DllMain приходит база образа. Не побоюсь выразиться в стиле Хакера: только полный идиот или полный нуб (новичок) будет вызывать GetModuleHandle для того, чтобы получить свою же базу dll. И я даже обосную почему именно так выразился: библиотеку, как и любой другой файл, можно переименовать. А теперь представь, что в коде у тебя зашито GetModuleHandle('my_cool_dll.dll'), а загружена она с именем broke_off_man.dll. Что произойдет?

Вот только 3 примера использования GetModuleHandle в Dll

1.

Код: Выделить всё

GetModuleFileName GetModuleHandle(""), curPath, 255

2.

Код: Выделить всё

ExtractIcon(GetModuleHandle(""), szModuleName, 31)

3.

Код: Выделить всё

hBMP = LoadImage(GetModuleHandle(BYVAL NULL), zBMP_Name, IMAGE_BITMAP, 0, 0, 0) 

И что это неправильный код?

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

Это называется "студент поплыл"... Почему так разнервничался?

[Хакер]

только полный идиот или полный нуб (новичок) будет вызывать GetModuleHandle для того, чтобы получить свою же базу dll.

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

[Twister]

Поэтому есть ненулевой риск, что в Windows 8 твоя программа не заработает.

Есть 100% вероятность того, что в следующей версии оно не заработает - следующая версия не будет 32 битной

Вот только 3 примера использования GetModuleHandle в Dll

Ты немного не в ту степь полез: GetModuleHandle с параметром NULL возвратит базу exe, а не собственной dll. Как говорится, почувствуйте разницу.

Почему так разнервничался?

Нет, просто предупредил, если без объяснений топик вдруг будет закрыт. И не факт что мной.

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

Хех. По поводу сверхкомпактности: чтобы запомнить какую-либо переменную не обязательно хранить ее в секции данных. Я видел не мало примеров вирей, где в неизменяемом регистре хранился указатель на блок с данными, а данные лежали на стеке. Вот вам реальная экономия размера кода на диске. Мало того - вызов функции будет 5 байт + длина строки с именем, а запоминание переданного параметра, конечно, меньше. Но при этом же функцию в сверхкомпактном коде еще надо найти! (если же говорить об обычной длл с импортом и экспортом, то какой тут нафиг компактный код?) Так что мимо. А по поводу динамического кода: не понял о чем именно ты, поясни.

[Хакер]

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

Так это блек-блек-кодинг. Ты не напишешь подобное на Си в стиле Си, это во-первых. Ну а во-вторых, нет гарантированно неизменяемых регистров. Чтобы тонче понять намёк, представь, что 15 библиотек от разных авторов захотели заюзать такую методику.

А по поводу динамического кода: не понял о чем именно ты, поясни.

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

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

[Twister]

нет гарантированно неизменяемых регистров

Хех

push ecx
call any_api
pop ecx

Чтобы тонче понять намёк, представь, что 15 библиотек от разных авторов захотели заюзать такую методику.

Намёк остался непонятым. Не вижу никаких преград, чтобы (просто к примеру) в DllMain сохранить hModule (не суть где) и потом юзать.

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

Согласен, я уже говорил об этом.

[Хакер]

Хех

push ecx
call any_api
pop ecx

И к чему это?

Намёк остался непонятым. Не вижу никаких преград, чтобы (просто к примеру) в DllMain сохранить hModule (не суть где) и потом юзать.

Каким образом юзать?

[Twister]

И к чему это?

К саге о невозможности насильно сделать регистр неизменяемым Не в рамках VB, конечно.

Каким образом юзать?

Вместо вызова GetModuleHandle, конечно же. Ибо GetModuleHandle скажет "аля-улю", если ты загрузишь dll в свое АП не с помощью LoadLibrary/LdrLoadDll, а распасив релоки и импорты.

Дружище, я никак не могу понять куда катится дискуссия. Ну ладно jangle молод и ретив, но ты-то?

[Хакер]

К саге о невозможности насильно сделать регистр неизменяемым

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

Во-первых, как я и говорил, это не в стиле Си.
Во-вторых, самое главное: как это применимо к сверхкомпактной DLL? Где ты там будешь делать push-pop-обрамление?

Вместо вызова GetModuleHandle, конечно же.

Динамический код не знает, где находится переменная, в которой хранится база. В этом суть.

[Twister]

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

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

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

как это применимо к сверхкомпактной DLL? Где ты там будешь делать push-pop-обрамление?

Что есть по-твоему сверхкомпактная длл? PE-файл без секции данных? А может без релоков? Имхо, сверхкомпактность и PE-файл мало совместимые понятия. Я понимаю, что в длл не выйдет хранить глобальные данные на стеке, т.к. они могут быть использованы в разных потоках. Но (если говорить о конкретной задаче с поиском своей же базы) как ты собираешься гарантированно найти свой hInstance? Ведь имя длл может измениться и не совпадать с зашитым в коде? И что тогда? Решение одно - хранить глобальные данные (для сверхкомпактности указатель на них) в секции кода, что сам знаешь чем чревато.

Динамический код не знает, где находится переменная, в которой хранится база. В этом суть.

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

[0xy]

Twister
NativeAPI, опять же, не рулит в 9x.

jangle

Наверное чтобы не я мог юзать GetModuleHandle, а чтобы DLL смогла получить GetModuleHandle? (1)А то без этого, она не сможет найти свои ресурсы... (2) Так с этим и так вроде проблем нет.. (3)И DllMain тоже получает сообщения.

1. Неправда--сможет.
2. Проблем действительно нет. Но исключительно благодаря п.1.
3. Нет--в "твоем" способе--не получает. Хотя практического смысла в этом я нне вижу (может Twister объяснит?)

[Twister]

NativeAPI, опять же, не рулит в 9x.

Ну что мешает переписать данный код без использования NativeAPI? Или народ сейчас только копипастит? Если возникнут вопросы с аналогами функций для API-уровня - велком, разъясню. А конкретно по поводу 9x могу сказать вот что: последняя рабочая софтина, которая работала на этой платформе и которую я видел "в живую", встретилась мне года три назад. При этом она работала на 9x, но, естественно, не хотела на NT-линейке. Нашей фирме заказали написать аналог под NT, мало кому хотелось геморроиться с 98-ой виндой. Это был учет анализов в Республиканском Центре СПИДа города Алматы, с тех пор у меня есть база всех больных СПИДом в Казахстане по состоянию на начало 2008го. Так что делайте выводы о судьбе 9х и совместимого софта, уважаемые камрады

Хотя практического смысла в этом я нне вижу (может Twister объяснит?)

Twister уже изрядно подустал объяснять эту прописную и очевидную истину по триста раз:
Вам надо просто вызывать функции из длл? Тогда парсинг релоков и импорта ждет Вас.
Вам нужна настоящая длл, которая принимает уведомления об аттаче других модулей/создании потоков, которая преспокойно ищется с помощью GetModuleHandle? Тогда вперед за дизасм LdrLoadDll и создание своего аналога.

[Хакер]

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

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

PE-файл без секции данных? А может без релоков?

Может и без релоков, а может и с ними. Не в них дело. Переменная должна быть размещена во W-секции. Всё остальное (включая релоки) не требует W-атрибута, и может быть размещено в одной общей не-W-секции.

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

hdn: трюк насчёт забора слов

[0xy]

NativeAPI, опять же, не рулит в 9x.

Ну что мешает переписать данный код без использования NativeAPI? Или народ сейчас только копипастит? Если возникнут вопросы с аналогами функций для API-уровня - велком, разъясню.

Интересует код, совместимый с 9x

А конкретно по поводу 9x могу сказать вот что: последняя рабочая софтина, которая работала на этой платформе и которую я видел "в живую", встретилась мне года три назад. При этом она работала на 9x, но, естественно, не хотела на NT-линейке.

Не вижу в этом ни чего естественного
А софт, который молча падает в старых виндах, считаю глючным.
PS
А Total Commander "видеть в живую" не доводилось?

Хотя практического смысла в этом я нне вижу (может Twister объяснит?)

Twister уже изрядно подустал объяснять эту прописную и очевидную истину по триста раз:
Вам надо просто вызывать функции из длл? Тогда парсинг релоков и импорта ждет Вас.
(1)Вам нужна настоящая длл, которая принимает уведомления об аттаче других модулей/создании потоков, (2)которая преспокойно ищется с помощью GetModuleHandle? Тогда вперед за дизасм LdrLoadDll и создание своего аналога.

1. А имеет ли это хоть какое-то смысл "в мирных целях"?
2. Это, безусловно, нужно. Но разве это реализуется через сообщения DllMain?

[Twister]

Потому что речь о DLL, и она есть вызываемая сторона.

Мы говорим на разных языках. Я имел ввиду вполне конкретную вещь: сохранение значения hModule внутри dll во имя избежания каких-то левых вызовов GetModuleHandle. Ни больше и не меньше, пример с пушпопом демонстрировал возможность сохранения некоторого указателя, но не в случае длл, а в случае сверхкомпактного кода, к коему длл никак относиться не может по определению. То что ты это знаешь мне известно как никому. Целью было доказать, что вызывающая сторона может сохранить что угодно, если захочет.

Интересует код, совместимый с 9x.

Хех. Ну алгоритм Вам теперь известен (формат PE везде одинаков), дерзайте.

А Total Commander "видеть в живую" не доводилось?

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

А имеет ли это хоть какое-то смысл "в мирных целях"?

Винда гарантрирует стабильность при соблюдении некоторых правил. Правила эти описаны и документированы. И тонны библиотек сторонних разработчиков будут опираться на то, что все должно работать так, как описано. Вы же эти правила нарушите, если не уведомите систему о загрузке новой длл. Если длл Ваша - проблем нет, скорректируйте ее код надлежащим образом. Если не ваша - убедитесь что такой подход не нанесет вреда. Если случай общий - увы, обработкой импорта вам не добиться стабильности. Я, надеюсь, теперь ясно изъяснился по поводу "мирных целей"?

Это, безусловно, нужно. Но разве это реализуется через сообщения DllMain?

Это реализуется занесением информации о подгруженном модуле в PEB_LDR_DATA. Прочитайте же наконец то, что я тут целый день пишу. Для кого, спрашивается?

[Хакер]

Twister.

Человек создаёт DLL, в которой одна единственная функция-callback, внутри которой нужен hmodule. Человек не хочет порождать секцию данных, создавая одну глобальную переменную, и плодить релоки.

Забираешь свои слова, что этот человек идиот?

[Twister]

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

[Хакер]

Правильно, что не забираешь

Лучше вшить в код константу с базой и поставить на неё релокацию. Это съест меньше места, чем импорт GetModuleHandle и хранение собственного имени.

[Twister]

Вооот...

А еще можно заюзать вот такой способ, но только VB- и .NET-кодеры лихо отлетают:

Код: Выделить всё

function GetMyImageBase(): DWORD;
asm
push  edx

call  @@1
@@1:
pop   eax

@@2:
dec   eax
cmp   word[eax], $5A4D
jne   @@2

mov   edx, dword[eax + $3C]
cmp   word[eax + edx], $4550
jne   @@2

pop   edx
end; // Delphi сама вставит ret

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

[jangle]

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

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

[Twister]

И кстати в первом варианте DLL получить все уведомления.

Максимум что она может получить - уведомление о собственной загрузке/выгрузке. И то, если ручками сделать. В том коде, который я привел, это есть. А больше никаких уведомлений не придёт, ибо для системы это никакая не длл (тебе уже не только я об этом сказал, но так же и ТС, читай внимательнее). Будешь спорить?

[0xy]

Интересует код, совместимый с 9x.

Хех. Ну алгоритм Вам теперь известен (формат PE везде одинаков), дерзайте.

PE-формат, а также клава и монитор, действительно одинаковы во всех виндах Только как сие обстоятельство помогает достучаться до PEB_LDR_DATA в Win 9x?
А алгоритм мне, к сожалению, не прочесть (не по-русски написано )

Начал ковырять LoadLibrary, но есть препятствия, и процесс продвигается медленно... Но не факт, что функция регистрации мгодуля присутствует в экспорте Kernel...

[Twister]

Только как сие обстоятельство помогает достучаться до PEB_LDR_DATA в Win 9x?

Ну тут ничего сказать не могу. Я больше чем уверен, что ее там просто нет. Так же я уверен, что твоя поддержка 9х - чисто академический интерес. Угадал?

А алгоритм мне, к сожалению, не прочесть

Тогда вооружись описанием PE-формата. Вроде на васме был где-то неплохой документ от HardWisdom (кажись его так зовут). В свое время он и статьи Billy Belcebu мне здорово помогли. И хотя в тот документ мне приходилось позже вносить некоторые поправки и дополнения, но тебе его должно хватить "за глаза".

Начал ковырять LoadLibrary, но есть препятствия, и процесс продвигается медленно...

Зачем тебе LoadLibrary? Я же говорил выше что надо ковырять.

Но не факт, что функция регистрации мгодуля присутствует в экспорте Kernel

Факт - ее там нет. Нет и в экспорте ntdll. Ее надо искать. За советом как это сделать - велком.

ЗЫ. Здесь и далее подразумевается, что все мной сказанное относится к линейке NT и только к ней.