| Разработка и ромхакинг > Ромхакинг и программирование |
| Hex-Rays |
| (1/3) > >> |
| Timmy!:
До меня дошла информация, что разработчики IDA разработали для своего дизассемблера плагин нового поколения - HexRays. Разработчики заявили, что данный плагин сможет декомпелировать ЛЮБОЙ бинарный файл на язык С#. В интернете его нигде не нашел, а сам плагин стоит недёшево. Вопрос, стоит ли преобретать этот плагин? Правда-ли то, что они обещают? Сможет-ли он декомпелировать РОМы? |
| aptyp:
поискал несколько секунд и нашёл этот "плагин", сам попробуй потом расскажешь... :lol: если что забей в google "IDA Pro Advanced v5.2+SDK+Hex-Rays+Official Utilit" и будет те счастье... |
| Timmy!:
У меня это есть, но где HexRays? Качал именно с хекс реем, но установил, а им там и не пахнет. |
| aptyp:
Личку проверил, да ??? |
| Timmy!:
Да, спасибо. |
| aptyp:
Да незачто... :) только расскажешь потом, тоже интересно... |
| Timmy!:
Здорово, уже декомпелировал THUG2.exe, всё понятно :) теперь пытаюсь компилить его на Гейм Студио А7 :lol: А вот что насчет ромов, я ни то, что не представляю, как с С# сварить ром, я даже незнаю чем его ассемблировать :lol: Нуб я еще, только любитель. :) |
| HoRRoR:
По-моему подобная декомпиляция возможна только в один конец - для удобства восприятия. Обратно полноценно не скомпилишь. |
| Timmy!:
Мда.. :( Я уже заметил, написал простую программу на Game Studio А7, потом дизассемблил и декомпелировал HexRay'ем, там вообще не то. Просто мне очень нужен исходник Tony Hawk's Underground 2, а на одних его скриптах много не сделаешь. А восприятию и правда помогает, можно на базе того, что декомпелируется, написать самостоятельно, например. :) Вернее что удалось распознать декомпилятору, а остальное самому дописать :lol: |
| Йобан Матич:
--- Цитата: Timmy! ---Tony Hawk's Underground 2 --- Конец цитаты --- А ты уверен что его на C# написали, а не на C++? |
| HoRRoR:
Абсолютно без разницы на чём писали, если всё равно скомпилировано в машинные коды. |
| MetalliC:
HoRRoR, есть разница, про С# не знаю, но скомпилённый C/C++ код с другим не спутаешь: передача аргументов в функции, резервирование локальных переменных, обращение к ним - всё это делается на стеке, отсутствие проверок указателей и типов, и т.п. скомпилённый паскаль выглядит совершенно по-другому. |
| CrazyMax:
--- Цитата: MetalliC от 10 Декабрь 2009, 21:46:24 ---HoRRoR, есть разница, про С# не знаю, но скомпилённый C/C++ код с другим не спутаешь: передача аргументов в функции, резервирование локальных переменных, обращение к ним - всё это делается на стеке, отсутствие проверок указателей и типов, и т.п. скомпилённый паскаль выглядит совершенно по-другому. --- Конец цитаты --- А еще можно сменить метод вызова функций и тогда, все что ты написал будет совсем подругому :) |
| MetalliC:
--- Цитата: CrazyMax от 10 Декабрь 2009, 22:07:15 ---А еще можно сменить метод вызова функций и тогда, все что ты написал будет совсем подругому :) --- Конец цитаты --- это да, но всё равно локальные переменные в основном на стек ложатся разбирал когда-то код с штук 3-х разных компиляторов - в целом очень похоже, в паскале всё совсем не так, на этапе выполнения куча проверок типа, ухода указателя куда-то е туда, переполнения и т.п. в сях этого нету в бейсике вообще бардак нереальный :) ЗЫ: это всё относится к асм M68K на Amiga, хотя на SMD наверное те же яйця.. |
| HoRRoR:
MetalliC, не неси чушь, не сбивай с толку народ. --- Цитата ---передача аргументов в функции --- Конец цитаты --- Понятия "аргумент" и "функция" как таковые существует только на уровне языка. При конвертации кода в ассемблер все аргументы становятся обычными значениями, которые кладутся в стек, а функции становятся вызываемыми затем процедурами. --- Цитата ---резервирование локальных переменных --- Конец цитаты --- WTF? Ты сам хоть понял, что говоришь? Возможно, ты имеешь ввиду резервирование места под локальные переменные. Но это уже зависит от компилятора/среды, а не от языка. --- Цитата ---обращение к ним - всё это делается на стеке, отсутствие проверок указателей и типов, и т.п. --- Конец цитаты --- Тут у тебя вообще каша какая-то. Нет на уровня ассемблера никаких проверок. Абсолютно. Есть значения и операции над ними. И из какого языка бы ты не компилировал, всё будет выглядеть примерно одинаково. --- Цитата ---скомпилённый паскаль выглядит совершенно по-другому. --- Конец цитаты --- Обоснуй или не неси что попало. Да, он будет отличаться. Но не более, чем код C/C++, скомпилированный на одном компиляторе, будет отличаться от того же кода C/C++, скомпилированного другим компилятором. Сути это не меняет абсолютно, только особенности реализации некоторых моментов у всех разные. Например, у Паскаля обратный порядок укладки аргументов в стек, но это при необходимости лечится директивой stdcall (у Delphi, по крайней мере). --- Цитата ---А еще можно сменить метод вызова функций и тогда, все что ты написал будет совсем подругому --- Конец цитаты --- Что ты подразумеваешь под методом вызова функций? Порядок укладки аргументов в стек? И что же тогда будет по-другому? Вывод: учите матчасть, а потом ведите дискуссии. |
| MetalliC:
--- Цитата: HoRRoR ---Вывод: учите матчасть, а потом ведите дискуссии. --- Конец цитаты --- кучу всего скипнул ещё раз: если брать современные компиляторы - всё что ты написал верно, разницы почти нет. всё что я написал это не теория, а практика разбора кода компиляторов SAS C, DICE C, GNU C, Hisoft Pascal и BlitzBasic под M68K/Amiga Добавлено позже: применительно к ромхакингу, разницы с например SMD почти нет да и многие игры для генесиса на амигах делались Добавлено позже: --- Цитата ---Цитата --- Цитата ---А еще можно сменить метод вызова функций и тогда, все что ты написал будет совсем подругому --- Конец цитаты --- Что ты подразумеваешь под методом вызова функций? Порядок укладки аргументов в стек? И что же тогда будет по-другому? --- Конец цитаты --- первую строку ты же сам писал :), в M68K можно при вызове функции передавать аргументы/возвращать результат на стеке или прямо в регистрах процессора |
| CrazyMax:
--- Цитата: HoRRoR от 10 Декабрь 2009, 23:45:03 ---Что ты подразумеваешь под методом вызова функций? Порядок укладки аргументов в стек? И что же тогда будет по-другому? Вывод: учите матчасть, а потом ведите дискуссии. --- Конец цитаты --- например в x86 стек может и не использоваться, если передается до 3-х переменных (значений) и функция объявлена как __fastcall, то передается черех регистры ecx, edx, eax без стека так же есть __pascal - передается так же как в Паскале и т.д. |
| HoRRoR:
--- Цитата ---всё что я написал это не теория, а практика разбора кода компиляторов SAS C, DICE C, GNU C, Hisoft Pascal и BlitzBasic под M68K/Amiga --- Конец цитаты --- Каким боком практика побудила тебя напрямую сравнивать машинный код с исходным кодом на языке высокого уровня? --- Цитата: CrazyMax от 11 Декабрь 2009, 00:30:38 ---например в x86 стек может и не использоваться, если передается до 3-х переменных (значений) и функция объявлена как __fastcall, то передается черех регистры ecx, edx, eax без стека --- Конец цитаты --- x86 тут не при чём, всё решают оптимизатор и компилятор, независимо от процессора. --- Цитата ---так же есть __pascal - передается так же как в Паскале и т.д. --- Конец цитаты --- Банально порядок аргументов. Ни на что толком эти изменения не влияют, основной код (обрабатывающий загруженные/переданные значения) останется прежним. |
| MetalliC:
--- Цитата: CrazyMax от 11 Декабрь 2009, 00:30:38 ---например в x86 стек может и не использоваться, если передается до 3-х переменных (значений) и функция объявлена как __fastcall, то передается черех регистры ecx, edx, eax без стека так же есть __pascal - передается так же как в Паскале и т.д. --- Конец цитаты --- насчёт x86 спорить не буду. но тут вроде как по ромхакингу раздел, и этот проц тут как бы не к месту ;) в моторах где-то так же, но регистров побольше - 8 регистров данных (аккумуляторов по интеловским понятиям) и 8 адресных (32битных) последний адресный A7 является указателем на стек, поэтому типичный сишный код с постоянными обращениями по A7 с отритцательными смещениями и кучей комманд типа move (a7,-xxx), xxxx парни: ну мне чё реально сейчас декомпилить разный m68k софт чтоб сравнивать ? Добавлено позже: --- Цитата: HoRRoR ---Каким боком практика побудила тебя напрямую сравнивать машинный код с исходным кодом на языке высокого уровня? --- Конец цитаты --- я ковырял/ломал разные программы, и похожу научился различать на чём они были написаны/скомпилены --- Цитата: HoRRoR ---x86 тут не при чём, всё решают оптимизатор и компилятор, независимо от процессора. --- Конец цитаты --- какой нахрен оптимизатор ??????? мы тут вроде о ромхакинге, и соответственно о компиляторах конца 80х-начала 90х, откуда там оптимизации ? Добавлено позже: вы мля ещё скажите что сишные компиляторы и паскали того времени давали одинаковый код! Добавлено позже: PCшные |
| HoRRoR:
Тема превращается в цирк. --- Цитата ---поэтому типичный сишный код с постоянными обращениями по A7 с отритцательными смещениями и кучей комманд типа move (a7,-xxx), xxxx --- Конец цитаты --- Всё-таки продолжаешь утверждать, что всё зависит от языка, а не от компилятора. --- Цитата ---но тут вроде как по ромхакингу раздел, и этот проц тут как бы не к месту --- Конец цитаты --- Ромхакинг и программирование. Ромхакинг - имеет отношение? Имеет, как потенциальный инструмент. Программирование - тем более. --- Цитата ---мы тут вроде о ромхакинге, и соответственно о компиляторах конца 80х-начала 90х, откуда там оптимизации ? --- Конец цитаты --- Huh? Ну после таких высказываний не вижу смысла о чём-либо спорить. |
| Навигация |
| Главная страница сообщений |
| Следующая страница |