|
1
|
# Runes of Magic - game - http://www.runesofmagic.com
|
|
2
|
# Pattern attributes: ok veryfast fast
|
|
3
|
# Protocol groups: game proprietary
|
|
4
|
# Wiki: http://www.protocolinfo.org/wiki/Runes_of_Magic
|
|
5
|
# Copyright (C) 2008 Matthew Strait; See ../LICENSE
|
|
6
|
|
|
7
|
runesofmagic
|
|
8
|
^\x10\x03...........\x0a\x02.....\x0e
|
|
9
|
# See below (this is also veryfast fast)
|
|
10
|
#^\x10\x03...........?\x0a\x02.....?$
|
|
11
|
|
|
12
|
# Greatwolf captured the following:
|
|
13
|
#
|
|
14
|
# Server:
|
|
15
|
#
|
|
16
|
# 10 00 00 00 03 78 76 7a 1e 8a dd b5 95 a3 3a de .....xvz ......:.
|
|
17
|
# 0a 00 00 00 02 df 85 cc cc cc ........ ..
|
|
18
|
#
|
|
19
|
# Client reply:
|
|
20
|
#
|
|
21
|
# 0e 00 00 00 02 28 82 cc cc cc 8b c9 cc cc .....(.. ......
|
|
22
|
#
|
|
23
|
# Server:
|
|
24
|
#
|
|
25
|
# 2e 00 00 00 02 1e 7f f4 f4 f4 ef f4 f4 f4 b3 8c ........ ........
|
|
26
|
# [...]
|
|
27
|
#
|
|
28
|
# And says: "Bytes 10 00 00 00 03, 0a 00 00 00 02 and 0e (client reply)
|
|
29
|
# were consistently present.
|
|
30
|
#
|
|
31
|
# ^\x10\x03...........\x0a\x02.....\x0e
|
|
32
|
#
|
|
33
|
# Pattern was able to match during the closed beta period. It is still
|
|
34
|
# matching okay after RoM started open beta but could definitely use
|
|
35
|
# more testing from others to verify effectiveness."
|
|
36
|
#
|
|
37
|
# Matthew Strait says:
|
|
38
|
#
|
|
39
|
# * If the server consistently sends those four bytes in the first packet,
|
|
40
|
# it is probably wasteful to wait for the next (client) packet before
|
|
41
|
# matching.
|
|
42
|
#
|
|
43
|
# * If we switch the match strategy to just looking at the first packet, and
|
|
44
|
# the first packet is always the same (or nearly the same) length, we can
|
|
45
|
# anchor (i.e. use a '$') at the end of the packet.
|
|
46
|
#
|
|
47
|
# * When there's a string of bytes that I don't understand and that take
|
|
48
|
# different values from connection to connection, I think it's good to allow
|
|
49
|
# for the possibility that at least one might be \x00, and so I'd make one
|
|
50
|
# of the "." into ".?", unless you *know* that \x00 is impossible somehow.
|
|
51
|
#
|
|
52
|
# * All of those \xcc bytes don't look random to me. Your comments suggest
|
|
53
|
# that it isn't always exactly like that, but is there always pattern of
|
|
54
|
# repeated bytes or something else that might be useful? It probably isn't
|
|
55
|
# necessary to exploit this, since it looks like there's already enough to
|
|
56
|
# go with, but it would be nice to understand.
|
|
57
|
#
|
|
58
|
# So perhaps it would be an improvement to use:
|
|
59
|
#
|
|
60
|
# ^\x10\x03...........?\x0a\x02.....?$
|
|
61
|
#
|
|
62
|
# but this depends on the assumptions I made above.
|
|
63
|
|