eXeL@B —› Вопросы новичков —› Как дизассемблировать приложение .NET Core? |
. 1 . 2 . >> |
Посл.ответ | Сообщение |
|
Создано: 16 мая 2019 09:42 · Личное сообщение · #1 Есть приложение, написанное с использованием .NET Core, можно ли его исследовать чем-то, как например, исследуются нет ассембли Reflectorом? | Сообщение посчитали полезным: Medsft |
|
Создано: 16 мая 2019 09:47 · Поправил: Adler · Личное сообщение · #2 |
|
Создано: 16 мая 2019 10:32 · Поправил: plutos · Личное сообщение · #3 |
|
Создано: 17 мая 2019 09:35 · Поправил: Medsft · Личное сообщение · #4 |
|
Создано: 17 мая 2019 11:28 · Поправил: Adler · Личное сообщение · #5 Medsft, При том нигде в настройках и ни в каких других выборах языка Net Core не упоминается. P.S. Скомпилированные приложения вообще не определяется как .Net приложение: |
|
Создано: 17 мая 2019 17:59 · Личное сообщение · #6 Adler 1. Net.Core не поддерживает WinForms - это с твоего скрина 2. В Net.Core не бывает exe файлов 3. Net.Core это не язык программирования а FrameWork 4. Прикрепил нормальное приложение на Net.Core. P.S. Вопрос к админам форума Как понизить карму человеку на этом форуме. b235_17.05.2019_EXELAB.rU.tgz - NetCoreTest.dll |
|
Создано: 17 мая 2019 21:15 · Поправил: Adler · Личное сообщение · #7 Medsft, а Поизучайте на досуге - ae8c_17.05.2019_EXELAB.rU.tgz - TestNetCoreWindowsForm.7z И компилируется это в .dll + .exe. ВЫ сперва как что то утверждать, сперва хотя бы погуглили. Я и не писал, что Net Core это язык, я имел ввиду, то что при выборе другого языка "Net Core" не появляется нигде, имея ввиду, что возможно Net Core только в IL, к примеру, разбирается. Я упустил, что исходник надо не в .exe искать, а в соседней .dll, т.к смотрел на dnspy с кучей файлов и это как то не очевидно. И судя по первому посту, то не только я... Medsft пишет: P.S. Вопрос к админам форума Как понизить карму человеку на этом форуме. Хороший вопрос... |
|
Создано: 18 мая 2019 00:34 · Личное сообщение · #8 |
|
Создано: 18 мая 2019 01:05 · Поправил: Adler · Личное сообщение · #9 |
|
Создано: 19 мая 2019 18:17 · Личное сообщение · #10 |
|
Создано: 25 мая 2019 08:09 · Личное сообщение · #11 |
|
Создано: 25 мая 2019 08:14 · Поправил: Adler · Личное сообщение · #12 |
|
Создано: 25 мая 2019 11:00 · Личное сообщение · #13 |
|
Создано: 28 мая 2019 20:05 · Личное сообщение · #14 |
|
Создано: 28 мая 2019 20:30 · Личное сообщение · #15 |
|
Создано: 28 мая 2019 20:41 · Личное сообщение · #16 Adler Чувак ты бредишь. Платформа net для формошлёпного создания приложений, но дело не в этом. Конечный код может быть нэйтив, либо вирт. Обычно это данные для вирт машины, она крутит это говно. Сам же модуль не содержит никаких полезных данных. Эта погань толстая и с ней идут в комплекте десятки модулей с таким же говном. Такие модуля не содержат код, только данные. Это значит что это говно можно криптовать как массив данных. ----- vx |
|
Создано: 28 мая 2019 20:43 · Личное сообщение · #17 |
|
Создано: 29 мая 2019 12:02 · Личное сообщение · #18 Чтото я это детский сад из виду упустил. 1) Net Core сборка компилится в в формат PE - dll, на данный момент релиза NET Core делающую Вашу сборку нативным приложением не существует (и в обозримом будущем не предвидится). Стандартными средствами сделать Net Core сборку в формате exe - НЕЛЬЗЯ 2) Также нет оф.релиза реализующего взаимодествие с WinForms тоже нет (- это обещают в NET Core 3.0 к сентябрю месяцу).(Превью не в счет) difexacaw пишет: это говно - не говно!! и в ряде случаев по производительности идет в ногу с нативными приложениями difexacaw пишет: Платформа net для формошлёпного создания приложений тут можно спорить бесконечно НО формы тоже иногда нужны win32nipuh пишет: а обычно - нет там рядом соответствующей длл, есть эхэ - скажем 50 мб либо ты из тех кто торопится что нибудь написать в чат, либо ищи boxer. |
|
Создано: 30 мая 2019 17:45 · Поправил: difexacaw · Личное сообщение · #19 Medsft > по производительности идет в ногу с нативными приложениями Время апп не определяется каким то слоем интерпретатора. Потоки большую часть времени в гуй апп ждут событий. Дело в том, что это потенциальная уязвимость - динамические буфера, туда что то собирается, никаких проверок безопасности, короче говоря рассадник заразы. Достаточно посмотреть сколько всякой дряни загружается и какие ивраты в памяти это всё делает. Знаю, так как немного поотлаживал, что бы реализовать криптование таких апп через анклавы В принципе можно зашифровать целиком образ как массив данных. Просто идеально для обхода ав. ----- vx |
|
Создано: 02 июня 2019 10:28 · Личное сообщение · #20 Adler пишет: win32nipuh пишет: Это в хорошем случае, а обычно - нет там рядом соответствующей длл, есть эхэ - скажем 50 мб и стадо длл для поддержки коре Где на такое посмотреть? Примером можно в меня кинуть? Например, postgrescompare.com там триал, в составе один большой эхэ и туча платформных длл для поддержки |
|
Создано: 02 июня 2019 11:13 · Поправил: Adler · Личное сообщение · #21 win32nipuh пишет: там триал, в составе один большой эхэ и туча платформных длл для поддержки А с чего вы взяли, что это вообще .Net Core? api-ms-win-crt-*.dll и api-ms-win-core-*.dll это вроде как из состава Microsoft Visual C++ Runtime Library. И похоже, что там P.S. Если речь о содержимом папки \resources\server\, то там все типично: PostgresCompareWebApi.dll открывается любым .Net декомпилятором - |
|
Создано: 03 июня 2019 09:16 · Личное сообщение · #22 difexacaw пишет: Конечный код может быть нэйтив, либо вирт. Обычно это данные для вирт машины, она крутит это говно. В .NET нет никакой виртуальной машины. Бинарные сборки EXE и DLL хранятся в виде скомпилированного MSIL кода, который при запуске компилируется JIT-компилятором в нативный образ, который потом запускается на исполнения. Никакого механизма непосредственного "исполнения MSIL кода" в .NET не существует. Это не Java-bytecode где при нехватки ресурсов для JIT-компиляции, байт-код может фигачится на стековой машине. |
|
Создано: 03 июня 2019 11:52 · Поправил: Medsft · Личное сообщение · #23 difexacaw пишет: Время апп не определяется каким то повторяю я не буду спорить с Вами по поводу производительности, слишком много потенциальных ветвлений будущем споре (одно могу сказать что если мериться на примере кода в 20 строк... то asm безусловно выиграет, преимущество NET в оптимизации кода под конкретную архитектуру для каждой физ. машины) win32nipuh пишет: Например, postgrescompare.com Adler Ваш вопрос хорошо разрулил. jangle пишет: В .NET нет никакой виртуальной машины. Добавлю откуда-то... специально для difexacaw Цитата откуда-то " 1.Полностью скомпилированный код выполняется процессором напрямую, а не интерпретируется или переводится с помощью дополнительного слоя абстракции программного обеспечения, который должен быть быстрее. 2.Компилятор JIT может использовать преимущества оптимизации, характерные для отдельной машины, запускающей программу, а не для определения самого низкого общего знаменателя. " Инкапсуляция присутсвует с этим не спорю |
|
Создано: 03 июня 2019 13:55 · Поправил: difexacaw · Личное сообщение · #24 Компиляция в привычном значении это сборка всего целого и исполнение. Этот же net непрерывно выбирает данные(msil") из баз(нп образа) и транслирует их. Как там это происходит никакого значения не имеет - трансляция или компиляция каких то блоков повторная. Есть данные и огромный поток их выборок, никакое это не исполнение после компиляции! Вот открыл отладчиком paint.net, такое толстое что отладчик висит. Для примера беру mscorjit.dll - часть платформы, для него есть дебаг символы. Смотрим число выборок только из этого модуля в образ апп ~110K и это только на этапе запуска(до отрисовки гуя) из небольшого числа мест(~40 адресов) в основном в символах это Compiler::impImportBlockCode О какой оптимизации может идти речь, если это транслятор/интерпретатор называйте как угодно. ----- vx |
|
Создано: 03 июня 2019 14:35 · Личное сообщение · #25 |
|
Создано: 05 июня 2019 14:55 · Личное сообщение · #26 "что "О какой оптимизации может идти речь" - к Вам это тоже относится. В краце механизм: NET приложение -> запускаем -> (внутри NET -> 1 проход -> prepare methods (еще ничего не компилируется НО выделяется пространство .. пока число обращений к образу огромное) -> а дальше магия -> компилятор строит цепочки вызовов msil методов и при вызове любого компилирует всю цепочку в натив, после этого вы больше не увидите обращения к этому куску msil кода.... не факт ... что компилятор при первом вызове любого элемента образа откомпилирует все содержимое в натив возможно это будет часть, а значит обращение к образу еще могут быть...... НО .... количество обращений должно падать на протяжении активности процесса и сойти на полный ноль. "О оптимизации" еще раз... каждый раз откомпилированный код для каждой физ машины будет разный в зависимости от архитектуры | Сообщение посчитали полезным: plutos |
|
Создано: 05 июня 2019 18:13 · Личное сообщение · #27 Adler пишет: А с чего вы взяли, что это вообще .Net Core? api-ms-win-crt-*.dll и api-ms-win-core-*.dll это вроде как из состава Microsoft Visual C++ Runtime Library. И похоже, что там Cef встроен (судя по некоторым файлам в папке, программу вообще не запускал). Из явно .Net там только squirrel.exe Во-первых мне автор сказал, я знаю его. Во-вторых, если студией VS2017/2019 сделать .NET Core крос-платформ приложение, скажем, с ипсользованием electron, то будет то, что в postgrescompare. |
|
Создано: 05 июня 2019 19:29 · Личное сообщение · #28 Medsft > В краце механизм Этот механизм, вы придумали, тоесть по вашему оно так должно работать ? Это не соответствует реальности. NET так не работает. Транслятор непрерывно выбирает данные из образа. Открой да сам посмотри, вернёшься заодно к реалу. Я этот транслирующий мусор пытался собрать ----- vx |
|
Создано: 05 июня 2019 19:31 · Поправил: Adler · Личное сообщение · #29 win32nipuh, дык, так что вас в моем ответе не устроило? Там четко видно, где C++, а где .Net, открываемый обычным dnSpy? win32nipuh пишет: Во-первых мне автор сказал, я знаю его. Аааа, ну это прямо все меняет Хотя... Electron вообще написан на смеси C++, JavaScript, Python, есть реализация (не совсем то слово, но другого не придумал) ElectronNET где черным по Electron.NET is a wrapper around a "normal" Electron application with an embedded ASP.NET Core application. Via our Electron.NET IPC bridge we can invoke Electron APIs from .NET. |
|
Создано: 05 июня 2019 21:47 · Личное сообщение · #30 |
. 1 . 2 . >> |
eXeL@B —› Вопросы новичков —› Как дизассемблировать приложение .NET Core? |