{% extends "base.html" %} {% block title %}Application protocol{% endblock %} {% block body %}
As the previous pages have eluded to (you did read them, didn't you?), eAmuse uses HTTP as its main way of getting data around. This means we need an HTTP server running but, as we'll see, we don't need to think too hard about that.
Every request made is a POST
request, to //<model>/<module>/<method>
,
with its body being encoded data as described in the previous sections. This behaviour can be altered using the
url_slash
flag in ea3-config.xml
. Disabling this switches to using
/?model=...&module=...&method=...
for requests instead. Make sure to implement both of these if
implementing a server!
Every request is followed immediately by a response. Any response code other than 200
is considered
a failure.
All requests follow a basic format:
{% highlight "cxml" %}?module method="??method" ...attributes> ...children ??module> {% endhighlight %}
The responses follow a similar format:
{% highlight "cxml" %}?module status="??status" ...attributes> ...children ??module> {% endhighlight %}
With "0"
being a successful status. Convention is to identify a specific method as
module.method
, and we'll be following this convention in this document too. There are
a lot of possible methods, so the majority of this document is a big reference for them all. There are a
number of generic methods, and a number of game specific ones. If you haven't clocked yet, I've been working on
an SDVX 4 build for most of these pages, and each game also comes with its own set of game-specific methods.
These are namespaces under the game.%s
module and, in the case of SDVX 4, are all
game.sv4_method
. I may or may not document the SDVX 4 specific methods, but I've listed them
here anyway for completeness.
Paths in the XML bodies are formatted using an XPath-like syntax. That is, status@/response
gets the
status
attribute from response
, and response/eacoin/sequence
would return
that node's value.
NOTE: I am using the non-standard notation of <node* ...
and
<node attr*="" ...
to indicate that an attribute or node is not always present! Additionally, I
am going to use the notation of <node[]>
to indicate that a node repeats.
Status | Meaning |
0 |
Success |
109 |
No profile |
110 |
Not allowed |
112 |
Card not found (cardmng.inquire ) |
116 |
Card pin invalid (cardmng.authpass ) |
Turns out bemani have been quite sensible in how they implemented their code for creating structures, so it's rather readable. That said, if you've been using Ghidra (like me!), this is the time to switch to IDA. I'll let the below screenshots below speak for themselves:
I know which of these I'd rather use for reverse engineering (sorry, Ghidra)!
services.get
):
numbering
pkglist
userid
local
local2
lobby
lobby2
netlog
globby
I'll try and figure these out in due course, promise!
{% endblock %}