Объявление

Свернуть
Пока нет объявлений.

dotNET проблема в получении пути сборки

Свернуть
X
 
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

    dotNET проблема в получении пути сборки

    столкнулся с проблемой, которая только от отчасти связана с реверсом, но где еще спросить не знаю...
    в общем есть цель - написана на dotNet. использую лоадер (написан на Delphi), который через CreateProcess запускает цель и внедряет в нее dll-патчер (так же на Delphi), которая дожидается загрузки нужных системных модулей и патчит их.... но это не суть
    цель в процессе лицензирования проверяет SHA256 от строки пути по которому расположена она и другие dll. Путь получается следующим образом Path.GetDirectoryName(Assembly.GetExecutingAssembl y().Location)).
    И тут у меня возникла проблема:
    Если пользоваться обычным Проводником и запускать цель напрямую или через лоадер, то получаю путь "C:\Program Files (x86)\XXX\xxx.exe"
    Если пользоваться TotalCommander и запускать цель напрямую, то так же все хорошо
    Но вот если запустить цель через лоадер в TotalCommnader, то путь становится уже "c:\Program Files (x86)\XXX\xxx.exe" (буква диска в нижнем регистре, а не в верхнем). Соответственно получаем другой результат хэша и процесс лицензирования проваливается.
    Я два дня мучился и не могу понять в чем проблема, почему не работает код хотя его уже много раз перепроверил и почему все работает в отладчике, а через лоадер нет, пока не нашел такую подставу. И теперь не могу понять в чем проблема: в TT или в моем лоадере? и как это исправить.
    При этом если получать путь в самом лоадере, то он получается как нужно с большой буквы, и не зависимо был ли он запущен в Проводнике или в ТТ.

    #2
    Всегда можно попробовать отладить проводник/TC и скопи-пастить оттуда запуск процесса 1-в-1. А вообще можно багрепорт разрабам отписать, с чего они закладываются на регистр в ОС, где регистр значения не имеет, и пусть правят сами. Варианты написания разные, от "я тут что-то переименовал, но вернул обратно и ничего не работает" до "я тут хечил ваш софт, и он коряв".

    Комментарий


      #3
      в общем это баг или особенность TC
      и я забыл добавить, что цель это консольное приложение
      я попробовал запустить консоль через Проводник или Пуск и в этом случае путь в консоли отображается с буквой диска в верхнем регистре
      а если запустить консоль в TC, то путь в ней отображается с буковой диска в нижнем регистре

      Комментарий


        #4
        Archer же уже написал выше.
        Баг в софтине которую ты ковыряешь, а не в ТС.
        В Windows пути регистронезависимые, софтина это не учитывает.
        И что вообще за бред привязываться к хешу от пути установки?
        Поставил софтину в другой каталог и всё, ключ не валидный?
        Ну и кто мешает в лоадере букву диска в верхний регистр привести?

        Комментарий


          #5
          cppasm
          софтина тут ни причем. это какой-то нюанс TC. сделал свою консольную приложуху которая просто выводит Path.GetDirectoryName(Assembly.GetExecutingAssembl y().Location)) - результат аналогичный
          зачем разрабы сделали эти заморочки с хэшем пути, я сам не понимаю.
          и вот скрин просто двух консолей. первая запущена через Пуск, вторая через TC, т.е. явно причина в TC.

          но опять же в приложении нижний регистр появляется только, если его запустить через лоадер в TC

          Комментарий


            #6
            Если ты один хрен лодырем патчишь процесс, что мешает подсунуть нужный путь на уровне апи или дотнета?
            2 оттенка серого

            Комментарий


              #7
              Напишите Гислеру письмо...

              Комментарий


                #8
                "и почему все работает в отладчике" - ?
                Потому, что отладчик инициализирует
                1. НЕ инициализированный сегмент

                * НЕ инициализированный сегмент - это то место где содержится все кроме чистого пространства - нуля.

                Значит - ЧТОБЫ - программа работала не только в отладчике - нужно:

                a) Найти участок где требуется обнулить переменную memset(a,0.2) ...

                и т.п.

                Комментарий


                  #9
                  Сообщение от zds
                  софтина тут ни причем.
                  Как это не при чём, если она заточена под букву диска в верхнем регистре? Это косяк.
                  Ещё раз - C:\MyAPP, c:\MyApp и c:\mYaPP это один и тот же путь, и если софтина этого не учитывает - косяк в ней.
                  Надо toupper() или tolower() к пути тогда применять перед получением хэша.

                  То что ты получаешь через Path.GetDirectoryName(Assembly.GetExecutingAssembl y().Location)) это скорее всего то, что передаётся процессу при запуске как первый параметр командной строки (argv[0]).
                  Твой лоадер откуда-то берёт путь по которому запускает модуль приложения, скорее всего из того же argv[0] лоадера.
                  Вот перед вызовом модуля приложения приведи в этом пути букву диска к верхнему регистру и всё.
                  А то что Проводник передаёт в пути букву диска в верхнем регистре, а ТС в нижнем - это просто особенности реализации.
                  Какой-нибудь новый билд Проводника тоже может завтра начать передавать путь в нижнем регистре - и что с того?

                  Комментарий


                    #10
                    cppasm
                    да, спс
                    пинок был в нужном направлении.
                    Я запускал приложение в лоадере через CreateProcess по относительному пути, а точнее просто по имени. Сделал запуск по абсолютному пути с верхним регистром буквы диска и все встало на место.

                    Сделал тестовое приложение и запускал его без всяких лоадеров напрямую из консолей, верхняя запущена из Пуска, нижняя из TC

                    действительно похоже, что Assembly.GetExecutingAssembly().Location выдает результаты в зависимости от того в каком формате был записан путь для запуска, а не в каком-то одном стандартизированном формате. Не знал о такой особенности
                    и проблема с лоадреом и ТС была в том что путь я указывал в лоадере относительный, а консоль через TC запускалась в буковой в нижнем регистре.

                    Комментарий

                    Обработка...
                    X