PjOrion - редактирование, компиляция, декомпиляция, обфускация модов (Версия: 1.3.5 Дата: 11.08.2019)

[GPCracker 2,088]

Если дверь нельзя открыть, это не значит, что ее нельзя вынести нафиг. Я что подумал, если в шифровщик нельзя подсунуть лишнего, то может можно заменить сам шифровщик?

[SkepticalFox 1,445]

заменить сам шифровщик?

Я уже вижу очередь из тех, кто будет этим заниматься)))

[StranikS_Scan 4,210]

Если дверь нельзя открыть, это не значит, что ее нельзя вынести нафиг. Я что подумал, если в шифровщик нельзя подсунуть лишнего, то может можно заменить сам шифровщик?

 

Ну конечно можно. Осталось самое меленькое - найти профессионального крэкера чтобы он ломанул нам exe ))))

[AlexChe 4]

Странник, обновы еще не было с поддержкой строки по пакетным функциям?

 

И еще пожелание сделать "запоминание" папок по последним операциям при обфускации-протекции. А то закрыл программу, открыл и снова папку компиляции заново искать.

[SkepticalFox 1,445]

@StranikS_Scan, можешь объяснить, что делает этот инструмент?

https://www.jetbrains.com/pycharm/help/remote-debugging.html

[StranikS_Scan 4,210]

Тест #1 для обновления PjOrion 1.3.2

----------------------------------

 

Скачать:

<устарело>

 

Изменения:

• Если при изменении настроек программы потребуются права Администратора программа выдаст сообщение
• Увеличил размер шрифта в окнах
• При выделении слова исправлен неверный подсчет его повторений в тексте
• Добавил опцию подсветки отступов в тексте "Show special characters" -> "Indents only"
• В функции Minimize:
  • Исправил излишнее удаление символа конца строки перед if
  • Исправил и улучшил работу подфункции, удаляющей многострочные комментарии
  • Исправил вылет функции, если в тексте встречаются склеенные строки вида 'abc''def'
  • Исправил излишнее удаление преамбулы в начале скрипта
• Исправлена ошибка в работе Obfuscate - Structure при обфускации сложных аргументов функций
• Исправил смещение преамбулы в начале скрипта при использовании Obfuscate - Strings
• Добавил в контекстное меню файлов и папок пункты обфускации и протекции скриптов
• Форматы *.visual_processed и *.font добавлены в список распаковываемых программой
• Исправлены ошибки при распаковке xml с отрицательными числами и длинными строками
• Обновлены dll-файлы и zip-архивы на Python 2.7.11 и Python 3.5.1

 

Тест #2

---------------------------

 

Изменения:

 

• Исправлены ошибки при обработке текста в UTF-8 формате функциями Obfuscate - Strings и Obfuscate - Variable names
• Внес исправления в свой парсер питон-кода для улучшения работы функции Minimize
• Исправил ошибки в работе функции Minimize

Тест #2c

-------------------------

 

Скачать: 

 

Изменения:

• Исправил неверную работу Minimize при комментариях в конце строки
• Исправил не правильную компиляцию русских символов если скрипт в UTF-8 формате, но без преамбулы в тексте

Edited January 30, 2016 by StranikS_Scan

[akey 35]

И все же, добавьте чтобы при компиляции автоматом в UTF переводилось. Допустим добавить вариацию с перекодировкой в UTF в чек боксе байткода, "Обфускация с UTF" к примеру. В версии 1.3.0 это делалось автоматом.

[StranikS_Scan 4,210]

И все же, добавьте чтобы при компиляции автоматом в UTF переводилось. Допустим добавить вариацию с перекодировкой в UTF в чек боксе байткода, "Обфускация с UTF" к примеру. В версии 1.3.0 это делалось автоматом.

 

Нет. Так как тебе нужно автоматом UTF, а другим нужно автоматом ANSI. Если хочешь чтобы по умолчанию был выбран UTF зайди в настройки и выбери Default encoding: UTF-8

[StranikS_Scan 4,210]

Вообщем столкнулся я с забавной проблемой - Питон-2.7-Парсеры и Юникод.

 

Из-за этой проблемы сейчас обфускация текста в скриптах (Script - Obfuscate), содержащих юникод символы, например print "Привет!", происходит некорректно или с ошибкой. Суть проблемы вот в чем. Я использую для анализа питон-кода скриптов ast-парсеры

 

import ast

ast.parse()

 

и

 

import compiler

compiler.parse()

 

которые в Питоне 2.7 как ни странно не понимают юникодовые символы. При попытке скормить такой функции строку выше в юникодовом формате "Привет" -> '\x41f\x440\x438\x432\x435\x442' можно словить ошибку декодера типа - 'ascii' декодер не понял символы с кодом больше 128/255. Если же декодировать юникод строку и передать в парсер - то проблема с его работает исчезает. Однако возникает проблема с распарсеным кодом. Ведь как известно декодированная юникод строка в случае с "Привет" вместо 6 символов будет содержать 12 символов '\xc3\x8f\xc3\xb0\xc3\xa8\xc3\xa2\xc3\xa5\xc3\xb2', а значит длина текста и позиции в нем различных элементов будут тоже смещены по отношению к исходному тексту, в котором строка имеет длину не 12, а 6 символов. Отсюда и косяки в работе парсера и обфускации.

 

Интересно чего с эти делать.

Edited December 19, 2015 by StranikS_Scan

[SkepticalFox 1,445]

Интересно чего с эти делать.

Выносить локализацию из питона.

[GPCracker 2,088]

Интересно чего с эти делать.

Вот чем мне понравился 3k Python - (плагин для ST когда писал) - так это тем, что строка и байты - это в принципе разные типы и их перепутать просто нереально, не примет получатель, сразу начнет ругаться на тип. Ну и получается автоматом учит кодера думать, что и куда он отравляет, и энкодеры/декодеры автоматом ставить или сразу на поток враппер вешать (немного повозился с этой темой, зато плагин русский текст нормально хавает).

А что по делу - наверняка это Python модули, загляни внутрь, м.б. там есть какое кодирование/декодирование, м.б. удастся подстроиться.

Edited December 19, 2015 by GPCracker

[StranikS_Scan 4,210]

Выносить локализацию из питона.

 

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

[GPCracker 2,088]

а что ты будешь делать с комментариями написанными на русском?

Не писать комменты на русском. ))

А если честно, вообще любой вид локализации в коде есть зло.

[SkepticalFox 1,445]

а что ты будешь делать с комментариями написанными на русском?

комментарии не нужны)

Вот чем мне понравился 3k Python - (плагин для ST когда писал) - так это тем, что строка и байты - это в принципе разные типы и их перепутать просто нереально

в Python 3.5 уже можно форматировать байтовые строки, как и обычные(странное решение, опять разница начнет исчезать)

b'name=%s' % b'Maxim'

.format() еще не добавили... Edited December 19, 2015 by ShadowHunterRUS

[GPCracker 2,088]

Нашел на хабре специально, в комментах

 

//самая жесть, когда у вас команда многонациональная… 
var sousDomaine = sld + tld;
var sousDomaineDlina = sousDomaine.length;

в Python 3.5 уже можно форматировать байтовые строки, как и обычные(странное решение, опять разница начнет исчезать)

Это нормально, т.к. ты байтовую строку форматируешь байтовой. Если комбо микс - скорее всего будет кодек ASCII юзаться, если примет такое интерпретатор.

 

>>> '{}'.format('test')

'test'

>>> import sys

>>> sys.version

'3.3.3 (default, Dec 19 2013, 14:11:33) \n[GCC 4.7.2]'

Это через ST в консоли, но думаю это неважно.

Edited December 19, 2015 by GPCracker

[StranikS_Scan 4,210]

Ну то есть мне забить, а всем кто захочет обфусцировать текст в юникод-кодировке с интер-строками или интер-комментами - посылать в лес пилить дрова, т.е. делать локализацию и запускать Minimize перед обфускацией. Так что ли?

[SkepticalFox 1,445]

Это через ST в консоли, но думаю это неважно.

эм...

>>> b'{}'.format(b'test')
Traceback (most recent call last):
  File "<blender_console>", line 1, in <module>
AttributeError: 'bytes' object has no attribute 'format'

[GPCracker 2,088]

Ну то есть мне забить, а всем кто захочет обфусцировать текст в юникод-кодировке с интер-строками или интер-комментами - посылать в лес пилить дрова, т.е. делать локализацию и запускать Minimize перед обфускацией. Так что ли?

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

А по чесноку посылать далеким маршрутом всех желающих использовать любой язык кроме английского в коде в любом его виде (нормальный, транслит, псевдографика, и т.д.) ИМХО правильнее. Ибо я привел пак лулзов в комментах на хабре, что бывает в таких случаях. Для языков есть файлы локализации и документации.

эм...

Блин, так ты байт-строку форматтить пытаешься! А формат - он исключительно имеет смысл только для строк. Байт-строка - это байты. И ничего кроме байтов.

>>> b'{}'.decode('ascii').format('test')
'test'

Байты можно декодировать, используя кодовую таблицу. Тогда все ок. Одни и те же байты в разных кодовых таблицах обозначают разные символы и вообще символ может быть и два+ байта длиной. Текст - это однозначно - один индекс - один символ. Edited December 19, 2015 by GPCracker

[SkepticalFox 1,445]

Байт-строка - это байты. И ничего кроме байтов.

% же добавили)))

[GPCracker 2,088]

% же добавили)))

Это старая штука вроде как, обратная совместимость, наверное... format() ИМХО мощнее в разы.