ShuriZma
/
Cxbx-Reloaded
mirror of https://github.com/Cxbx-Reloaded/Cxbx-Reloaded.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Created Maintaining OOVPA's for HLE function detection (markdown)

PatrickvL 2017-02-02 14:14:26 +01:00
parent 2b15740efe
commit 9c2d5ca14a
1 changed files with 19 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Maintaining-OOVPA's-for-HLE-function-detection.md Normal file

@ -0,0 +1,19 @@
#Introduction
Cxbx in it's current form, uses HLE (High Level Emulation). This roughly means, that code in an XBE (XBox Executable) is executed as-is. However, any code that accesses XBox hardware registers will cause problems, since this hardware is not present in the host system running Cxbx.
So, for HLE to work, Cxbx needs to prevent those hardware accesses. Cxbx does this by scanning for problematic pieces of code, and patches these with replacement code, that emulates the original behavior.
#Scanning
Cxbx scans the contents of an XBE using so-called OOVPA's. This stands for Optimized (Order,Value)-Pair Array.
It's a datastructure that was thought up by Aaron Robinson (also known as Caustik), the initiator of the Cxbx back in 2003.
It's initial description can be read on http://www.caustik.com/cxbx/download/progress.htm, it says:
>In order to efficiently locate a given chunk of assembly code (i.e. a High Level Function), a database of (offset,value) pairs can be used. Offset represents the offset (in bytes) from the start of the function. Value represents the byte value at that location. With this datatype, we can locate the function by hand, and then write down important (offset,value) pairs. This process is time consuming, but very rewarding. Cxbx is able to successfully (and with no false identifications to date) identify High Level Functions inside an arbitrary XBE file. This is due to the fact that, statistically, carefully chosen (offset,value) pairs are capable of uniquely identifying relocatable code. The likelihood of falsely locating a function body is inversely proportional to the number of pairs combined with the rarity of those pairs.
Each OOVPA describes one unique function which originated from a specific version of a library. Cxbx uses the OOVPA to scan for the location of that function in the XBE. If the OOVPA can be matched to a location in the XBE, that location can be overwritten with a call to a replacement function, called a patch, which emulates this function.
OOVPA's are registered in OOVPATable's. In it's current state, Cxbx contains one OOVPATable per version of a library.
Together with the registration of an OOVPA in a OOVPATable, a patch can be mentioned. Registrations without a patch mention are not patched (obviously) but are still useful for scanning.
Apart from OOVPA's, Cxbx contains a set of so-called XRef numbers (short for cross-reference numbers), which are unique ID's to indenify a function by. When scanning for functions, Cxbx records the location of each function XRef's for which the location is determined,
Some OOVPA's are defined including an XRef number. When scanning for functions using the OOVPA's, matching locations are found. When there's a match found for an OOVPA with an XRef, the matching location is written to a list, indexed by the XRef number. Once this XRef is set, it's final, meaning that Cxbx will skip any further OOVPA mentioning that same XRef number. Also, some OOVPA's contain a XRef that must be previously detected. During scanning, if this XRef isn't set, the OOVPA is skipped and retried in a later pass. (As scanning is done in passes, repeating until no more XRef's are located.)