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:19 PM (This post was last modified: 07-23-2017 08:22 PM by assp1r1n3.)
Post: #1
Question Practical reverse engineering methods and procedures
When I see how far RPCS3 went (and will eventually go), I want to know what it takes to reverse engineer a console like PS{3,4,Vita} from scratch without any access to Sony SDK/Dev consoles. PS* wiki(s) have only the results of community's reverse engineering efforts, although I must admit I've been surfing them only for one day. Techniques and procedures are not so evident for me, particularly:
  • What skills are required?
  • What are the initial points of interaction with the vanilla system?
  • What techniques are commonly used against each point of interaction?
  • Where to obtain info on hardware components and their function(s)/internal(s)?
  • How to figure out the ISA of CPU/GPU? Does somebody need to possess $$$ lab like ChipWorks?
  • What crypto/DRM measures are present there and how could one possibly reverse/emulate them?
  • Is/Was any sort of insider knowledge required/used?
Find all posts by this user
Quote this message in a reply
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 

Forum Jump:

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