kyoukaya / hoxy

Intercept, decrypt, and process Girl's Frontline game data

Hoxy

Hoxy is a proxy server designed to intercept, decrypt, and process Girl's Frontline game data. Modified data can not be written back to the request or response at this point and only the global server is supported. Hoxy also blocks requests to telemetry or ad domains that are frequently contacted if connecting from an android emulator. The block list is currently hardcoded in proxy/filters.go but may be user configurable in the future.

Usage

An example program is provided in cmd/example which initializes the packetlogger and constructioninfo mods. Use go run cmd/example/hoxy.go to start the proxy server up, and then direct your client to use it.

Modules

Each module should initialize itself by calling proxy.RegisterMod(modName, initFunc) at program start up, either in the init() function or in the global scope. The init function will be called when a user authenticates with the game server to set up the module for that user. Here's an example from the constructioninfo mod:

func init() {
	const modName = "Construction Info"
	initFunc := func(userCtx *proxy.UserCtx) ([]*proxy.PacketHook, proxy.ShutdownCb, error) {
		dollinfo.Init()
		equipinfo.Init()
		mod := &constructInfo{}
		hooks := []*proxy.PacketHook{
			proxy.NewPacketHook(modName, "SGun/developGun", 0, false, mod.handleGunConstruct),
			proxy.NewPacketHook(modName, "SGun/developMultiGun", 0, false, mod.handleGunConstruct),
			proxy.NewPacketHook(modName, "SEquip/develop", 0, false, mod.handleEquipConstruct),
			proxy.NewPacketHook(modName, "SEquip/developMulti", 0, false, mod.handleEquipConstruct),
		}
		return hooks, func(bool) {}, nil
	}
	proxy.RegisterMod(modName, initFunc)
}

Packet Definitions

If you plan on using hoxy, please note that there will be many breaking changes to the packet definitions as JSON handling will be changed.

Definitions that start with the character "S" indicate that the packet originates from the server, likewise, a "C" prefix indicates that the packet originates from the client.

Definitions are discovered, not reversed from the game client, so definitions may be incomplete or missing. Please feel to contribute additional definitions or fixes to current definitions. Additionally, helpful comments about packet fields that are not immediately obvious are welcome.

hoxy's Issues

Mod Loading through external .so/.dll

Should i reimplement modules as loadable shared libraries? the basic idea is stolen from here:

You can write a plugin to change the way YClass reads memory. To do that you will need a shared library(.dll or .so) that exports following functions

fn yc_attach(process_id: u32) -> u32 - Called when attaching to a process.

fn yc_read(address: usize, buffer: *mut u8, buffer_size: usize) -> u32 - Called when reading memory(very frequently).

fn yc_can_read(address: usize) -> bool - Called to check if address is "readable", i.e. a pointer.

fn yc_detach() - Called when detaching from a process.

After its done, put your library at ./plugin.ycpl or specify the path under plugin_path key in your config.```

Fairy Talent Names

In game packets (SFairyAdjust, SEquipDevelop), fairy talents are referred to by their id in the passive_skill field. The FairyInfo struct should offer a method for getting the string representation of the talent id.

Order hook execution by their priority

Mods can already request a priority on their hook, but order is not enforced when generating hooks currently.

Support caching of update data

The game updates off AWS using a HTTPS connection, capability to generate a unique CA cert and MITM https connections is already written in and can be activated with the -https flag. Further analysis of update traffic is required.

For the global server, it seems like the patches are all pulled off s3.us-east-2.amazonaws.com:443/gf1-file-server/.

Config file

Load the url block list from a file and provide an interface for mods to use a config file of their own.

JSON Validation

The JSON data that the servers send us is an absolute nightmare. Thankfully, the client seems to send sanely formatted JSON.

These are the known quirks of the server sent JSON:

• The ordering on keys in JSON objects may change. This may not be much of an issue to a user, but it'll be hard to verify the correctness of marshaled data.
• Integers may be encoded in a string, e.g., "123", empty string, e.g., "", if the value is effectively nil, or as a JSON number, e.g., 123.
• Floats may be encoded in a string, e.g., "1.23", empty string, e.g., "", if the value is effectively nil, or as a JSON number, e.g., 1.23.
• The empty value of a string in the JSON may be the empty string "", or null.
• In the case where an object is used as a value, when the object is effectively nil, it may be represented as an empty JSON array [].
• JSON objects are used as a key value map.

The current solution to this problem is to use custom types in the packet definitions to facilitate the marshaling and unmarshaling of JSON data, which is far from ideal.

My current idea to remove the custom types from the packet definitions themselves and at runtime, create a dynamic struct based on the static packet definition but with the custom types in them and marshal the data into that.

Support other game servers

This is limited by the fact that I don't have clients for any server other than the global server. If anyone has clients installed for the other game servers, feel free to submit a PR or send me some JSON data so I can modify user authentication.