гуглил, гуглил, толку нету. Есть такая приблуда, как execJ http://www.jpackages.com/execj , делает из jar-файла (приложение Java), exe-файл/сервис таким образом, что получить исходный jar не очень просто.
Эта приблуда заинтересовала меня потому, что ей зашифрована программа обновления прошивок телефонов SonyEricsson (SEUS), также известная как EMMA III.
Не будет ли любезен кто-нибудь из мэтров глянуть на этот execJ, с целью извлечь исходный jar-файл (HelloWorld из экзамплов к проге - типичный пример), закриптованный jar - это ресурс номер 17.
Извините, что создал новую тему, просто я считаю, что данный криптор заслуживает отдельной темы, так как может встретиться где-то помимо SEUS

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

кто-нибудь из знающих java, скажите - можно запустить на выполнение не сбрасывая дамп на диск?
если верить filemon при запуске оно ищет HelloWorld_this_windowAdapter.class & HelloWorld.class (пускаю пример из samples)
также в логе filemon видны ejpb\ExeClassLoader$ByteArray.class & ejpb\EncGen.class - выглядит подозрительно

---

или оно хучит функции работы с файлами etc и организует свою виртуальную фс a-la thinstall ?

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

сижу дебужу этот хелловорлд, видно, что тут

.text:00402C43 call ReadResource ; N 17, классы

читают сам jar-файл (или что-то подобное, пока не врубился)
здесь:

.text:00402C78 call GetOrigResource

похоже, что получают то, что было в оригинале, но результат на jar не похож (jar - это обычный ZIP файл).
Но самое странное, дальше:

.text:00402CB6 call ReadResource ; N 1734, всё, кроме классов

читают какие-то ресурсы (не те, которые в helloworld.exe расположены, а те, что были в Jar-файле, все файлы помимо .class-файлов, в случае HelloWorld - это файл helloworld.jar\META-INF\MANIFEST.MF), а в случае SUSE это файл занимает почти мегабайт. То есть похоже, что оригинальный jar(aka zip) разбивают по крайней мере на две части, классы и не классы, и хранят их отдельно. Классы можно опознать началу - там всегда находятся байты CAFEBABE

Не думаю, что она что-то хучит, более вероятно, что она использует обычную JRE, виртуальную машину java, чтобы запускать оригинальные .class - файлы. JRE занимает около 15 мегов, нереально её запихать в 100кб

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

запустить класс на выполнение прямо из памяти можно - правда нужен свой ClassLoader, что и видно по строке ejpb\ExeClassLoader$.....
ejpb - это на самом деле тоже класс ejpb.class, только его че-то не видно нигде, за исключением Native-методов (то есть методы, которые выполняются за пределами виртуальной машины, самой системой), расположенные с файле ejpb.dll

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

на самом деле оказалось, что помимо этого execJ в прошивке сонериков есть другой подводный камень, который может легко свести все усилия на нет, а именно:
этот самый SEUS закачивает в мобилку лоадеры прошивок, которые сверяют контрольные суммы того, что мы пытаемся зашить в телефон, и эти контрольные суммы считаются на основе криптографии, то есть для своей измененной прошивки такую сумму посчитать не удасться в разумный срок, и сами лоадеры тоже подписаны с помощью криптографии, и их самих тоже не получится поменять.
Однако в реализации криптографии содержатся ошибки, и обычные SE-звонилки давно имеют как хотят, чего не скажешь о смартах, хотя программа та же самая

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

Не думаю, что она что-то хучит, более вероятно, что она использует обычную JRE, виртуальную машину java, чтобы запускать оригинальные .class - файлы. JRE занимает около 15 мегов, нереально её запихать в 100кб
да, скорее всего. .dll из jre оно использует.
запустить класс на выполнение прямо из памяти можно
а может и сдампить из памяти можно?

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

наверняка можно, только бы понять, что за структура возвращается из
.text:00402C78 call GetOrigResource
(видно, что там через JVM.dll выполняется какой-то java-метод, и возвращает похоже jvm_??_7typeArrayKlass@@6B@, ссылку на массив классов, но это уже загруженные классы, они не имеют ничего общего с теми, которые начинаются с CAFEBABE.
осталось как-то отыскать, чтоже за метод такой.
-----
как же не хочется jvm отлаживать, это такое нагромождение кода

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

Stiver, ты где?

wl - попробуй еще на wasm.ru спросить

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

Сорри за простой вопрос. Как я понял, ExecJ берет на вход некий JAR (==ZIP?) и делает exe, который можно выполнить? А можно сделать последовательно из нескольких HelloWorld1.JAR..HelloWorldN.JAR -> HelloWorld1.EXE...HelloWorldN.EXE? (пусть они отличаются минимально и пусть будет в ZIP метод Store (такой метод вроде есть в ZIP - архивация без сжатия). Чем они будут отличацца? Изменяются ли выходные файлы от одного и того же файла (т.е. используется salt)?

-----
The one derivative you manage is the one I abhore (c) Slipknot

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

ssx, да мне кажется так разберусь, картинка постепенно проясняется. Один из ресурсов, скорее всего 9 или 10 - это и есть нужный класслоадер, эти файлы довольно большие и повторяются в каждом exe. Думаю, что немного потрассировав код на разных jar-ах, удасться получить восстановить и классы и данные.
Если всё пройдет успешно, можно будет создать автоматический распаковщик, и тогда эта защита отвалится

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

похоже криптография используется.

.text:00406370 readRes21_ERR_MSG proc near

читается и дешифровывактся (как-пока непонятно, возможно, простой xor) некий текстовый файл, в результате видно, например это:

debug026:009B52C8 db 'encryptBootClasses=FALSE',0Ah
debug026:009B52C8 db 'embedClasses=TRUE',0Ah
debug026:009B52C8 db 'compressClasses=TRUE',0Ah
debug026:009B52C8 db 'encryptClasses=TRUE',0Ah
debug026:009B52C8 db 'encryptKey=gRrvl#7$9ts?S u?ftz.Evrg-D.(- 901mpCS$m-2nmB7gsZ)'
debug026:009B52C8 db '8?V@z.p(rCEvnsuv$(BD*9naqs-W*vF8hD(vqB#f8ClzY rw1x1vpmpBzg0T'
debug026:009B52C8 db ' DuXDl $#vF@q7ngxj?kwj#?qqVxvE.(bv0nrhlYD)xDulm;zFtyk$k?bju0'
debug026:009B52C8 db 'mmjZDptDvE9Tz -h#)#qwj0)ggjd-F9.Stru$qCjt8rsirrjrEvzvhz u.te'
debug026:009B52C8 db 'xg!0s#8llF80shcsrukhu7ga #y!SE9n*t uhm?hgxs1U;unBQcS',0Ah
debug026:009B52C8 db 'hasResources=TRUE',0Ah
debug026:009B52C8 db 'compressResources=FALSE',0Ah
debug026:009B52C8 db 'encryptResources=FALSE',0Ah

красотище, выявился некий "encryptKey".
а использовать zip без сжатия на входе программы смысла имхо не имеет - прога все равно его распаковывает перед обработкой

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

я нашел в памяти класс, который является главным и загружает все остальное. Подскажите IDC-скрипт, который скинет этот участок памяти на диск?

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

он использует RSA encryption для шифрования jar'ов.
также используеться JRE установленная в системе, если JRE нет то ессесно работать не будет.

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

З.Ы. по умолчанию RSA 96-bit
З.Ы.Ы прога сама написана жаве и самой же преобразована. можно попробовать позапускать ее с параметрами jvm'a мот пропустит и тада можно будет приаттачиться jvm'им дебаггером и посмотреть как она расшифровывает.

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

[wl] пишет:
Подскажите IDC-скрипт, который скинет этот участок памяти на диск?

#include <idc.idc>
static main()
{
auto f,s,e,i,b;
f=fopen("C:\security.dll","wb");
s=0x00960000;
e=0x009D0000;
for (i=s;i<e ;i++ )
{
b=Byte(i);
fputc(b,f);
}
fclose(f);
}

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

Всё, распаковал я этот SEUS, теперь у меня есть jar-файл прошивальщика смартов от Sony Ericsson. Оказалось, что всего-то нужно было скинуть начальные классы, которые грузятся стандартным ClassLoader'ом на винт, поменять их так, чтобы они расшифрованные файлы кидали на винт, подсунуть им ключ криптования, ресурсы из exe-файла и всё.
Всем спасибо за помощь и участие, первый этап закончен, теперь надо разбираться, как закриптована прошивка, расшифровать её, поменять и попытаться залить в мобилу...

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

пропатченные .class не выложишь?

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

исходники на java подойдут? Там заданы конкретные данные от SEUS, так что скомпилированные классы в таком виде бесполезны. (чтобы эти данные узнать, нужно с помощью IDA к примеру, протрассировать до того места, где читается и декриптуется ресурс номер 21)
плюс, у ресурсов номер 17.res и 1734.res (доставать их тоже придется руками, ресторатором например) нужно отрезать заголовок 0x40 байтов, и нули в конце, иначе неправильно декриптуется.
В общем, никакого удобства, но мне и нужно было на один раз

6e7f_21.05.2007_CRACKLAB.rU.tgz - src.zip

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