Ещё можно задать фоновую картинку на область окна (определённого подпрограммой _SUB)
Код:
IMAG Image1,L8T380W140H70,%CurDir%\logo.gif,,#0xFF00FF,2 `Картинка %CurDir%\logo.gif указанного размера IMAG ,L-1T-1W182H275,#100,EXEC $http://usbtor.ru,#0xFF00FF,2 `А тут картинка вшита в сам PECMD (#100), и если нажать на неё, будем перенаправлены на usbtor.ru
При этом сама картинка может иметь размер 1х1 (пиксель на пиксель) одного цвета, тогда получится заливка указанной области этим цветом. И до кучи - можно задать цвет надписи на кнопке [ButtonName]
Код:
ENVI @ButtonName.color=[Color]" to set the text color
что-то не могу разобраться с командой DISK сейчас в начале pecmd.ini есть DISK ,,,3,U (т.е. все флешки получают свои буквы начиная с U:) если воткунута только одна загрузочная, она получает U, и я могу набрасывать ярлыки на рабочий стол из её програмного пакета но если воткнуто 2 флешки, букву U может получить не загрузочная, и ярлыки не корретны Пытаюсь привязать команду к конкретной метке (файлу) на загрузочной флешке DISK \W8PE\w8164.wim,,,3,U почему-то не срабатывает. Вторая флешка все равно садится на букву U Как однозначно присвоить командой DISK присвоить именно загрузочной флешке букву U, а все остальные флешки/разделы флешек только потом? UPD методом тыка вроде сработала привязка к папке с ядрами на закрузочной флешке ... DISK \W8PE,,,3,U ... будем наблюдать UPDUPD так и не сработало...
Только это было давно. Не уверен, что найду нужный инструментарий. Я им делился тут, может осталось... На сколько я помню там далеко не все расшифровывается и не любой версией pecmd.
А можно конкретную версию pecmd с которой работают зашифрованные скрипты? Желательно, что бы pecmd.exe был не упакован в mpress или что-то подобное (помню раньше он часто был упакован). Посмотрю, может что-то получится сломать.
Adler, pecmd.exe в архиве вместе со скриптами. А вот ветка обсуждения "декриптора" (China). Если в двух словах: им можно расшифровать то, что начинается на CMPS, а вот то, что на CMPa - нет.
Что-то там вообще намутили непонятное. Вчера пол дня гонял в отладчике и толком ничего не нашел. Взял простой скрипт и закриптовал его, а потом отладчиком гонял, пытаясь найти хоть что-то. Самого места, где происходит дешифрование вообще не нашел. Еще интересный момент, что один и тот же исходник при каждом шифровании выдает разный результирующий файл. Промелькивают местами только цифры из исходника и некоторые отдельные фрагменты из команд. К примеру, из скрипта:
В одном месте промелькнуло "L460T90W290H70", а в другом "Windows1.Visible" (??? ). Через MultiByteToWideChar, служившей ранее местом "отлова" исходного кода сейчас какой-то мусор гоняется, а другой зацепки я не нашел.
Adler, если код меняется значит ключ шифрования зависит от времени или рандомный. Я пытался логически понять можно ли зашифровать файл с возможностью его расшифровки. Ключ должен присоединяться к файлу в конце или в начале или по смещению. Если ключ неизменяемый, то он содержится в распаковщике-интерпретаторе, если ключ изменяемый, то у него должна быть позиция внутри файла (конец, начало или смещение). Возможно в памяти он в расшифрованном виде, иначе как он будет работать, хотя он же не компилируется, в любом случае он не сможет обрабатываться построчно, если он зашифрован. Надо память процесса сохранить.
AZJIO, ну ключ вероятнее всего содержится в самом конечном зашифрованном файле. Для расшифровки он же должен его откуда-то взять.
AZJIO писал(а):
79432Возможно в памяти он в расшифрованном виде, иначе как он будет работать, хотя он же не компилируется, в любом случае он не сможет обрабатываться построчно, если он зашифрован. Надо память процесса сохранить.
Пробовал дампить, ничего там нет похожего на оринальный скрипт, хотя какие-то ошметки в PlainText там есть, но они не имею отношения к исходному скрипту. Опыта в реверсе явно не хватает
Adler, надо наверно 2 дампа сравнивать, чтобы отличить данные от частей интерпретатора. Могу предположить, что если файл зашифрован, а интерпретатору надо читать его построчно, то каждая строка зашифрована, но число переносов строк должно быть столько же сколько в оригинале, то есть найти какой символ сколько раз повторяется, чтобы распознать его как перенос строки, потом браться за строки.
AZJIO, конечные дампы (когда скрипт запустился) с зашифрованным или обычным скриптом почти одинаковы (в некоторых местах одиночные байты отличаются). Т.е. в итоге это все приводится к одинаковому виду. Различия значит должны быть где то в промежуточном этапе выполнения. У меня вчера идея появилась записать трасировку выполнения обычного и зашифрованного скрипта и потом их сравнить, найдя в каком месте начинает меняться сценарий выполнения. Но с этим еще нужно поработать. Первый эксперимент не дал результата, т.к. в отклонений очень много, включая внутри системных библиотек. А как записать трасировку, что бы она не затрагивала системные библиотеки пока не разобрался. В общем надо еще покопаться с этим ..
79445конечные дампы (когда скрипт запустился) с зашифрованным или обычным скриптом почти одинаковы
А если посмотреть дамп минимального скрипта с одной строкой и большого скрипта? Должен ведь скрипт располагаться внутри сплошным потоком. Вся память, которая выделена процессом, в том числе и скрипт должны быть в дампе.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах Вы не можете прикреплять файлы к сообщениям Вы можете скачивать файлы
Вход
Регистрация
![[Цитировать]](./styles/templates/default/images/lang/ru/icon_quote.gif "Ответить с цитатой"){kind=icon}
Отправлено: 
Только это было давно. Не уверен, что найду нужный инструментарий. Я им делился тут, может осталось...
).
