Fate/Grand Order is a popular mobile RPG game (for Android and iOS) made by DelightWorks and featuring characters and Servants from TYPE-MOON‘s expansive Fate universe. It’s main gameplay involve going through a visual-novel-style storyline that lead to turn-based combat against enemy NPCs using Servant cards that you can collect. Finishing battles and defeating enemies give item rewards, which can help you level up your Servants to make them stronger.
As a simple mobile game designed for commuters, much of the time spent in-game is spamming repeatable battles, also known as grinding. When grinding for a specific item/reward, the term to use is farming. In Fate/Grand Order, one of the most end-game activities is farming for ascension items needed to ascend your Servant. But farming is tedious, especially when you own servants such as Gilgamesh, whose 4th tier ascension requires item that have single-digit drop rate percentages and only drop from bosses that appear on certain days of the week. You could be spending hours upon hours mindlessly grinding battles and come out with nothing in return; nothing feels worse than finally killing that last boss only to have it not drop the item you wanted. Isn’t there a faster way?
Thankfully, there is! And today, you will learn how with the help of packet sniffing!
Note 1: This is a very technical guide. If you aren’t familiar with networking/how games work, you may easily find yourself lost on the first read-through. Take your time.
Note 2: In this guide, you will be doing a lot of battle skipping. This means you will be sacrificing normal battle rewards (QP, master EXP, bond EXP, random small items) in exchange for speed and efficiency. AP always gets consumed whether you decide to complete the battle or not. This is only recommended for those who don’t mind burning quartz or those who prefer to be time-efficient with their farming.
If you want to squeeze the absolute most out of your AP, stop right here.
If you want to ascend your waifu as fast as possible, continue reading.
What is packet sniffing?
Packet sniffing is the act of using a software program (packet sniffer/analyzer) to monitor and inspect network packets (i.e. your internet traffic) between two computers/end-points. In this case, you will be inspecting the traffic between the Fate/Grand Order app running on your phone and the DelightWorks game servers.
Is it like hacking?
No. You are doing a read-only inspection of network traffic. You are not tampering with or modifying anything, be it the game client’s code or network data itself. For a better understanding of how game hacks work, see this article (which also applies to Fate/Grand Order, but we won’t be going over that here).
Is it legal?
It depends. There are plenty of articles online that will debate this or that, but it ultimately comes down to what traffic you’re sniffing and for what intent. In this case, you are sniffing unencrypted traffic between you and someone else from a device that you own. I’m not a lawyer, but I’m 99.9% sure that the answer in this case is yes, it is legal in the usage described in this guide.
Will I get banned?
Packet sniffing is inspection and monitoring, not tampering. As long as you are only looking at the data and not modifying it, there is no way for the DelightWorks servers to know that the traffic is being monitored. So no, you will most likely not get banned. Not to mention they probably don’t even care, since you’ve already bought their quartz and spent the AP (more into this in the next section).
Can I choose what loots drop?
No, the loot rolls (as well as quartz rolls and FP rolls) are done entirely server-sided. You only get a read-only copy of the result. Even if you make client-sided changes to try to trick your game into thinking you got a different drop, the game will auto-correct itself the next time it syncs with the server. There is no known way to modify the server’s content right now (if there existed one, it would be called an “exploit” and likely be patched very, very fast). This guide will help improve your farming speed, but it won’t change your RNG luck.
There are 3 battle-related network calls that happen between your game client and the DelightWorks game servers. These network calls are made as regular unencrypted HTTP POST requests that return with an unencrypted JSON response.
The Setup network call happens when you initiate the battle. It happens the moment you press the “Next” button after choosing your support Servant and confirming the party. When this call gets made, all the details of the battle gets returned to you, including the full loot table (what we are most interested in here). This network call’s response contains all the information needed by the game to render out the entirety of your 1-3 round battle, which takes place entirely client-sided (there is no communication between you and the DW servers during the battle, except when you use Command Seals). Note that the moment this network call is made, your AP is consumed (AP is tracked server-sided, your client just shows the estimated value) and your FP has already been rewarded (to both you and your Support friend).
The Resume network call only happens if you are resuming the battle after a game restart (e.g. game quit, app crash, force kill, etc.). It gets called right after the login step (when you go past the splash screen) and only if there was a previous battle that did not complete (according to the server). This network call’s response contains more or less the exact same battle information that you got in the Setup response, but with a bunch of non-battle-related info. Of note is that the RNG seed value does not change for that battle ID, so don’t expect to see different results if you keep killing and relaunching the app and doing the exact same sequence of actions.
The Result network call happens either when you finish the battle (through victory or through defeat) or when you decide to quit the battle early. It’s pretty much a verification call telling the server that the battle ended and the response returns more or less what you previously already knew but with some additional info such as the QP reward amount, etc. (the loot table always matches as far as I’ve seen). Of note is that the network request contains in it a log of the sequence of actions you took in the battle. This is probably used for cheat detection/post verification, though as far as I know, that server-sided logic currently doesn’t exist/is enabled (it will probably be enabled when PvP get implemented though, I hope).JSON API Details
Of the three network calls, the one we are most interested in is the first, the Setup network call, as it contains the loot info (i.e. what items will drop, on what round will it drop, and from which enemy NPC it will drop). So lets take a closer look at the details of the network call (e.g. JSON API)…
HTTP POST request:
Body key-values: activeDeckId, followerId, userId, authKey, appVer, lastAccessTime, questPhase, dataVer, authCode
Most of the body content is straightforward and not of much interest. The only thing of note is that followerId is your support’s userId I believe, and activeDeckId would map to which party slots you choose.
Abridged JSON response:
--------------------limitCount = #
--------------------mstGiftId = id
--------------------num = #
--------------------objectId = id
--------------------rarity = enum
--------------------type = enum
----------------id = #
----------------name = string
----------------npcId = id
----------------roleType = enum
----------------uniqueId = id
----------------userSvtId = id
----------------id = #
----------------isFollowerSvt = bool
----------------name = string
----------------uniqueId = id
----------------userSvtId = id
--------------atk = #
--------------hp = #
--------------id = id
--------------lv = #
--------------npcSvtType = enum
--------------svtId = id
--------------tdRate = #
--------id = id
--------seed = #
--------userId = id
Full JSON response:
So there’s tons and tons of info in the /battle/setup response (as to be expected). A lot of the info is not of interest/relevance (much of it is to just update the client’s game state) and there’s even a few currently empty/unused fields that are probably meant for future game features (such as rankingEventId, myUserSvtEquip, etc.), so lets just instead take a look at the abridged JSON response.
The userSvt section contains entries for each Servant/enemy and includes details such as level, attack value, max HP, etc. Each enemyDeck/svts/userSvtId and myDeck/svts/userSvtId maps to a userSvt/id. Note that Servants and enemy NPCs have some slightly different fields, e.g. enemy NPCs will have additional fields such as aiId, hpGaugeType, npcSvtType, etc. For farming purposes, you probably don’t care about these values, but they’re nice to look at if you’re curious on what enemy NPCs’ stats look like.
The myDeck/svts section contains entries for every of your Servants in your party and includes only basic metadata, mainly only the userSvtId map and the isFollowerSvt boolean. I find it amusing that the name and npcId fields are included in the response even though they are blank (name gets loaded from game data and npcId is irrelevant here). That said, if you take a look at all the JSON responses, you’ll notice quite a lot of redundancy/useless bytes taking up network bandwidth (DW, please learn to sanitize your output!), but I digress.
The enemyDeck/svts section is the section you care most about. It contains entries for every of your enemies, separated into up to 3 svts arrays. Along with the actually-populated name field and userSvtId map (as well as some other information you probably don’t care about for farming, such as enemyScript) is the sub-section that is the focus of this guide: enemyDeck/svts/dropInfos. Lets take a look at the values here and what they mean:Drop Infos
Here’s the breakdown of what each field in the dropInfos subsection means. Note that even though it is an array, I’ve never seen any enemy drop more than 1 item.
- limitCount – Ascension rank for Servant/CE cards (non-cards are 0, lvl 1 CEs are 1)
- mstGiftId – Server-sided drop table entry ID indicating a unique objectId+num combination
- num – For item drops, this is always 1; for QP, this is the QP amount
- objectId – This is the item’s object ID
- rarity – This is used to help determine the loot item graphic, i.e. the orb/chest colour
- type – This is used to help determine the loot item graphic, i.e. whether it’s a orb or a chest
The most up-to-date dropInfo mapping with specific item details can be found on the Drop Infos wikia page. Please help keep the table updated each time new item drops are introduced (e.g. from special events). See here and here for where to find each item.The Guide
Well here’s the general steps:
- Proxy your game traffic through Fiddler2/Fiddler4 (or the packet analyzer of your choice)
- Filter for /battle/setup API calls
- Convert the network response to JSON
- Inspect the dropInfo section and check the objectIds for the item you want
- Decide whether to finish the battle and collect your reward, or abandon and save your time
1) Proxy your game traffic through Fiddler2
The first step is setting up your game to proxy all its network traffic through a packet sniffer/analyzer. My tool of choice is Fiddler2 (download here), which has a built-in JSON format viewer. Wireshark will probably work but I’m not familiar with it. ngrep if you’re a masochist. Either way, this guide will use Fiddler2, so get downloading and installing. Note that it is recommended that you instead install Fiddler4 if you are running Windows 7 or higher.
Once you’ve downloaded and installed Fiddler, configure the program to allow itself to act as a proxy for your device. See here for the Android instructions or here for the iOS instructions. If you are using a Bluestack Android emulator to play the game on your PC, you will also need to install ProxyCap and follow their setup instructions here. Note that the exact process of setting up Fiddler on your device is outside the scope of this guide so please do not send me emails/msgs asking for help on this (instead, consult Google sensei).
Once you’ve configured everything correctly, you should see network traffic to the game.fate-go.jp host when you do something like close and relaunch the game, or navigate around the news pages.
2) Filter for /battle/setup API calls
For Fiddler2, there’s a handy-dandy “Filter” tab that you can use to clean up the network traffic logs to only show F/GO battle info (to clear previous logs, just select all and press your keyboard’s delete button).
- Switch to the “Filter” tab
- Check “Use filters”
- Change the second dropdown menu item to “Show only the following hosts”
- Input “*.fate-go.jp” into the text box (without quotation marks)
- Check “Show only if URL contains”
- Input “setup” in the text box beside that checkbox
Now do a few actions and make sure your filtering work (uncheck the “Show only if URL contains” box at first to include all game network activity, then check it again once you’ve confirmed it works and are ready to proceed).
3) Convert the network response to JSON
Now start a battle, locate the corresponding /battle/setup network call and response. If you are using Fiddler, converting the raw text response to formatted JSON for inspection is easy; just switch back to the “Inspectors” tab and choose “JSON” tab for the bottom section (you might want to resize each of the subwindows a bit so you can fully see things). Note that if you are seeing garbled output, it means you forgot to check “Decrypt HTTPS traffic” under Fiddler Options/HTTPS. For those using other packet sniffers, here is a pretty nice tool for formatting the response body’s text into something readable. Just keep in mind that the network response is compressed in gzip format, so you will have to also configure your packet sniffer to decompress the data first.
4) Inspect the dropInfo section and check the objectIds
In the screenshot below, you’ll notice that I’ve highlighted an item drop with an objectId of 6501. That means that, straight from the start of the battle, I know that the last boss will drop a Phoenix Plume ascension items for me. Yay for a lvl 90 Arturia!
5) Decide whether to finish the battle or not
In the above case, since I know the item I want is going to drop, I will continue and complete the battle as normal and pick up my loot. In most cases, however, you will not be so fortunate. When that happens (i.e. 90% of the time), you will have to make a decision: Do you want to A) go ahead and spend the next 2-5 minutes completing the battle and pick up a small amount of QP and bond EXP, or B) save your time by ditching the battle and going on to try your luck with the next one? If you want to choose option B (as you most likely will if you’re reading this guide), do the following to quit the battle early:
- Tap the “Battle Menu” button on the top right under your Master icon
- Tap the gray button on the top right of the popup menu
- Tap the right button in the confirmation dialog
- Tap the only button in the info dialog and return back to the home screen
Note that sometimes you will get a network connection error either when you quit the battle or when you complete the battle. This will happen commonly as there is a slight delay when proxying through Fiddler. If you see the dialog, just tap the right button to retry.
Enjoy The Loot
And that’s that. If you’ve somehow made it to the end of this guide without getting lost on the way, congratulations. You now have a basic understanding of how mobile games like these work, good job!
Thanks to the pre-emptive assistance of packet sniffing, you can save yourself some major farming time and get your max lvl waifu faster. Get into the flow and you’re easily looking at 100 battles every half hour or faster. Now get farming and enjoy your sweet loots!
Fiddler2 website: http://www.telerik.com/fiddler
Drop Infos Wikia page: http://fategrandorder.wikia.com/wiki/Drop_Infos
Item Cirnopedia page with drop info: http://fate-go.cirnopedia.info/item.php
Reddit post: https://www.reddit.com/r/grandorder/comments/3knfht/fast_ascension_item_farming_guide_with_packet/