Есть приложение, написанное с использованием .NET Core, можно ли его исследовать чем-то, как например, исследуются нет ассембли Reflectorом?

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

А .Net Core тем же dnSpy разве не открывается?
Сам отвечу на свой вопрос - не открывается...
P.S. Открывается, только не .exe надо открывать, а "соседний" .dll.

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

del

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

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

дай таргет посмотреть
http://prntscr.com/npo6xb

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

Medsft, https://prnt.sc/nppoil
При том нигде в настройках и ни в каких других выборах языка Net Core не упоминается.
P.S. Скомпилированные приложения вообще не определяется как .Net приложение:


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

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

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

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. Вопрос к админам форума
Как понизить карму человеку на этом форуме.

Хороший вопрос...

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

Adler ну так открывается net core в dnspy?))

Добавлено спустя 3 минуты
Adler пишет:
Я упустил, что исходник надо не в .exe искать, а в соседней .dll молодец что не постеснялся

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

Medsft, меня сам dnSpy с толку и сбил, когда его же .exe я в нем попробовал и открыть, а он меня лесом послал, т.к.


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

Заглушка чтобы не писать в cmd dotnet dnspy. Dll

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

А .NET Core разве не в нативный код компилится?

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

jangle, нет. Технология компиляции в нативный код - .Net Native и работает это только для UWP приложений.
Выше же два примера .Net Core выложено...

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

Да спутал с CoreRT, это он в натив компилится

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

Adler пишет:
P.S. Открывается, только не .exe надо открывать, а "соседний" .dll.

Это в хорошем случае, а обычно - нет там рядом соответствующей длл, есть эхэ - скажем 50 мб и стадо длл для поддержки коре

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

win32nipuh пишет:
Это в хорошем случае, а обычно - нет там рядом соответствующей длл, есть эхэ - скажем 50 мб и стадо длл для поддержки коре
Где на такое посмотреть? Примером можно в меня кинуть?

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

Adler

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

-----
vx

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

difexacaw пишет:
Конечный код может быть нэйтив, либо вирт
С коробки?

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

Чтото я это детский сад из виду упустил.
1) Net Core сборка компилится в в формат PE - dll, на данный момент релиза NET Core делающую Вашу сборку нативным приложением не существует (и в обозримом будущем не предвидится). Стандартными средствами сделать Net Core сборку в формате exe - НЕЛЬЗЯ
2) Также нет оф.релиза реализующего взаимодествие с WinForms тоже нет (- это обещают в NET Core 3.0 к сентябрю месяцу).(Превью не в счет)

difexacaw пишет:
это говно - не говно!! и в ряде случаев по производительности идет в ногу с нативными приложениями

difexacaw пишет:
Платформа net для формошлёпного создания приложений тут можно спорить бесконечно НО формы тоже иногда нужны

win32nipuh пишет:
а обычно - нет там рядом соответствующей длл, есть эхэ - скажем 50 мб либо ты из тех кто торопится что нибудь написать в чат, либо ищи boxer.

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

Medsft

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

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

Дело в том, что это потенциальная уязвимость - динамические буфера, туда что то собирается, никаких проверок безопасности, короче говоря рассадник заразы. Достаточно посмотреть сколько всякой дряни загружается и какие ивраты в памяти это всё делает. Знаю, так как немного поотлаживал, что бы реализовать криптование таких апп через анклавы --> Link <--

В принципе можно зашифровать целиком образ как массив данных. Просто идеально для обхода ав.

-----
vx

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

Adler пишет:
win32nipuh пишет:
Это в хорошем случае, а обычно - нет там рядом соответствующей длл, есть эхэ - скажем 50 мб и стадо длл для поддержки коре
Где на такое посмотреть? Примером можно в меня кинуть?

Например,
postgrescompare.com

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

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

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

Это ?
А с чего вы взяли, что это вообще .Net Core? api-ms-win-crt-*.dll и api-ms-win-core-*.dll это вроде как из состава Microsoft Visual C++ Runtime Library.
И похоже, что там Cef встроен (судя по некоторым файлам в папке, программу вообще не запускал). Из явно .Net там только squirrel.exe

P.S. Если речь о содержимом папки \resources\server\, то там все типично:


PostgresCompareWebApi.dll открывается любым .Net декомпилятором - тыц.

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

difexacaw пишет:
Конечный код может быть нэйтив, либо вирт. Обычно это данные для вирт машины, она крутит это говно.

В .NET нет никакой виртуальной машины. Бинарные сборки EXE и DLL хранятся в виде скомпилированного MSIL кода, который при запуске компилируется JIT-компилятором в нативный образ, который потом запускается на исполнения. Никакого механизма непосредственного "исполнения MSIL кода" в .NET не существует. Это не Java-bytecode где при нехватки ресурсов для JIT-компиляции, байт-код может фигачится на стековой машине.

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

difexacaw пишет:
Время апп не определяется каким то повторяю я не буду спорить с Вами по поводу производительности, слишком много потенциальных ветвлений будущем споре (одно могу сказать что если мериться на примере кода в 20 строк... то asm безусловно выиграет, преимущество NET в оптимизации кода под конкретную архитектуру для каждой физ. машины)

win32nipuh пишет:
Например,
postgrescompare.com Adler Ваш вопрос хорошо разрулил.

jangle пишет:
В .NET нет никакой виртуальной машины. Добавлю откуда-то... специально для difexacaw
Цитата откуда-то
"
1.Полностью скомпилированный код выполняется процессором напрямую, а не интерпретируется или переводится с помощью дополнительного слоя абстракции программного обеспечения, который должен быть быстрее.
2.Компилятор JIT может использовать преимущества оптимизации, характерные для отдельной машины, запускающей программу, а не для определения самого низкого общего знаменателя.
"
Инкапсуляция присутсвует с этим не спорю

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

Компиляция в привычном значении это сборка всего целого и исполнение. Этот же net непрерывно выбирает данные(msil") из баз(нп образа) и транслирует их. Как там это происходит никакого значения не имеет - трансляция или компиляция каких то блоков повторная. Есть данные и огромный поток их выборок, никакое это не исполнение после компиляции!

Вот открыл отладчиком paint.net, такое толстое что отладчик висит. Для примера беру mscorjit.dll - часть платформы, для него есть дебаг символы. Смотрим число выборок только из этого модуля в образ апп ~110K и это только на этапе запуска(до отрисовки гуя) из небольшого числа мест(~40 адресов) в основном в символах это Compiler::impImportBlockCode

О какой оптимизации может идти речь, если это транслятор/интерпретатор называйте как угодно.

-----
vx

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

Medsft пишет:
.Компилятор JIT может использовать преимущества оптимизации,

Чето я сомневаюсь, что JIT что-то может оптимизировать. У него на это просто нет времени. Ему надо прогу скомпилировать и запустить максимально быстро, а не оптимизации крутить.

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

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

"О какой оптимизации может идти речь" - к Вам это тоже относится.

В краце механизм: NET приложение -> запускаем -> (внутри NET -> 1 проход -> prepare methods (еще ничего не компилируется НО выделяется пространство .. пока число обращений к образу огромное) -> а дальше магия -> компилятор строит цепочки вызовов msil методов и при вызове любого компилирует всю цепочку в натив, после этого вы больше не увидите обращения к этому куску msil кода.... не факт ... что компилятор при первом вызове любого элемента образа откомпилирует все содержимое в натив возможно это будет часть, а значит обращение к образу еще могут быть...... НО .... количество обращений должно падать на протяжении активности процесса и сойти на полный ноль.

"О оптимизации" еще раз... каждый раз откомпилированный код для каждой физ машины будет разный в зависимости от архитектуры

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

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.

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

Medsft

> В краце механизм

Этот механизм, вы придумали, тоесть по вашему оно так должно работать ?

Это не соответствует реальности. NET так не работает. Транслятор непрерывно выбирает данные из образа. Открой да сам посмотри, вернёшься заодно к реалу. Я этот транслирующий мусор пытался собрать --> Link <--

-----
vx

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

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.

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

Adler пишет:
Аааа, ну это прямо все меняет Хотя..

Не знаю, меняте или нет, но выс просили - я ответил, не вижу проблемы.
В том наборе длл нет NET, т.е. таких, которые открываются dnSpy

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