Rough explain with ps2_gxemu.self from 4.81/4.82
First you need to decrypt the file with scetool (scetool.exe -d ps2_gxemu.self ps2_gxemu.elf)
Then open it in hexeditor and delete the first 0x10000 bytes (save it as new file ps2_gxemu.cropped.elf)
Now, in this version of the emu we know the table containing the game title IDs (CRC hashed) is at offset 0x33DFE8
So "go to" that position (in HxD ctrl+g)
You can also jump to that position by searching for the first title_id_crc mysis posted for the first game, the first game in the list is "24: The Game" (SLUS-21268)... or the value resulting after hashing the title ID mysis posted before, for this game is: 0x00000054a955f965
So you can "find" that value (in HxD ctrl+f)
Im going to call this area the "TITLE ID table"... you are at the start of that table
Every entry in this table is 0x18 bytes length, there are 788 entries (in decimal), and every entry is a game, the entry fields are divided like this:
0x8 bytes = title_id_crc
0x8 bytes = commands_offset
0x4 bytes = commands_count
0x4 bytes = unknown
So... the title_id_crc is the value you have marked in bold right now (incase you tryed to "find" the value 0x00000054a955f965)
commands_offset is the offset where are located the next data you have to read
commands_count is just a counter, usually is just 1 or 2... the bigger value you are going to find in gxemu is 5
And the unknown seems to be always zero (at the end of other areas appears that zeroes too, i think is some kind of terminator)
Ok... so lets move deeper

You need to copy the commands_offset and "go to" that offset (in HxD ctrl+g)
Now you are in a different table (1 level deeper in the structure), im going to call this the "Command table"
In it you have 0x18 bytes for every entry, divided like this:
0x4 bytes = command_id
0x4 bytes = unknown
0x10 bytes = varies_by_command
The command_id is straightforward, the only worry you have to care is the ID numbers gets confusing because changes by emulator type, i have been making a table in the last days in wiki that works pretty fine as an overview of what the commands does and its correspondency in between emus (if someone has some suggestion of wants to help i will like it):
http://www.psdevwiki.com/ps3/Talk:PS2_Emulation#PS2_Emulators_Config_Commands
The 0x4 unknown bytes is again filled with zeroes (so is used again as a terminator or is an area reseved they never used, at least in gxemu seems to be always zeroes)
And the 0x10 bytes that varies_by_command are harder to explain (and needs a list of all commands to see how every commands uses that 0x10 bytes), im not going to explain that to not make this too longer and because i dont have everything identifyed at this point
But basically...
If you look at the table in wiki you will realize i used a naming convention to simplify the purpose of the commands, there are some commands that just works as a "switch"... this ones has the 0x10 bytes filled with zeroes (doesnt stores any value in the config)
Next ones in complexity are the commands that "sets" a value, this ones stores a value (or two) and the usage of that 0x10 bytes depends of the length of the value/s
For all this kind of commands (the ones for "switches" and "sets") the data structure finishes here (you dont need to jump to other offsets to search for more data)
And now is where it gets more harder :P
There are some commands that uses a "list", are the ones marked in green color in the table in wiki
This ones stores offsets inside the 0x10 bytes i was mentioning before, actually iirc most of them stores 2 offsets of two different positions, so we need to "jump" again to other area of the file, in the last days i made my mind several times about how to label this area, initially i thought in "extended data", "expanded data", and other things like that, but at this point i think the best name is "command list table"
In that command list table you are going to find the data used to apply patches , either to the game disc image, or to EE memory, or well... some others are unknwon
But this doesnt ends here... some of the commands uses another "level down" in the structure, that last level seems to be pretty straightforward though, to locate it you are given the offset and lenght of every value, so is very easy to retrieve them, the problem is we are at the most deeper level of the structure and if you want to continue reading the other data for this same command you have to jump back and forth several times... doing it in a manual way in hexeditor is a mess, lol, but with some practise you will get the concept fast
So as a resume... there are 4 tables... we are "jumping blindly" to the table most at top because we know the position, and the hashed title_id_crc of the games that appears on it, this is not the correct way of doing it but is ok

The simple commands (the ones of type "switch" and "set") only uses two levels of the structure
The other commands goes deeper to the third level and fourth in some cases