Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
автор уязвимости ранее имел негативный опыт общения с техподдержкой Blizzard, которая ему для решения всех проблем предлагала переустановить игру
Странно, у Близзардов самый клёвый саппорт, который я только встречал.
На первое письмо о помощи отвечали ссылками на ФАКи, конечно, но потом уже сотрудники пытались действительно разобраться в проблеме и всегда помогали.
Мне как-то раз три раза подряд робот отвечал. Я забил.
Раз на раз не приходится.
Раз на раз не приходится.
обычный суппорт, в стиле «у нас все работает, проблемы на вашей стороне»
Мне что-то подобное ответили на мои проблемы с авторизацией в вовке, когда поменялся мой IP адрес на другого провайдера. Система тупо банила меня и предлагала сменить пароль под предлогом, что обнаружена попытка несанкционированного доступа. После пяти смен пароля и чтения всех ФАКов на сайте, написал в суппорт. Через сутки все заработало само, а мне пришло письмо — что у них все хорошо =(
Мне что-то подобное ответили на мои проблемы с авторизацией в вовке, когда поменялся мой IP адрес на другого провайдера. Система тупо банила меня и предлагала сменить пароль под предлогом, что обнаружена попытка несанкционированного доступа. После пяти смен пароля и чтения всех ФАКов на сайте, написал в суппорт. Через сутки все заработало само, а мне пришло письмо — что у них все хорошо =(
У меня последнее с ними общение было по поводу беты СК2. Клиент не хотел обновляться.
Сначала ответили ссылками, но я написал что далеко не идиот, и все инструкции прочитал, как и гугление похожих проблем ничего не дало.
Тогда уже ответил живой человек, и начали вместе искать причины проблемы.
Оказалось, что клиент берет настройки сети из IE, а у меня там был когда-то давно вбит дохлый прокси.
Кстати, в инструкции потом этот нюанс они так и не добавили, вроде. )
Сначала ответили ссылками, но я написал что далеко не идиот, и все инструкции прочитал, как и гугление похожих проблем ничего не дало.
Тогда уже ответил живой человек, и начали вместе искать причины проблемы.
Оказалось, что клиент берет настройки сети из IE, а у меня там был когда-то давно вбит дохлый прокси.
Кстати, в инструкции потом этот нюанс они так и не добавили, вроде. )
Чтобы восстановить аккаунт нужно писать в сапорт с рабочего аккаунта… И это многое объясняет… =)
Как показала практика, проще звонить +)
А можете пояснить код функции Inj_PrepareInjector? Почему массив называется zg0oI, почему начинают записывать со смещения 0x200. Есть ли смысл у записываемых данных?
Куски кода — копипаста из оригинальной карты, и названия придумывал не я. Скорее всего это делалось для обфускации — редактор WarCraft использует достаточно убогие шрифты. А может просто для хакерского лоска.
Почему индекс 0x0200? Ведь это отступ в памяти. В другом месте код пишется по смещению 0x00. Насколько я помню, в данный момент массивы ссылаются на стек, поэтому возможно отступ в 0x0200 выбран просто как безопасный, не затрагивающий важные данные. Сейчас подыму историю переписки:
Так вот, используя операцию присвоения значению переменной массива, которая является указателем на подобную структуру, произвольного значения, содержащегося в обычной переменной (на самом деле совсем не произвольного) мы получаем массив, Items которого ссылается на нужный нам адрес в адресном пространстве процесса, в данном случае это стек одной из веточек. Откуда можно легко перехватить управление. Теперь при записи в массив игра будет на самом деле писать в код процесса. Соответственно, при записи в массив foo[n], данные будут записаны по адресу Items+n.
Кстати, насколько я понял, тут идет запись в стек, основной же код пишется действительно просто в массив. Такой же методикой находится адрес процедуры VirtualProtect, и она выполняется с флагом PAGE_EXECUTE_READWRITE на память, куда записан код. Дальше управление и передается этому коду.
Данные, показанне в примере — очень хорошие, это код. Только надо свапнуть их задом наперед (я делаю это инстинктивно):
Почему индекс 0x0200? Ведь это отступ в памяти. В другом месте код пишется по смещению 0x00. Насколько я помню, в данный момент массивы ссылаются на стек, поэтому возможно отступ в 0x0200 выбран просто как безопасный, не затрагивающий важные данные. Сейчас подыму историю переписки:
struct JassVArray
{
int *VFuncs;
int ListSize;
int NItems;
int *Items; // Это поле является указателем на данные массива
int BlockSize;
}
Так вот, используя операцию присвоения значению переменной массива, которая является указателем на подобную структуру, произвольного значения, содержащегося в обычной переменной (на самом деле совсем не произвольного) мы получаем массив, Items которого ссылается на нужный нам адрес в адресном пространстве процесса, в данном случае это стек одной из веточек. Откуда можно легко перехватить управление. Теперь при записи в массив игра будет на самом деле писать в код процесса. Соответственно, при записи в массив foo[n], данные будут записаны по адресу Items+n.
Кстати, насколько я понял, тут идет запись в стек, основной же код пишется действительно просто в массив. Такой же методикой находится адрес процедуры VirtualProtect, и она выполняется с флагом PAGE_EXECUTE_READWRITE на память, куда записан код. Дальше управление и передается этому коду.
Данные, показанне в примере — очень хорошие, это код. Только надо свапнуть их задом наперед (я делаю это инстинктивно):
set zg0oI[0x200]=0xE8575653
set zg0oI[0x201]=0x000000F3
//...
CPU Disasm
Hex dump Command Comments
53 PUSH EBX ; сохраняем регистры
56 PUSH ESI
57 PUSH EDI
E8 F8000000 CALL 0056C100 ; Вызов. Адрес равен адресу начала кода + 0x0100
да да, помню этот патч
Не забывай, адик, что в 1.24 обратные преобразования тоже реальность.
Пост некромантии, но справедливости.
В 2012, когда я писал эту статью компанией-разработчиком был уже выпущен патч, который исправлял не саму уязвимость, но способ добраться до нее.
Но кто-бы мог подумать, что найдется другой метод эксплуатации данной уязвимости. Я в подробности не вникал, но суть в том, что интерпритатор JASS языка как был дырявым, так им и остался. Уязвимость, насколько я понял работает в патче 1.26 включительно, но уже не работает в 1.27. Уязвимость была открытой еще года 4 наверное.
Я не вникал подробно, поэтому далее могут быть неточности, но если коротко — вместо использования return bug для того, чтобы получить значение переменной типа code и потом изменить ее значение теперь используется некорректная проверка на то, является-ли переменная массивом. Объявляем глобальную переменную-массив, потом внутри функции объявляем локальную переменную с таким-же именем и типом, но не массив, и потом, при обращении из другой функции к переменной с данным именем движок будет считать, что все ок, он обращается не к массиву, но по факту он будет обращаться к массиву, в результате чего и будет получен доступ к памяти с возможностью читать и писать.
Эх, ведь сейчас можно использовать готовое решение, какой-нибудь LUA, python или любой другой скрипт, но в те былинные годы надо было изобретать свой велосипед. Вот и решила Метелица сделать свой скриптовый язык JASS, как говорится сблекджеком и шлюхами бэкдормаи и эксплойтами.
www.hiveworkshop.com/threads/memory-hack.289508
В 2012, когда я писал эту статью компанией-разработчиком был уже выпущен патч, который исправлял не саму уязвимость, но способ добраться до нее.
Но кто-бы мог подумать, что найдется другой метод эксплуатации данной уязвимости. Я в подробности не вникал, но суть в том, что интерпритатор JASS языка как был дырявым, так им и остался. Уязвимость, насколько я понял работает в патче 1.26 включительно, но уже не работает в 1.27. Уязвимость была открытой еще года 4 наверное.
Я не вникал подробно, поэтому далее могут быть неточности, но если коротко — вместо использования return bug для того, чтобы получить значение переменной типа code и потом изменить ее значение теперь используется некорректная проверка на то, является-ли переменная массивом. Объявляем глобальную переменную-массив, потом внутри функции объявляем локальную переменную с таким-же именем и типом, но не массив, и потом, при обращении из другой функции к переменной с данным именем движок будет считать, что все ок, он обращается не к массиву, но по факту он будет обращаться к массиву, в результате чего и будет получен доступ к памяти с возможностью читать и писать.
Эх, ведь сейчас можно использовать готовое решение, какой-нибудь LUA, python или любой другой скрипт, но в те былинные годы надо было изобретать свой велосипед. Вот и решила Метелица сделать свой скриптовый язык JASS, как говорится с
www.hiveworkshop.com/threads/memory-hack.289508
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История и описание уже исправленной уязвимости в игре WarCraft 3