手机安装大全
安装的游戏 解析包出现问题
要怎么解决
已有1个回答
内容为广告/垃圾，我要举报！
特聘专家具有协助内容审核的特权
举报后内容将不能在前台展示
错乱举报会导致该权利被剥夺
选择举报原因×
参与话题：
&& &删掉软件，重新下个正版的，一般解析包错误都是因为软件质量的问题。
留下你的评论
微信公众账号ZOL问答堂
关注微信，随时随地解答您的疑惑
ZOL问答堂官方微博@ZOL问答堂
关注成功！该问题被回答后，将给您发送站内短信。
您也可以通过关注问答堂微信，及时获得您关注问题的回答。
微信关注问题方法“”游戏资源分析1——文件包分析 - 汉化交流 - 扑家吧
游戏资源分析1——文件包分析
游戏资源分析1
文件包分析
地狱门神
摘要：游戏汉化或者修改中，经常需要进行数据文件格式分析，而其中的文件 包分析往往是第一步。文件包分析的步骤非常固定，也比较容易掌握。本文主要介绍文件包分析的思路、实例，并介绍一种快速实现文件包文件导出替换程序的方 法。
声明：本文档按现状提供，仅用于研究和学习，因为使用本文档造成的任何损失，本人 概不负责。
游戏汉化或者修改中，经常需要进行如下几种数据文件格式分析：
文件包分析
文 本分析
图片分析
字符映射表和字库分析
压缩文件分析
模型分析
其中文件包分析和文本分析一般比较简单，图片和字库分析一般比较复杂，压缩文件复 杂度跟具体的文件有关，模型等其他文件分析则非常复杂。
这里介绍文件包分析。
所谓文件包，就是用来集中存放游戏中的多个资源文件的文件。
2.文件包的作用和特征
现在的各种游戏，资源文件数量非常多，将资源集中存放到几个文件包中，能够有效加 快游戏的安装速度。当然，文件包的作用不仅仅如此，有一部分游戏也使用文件包来实现压缩、加密等功能。
文件包中的文件，一般是顺序的，不存在一个 文件数据分成几块的情况。这种设计是适用于只读的文件系统的情况的。
一个游戏的文件包中，一般有几个比较大的文件包，所以，要确定哪些文件是文件包很 容易。
文件包的格式的设计余地比较小。无论怎样写，一个文件包总是由索引和文件数据两部 分组成的。
最近常见的文件包一般都没有文件夹格式，或者文件夹名称直接写入到文件名中。这样设计，可以直接使用散列表来优化文件访问，快速从文件 路径映射到文件索引。文件夹名称直接写入文件名中有个缺陷，就是不容易枚举一个文件夹下的所有文件，所以在磁盘分区格式中一般没有这种设计。但这在游戏文 件包格式中不存在问题。
索引一般是集中到文件包的头部。不过也有索引在文件尾(如Maxis的游戏)、索 引独立成文件和索引分布到各文件数据之前的情况。
索引一般由文件地址、文件长度、文件名三部分组成。
如果索引中包含文件地址和文件长度，我们把这种文件包称为离散文件包。这种文件包 能够很容易的在尾部扩展数据。这种文件最常见。
如果索引中不包含文件地址，仅包含文件长度，我们把这种文件包称为连续文件包。这种文件包读取时， 文件地址是它之前的文件的长度之和(或者对齐的长度之和)。向这种文件包导入文件，必须要移动导入的文件之後的所有文件。这种设计在光荣等厂商的游戏中有 出现。
索引中不包含文件长度，仅包含文件地址的文件包也存在，不过一般是在日系游戏机游戏中。一般文件都很小，可以按实际情况转化为上述两种之 一。
文件名的情况比较复杂。一些游戏使用正常的文件名。一些游戏使用正常的文件路径。
这 两种情况都很好处理。比较复杂的是，某些游戏使用文件名或文件路径的散列值来表示文件名。这种情况下，经常无法获得文件名。这时候，一般按照出现顺序将文 件编号。
文件类型是很重要的信息。在缺乏文件名或者缺乏文件扩展名的情况下，判断文件类 型，一般通过文件的前4个字节猜测。可以在程序中寻找这4个字节中的不少于两个连续字符的英文字母和数字，作为扩展名，来表示文件类型。
有的时 候，游戏索引中会包含一个文件类型号(如Maxis的游戏)。这时候可以根据网上的记录来判断一些类型。
有时候，文件包中的数据是压缩的，索引可能包含压缩前後的大小、
3.一般分析步骤
分析文件包的步骤，一般是这样的：
(1)从文件包头部判断文件包是否是已 知格式，如PK是zip文件的标记。许多游戏使用zip文件来作为文件包。
(2)根据游戏的背景和文件包扩展名、头部等信息在网上搜查是否已有人 完成了相应的工具。同一公司的游戏和同一系列的游戏文件包经常有类似之处。如果能找到有用的工具或者信息。
(3)分析文件的大体结构，如索引的位 置、文件数据有没有被压缩等。如果一个文件包中的文件数据大部分是以78开头的，那说明这个文件包使用的Deflate压缩，可以用zlib来进行解压和 压缩。如果数据很奇怪，说明这个游戏可能加密或者使用了自由压缩，困难比较大。
(4)确定包内文件数量、单个索引长度、索引边界。如果文件索引是 对齐的，那么可以从文件索引的大致数据长度除以单个索引长度来获取大致的文件数量。在文件包的头部，一般能找到近似的一个整数，这就是包内文件数量。确定 了包内文件数量，从单个索引长度，可以获取整体的索引长度。这样就能更正确的确定索引边界。
(5)确定索引中的文件地址和文件大小数据。一般通过 对比相邻的索引的内容来完成。大部分包中文件索引的顺序和文件地址的顺序是一样的，因此一般有一个明显递增的整数，如果两条相邻的索引A、B，递增数据a 的旁边有另外一个数据b，A.a + A.b =
B.a，通常说明a是地址，b是长度。这种方法，可以称为差分分析法。很多文件包中文件地址是对齐的，最常见的是800h对齐。800h是CD的最小读写 块大小。确定了地址和长度之后，应该对几个文件按照地址转到文件数据，以确认是否存在地址的整体偏移。有时候地址记录的是块地址，需要乘以块大小才能获得 真实地址。
(6)确定索引中的文件名。文件名可能直接包含在索引中，或者在集中的文件表中。后一种情况下，索引中应该有文件名的地址和长度。这里 的分析和第四步类似。
(7)分析索引中的其他数据。
4.文件包程序制作
文件包程序的制作，推荐使用萤火虫汉化框架。
这个框架在文件包管理方面，进行了最大化的抽象。
符合模型的文件包，只需 要书写少量关于文件格式的代码，即可得到一个完整的界面支持。
对于离散文件包和连续文件包，文件包的扩容都已经默认支持。无需手写大量易错代码。
这个框架是.Net Framework上的库。支持.Net上的各语言。
具体实例代码参见Examples\\Packaging。
该示例用于处理 PSP上的游戏《プリニ》(普里尼)。
示例有F#、VB、C#、C++/CLI这四个语言的版本。
本文第一个实例是就是プリニ的文件包。
本文的两个实例的数据均包含于Examples\\Packaging中。
プリニ文件包SCRIPT.DAT
首先用UltraEdit打开文件。
如果你从来没分析过文件的二进制结构，也不要紧张。
在UltraEdit 的Hex编辑模式中，最左边一栏是该行最开始的字节的偏移量，中间一栏是文件的所有的字节数据，每一字节用两位16进制数表示。最右边一栏是这些字节数据 的ANSI码解释。在中文的系统中，是GBK的编码解释。因为中文是借用了128-255的扩展ASCII码的空间来表示的，所以可能会出现一些中文字的 乱码，这纯粹是巧合。00用点表示，不存在的符号用问号表示。
打开文件后，发现文件包头部有几个文件名，之后是一片空白，直到800h有一段数 据，数据结束后又有一片空白，之后1000h处又有数据。基本确定文件包是按800h对齐的。往后翻，发现包中的文件数据有比较多的00，不像是压缩过或 者加密过的。
然后分析文件头和索引部分。
h: 4E 49 53 50 41 43 4B 00 00
00 00 00 07 00 00 00 ; NISPACK.........
h: 64 65 62 75 67 2E
6E 73 66 00 00 00 00 00 00 00 ; debug.nsf.......
h: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
h:
00 08 00 00 F5 03 00 00 E8 03 47 39 64 65 6D 6F ; ....?...
.G9demo
h:
2E 6E 73 66 00 00 00 00 00 00 00 00 00 00 00 00 ; .nsf............
h:
00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 ; ................
h:
80 3B 03 00 E6 03 47 39 44 4C 30 30 30 2E 6E 73 ;
;..?.G9DL000.ns
h:
66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; f...............
h:
00 00 00 00 00 00 00 00 00 50 03 00 36 01 00 00 ; .........P..6...
h:
05 4B D3 38 65 66 66 65 63 74 2E 6E 73 66 00 00 ; .K
8effect.nsf..
h:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
h:
00 00 00 00 00 58 03 00 54 05 00 00 E8 03 47 39 ; .....X..T...
.G9
h:
65 6E 65 6D 79 2E 6E 73 66 00 00 00 00 00 00 00 ; enemy.nsf.......
h:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
h:
00 60 03 00 48 2C 09 00 E8 03 47 39 70 72 65 76 ; .`..H,..
.G9prev
h:
69 65 77 2E 6E 73 66 00 00 00 00 00 00 00 00 00 ; iew.nsf.........
h:
00 00 00 00 00 00 00 00 00 00 00 00 00 90 0C 00 ; .............?..
h:
8A 14 00 00 E8 03 47 39 73 79 73 74 65 6D 2E 6E ; ?...
.G9system.n
h:
73 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; sf..............
h:
00 00 00 00 00 00 00 00 00 A8 0C 00 18 38 00 00 ; .........
...8..
h:
E5 03 47 39 00 00 00 00 00 00 00 00 00 00 00 00 ; ?.G9............
h:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
h:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
h:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
h:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
注意到文件标志NISPACK之后有一个整数7(07 00 00 00)。
这 个整数之后有第一个文件名
debug.nsf
(10h)，从文件名开始经过44(0x2C)个字节到第二文件名
demo.nsf
。对比后面的文件 索引可以发现
G9
并不是文件名的一部分。每隔44字节就到下一个文件名开始，7个文件名的开始位置分别是10h、3Ch、68h、94h、C0h、 ECh、118h。这样能够确定文件索引的长度是44。从最后143h处的
G9
可以知道，索引均是从文件名开始的。NISPACK之后的整数7是文件 数量。
如果你对07 00 00 00表示7不理解，我在这里简单解释一下。
目 前的计算机中，一般用到8位、16位、32位、64位的二进制整数，且有有符号和无符号两种。
不妨按下表标记：
64位
无符号
UInt64
有符号
Int64
最常见的整数是Int32类型的，其次是Byte、UInt16和Int16，其余 的很少见。
除了8位整数是直接一字节以外。其余的整数都是多字节的，每8位分割成一字节。这里有一个字节序的问题，也就是说，高字节优先 (big-endian)还是低字节优先(little-endian)。对于16进制整数0x2EDA(十进制为11994)，表示成高字节优先，则其 字节形式为00 00 2E DA，低字节优先则是DA 2E 00 00。
在x86和Windows上的格式，通常是低字节优先。
所 以，07 00 00 00就是指7。
对当前的已知的结构写成文档，如下：
Header 00h
12
Identifier
"NISPACK"
4
Index 10h
(
44
"debug.nsf" ..
){NumFile}
Data 800h
(
*
FileData
800h对齐
){NumFile}
其中，从左到右四栏按重要性排列，分别是字段的长度、类型、名称或注解、示例数 据。
( ... ){NumFile}表示这种结构重复了NumFile次。
现在需要详细的分析索引本身的内容。
32 33 34 35
36 37 38 39
40 41 42 43
64 65 62 75 67 2E
6E 73 66 00 00 00 (20个00)
00 08 00 00
F5 03 00 00
E8 03 47 39
64
65 6D 6F 2E 6E 73 66 00 00 00 00 (20个00)
00 10 00 00
80 3B 03 00
03 47 39
44 4C 30 30 30 2E 6E 73 66 00 00 00 (20个00)
00 50 03 00
05 4B D3 38
65 66 66 65 63 74 2E 6E 73 66 00 00 (20个00)
00 58 03 00
54 05 00 00
E8 03 47 39
65 6E 65 6D 79 2E 6E 73 66 00
00 00 (20个00)
00 60 03 00
48 2C 09 00
E8 03 47 39
70 72 65 76 69
65 77 2E 6E 73 66 00 (20个00)
00 90 0C 00
8A 14 00 00
E8 03 47 39
73
79 73 74 65 6D 2E 6E 73 66 00 00 (20个00)
00 A8 0C 00
18 38 00 00
把7个索引的数据都提取出来，排列整齐，如上，每行一个索引的数据。
现在 要在这些数据中找到文件地址、文件大小。
使用差分分析法。32-35的Int32很明显的递增，36-39的Int32，都是略小于递增的整数的 差。因此可以判断，32-35是文件地址，36-39是文件大小。
40-43的数据不清楚有什么用处，就不管了。
索引的结构如下：
32
"debug.nsf"
4
00 08 00 00
4
F5 03 00 00
4
E8 03 47 39
对寻找的文件地址进行验证，发现这些地址都是文件的直接地址，没有偏移等情况。文 件长度也吻合。
文件包分析终了。
完整文件格式文档如下：
プリニ DAT格式
Header 00h
12
Identifier
"NISPACK"
4
Index 10h
(
32
"debug.nsf"
4
00 08 00 00
4
F5 03 00 00
4
E8 03 47 39
){NumFile}
Data 800h
(
*
FileData
800h对齐
){NumFile}
(2)程序
这里以VB为例讲解。
使用Visual Studio
2008创建WinForm项目。删去所有源文件。去掉框架，将启动对象改为Sub Main。
添加对Firefly.Core.dll和 Firefly.GUI.dll的引用。
创建一个DAT.vb来处理该格式。内容如下：
System
.
Collections
.
Generic
System
.
IO
Firefly
.
Packaging
PackageDiscrete
''
使用离散文件包接口，表示文件数据不一定非要连续，即通过位置和长度来确定，连续文件一般只有长 度一个数值
''
在构造函数中填入文件包读取的部 分，对每个文件需要调用
PushFile
以构造路径信息和各种映射信息
New
(
ByVal
ZeroPositionStreamPasser
)
MyBase
.New(
sp
)
sp
.
GetStream
''
判断文件头部是否正常
s
.
ReadSimpleString
(12)
InvalidDataException
s
.
ReadInt32
''
读取索引的各部分
s
.
ReadSimpleString
(32)
''
读取简单字符串
s
.
ReadInt32
s
.
ReadInt32
s
.
ReadInt32
''
创建一个文件描述信息，包括文件名、文件大小、文件地址
FileDB
(
Name
,
FileDB
.
FileType
.
File
,
''
将文件描述信息传递到框架内部
''
框架内部能够自动创建文件树
(
将文件名中以
''\\''
或者
''/''
表示的文件路径拆开
)
''
框架内部能够自动创建
IndexOfFile
映射表，能够 将文件描述信息映射到文件索引的出现顺序
''
框架内部还记录一些数据用于寻找能放下数据的空洞
PushFile
(
f
)
''
离散文件在打开的时候应该寻找空 洞，以供导入文件使用
''
寻找的起始地址是从当前位置的下 一个块开始的位置
ScanHoles
(
GetSpace
(
s
.
Position
))
''
提供格式在打开文件包窗口中的过 滤器
DAT
格式
(*.DAT)|*.DAT"
''
打开文件包的函数
Open
(
ByVal
StreamEx
(
Path
,
FileMode
.
Open
,
FileAccess
.
ReadWrite
)
StreamEx
(
Path
,
FileMode
.
Open
,
FileAccess
.
Read
)
''
读取文件在索引中的地址信息，所 有索引中的地址信息应该在这里更新
FileAddressInPhysicalFileDB
(
ByVal
BaseStream
.
Position
= 16 + 44 *
IndexOfFile
(
File
) + 32
BaseStream
.
ReadInt32
Set
(
ByVal
BaseStream
.
Position
= 16 + 44 *
IndexOfFile
(
File
) + 32
BaseStream
.
WriteInt32
(
Value
)
''
读取文件在索引中的长度信息，所 有索引中的长度信息应该在这里更新
FileLengthInPhysicalFileDB
(
ByVal
BaseStream
.
Position
= 16 + 44 *
IndexOfFile
(
File
) + 36
BaseStream
.
ReadInt32
Set
(
ByVal
BaseStream
.
Position
= 16 + 44 *
IndexOfFile
(
File
) + 36
BaseStream
.
WriteInt32
(
Value
)
''
提供文件数据的对齐的计算函数
GetSpace
(
ByVal
&
H800 - 1) \\
创建Main函数：
System
.
IO
System
.
Windows
.
Forms
Firefly
.
Packaging
Main
(
ByVal
String
())
''
在这里添加所有需要的文件包类型
PackageRegister
.
Register
(
DAT
.
Filter
,
DAT
.
Open
)
PackageRegister
.
Register
(
ISO
.
Filter
,
ISO
.
Open
)
Application
.
EnableVisualStyles
()
Application
.
Run
(
New
GUI
.
PackageManager
())
这样就能够对这种类型的文件包进行文件导出、替换等操作了。
文件包boot.pack
(1)分析
打开文件包，发现文件头部分有很多文件路径。
最后一个 文件路径之后有一个
DDS
，说明这是一个DDS文件，文件数据从这里开始。
经过分析，可以发现，每个文件路径后面跟有一个00，两个文件路径 之间除了这个00以外，还有一个Int32。
最后一个文件路径后面没有跟Int32，说明Int32位于文件路径之前。
索引格式如下：
4
D4 00 00 00
*
"commontextures\\default_black.dds"
Null-terminated Ascii String
这一个单个的Int32，没有什么规律，只能假设是长度。对比第一个文件，似乎不 能确定。
总之先猜测文件结构如下：
pack文件格式
boot.pack
Header 00h
4
Identifier
PackageIndex?
00 00 00 00
4
00 00 00 00
4
00 00 00 00
4
0A 00 00 00
4
IndexTableLength
E4 01 00 00
IndexTable 18h
(
4
D4 00 00 00
*
"commontextures\\default_black.dds"
Null-terminated Ascii String
){NumFile}
Data 1FCh
(
*
"DDS" 20 ..
Continuous File Data Without Alignment
){NumFile}
(2)程序
这次需要使用连续文件的模型。
PackageContinuous
PhysicalLengthAddressOfFile
Dictionary
(
Of
New
(
ByVal
ZeroPositionStreamPasser
)
MyBase
.New(
sp
)
sp
.
GetStream
s
.
ReadSimpleString
(4)
InvalidDataException
PackageIndex
s
.
ReadInt32
s
.
ReadInt32
s
.
ReadInt32
s
.
ReadInt32
IndexTableLength
s
.
ReadInt32
IndexTableLength
PhysicalLengthAddress
s
.
Position
s
.
ReadInt32
s
.
ReadByte
l
.
Add
(
b
)
s
.
ReadByte
System
.
Text
.
Encoding
.
ASCII
.
GetChars
(
l
.
ToArray
)
FileDB
(
Path
,
FileDB
.
FileType
.
File
,
PushFile
(
f
)
PhysicalLengthAddressOfFile
.
Add
(
f
,
PhysicalLengthAddress
)
Assert
(
s
.
Position
IndexTableLength
)
"PACK
文件
(*.PACK)|*.PACK"
Open
(
ByVal
StreamEx
(
Path
,
FileMode
.
Open
,
FileAccess
.
ReadWrite
)
StreamEx
(
Path
,
FileMode
.
Open
,
FileAccess
.
Read
)
PACK
(
s
)
GetSpace
(
ByVal
FileLengthInPhysicalFileDB
(
ByVal
BaseStream
.
Position
PhysicalLengthAddressOfFile
(
File
)
BaseStream
.
ReadInt32
Set
(
ByVal
BaseStream
.
Position
PhysicalLengthAddressOfFile
(
File
)
BaseStream
.
WriteInt32
(
Value
)
另外就是此次的文件在索引中的地址信息难以通过计算来获取，需要事先生成映射 PhysicalLengthAddressOfFile，之后在FileLengthInPhysicalFileDB中直接调用。
也可以对 FileDB进行继承，向其中保存新的信息。
7.结论
大部分文件包按照前述步骤都能够解析。核心思想只有两 个：
(1)先大后小，先分析外层的、宏观的结构，再分析细部的、微观的结构。
(2)差分分析法，这种方法对很多索引都有作用，不仅仅是文 件索引。
解析后的文件包，使用前述框架，能够很容易的实现文件导出和替换。
请先再回复，如果你还没有账号，请先。快速通道客服电话：020-
查看: 311|回复: 14
解析包错误 求解
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
正如题所见。官网，论坛，都试过了。手机魅蓝note1。
并不是客服的苏苏！
并不是客服的苏苏！
Lv7.返璞归真, 积分 5783, 距离下一级还需 4217 积分
Lv7.返璞归真, 积分 5783, 距离下一级还需 4217 积分
少安毋躁，目前好像有部分玩家会出现这个问题～～试过论坛这边玩版提供的新的覆盖下载了吗？
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
犬苏 发表于
少安毋躁，目前好像有部分玩家会出现这个问题～～试过论坛这边玩版提供的新的覆盖下载了吗？
试过了，没用
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
顺便说一下我下载的版本大小是66.65M
那可能需要重新下载了，目前好像确实有少量机型覆盖包无法使用的问题，非常抱歉～～【土下座&
并不是客服的苏苏！
并不是客服的苏苏！
Lv7.返璞归真, 积分 5783, 距离下一级还需 4217 积分
Lv7.返璞归真, 积分 5783, 距离下一级还需 4217 积分
顺便说一下我下载的版本大小是66.65M
那可能需要重新下载了，目前好像确实有少量机型覆盖包无法使用的问题，非常抱歉～～【土下座
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
犬苏 发表于
那可能需要重新下载了，目前好像确实有少量机型覆盖包无法使用的问题，非常抱歉～～【土下座
我从三点到现在下了不少于20次了一_一|& &还是一个鸟样，幸好是连Wifi不然要哭了
非常抱歉！！【土下座跪下】
不然再等等看呢QAQ&
并不是客服的苏苏！
并不是客服的苏苏！
Lv7.返璞归真, 积分 5783, 距离下一级还需 4217 积分
Lv7.返璞归真, 积分 5783, 距离下一级还需 4217 积分
我从三点到现在下了不少于20次了一_一|& &还是一个鸟样，幸好是连Wifi不然要哭了
非常抱歉！！【土下座跪下】
不然再等等看呢QAQ
模拟器进游戏黑屏闪退有解决办法吗&
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
Lv3.渐入佳境, 积分 156, 距离下一级还需 344 积分
犬苏 发表于
非常抱歉！！【土下座跪下】
不然再等等看呢QAQ
希望明天能修复，不然我的双卡都没得领了。今晚的世界boss没了(ToT)我的砖石啊！！！
Lv5.出神入化, 积分 2699, 距离下一级还需 301 积分
Lv5.出神入化, 积分 2699, 距离下一级还需 301 积分
非常抱歉！！【土下座跪下】
不然再等等看呢QAQ
模拟器进游戏黑屏闪退有解决办法吗
这个问题……或许换个模拟器试试，听说海马玩好像会出问题【&
并不是客服的苏苏！
并不是客服的苏苏！
Lv7.返璞归真, 积分 5783, 距离下一级还需 4217 积分
Lv7.返璞归真, 积分 5783, 距离下一级还需 4217 积分
模拟器进游戏黑屏闪退有解决办法吗
这个问题……或许换个模拟器试试，听说海马玩好像会出问题【
我也解析错误 这是欺负低端手机不能玩么？？魅族mx2&
阴阳师|式神の圣诞礼
式神们送给阿爸的圣诞礼物哟～
乖离性MA|一周年真爱人气王
真爱人气王应援活动。
乖离性MA|限定勋章体验课堂
“一定要听鹿老师的话哦！”
乖离性MA|限定勋章体验课堂
“听鹿老师话的好同学才有哦！”
乖离性MA|百万画师大作战
参与百万画师投票
乖离性MA|脑洞邂逅故事会
参与EVA脑洞邂逅故事会
阴阳师|触团胖次
请叫我菊苣
阴阳师|盂兰盆节
笑谈奇异事，细想鬼神惊活动勋章
阴阳师|青灯夜话
来自青灯的青睐
阴阳师|山兔牌眼力勋章
参与式神化妆舞会可得
阴阳师|玩家版主
镇守阴阳界的至高荣誉
阴阳师|内测限定
参与式神友人帐活动可得
阴阳师|首测限定
御用阴阳师专属式神
乖离性MA|阵营应援
乖离性MA|星空馆II
角宿一纪念勋章
乖离性MA|雪初音
乖离性MA|圆神真爱
乖离性MA|地错联动祭
乖离性MA|ELEVEN'S 星空馆II
ELEVEN'S 悬赏令专属勋章
乖离性MA|520
乖离性MA|绯弹联动期
乖离性MA|破蛋勋章
庆贺·少主の破蛋日
乖离性MA|萌战
乖离性MA|参与论坛萌战活动获得
乖离性MA|大触团&广播剧团专属勋章
MA论坛大触团&广播剧小分队成员专属勋章
乖离性MA|奇迹瞬间勋章
参与奇迹瞬间活动可获得。
乖离性MA|极限生存勋章
参与极限生存大赛可获得。
乖离性MA|桃花勋章
BLING BLING桃花来，恋爱多精彩！
乖离性MA|美好亚瑟大人认证
参与美好回忆集获得
乖离性MA|脑洞勋章
参与猜数字活动获得
乖离性MA|神秘勋章
乖离性MA|神奇勋章
MA玩版专属勋章2，液！=w=
萌王|李煜煜团团徽
加入萌王EX李煜煜团玩家团队获得
阴阳师|青坊主专属勋章
参与青坊主技能猜想可得
乖离性MA|EVA真爱人气王
EVA联动真爱人气比拼活动。
乖离性MA|我才是真汉子
男子汉战争·我才是真汉子
乖离性MA|红组勋章
乖离性MA|红组勋章
乖离性MA|AA联动
嘲讽嘲讽嘲
答应我！关爱你的壕爸爸！
乖离性MA|五一劳动祭
乖离性MA|地错联动祭
乖离性MA|地错联动祭
乖离性MA|地错联动祭
乖离性MA|EVA联动祭
master召唤
乖离性MA|EVA联动祭
兑换EVA看板娘可得
乖离性MA|EVA联动
乖离性MA|初音联动祭
master勋章
乖离性MA|初音联动祭
宣告公主殿下降临活动获取
乖离性MA|初音联动祭
化身初音活动获取
乖离性MA|情人节限定勋章1
情人节限定勋章
乖离性MA|情人节限定勋章2
情人节限定勋章
乖离性MA|小埋看板
乖离性MA|参与论坛晒小埋看板活动获得
乖离性MA|红组勋章
2016乖离MA官方论坛红白擂台赛红组勋章。
乖离性MA|召唤勋章4
MA论坛第四期“我就是你的Master！”活动召唤勋章。
, All Rights Reserved
杭州网易雷火科技有限公司版权所有 & |
全国文化市场统一举报电话: 12318
文化部网络游戏举报和联系电子邮箱:}