Below are the 18 most recent journal entries recorded in quest_for_glory's LiveJournal:

Monday, July 25th, 2005
12:30 pm	Планы Текущий прогресс таков, что мне удалось начать игру, и сделать там ход. Так что я занялся написанием мидлета. Сегодня планирую оформить тот мусор, что я написал вчера, чтобы код для рисования доски был уже "правильным". (4 Comments |Comment on this)
Wednesday, July 20th, 2005
11:55 pm	Последние дни В последнее время я продолжал писать клиента. И столкнулся с проблемой. С одной стороны, мой клиент уже кое-что умеет, например, логиниться и принимать сообщения и прочие евенты, с другой - он не умеет "играть", и вообще, эта область - как начинается игра, какие там пакеты, и т.д. - не исследована. Нужно выбрать между развитием моих знаний о протоколе с одной стороны, и демонстрации уже имеющихся знаний (в большей степени мне, чем кому-либо), с другой. Я выбрал второй вариант - я решил написать болванку, которая бы примерно позволяла представить, к чему я вообще иду. Ну и тут возникли новые проблемы. Имплементационного характера. Например, простейшая задача - выводить строчки чата, оказалась не такой уж простой, потому-что стандартного (и удобного) способа сделать это не существует. Есть Form, в которую можно пихать Item'ы, которые могут быть чем угодно, но во-первых нужная мне функциональность находится в MIDP2, а а во-вторых, даже этого мало - например, я так и не понял, как сделать авто-скролл, т.е. чтобы при добавлении новых данных в форму, она скроллировалась на эти данные. Другой подход - юзать уже готовые классы, которые будут эти строчки как-то самостоятельно рисовать на Canvas'е. Тут есть j2mepolish, jmobilecore, и классы из jimm. Я попробовал jimm, оказалось, что он не делает враппинг. j2mepolish - это монстр, какого ещё поискать. Шутка-ли, весь MIDP ручками написан. jmobilecore ещё не смотрел, но у меня осталось впечатление, что он попроще будет (в использовании). Но! Вот сейчас мне пришла в голову мысль, что это всё нах не нужно - все эти чаты, в которые можно только смотреть (так как я гость), и все эти списки столов, от которых толку 0, потому-что всё, что нужно - найти стол с готовым играть чуваком, или самому сесть и объявить готовность - проще и удобнее делается автоматически. Короче, я начинаю ботанить дальше. Научусь играть, и сделаю вообще тупой мидлет с одной кнопкой "Играть". (Comment on this)
Friday, July 15th, 2005
11:50 pm	Пятница Сегодня я научился садиться за столы :) Прикольно видеть (стандартным клиентом), как Гость#1232 раз за разом садится за один и тот-же стол. Веселее будет только если сделать последовательный перебор всех столов. Да побыстрее, хехе. Но, не будем раньше времени привлекать к себе внимание. Ещё выяснился неприятный косяк, дурацкая проблема, как говорит Маньяк - receive блокирует выполнение, пока не придут байтики с сервака. С одной стороны оно так и должно быть, чегож я хотел, а с другой - во-первых я бы предпочёл асинхронные сокеты, которых конечно нет в телефонах, а во-вторых единственное решение этой проблемы - два потока, один из которых тупо висит в receive, а второй отправляет запросы на сервак, по мере их поступления. В принципе получается ничего, но мне не нравится, как это будет выглядеть на яве. Значит, если один поток, то всё ок - implements Runnable, затем запускаем поток от this. А если два, то ничего не поделашь - придётся делать inner класс, запускать его в потоке, а в его методе run() звать метод из родительского класса. Zzzz. Текущая задача - написать парсер закапчуренных пакетов. И можно начинать реализовывать непосредственно шашки. Хотя думается мне, придётся чё-нить хукнуть "по живому", чтобы в реалтайме смотреть пакеты туда и оттуда. (Comment on this)
Thursday, July 14th, 2005
2:04 pm	2 дня Вторник, среда - я пишу клиента на яве. Ну, что я могу сказать: ломать - не строить, хехе. Основные проблемы - с тем, что приходится разбирать ответы сервера, потому-что когда пишешь код, знания "а ну вот эти х байт похоже вот это" уже недостаточно, нужно точно знать, что где лежит. Ещё не до конца понятно, как написать правильного клиента на яве, чтобы им было удобно пользоваться. Я думаю, я сделаю очередь (стек) евентов, которые из клиента можно будет читать, и которые он, получая сообщения от сервера, будет в эту очередь пихать. Однако, так как евенты будут разных типов, типа "сообщение от", или "чувак сел за стол", или "началась игра", то придётся делать базовый класс, и плодить от него классы евентов. Тут у меня недостаток знаний, вроде бы в яве можно сказать isinstanceof, чтобы узнать, чем на самом деле является объект, однако я боюсь, что это будет медленно (кхм). Пока у меня есть базовый класс с полем type, в котором будет тип евента. То, что удобнее сделать switch() вместо cascading if - это очевидно, но с другой стороны - у меня доп. класс с каким-то непонятным типом, полезность которого неочевидна. Короче, время покажет. Ещё я только что разботанил как в сообщении кодируется его цвет и свойства фонта - pt,bold/italic, и т.д. Это феноменально, господа. Значит, они берут 6 байт, делают из них число, а потом записывают его в системе по модулю 90. Получается 6 символов. Дааа. Используются почти все символы ASCII - от '!' до '{' включительно. Цвет в этих 6 байтах виден сразу, да и насчёт bold/italics флагов вроде всё понятно, а вот насчёт размера шрифта - пока смутно. Ну да, зачем мне размер шрифта. Пока можно забить. (1 Comment |Comment on this)
Monday, July 11th, 2005
11:05 pm	Понедельник За воскресенье и понедельник я начал писать java-версию клиента. Первое, что мне пришлось сделать - разобраться с блоуфишем. Итак, дано - выдранные контексты, и функции (1), выдранные фукнции инициализации контекстов (2), две сторонних реализации блоуфиша (с сайта) (3),(4), ява-версия (5). Проблема - никакие версии не дают одинакового результата. Муахаха. Под результатами я имею в виду как и сами значения контекстов, так и результаты шифрования/дешифрования. Короче, долбился долго. Выяснилось, что у явы-версии контексты получаются правильные, а результат - нет. Стал разбираться, и выяснилось, что если в каждых 4 байтах данных поменять их порядок на обратный, то результат шифрования опять-таки совпадёт с точностью до обмена байт. Ура. В общем, через некоторое время, уже в понедельник, я сделал, чтобы всё работало. Текущее состояние ява-клиента - отправляется 2 запроса, получается 2 ответа. Самое главное, что всё правильно генерится и шифруется, прям не верится. Теперь меня ждёт дезигн и имплементейшн. Надо бы хотя-бы парсить лобби-инфо, да нотификацию о входе\выходе, ну и сообщения. И можно начинать сувать в телефон. (3 Comments |Comment on this)
Saturday, July 9th, 2005
11:23 pm	Суббота Сегодня я дописал клиента до состояния, что он умеет "логиниться", и потом просто тупо принимать всё, что ему посылают. Так как сначала попадаешь в лобби, то приходят сообщения от чуваков и нотификации об их входе/выходе. Сейчас я изучаю дампы :) Это прямо праздник здравого смысла! Прямо смотришь, и видишь, ага 96 00 02 00 - это количество столов (150) и количество игроков за каждым столом (2). Ну, не так конечно быстро, но почти. Буквально только что распознал 52х байтовую последовательность - инфу о занятом столе. Оказывается, макс. количество игроков за столом равно 8. Ну, ещё болтовня чуваков тоже радует. Особенно, когда перед сообщением видишь имя шрифта, от сообщения его отделяет байт 0x01 :) Ещё прикольно сделаны нотификации о входе/выходе - отправляется сообщение от пользователя с именем (Enter)/(Exit), а само сообщение - это имя чувака которых входит/выходит. Вообще, постепенно я понимаю, что раньше я не смог бы ничего зареверсить, не смог бы ничего распознать/догадаться. Для этого нужен опыт, причём опыт именно созидательного труда. Короче, всё должно быть вовремя. Ну а хакеры/крякеры, настоящие, конечно, - это реально профессиональные чуваки. Респект им. (Comment on this)
Friday, July 8th, 2005
1:21 pm	В последнее время В последнее время я пишу клиента. В четверг парился с мистической ботвой - утром я обнаружил, что могу расшифровать первый запрос, но не могу его зашифровать. Т.е. я делаю обратные действия, и получаю неверный результат! Проверил - если зашифровать / расшифровать контекстом3 нулевые байты, то в результате получаются не-нулевые байты! Муахаха. Для всех остальных контекстов - всё ок. Всё утро только этим и занимался, так ничего и не понял. Зато я выдрал инициализацию контекстов - это всё равно бы пришлось делать, хотя-бы для экономии места в мидлете - так мне придётся хранить не 4 куска по 0х1048 (контексты), а всего один (инициализация для p- для s-boxes). А, ну так вот. А вечером, оказалось, что всё ок. Нулевые байты по прежнему не получаются, зато пакет зашифровыватся нормально. А вроде ничего не менял. Мистика, короче. Результат уже есть - меня не отпнули после второго запроса, я даже получил ответ. Хороший знак :) (Comment on this)
Wednesday, July 6th, 2005
11:52 am	Среда Чтож, я разобрался с белибердой. Это феноменально. Это никакая не белиберда, а просто много маленьких пакетов (по 32 байта), склееных вместе. Вчера я, стало быть, расшифровал только первый, а белиберда - это все остальные пакеты. Но посылать склеенные пакеты?! Воистину, "что день грядущий мне готовит". (Comment on this)
Tuesday, July 5th, 2005
11:50 pm	2 дня За понедельник и вторник я ещё немного покусал прогу. Разботанил recv, и научился расшифровывать пакеты. Самое большое достижение - я расшифровал коммуникацию начиная с первого пакета, и до 7го. Круто было :) Чуваки не перестают меня поражать - мало того, что пакет шифруется двумя разными блоуфиш-контекстами, так ещё первый запрос шифруется 3ьм, а первый ответ расшифровывается 4ым контекстом! Где-то меня ждёт 5й, и, надеюсь, последний контекст. Ещё написал крякер для их xor шифрования, который подбирает seed такой, чтобы первые 4 байта расшифровались правильно. На моём компе перебор 0xFFFFFFFF вариантов занимает минуты 3, ну 5, короче, приемлемое время, чтобы тупо сидеть и ждать. Вот до чего техника-то дошла! Тем не менее, оказалось (уже потом, конечно), что делал я это всё зря, и надо было просто внимательнее посмотреть на код, из которого ясно было видно, куда суётся seed. Текущая проблема - в 6 и 7ом пакетах, в данных, я наблюдаю какую-то белибердень. А я так привык видеть в расшифрованных данных милые глазу ASCII строчки. Думаю, что это сжатые данные, однако наивная попытка скормить zlib'у ничего не дала. Или может это шифрованные данные. От них всего можно ожидать - шифрованные данные в пакете, который затем шифруется? Легко! :) В первых пакетах встретил имя SSPI провайдера (в ответе), и те 4 жалких байта, которые он возвращает (в последующем запросе). В общем, прогресс. Думаю начать в свободное время переводить блоуфиш на яву. Сейчас он в асме, так что сначала придётся в С, используя только тот минимум, который пересекается с явой, а потом на яву. (Comment on this)
Sunday, July 3rd, 2005
1:40 am	Суббота Результат субботы таков: написана функция, которая по входным данным (сырые данные + 3 магических числа) генерит правильный пакет. Прям хоть бери и отсылай :) Среди магических значений одно пытался проследить, но дело осложнилось Армадиллой. Статически анализировать не получается, так как то и дело в коде стоят весёлые jmp в память (где на момент дампа и была армадилла). Прыгаем на код, который делает какую-то белиберду (обменимает по пять раз регистры, пушает-попает, и т.д.) а в конце - опять прыгает назад, на следующую инструкцию за первым jump'ом. Это, насколько позволяют мне туманные знания, "полиморфный код", т.е. он делает какие-нибудь простые действия, типа вот я раскопал, делается два push'а, но вокруг наворочено всякой разной херни, так что сразу и не разглядеть. Короче, защита, бля. Наверное, мне даже не понадобится это всё анализировать, так как в конце всё приходит в нормальную функцию. Ещё сегодня воровал код :) Чтобы не было проблем с блоуфишем, я выдрал контекст (1048h байт кстати, довольно дохрена), и функции. Распихал их по __declspec(naked) __stdcall функциям, которые полностью состоят из блока __asm. Что порадовало - копипейст из иды абсолютно нормально кушается студией. Хотя, наверное так и должно быть, хз. Сначала возился с аргументами - т.е. вот я вижу, что функция принимает 3 аргумента, я и пишу их все. Потом до меня дошло, что нахрен это не надо, так как функции напрямую не зовутся, только из __asm'а. Теперь все функции (), что смотрится довольно странно, так как я точно знаю, что вот эта функция принимает один, а вот эта - три агрумента. Короче, надо ботанить recv. Думается мне, потом сразу можно будет писать клиента. (Comment on this)
Saturday, July 2nd, 2005
12:57 pm	Пятница В пятницу я узнал немного больше о том, что и как шифруется. Ну во-первых, пакет состоит из заголовка (8 байт) + заголовок сырых данных + сырые данные. Так вот, заголовок пакета шифруется одим ключём, а всё остальное - другим. Это удивительно! Я-то думал, странно, что два вызова Blowfish_Encrypt, а оказалось, подсовываются разные конкексты. Но и это ещё не всё. Во-вторых, я понял, зачем требуется супер-xor-шифрование - так как Blowfish используется в ECB моде, когда любые две одинаковые 8 байтовые последовательности переходят в опять таки в одинаковые последовательности, то xor-шифрование нужно для того, чтобы внести неоднородность в данные. Т.е. иначе последовательности 0, например, распознавались бы влёт. Такс, дальше. Дальше больше - ключи, которыми инициализируется блоуфиш всегда одинкаковы, так что контекст блоуфиша всегда одинаков. Я даже не буду париться выдирать инициализацию (которая опять-таки использует xor-шифрование)- я сразу выдеру контекст. Что ещё... Ещё - у них как минимум 5 блоуфиш контекстов. Т.е. как я понимаю, ещё 2 используюься на расшифровке полученных данных, а зачем нужен 5й - хз. Ну ещё опознал алгоритм подсчёта хеша - им оказался CRC32 :) Единственно, что мне не понятно пока - это магическое 4х байтовое значение, которое, похоже приходит из сервака, и его роль в xor-шифровании. Похоже дело обстоит так - в пакет пишется magic, затем он-же используется для шифрования. Затем, перед посылкой, это значение увеличивается на 1. Странно, потому-что на счётчик оно явно не тянет, слишком велико. Короче, я двигаюсь вперёд. Очень радует, что используются такие относительно простые алгоритмы - их будет просто реализовать на яве. (Comment on this)
Friday, July 1st, 2005
11:09 am	Вчера! Вчера был совершён прорыв! В результате, была отключена (сазаспенжена) злобная крокодилла, и появилась возможность дебажить процесс. И ставить хуки на функции из длл, естессно. Что я и сделал, и выяснил, что в одну из функций приходят сырые пакеты. Хо-хо-хо! Так что я приаттачился, поставил бряк, и в течении полутора часов, буквально mov за mov'ом разбирался, как шифруется пакет. Чтож, это Blowfish, господа. Правда, реализация какая-то странная, я такой в инете не нашёл, какая-то древняя, что-ли. Нашёл что-то похожее на линуксовом ассемблере :) Я думаю, я просто выдеру все их функции, и всё. __declspec(naked), нах! А, но блоуфиш - это ещё не всё. Там есть замечательное шифрование, до него. Делается rand() от предопределённого seed'а, и результатом xor'ится заголовок пакета. Зачем это делать, если сверху будет енкрипшн, который гораздо круче этого отстоя, я не понял. Теперь как это было. Началось с того, что я пришёл в твёрдой уверенности, что мы неправильно хукаем функцию, вот она и падает. Ну ладно, int 3 в прокси, и вот появляется возможность дебажить. Но не всегда, так как прога отлавливает IsDebuggerPresent, и иногда, после запуска студии и начала дебага, прога просто выходит. Иногда - это 2 раза из 3 :) Ладно, фигня. Дебажим, значит. Вот мы в прокси, вот наш инт 3, вот мы вызываем хук, вот делаем ret, и оппа - попадаем в мусор. Странно, думаем, повторяем. Наблюдаем - сразу после аттача студии код нормальный, а после ret - мусор. Ага. Значит, кто-то меняет код, пока мы ходим по проксям да по хукам. Сначала думали, крокодилла расшифровывает/зашифровывает по мере продвижения, но нет - в задампленной ДЛЛке весь код нормальный. Стали смотреть на потоки, коих довольно много - штук 10-12. Выяснили, что если засаспендить все, то всё ок - код не меняется. А, и ещё одно западло, которое делают потоки - они закрывают прогу, как только чуют дебаггер. Соответственно, если всё засаспендить, то всё ок, прога не закрывается, код не меняется. Но и прога не работает как надо, ессно. Занялись потоком, который проверяет наличие дебаггера. Причём хитро, не вызывая функцию, а ручками читая fs:18h. Попробовали в бинарнике заменить movz на xor,nop,nop - игра вообще не запускается, хеш наверное считает. Хорошо, стали делать в DLLMain, помимо всего прочего, патчить эти 3 места проверки дебаггера. Ок, дебаггер не прочухивается, зато код меняется. Стали монотонно рассаспенживать потоки, чтобы понять, какой меняет. Нашли поток, который, кстати, "вырос" из ДЛЛи, распакованной в память. Это крокодилловская ДЛЛ, security.dll. Нашли её начало, конец, хотели задампить, да руки что-то не дошли. Короче, нашли поток. Выяснилось, что если его засаспендить, то всё ок - прога работает, код не меняется. Кроме того, обнаркжилось, что этот поток всегда 7ой в списке потоков процесса в студии. Оок, пишем код, который енумерэйтит потоки, и заспендит 7ой. И вуаля! Прога работает, но абсолютно беззащитна, мухахаха. (1 Comment |Comment on this)
Thursday, June 30th, 2005
1:02 am	2 дня За понедельник и вторник я много чего узнал, и немного продвинулся в освоении вражьей длл-ки, которая, как оказалось, запротекчена Armadillo'й. У неё там есть кусок, который она расшифровывает по ходу работы. Но это для меня не проблема - я задампил всё длл из памяти на диск, а потом засунул в иду по адресу. Там такой хитрый сегмент, с большим виртуальным, но маленьким физическим размером. Научился (с помощью Маньяка) писать скрипты к иде :) Короче, увидел этот запротекченный-распротекченный код. Ида даже ссылки проставила, ляпота. Затем я осваивал патчинг функций из dllек. Для начала запатчили send из WS2_32, и затрейсали стек. Стек затрейсился хорошо. Затем я обнаглел, и решил запатчить одну из функций из этого callstack'а. Прога вызывает функцию один раз, а потом закрывается. Думали, защита, хэши и TerminateProcess. Хер-то-там. Вот только щас я поставил ExceptionHandler, это оказался банальный креш 0xC000005. Задампал EIP, завтра буду разбираться (будем разбираться). Ещё - хорошие новости насчёт SSPI. Маньяк обнаружил там магические константы, которые на проверку оказались из MD5. Нашёл все MD5_ функции. Это было круто - смотришь в код, смотришь в иду - один к одному :) Короче, считается там дайжест. Но считается на каком-то 2 или 3ем вызове InitializeSecurityContext. А у меня только один, в котором прописыватся какая-то херь 4-х байтовая. Ещё, что мне понравилось - чуваки из Wine'а похоже эмулируют винду один-к-одому. Смотрю, что-то в хендле, который состоит из двух DWORD'ов, подозрительные какие-то значение DWORD'ов, на адреса очень уж похожи. Пошёл в Wine - точно, как раз тот DWORD, который не заполняется в моём SSPI, хранит указатель на хитрую структуру. Хитрую, но бесполезную - просто инфа про этот SSPI, чтобы для вызова было только хендла достаточно. Короче, план простой - хукнуть всю цепочку до send'а, и, я ОЧЕНЬ надеюсь, поймать вызов с "сырыми" данными. После этого задебажить цепочку, и понять, как они шифруют сообщения. Ещё надо бы хук написать, а то что-то DLLMain моего SSPI зовётся поздновато. (Comment on this)
Tuesday, June 28th, 2005
12:27 am	Сегодня Вернулся я значит, к Zone Games. И обратил свой взрор на ихний SSPI провайдер, коий занимает всего 16К. Написал к нему враппер, положил его в SYSTEM32. Эта ботва давай апдейтить длл-ку. Ну думаю, началось. Не хватало мне ещё под размер подгонять, да под хеш какой-нить. Оказалось, что MS это круто! Они всего-лишь читают версию, и сравнивают её. Пара манипуляций с MSVC - не многие знают, что им можно открыть бинарник как "ресурсы", и вот у меня уже скопирована VERSION_INFO. И вуаля - моя ДЛЛка дёргается! Это успех, господа. Дальше ещё лучше - смотрю я в строки, в иде, и что я вижу - знакомые сообщения об ошибках из zlib! Смотрю - и точно, deflate/inflate присутствует. Отлично, значит пакеты небось сжимаются. А то проверить данные на zlib compressed заголовок я бы догадался в последнюю очередь. Смотрю дальше - вижу строчки что-то типа "не могу найти протектед сигнутуру". Надо сказать, что это происходит в длл-ке, у которой корявые импорты. Старая ида вообще на ней падала. Короче дальше туева хуча строк, ида их распознала как строки, которые на самом деле являются каким-то закодированным кодом. Муахахаа, моя длл-ка в твоём процессе! Короче, начал я со стек трейса. Вижу адреса - иду в дллку, а там пустота. Делаю dump всего экзешника, и вуаля бля - по тем адресам вижу код, очень похожий на правильный. Вижу, правда во hiew, ида чё-то слишком умная, а как ей сказать - не знаю. Короче, идей теперь - уйма! Видит бог, буду патчить таблицу импортов, чтобы проследить откуда зовётся send/receive. Ещё пробовали такой трюк - на entry point'е меняем Push ebp (55) на CC, и получаем возможность залезть дебаггером в процесс. По другому это никак - эта тварь, как только прочухивает IsDebuggerPresent, сразу делает TerminateProcess, да ещё как - пихает аргументы в стек, и перетирает адрес возврата на самый первый push этих аргументов. Получается веселуха. А, ну и callстека у функции нет - на неё делается jump. Короче, есть ещё мулька - отключить защиты и проверки, и дебажить нормально. Не знаю, не знаю. Посмотрим. Мне единственно из всего этого нужнен протокол + схема шифрования. (Comment on this)
12:17 am	Пятница Пятница прошла под знаком дебага. Маньяк учил меня плохому - аттачиться к процессу, и ставить бряки в функции. Век живи, век учись, а делали мы это MSVC-ёвым дебаггером. Что выяснилось. Как-то было странно. Запускаем XP шашки, аттачимся ставим бряки на всевозможные send/receive'ы. Получаем, что посылает-то прога, а получает какой-то WinInet. Дальше больше - во время игры бряки вообще не работают. Не работают и всё тут. Или сначала работали, но были неочевидными, типа прога вызывает что-то, что через SHWL-что-то-там вызывает WinInet, который и делает send/receive. Потом я начал ставить всякие проги для мониторинга API, чтоб с параметрами. Mutek BugTrapper, очень здравая прога, вообще не работат под XP - закрывается сразу после аттача к процессу, или запуска процесса. Ничего больше найти не смог, но отстоя понаставил много, в том числе пару Bounds Checker'ов. Короче, долго-ли коротко-ли, но наступил вечер, а результата нет как нет, да ещё бряки перестали брякаться вообще. Т.е. send срабатывает ОДИН раз, потом начинается игра, и всё - тишина... Потрахался ещё немного, и забил. Пошёл на форум, и читаю ответ на свой вопрос относительно протокола - типа чувак, encryption scheme used in Zone Games is still unkonwn. Йо! Still unknown, этож круто! Было unknown, станет known. В общем, я опять вернулся к Zone Games. (Comment on this)
Friday, June 24th, 2005
3:36 am	Вчера Начал, значит, ботанить. Выяснилось, что WSOCK подлинкован к двум DLLкам. Смотрю в первую - send есть, recv'а нет. WSA-аналога тоже нет. Смотрю во вторую - sendto есть, recvfrom есть. Чё-то странно, думаю, вроде sendto с UDP используется. Почитал MSDN - вроде нет, SOCK_STREAM тоже канает. И НЕ ПРОВЕРЯЯ, что создаётся ебучий STREAM сокет я начинаю писать враппер над этой DLLкой, чтобы понять, что и с какими агрументами из неё зовётся. Смейтесь, смейтесь... Смейтесь, смейтесь... Смейтесь, смейтесь... Зато я много чего нового узнал. Даа. DUMPBIN /EXPORTS генерит .def файл. LIB /DEF: генерит либу из def файла. Ещё есть DLL to LIB, который конвертит DLL в LIB. Есть IMPLIB, который делает тоже, что и DUMPBIN/LIB. Cкачать можно, например, с DigitalMars'а, но тогда LIB'а не будет подходить к MSVC. Ещё есть IMPLIB32, эта для MSVC, только генерит полную хуйню с номерами вместо имён функций. Но самое полезное - это то, что если extern "C" и __stdcall, то функция имеет вид _myname@size. Даа. Короче, сгенерил я либу для DLLки, для которой я написал враппер. А! А как отключить WFP под XP? Чтобы умная винда не восстанавливала системные DLLки? Есть способ, с исправлением каких-то 4 байт в каких-то дллках, но мне было влом, и я просто занулил размер DLLCache в реестре. XP начала просить диск, и появилась возможность сказать Отмена/Да. И у меня сгенерился лог вызовов функций! Ещё немного - и я выделил 4, и залогал их аргументы. Потом выяснилось, что в одну передаётся callback, я залогал и его, нашёл в параметрах указатели, залогал первые 100 байт по ним. Вот теперь мы подощли к моменту, по которому я завёл журнал. Потому-что очень быстро я понял, что чё-то не меняется значения по указателям (которые, я предполагал, являются буферами). Даа. Ещё немного - и я понял, что эта ебучая DLLка вообще ничего не отсылает/принимает. Таким образом, ещё полтора дня в жопу. Хотя нет, постойте! Я же знаю теперь, что такое DUMPBIN! Хе-хе. Ну так вот. А чтобы от моей ёбли был хоть какой-то толк, я решил описать все процессы тут. Я уверен, есть люди, которым это будет интересно/весело почитать. Или может быть, кто-то захочет мне как-то помочь. Посмотрим. (Comment on this)
3:26 am	Продолжение... Короче, долго-ли коротко-ли, но я наткнулся на DirectPlay. "Вот оно!", сказал я, и начал писать враппер над стандартной реализацией. В полтора дня я закончил. И? А нихрена! DirectPlay объект не создаётся. Вообще, прежде чем писать, нужно было глянуть на список загруженных модулей, и НЕ увидеть там dplayx.dll. Блядь! Хакер из меня никакой. Сказываются годы созидательного труда. Хе-хе. Ладно, вариант Б - стандарные XP-игры. В отличие от MSN zone-паранойи, где считаются какие-то хеши, проверяются дебаггеры, и делается прочая херня, в XP-играх всё нормально. Если не считать 5 DLLек, в которых чёрт ногу сломит. Херня, я начал ботанить. (Comment on this)
3:17 am	Начнём-с Этот журнал посвящён реверсингу шашек, входящих в стандартную поставку Windows XP. Конечная цель проекта - написать j2me клиента(ов) для стандартных XP игр. Чем обеспечить себя славой отныне и во веки веков. Краткая история: 1. Попытка первая. Изначально я хотел зареверсить (как же мне нравится это слово) клиента для шашек с MSN Gaming Zone (www.zone.com). Однако. Однако оказалось, что протокол шифрован. Ставится zwebauth.dll, которая является SSPI провайдером. Что этот провайдер делает, и с чем его едят - не знаю, но жизнь шифрование портит конкретно. Поэтому я занялся дизассемблингом-мблингом. Оказалось, что я не могу сходу обнаружить код отправки/принятия данных. Никаких WSA, send или recv. (Comment on this)