2013-2471 + preloader bypass

[neko]

У кого-нибудь получилось совместить сабж? Что-то совсем не работает (те работает если только консоль открыта).

 

[el-]

хз как с 2471 но 2465 который я гонял нормально сработал, было пару проблем которые не сразу понял.

главное наличие класса наследуемого от preloader с функой start(Stage) в которую получаешь управления до старта мейн класса, причем не надо даже таскать с собой мейн класс ( который якобы должен стартовать за прелоадером ), никаких загрузчиков ( или хз что это такого ) которые все таскают тоже не нужны. Из пустого класса видны ауты ( out.println ) потом вылетаем мессадж, что мол на основание секурных настроек основной класс запущен не будет, дабы избавиться от этого юзают system.exit для которого видимо нужно отрубить security manager, т.е. эксп должен 100% сработать либо не приятный алерт. вообще стоит посмотреть в сторону стейджей прелоадера, мб есть возможность завернуть загрузку мейн класса в прелоадере юзая какие то официальные методы, дабы не скрещивать пальцы за работу эксплоита.

и да у меня с отрубленой консолью все нормально работает.

 

[neko]

el-
приятно тебя опять увидеть )
Уже разобрался, но 2471 нестабильно работает c прелоадером, вне зависимости от того, какой поток - обычный (init метод) или javafx thread. Крешит плагин в большинстве случаев.
Решил юзать 2460 с этим байпасом для 1.7 (все стабильно). А 2470 взять для 1.6, ну и нормально все будет покрыто.

>> system.exit
я тут долго тупил, когда у меня непрошло с сепшеном отрубить загрузку. Он сцуко сепшен игнорит и устанавливает дефолтный прелоадер в PreloaderDelegate.

>> мб есть возможность завернуть загрузку мейн класса в прелоадере
Нет там если что-то не так пошло сразу выставляется дефолтный прелоадер, что-то более существенное уже требует прав. Подвешивание потока вешает все окно, что также нехорошо. Подставка подписанных модулей со сторонних ресов будет всеравно вызывать варнинг на ран. Но например, 2460 довольно стабильный и не основан на мемори коррупшионе как пачка 2463/2465/2471, там врятли чтото не сработает, а на крайний случай можно и браузер подвесить )

 

[neko]

чтобы пробрасывать в прелоадер параметры:
в исходном html как и всегда добавляем параметр <param />
в прелоадере делаем следующее

Map<String, String> x = getParameters().getNamed();
String url = x.get("url");
System.out.println("url : " + url);

 

[el-]

попробовал разные варианты stop/exit/curretnThread().destroy() но проклятое сообщение вылетает, это в принципе не так страшно сплоит с высокой вероятностью сработает ( на локалке 10 из 10 ), просто это как то не правильно.

пачка мем коров кстати может стать немного стабильнее, если её немного переписать, правда тесты показали различие объектов в памяти, вернее порядка расположения в памяти переменных класса, у разных версий 6ки. юзаю подобие класса Leak из 1493 для более точно поиска объекта Statement в памяти. в моем случае там замешаны int, а в пакетстормовском варианте их нету, так что он мб вполне рабочий под все версии 6ки.

еще из проблем это плохое определение версии явы, судя по логам она не всегда определяется хоть запрос за аплетом идет с указанием версии, в свойственной ему манере по 4ре раза, так что это скорее всего не боты, а особенности безопасности ишака, который запрашивает у юзера разрешение на активацию плагинов явы, который видимо и отвечает за определение версии, но не запрешает яве запускать апплеты.

а раз нельзя 100% определить версию придется отдавать все как есть, но тут опять же ряд проблем:

- javafx 2.2 и сам preloader появился с 7u6
- jnlp_embedded работает только в 7
- от дурацкой <param name='javafx_version' value='2.2+'> можно избавиться с помощью <jfx:javafx-runtime version="2.2+" /> в jnlp но это породит две консоли.

в общем картина того как все это собрать максимально эффективна только начинает складываться ...

update:
<param name='javafx_version' value='2.0+'> в аплете не уживается <param name='__applet_ssv_validated' value='true'/> в jnlp для 7u17, можно конечно юзать прелодер но лишний раз наверное не стоит

 

[neko]

>> javafx 2.2 и сам preloader появился с 7u6
немного уточню, прелоадеры с JavaFX 2.0, proof > http://download.java.net/jdk8/jfxdocs/java.../Preloader.html, но как часть JRE действительно с 7u6 (http://www.oracle.com/technetwork/java/javafx/downloads/supportedconfigurations-1506746.html)


>> еще из проблем это плохое определение версии явы
насколько часто такое происходит? Может быть просто плюнуть где не определяется? Беспалевность важнее имхо.

что-то пробегало по поводу распознавание ав через res:\\ и шару. Если оно рабочее можно по крайней мере разделить jre6/7 (думаю в подавляющем большинстве случаев путь не меняют при инсталяции джавы).
а 7u6 vs более младшие по наличию файлов связанных с java fx (jfxrt.jar например)


>> stop/exit/curretnThread().destroy()
первое имеет пустую реализацию в базовом классе, это просто коллбек. Остальное вызывают секурити сепшен, ктр игнорится и выставляется дефолтный прелоадер. Можешь увидеть если в свойствах джавы в контрол панеле на вкладке адвадсед выставишь все галки типа трейс и лог.

 

[Aels]

el-
neko
Я чуть-чуть игрался с определением версии явы через ua, и тогда главное проблемой было "а что отдавать, если версия не та".
Для подавления окна с вопросом (или ошибки загрузки) нашел только 1 способ - не отдавать аплет целиком, и оставлять висящим конект. Т.к. работа с классом начинается только после полной его загрузки, то подходит вот такой вариант (псевдокод, простите):

while(true) {
  echo '1';
  sleep(10);
  flush(); // в пхп принудительное опустошение буфера, я не помню как оно точно будет.
// И размер буфера апача нужно сжать с дефалтных 4кб
}

Так же, еще не довелось проверить, как поведет себя jvm, если <applet> удалить из DOM страницы, или в ИЕ выполнить document.execCommand('stop').
Если у кого-то будет минутка попробовать - отпишитесь о результате пож)

Пример определения 6\7 явы через res://-протокол

<!--[if IE]>
	<iframe src="res://C:\\wrong_path_blabla" onload="stopDetecting();" style="display:none;"></iframe>
	<iframe src="res://C:\\Program%20Files\\Java\\jre7\\bin\\java.exe/24/1" onload="has7java = true;" style="display:none;"></iframe>
	<iframe src="res://C:\\Program%20Files\\Java\\jre6\\bin\\java.exe/24/1" onload="has6java = true;" style="display:none;"></iframe>
<![endif]-->

Нужно дополнить путями для "Program Files(x86)".
Как это работает:
Для ие9+ onload запускается если содержимое фрейма успешно загружено (тоесть мы точно знаем, что по указанному пути есть бинарник, и в нем есть манифест.
А для ие8- onload запускается всегда, независимо от того, грузится ли в ифрейм существующий файл, или там "заглушка 404" от самого ие. Но в случае работы с локальными путями, заглушка таки грузится сразу после всех реально существующих файлов, и (т.к. она у нас первая по-порядку, это _важно_) до других несуществующих.
То есть, в момент срабатывания onload-а на битом адресе, проверку нужно остановить.

Кто-то мне нашептывал когда-то, что через loadXML активиксом, манифесты вообще читать можно, но я пока не осилил( Как разгребусь - займусь этим вопросом подробнее.

 

[el-]

>>немного уточню
меня смутило 2.2 в тайтле страницы http://docs.oracle.com/javafx/2/api/javafx.../Preloader.html

>>насколько часто такое происходит? Может быть просто плюнуть где не определяется?
внимательно логи не рассматривал, но первое впечатление сложилось, что эта проблема проявляется на свежих версиях явы того времени, 21 и выше, так что это напрямую связано с топиком

>> res:\\
вы уж извините, но это уже слишком, все имхо должно быть сделано официальными методами, дабы гарантировать стабильность работы во все времена, официальные методы конечно подкачали, но ничего не поделаешь.

update:
ч.т.д. в ишаке через Tool->Manage Add-ons отрубаем Deployment Toolkit и все версия явы не определятся, но на запуск апплета это никак не влияет.

update:
в 721 есть трабла или это из-за javafx но jar запрашивается пару раз, что конечно не критично, но не приятно, в случае когда юзается <jfx:javafx-runtime version="2.2+" /> уже 4 раза.

 

[neko]

>> ч.т.д. в ишаке через Tool->Manage Add-ons отрубаем Deployment Toolkit и все версия явы не определятся, но на запуск апплета это никак не влияет.

дык многие ли это делают? Тут можно ж как с js, отключено - не наш клиент.

 

[el-]

отключение вручную конечно возможно, но я не про это. в данный момент у меня нет возможности проверить, но по дефолту в ишаке 9 и 10, стоит режим но активикс и там по моему даже флеш не работает пока ты его не разрешишь, т.е. все плагины даже доверенные не работают, но мб апплеты все же тянуться. вот и получается что версии нет, а апплет загружается.

 

[Aels]

el-
не-не-не.
По-умолчанию все работает ок. В 9м ИЕ плагины все по-умолчанию в порядке, даже wmp (хотя через другой clsid его можно вызвать так, что попросит разрешения).
А вот в 10м ИЕ в метро-режиме (только в нем), по-умолчанию выключены вообще все плагины (как будто и нет их)
Схожим образом ведет себя IEMobile, который и не Windows вовсе, но упорно ей представляется, и даже несет на борту window.activeXObject со всеми плюшками.
Это winPhone-ы =(
Конкретно в твоем случае, глянь с каким реферером обращаются к яве (его быть не должно), и с каким реферером идет запрос к ресурсу, сокращенному через https://goo.gl (рефа быть не должно, ибо соскок с ssl) на той же странице.
Очень вероятно, что у тебя проходят именно мобилки

Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; XBLWP7; ZuneWP7)

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

*и, ня, я помню про фазер, но время(

п.с. Попробуй вот так:

function isIE() {
	
	$ua = $_SERVER['HTTP_USER_AGENT'];
	
	if(
   stripos($ua, '(compatible; MSIE')
  && !stripos($ua, 'csvt') // VirusTotal
  && !stripos($ua, 'chromeframe') // ChromeFrame
  && !strpos($ua, 'Macintosh') // IE on OSX 0_o
  && !strpos($ua, 'Xbox') // Xbox is not win
  && !strpos($ua, 'IEMobile/') // WinPhone
  && !strpos($ua, 'XBLWP7; ZuneWP') // WinPhone too!
  && !strpos($ua, 'ARM; Touch; WPDesktop') // WinPhone too . . .
  && !strpos($ua, 'MSIE 5.5;') // No respect to referer rules, so must die
  && !strpos($ua, '360SE') // "360 Security Explorer" addon. Die.
  && !strpos($ua, 'SE 2.X') // "Sogou Explorer". Die.
  && !strpos($ua, 'GTB') // "Google Toolbar". Die.
  && !strpos($ua, 'BRI/') // "BING bar". Die.
	) { return true; }
}

все эти строки выловлены из-за того, что слали реф куда нельзя.