This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Post Reply 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Practical reverse engineering methods and procedures
07-23-2017, 08:49 PM
Post: #2
RE: Practical reverse engineering methods and procedures
Just my 2 cents:

1. Hard to say - but you need to understand how hardware interacts with software at the very least. Also, knowledge of the processor architecture will almost always be key.
2. Differs from system to system. Community efforts go a long way here
3. Same as point 2
4. Chips will often be documented to some extent officially. That gives a good base
5. Same as point 4. Usually in select cases, community efforts will have already done so, through a variety of methods. e.g For GPU reverse engineering, its almost always MMIO tracing from a *nix machine. The devs pour over the logs and slowly start to form a picture of what registers do when certain values are written to them. There are very few GPU makers so its likely any chip you encounter has been reverse engineered to some extent, or shares architectural similarity with a previously released product
6. No idea. Usually this information is figured out very early (how it works, not how to reverse engineer it) so its largely a community thing. See explanation below
7. Not as far as I know. Also, the important stuff will never be in any documents as leaks are almost always guaranteed to happen eventually

To summarize, as far as emulators go, the community efforts are the greatest advantage. You might have noticed how emulators appear once a community sdk is written as it becomes easier for testers to write test cases for the target system. Its nearly impossible to go it alone. Usually very experienced people will start working on these things as soon as new hardware is available, and most of the methods used are very complicated and system intrusive. Bypassing security can involve tinkering with the hardware directly for example.
I think fail0verflow made a pretty good presentation on how they reverse engineered the ps4 internals. That will be more informative than anything anyone can write here.
Find all posts by this user
Quote this message in a reply
Post Reply 

Messages In This Thread
RE: Practical reverse engineering methods and procedures - kd-11 - 07-23-2017 08:49 PM

Forum Jump:

User(s) browsing this thread: 1 Guest(s)