--- /dev/null
+---
+title: "Reverse Engineering a Mobile App Protobuf API"
+date: 2024-05-11T12:00:00+03:00
+description: "In recent times more than ever, live service and overuse of APIs soon-to-be-stale is only increasing. This causes a lot of once-written software to become either unusable or handicapped in many regards. One way to fight this is to learn reverse engineering for sake of digital preservation. In this blog, I take you through a journey of reverse engineering a simple mobile game's protobuf API."
+tags: ['tutorial', 'reverse-engineering', 'opensource']
+type: blog
+draft: false
+---
+
+# Why
+Why not? Digital preservation is important, even if you don't care for a specific program.
+This is also a good way to get started with protocol reverse engineering due to way protobuf
+is often left behind in source format within client applications.
+
+## The target
+In this series of blogposts, I will be using a mobile game "Egg, Inc." as the target for
+demonstration. It's a simple time killer app that got me through boring long waits when I was still at school.
+
+I won't bore you with details, but in essence it's an incremental game with partial online features
+such as cloud save, co-op contracts and server scheduled boosts.
+
+## The existing works
+In some cases, you will find previous works on the target you pick, in my case, some clever people have created
+[scripts to extract .proto file out of app.](https://github.com/DavidArthurCole/EggIncProtoExtractor)
+I advise you to check it out if you wish to get a better understanding of how you would go about retrieving the
+API spec .proto file for your target.
+
+Further there are a few dedicated individuals in the game's community who have created numerous tools and historical databases.
+
+For this blog purposes, we will assume the game server is shut down (as in we cannot query from the live API) and our goal is
+to make a semi-functional selfhosted gameserver for our own needs, assuming we are the only one on said server.
+
+## Getting Started
+Thanks to the previously mentioned script, it's easy to get started - find the APK, extract protobuf spec file, convert it with
+protoc and we're done there. One small problem - due to cheaters, latest version of the game includes "AuthenticatedMessage" structure,
+which contains a salted sha256sum of the payload message.
+
+At this point, after a bit of internal dilemma, I decided to not further the problem while service is still live for people playing and did the
+more morally sound decision of picking a version prior to these integrity checks. We can crack that another day as all the needed information
+is retained in the app itself.
+
+Going forward with this, we are targetting game version 1.12.13 (Build ID 111121).
+
+With all that out of the way, lets get into actual commands used here:
+```
+git clone https://github.com/DavidArthurCole/EggIncProtoExtractor.git
+cd EggIncProtoExtractor
+./apkextract.sh com.auxbrain.egginc_1.12.13.apk
+# We should have a new folder "protos" now with resulting files
+cd protos
+# There should be a file called ei.proto - that's our protobuf spec file
+# At this point, we can use the protoc utility which can convert the specfile
+# to interfaces in C++, C#, Java, Kotlin, Objective-C, PHP, Python and Ruby with
+# additional plugin support for Dart and Go.
+# To make this easier to understand, we will use Python in this demonstration
+protoc -I=. --python_out=. ./ei.proto
+# Success! We now have a "ei_pb2.py" file which can be directly imported to Python programs
+```
+
+With the protobuf interface in Python created, we can now proceed with creating the API emulator - but there's a slight problem.
+What URL? What endpoints? How do we find this out? Simple answer, disassembling the game. Get your RE tool of choice, I will be
+using [Ghidra](https://ghidra-sre.org/) myself.
+
+(Note: You can also just try to find this out using tools such as WireShark)
+
+The game contains a linked-library written in C++, which you can find inside the .apk `lib` folder, named as `libegginc.so`.
+This is perfect for our use-case, Ghidra is going to slice through this like butter. Import the file to your RE tool of choice
+and let it perform some analysis on it, have a cup of tea or coffee as this is going to take a hot minute.
+
+Once that's done, we are going to start by looking at the defined strings - try our luck there. Search for any debug prints left
+behind or maybe some clues. I started by searching for `http`, which lead me to following string `"HTTP REQ: %d"`, seems promising.
+When I jumped to it, I saw an exactly adjacent string to it which could give more clues:
+```
+ s_www.auxbrain.com_00c02b60 XREF[0,1]: FUN_00518ab8:00518b38(R)
+ 00c02b5e 47 3f 77 ds "G?www.auxbrain.com"
+ 77 77 2e
+ 61 75 78
+ s_HTTP_REQ:_%d_00c02b71 XREF[1]: makeRequestInternal:0067bbd4(*)
+ 00c02b71 48 54 54 ds "HTTP REQ: %d"
+ 50 20 52
+ 45 51 3a
+```
+Interesting, `www.auxbrain.com`. If we jump to its XREF, we get a garbled function, but what it seems to be doing is setting up
+certain global values.
+
+So we have a potential API endpoint, let's put it to the test. We're not going to recompile anything yet or do any byte-patching,
+let's try a quick smoke-test. Ensure your phone is rooted and you have a variant of Xposed Framework installed (I used LSPosed).
+We will need to untrip the SSL pinning present in most apps, including this one, I used [io.github.tehcneko.sslunpinning](https://github.com/Xposed-Modules-Repo/io.github.tehcneko.sslunpinning) module.
+(Note: I know it is possible to repackage the app to do SSL unpinning in most cases, but in many cases, you won't know if it's worth the effort yet)
+
+Next, install [AdAway app from F-Droid](https://f-droid.org/packages/org.adaway/) so we can setup a redirection on any network we are on.
+Inside AdAway, add a redirection rule for the address we just found and point it to an IP address in your LAN that will run the API server.
+
+Generate a self-signed certificate authority and a certificate signed by it and run a webserver with both HTTP and HTTPS on the API server machine.
+Import the self-signed CA to your phone's truststore. Once all of that is done, run the app for first time.
+
+```
+192.168.1.212 - - [...] "POST /ei/first_contact HTTP/1.1" 404 0 "-"
+```
+
+Bingo. We have contact and we have an API endpoint. Searching for "ei/" in the strings reveals a extensive list of API endpoints, we now have something
+to go off from. We have everything we need to start creating the server.
+
+## Implementing the Server - Getting first contact
+Next up, we create a new project - as we generated the protobuf definitions for Python, we will proceed accordingly.
+If you are following along, get respective packages for your operating system to create python venvs.
+As the protobufs are being sent over HTTP, we will be serving our application over flask which is being reverse proxied by nginx.
+
+```
+# Lets stage the environment
+mkdir apiserver
+cd apiserver
+python -m venv .venv
+source .venv/bin/activate
+touch app.py
+cp ~/EggIncProtoExtractor/protos/ei.proto .
+
+# Get some dependeices
+pip install protobuf
+pip install flask
+```
+
+We now have the project set up for reading protobuf definitions and a framework to listen for HTTP and routes sent to it.
+Let's create an actual listener application, open app.py with your favourite IDE or text editor.
+
+```
+import ei_pb2 as EIProto
+from flask import Flask
+from flask import request
+
+@app.route("/ei/<path:subpath>", methods=["POST"])
+def ei_routes(subpath):
+ print("HTTP POST /ei/" + subpath)
+ print(request.headers)
+ return ""
+```
+
+This should get the ball rolling, we will see whatever call comes in and we can see what the payload of each request contains.
+At this point you should setup the reverse proxy, override your nginx / directive with:
+```
+location / {
+ proxy_pass http://127.0.0.1:5000;
+}
+```
+
+Reload your nginx and start the flask application you just created with `flask run`.
+
+Run the app again and have it phone home and see what it contains.
+```
+HTTP POST /ei/first_contact
+Host: 127.0.0.1:5000
+Connection: close
+Content-Length: 37
+Content-Type: application/x-www-form-urlencoded
+User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; M2012K11AG Build/TQ3A.230901.001)
+Accept-Encoding: gzip
+```
+
+We can see there's a form payload attached to this request, let's modify our app route a bit:
+```
+@app.route("/ei/<path:subpath>", methods=["POST"])
+def ei_routes(subpath):
+ print("HTTP POST /ei/" + subpath)
+ print(request.form)
+ return ""
+```
+
+Now if we run the modified flask application again, we see following output on the first_contact endpoint.
+```
+HTTP POST /ei/first_contact
+ImmutableMultiDict([('data', 'ChAzNTVlNDZlOTA4OWQxZTRjEAAYAg==')])
+```
+
+We have a base64-encoded protobuf binary data - which isn't terribly useful for reading plain-text, since protobuf *is* a binary
+format, so we will need to figure out what protobuf message this payload belongs to.
+
+Remember that ei.proto file alongside the ei_pb2.py we got earlier? Lets go back there and inspect it a bit.
+We know we just contacted something called "first_contact", maybe there is something in that file that could help us?
+
+```
+message EggIncFirstContactRequest {
+ optional string user_id = 1;
+ optional uint32 client_version = 2;
+ optional Platform platform = 3;
+}
+
+message EggIncFirstContactResponse {
+ optional Backup backup = 1;
+}
+```
+
+Seems like the application is using message names in almost similar fashion to API endpoint names themselves. This will prove
+to be useful knowledge. We now know what the payload should be, lets put this to the test.
+
+Edit your app routine again
+```
+# add "import base64" to top of the file
+@app.route("/ei/<path:subpath>", methods=["POST"])
+def ei_routes(subpath):
+ print("HTTP POST /ei/" + subpath)
+ if subpath == "first_contact":
+ # Create the protobuf object so we can load data from the b64 payload
+ FirstContact = EIProto.EggIncFirstContactRequest()
+ FirstContact.ParseFromString(base64.b64decode(form["data"]))
+ print(FirstContact)
+ else:
+ print(request.form)
+ return ""
+```
+
+We should now be able to see deserialized output when we run the flask application and the mobile app, let's try it out:
+
+```
+HTTP POST /ei/first_contact
+user_id: "355e46e9089d1e4c"
+client_version: 0
+platform: DROID
+```
+
+Nice! We now know how to identify which protobuf object corresponds to which API endpoint. We can now make an educated guess
+on what would come next.
+
+Seeing how we got `EggIncFirstContactRequest` and saw an adjacent `EggIncFirstContactResponse` message in the proto file, we
+can safely assume that this is what the game is expecting from us in return.
+
+Lets modify the server a bit to account for that.
+
+```
+@app.route("/ei/<path:subpath>", methods=["POST"])
+def ei_routes(subpath):
+ print("HTTP POST /ei/" + subpath)
+ if subpath == "first_contact":
+ # Create the protobuf object so we can load data from the b64 payload
+ FirstContact = EIProto.EggIncFirstContactRequest()
+ FirstContact.ParseFromString(base64.b64decode(form["data"]))
+ print("We got a first contact hello from user " + FirstContact.user_id)
+ # Lets respond with a FirstContactResponse
+ FirstContactResp = EIProto.EggIncFirstContactResponse()
+ # This takes only one optional argument - a Backup object - but we have no account
+ # system yet, so we will opt out of sending that for now.
+ # ---
+ # We send the payload back as a base64 string - the same way we retrieved it.
+ return base64.b64encode(FirstContactResp.SerializeToString())
+ else:
+ print(request.form)
+ return ""
+```
+
+Now when we run the app again, we notice that we no longer get spammed this endpoint, but instead in its place we see a few new friends
+
+## Implementing the Server - New Friends
+Say hello to `/ei/save_backup` and `/ei/get_periodicals`. We can infer from the name, that save_backup would involve a Backup message
+and get_periodicals would involve a GetPeriodicalsRequest, both of which are defined fully in the proto spec file.
+
+Both of these are clogging up the flask application log periodically, we should check out what they are so we can have a sane log again.
+
+```
+@app.route("/ei/<path:subpath>", methods=["POST"])
+def ei_routes(subpath):
+ print("HTTP POST /ei/" + subpath)
+ if subpath == "first_contact":
+ # Create the protobuf object so we can load data from the b64 payload
+ FirstContact = EIProto.EggIncFirstContactRequest()
+ FirstContact.ParseFromString(base64.b64decode(form["data"]))
+ print("We got a first contact hello from user " + FirstContact.user_id)
+ # Lets respond with a FirstContactResponse
+ FirstContactResp = EIProto.EggIncFirstContactResponse()
+ # This takes only one optional argument - a Backup object - but we have no account
+ # system yet, so we will opt out of sending that for now.
+ # ---
+ # We send the payload back as a base64 string - the same way we retrieved it.
+ return base64.b64encode(FirstContactResp.SerializeToString())
+ elif subpath == "save_backup":
+ # NOTE: This took me way longer to realize than it should have, but the base64
+ # payload you receive from client is broken due to some Android bug, where it
+ # substitutes "+" symbols with a " " whitespace.
+ # I don't want you to waste half hour to hours figuring out why you're getting
+ # corrupted data, so you're welcome.
+ Backup = EIProto.Backup()
+ Backup.ParseFromString(base64.b64decode(form["data"].replace(" ", "+"))
+ print(Backup)
+ elif subpath == "get_periodicals":
+ Periodicals = EIProto.GetPeriodicalsRequest()
+ Periodicals.ParseFromString(base64.b64decode(form["data"])
+ print(Periodicals)
+ else:
+ print(request.form)
+ return ""
+```
+
+We should now see what these payloads actually contain when deserialized (for your reading experience, I advise you to rather
+try this out yourself - the Backup structure is VERY large).
+
+Upon these payloads reaching the server, we see that a very much populated Backup message makes its way through and a relatively
+thin payload of PeriodicalsRequest comes through, which isn't very useful by itself.
+
+Now, this is why the game developer ended up creating forms of anticheat in future versions of this app - the Backup message contains
+your entire game state, which is often sent as a way to save your progress to cloud, but there is no actual sanity checking in place
+to ensure you're not progressing way too fast. Personally, I am of the mind that anticheat should be done on the server-side, not
+on the client-side, but I digress. We can use this to prove a very obvious vulnerability when using trust-client-always architecture.
+
+The game has an In App Purchase for "Pro Permit", which allows you to build more Silos, which in turn allow you to get offline
+rewards for a longer period of time. If we look at protobuf definition file, you can see under Backup.game, a field called "permit_level",
+which by default is zero. Lets try to change that and present a modified Backup the next time user opens the game.
+
+
+```
+cache = {}
+
+@app.route("/ei/<path:subpath>", methods=["POST"])
+def ei_routes(subpath):
+ print("HTTP POST /ei/" + subpath)
+ if subpath == "first_contact":
+ # Create the protobuf object so we can load data from the b64 payload
+ FirstContact = EIProto.EggIncFirstContactRequest()
+ FirstContact.ParseFromString(base64.b64decode(form["data"]))
+ print("We got a first contact hello from user " + FirstContact.user_id)
+ # Lets respond with a FirstContactResponse
+ FirstContactResp = EIProto.EggIncFirstContactResponse()
+ if FirstContact.user_id in cache:
+ FirstContactResp.backup.CopyFrom(cache[FirstContact.user_id])
+ del cache[FirstContact.user_id]
+ return base64.b64encode(FirstContactResp.SerializeToString())
+ elif subpath == "save_backup":
+ # NOTE: This took me way longer to realize than it should have, but the base64
+ # payload you receive from client is broken due to some Android bug, where it
+ # substitutes "+" symbols with a " " whitespace.
+ # I don't want you to waste half hour to hours figuring out why you're getting
+ # corrupted data, so you're welcome.
+ Backup = EIProto.Backup()
+ Backup.ParseFromString(base64.b64decode(form["data"].replace(" ", "+"))
+ if Backup.game.permit_level == 0:
+ print("Saved a modified Backup for next game load")
+ # Modify the permit level, force offer the backup
+ Backup.game.permit_level = 1
+ Backup.force_offer_backup = True
+ Backup.force_backup = True
+ cache[Backup.user_id] = Backup
+ elif subpath == "get_periodicals":
+ Periodicals = EIProto.GetPeriodicalsRequest()
+ Periodicals.ParseFromString(base64.b64decode(form["data"])
+ print(Periodicals)
+ else:
+ print(request.form)
+ return ""
+```
+
+Lets load up the game. Nothing interesting seems to be happening yet - lets wait until we see the "Saved a modified Backup for next game load" message
+show up in the server console. Once this shows up, restart the game - you are presented with a popup that you are offered to load a
+Backup from server. Let's accept that.
+
+Now click on your silos, you have the Pro Permit for free.
+
+Now, it goes without saying, I do not condone piracy - the future versions of this game are very much guarded against this, rightfully so.
+If you attempt this in actual game servers, this is considered fraud and IS detectable by the developer (every IAP has a receipt, logically!).
+
+This version of the game is defunct as the protocol has changed quite a bit in the years since this version and additional anticheat
+measures have been added since. You cannot transfer this status (or even purchase what you just did) from this game version to the next.
+
+### Onto the PeriodicalsRequest
+This one is a bit more fun to delve into blindly - the proto spec wont help you much here. We will need to use our trusty RE tools again and delve into
+the game disassembly again.
+
+By public knowledge, we know there are server events for "Epic Research Sale", "Research Sale", "Drone Bonus" and "Prestige Boost". We can use this information to try
+and look at any potential leads in strings. Drone seems like a good canditate, lets look into that.
+```
+drone_fans2
+drone_crash
+drone_enemy
+drone_hunter
+r_icon_drone_rewards
+b_icon_drone_boost
+drone_touch
+ei_drone_lights_green
+ei_drone_lights_red
+ei_drone_package
+ei_drone_propeller
+drone-boost
+GENEROUS DRONES
+```
+This looks promising, right off the bat, first strings I'd check here are `r_icon_drone_rewards`, `b_icon_drone_boost`, `drone-boost` and `GENEROUS DRONES`.
+
+I inspected all 4 of them, and when I got to final 2, I found the enum string translations used for event IDs - here they are extracted for game version 1.12.13
+```
+piggy-boost (Rate piggy fills is increased.)
+piggy-cap-boost (UNLIMITED PIGGY;Gains are retained when event ends.)
+prestige-boost (PRESTIGE BOOST;Collect more soul eggs on prestige, you must prestige to take advantage of this event.)
+earnings-boost (CASH BOOST;Regular earnings are increased.)
+gift-boost (GENEROUS GIFTS;Boost applies to random gifts and video gifts.)
+drone-boost (GENEROUS DRONES;Drones will produce larger rewards.)
+epic-research-sale (EPIC RESEARCH SALE;Only applies to Epic Research.)
+vehicle-sale (VEHICLE SALE;Applies to all vehicles.)
+boost-sale (BOOST SALE;Applies to the gold price of boosts.)
+boost-duration (BOOST TIME+;Boosts last longer, you must start a boost during the event.)
+```
+I recall there being a few more boosts, but this is useful for getting started with compositing PeriodicalsResponse with an active running event.
+
+### Putting together the response
+We have the enum, we have the names, descriptions, lets try to create a sample server event when the client enqueries about current server periodical events.
+```
+ elif subpath == "get_periodicals":
+ # We don't actually need the information client sends us,
+ # we aren't verifying any stats about client in our server.
+ CurrentPeriodicals = EIProto.PeriodicalsResponse()
+ # In order to add items to a repeatable field in protobuf structure,
+ # we need to call .add() method on it
+ event = CurrentPeriodicals.events.events.add()
+ # Refer to ei.proto - we are filling fields for EggIncEvent structure here.
+ event.type = "drone-boost"
+ event.multiplier = 5.00
+ event.subtitle = "Drones will produce larger rewards."
+ event.identifier = "GENEROUS DRONES"
+ event.seconds_remaining = 300.0
+ # Lets make it respond with a 5 minute event (this will re-arm itself when client calls
+ # for get_periodicals again every 6 minutes)
+ return base64.b64encode(CurrentPeriodicals.SerializeToString())
+```
+
+Launch the server and observe as the client periodically calls this endpoint again, it will now receive a 5 minute 5x Drone Rewards boost on the game.
+
+## Created the Server - What now?
+We have now created a very basic server, which appropriately responds to a first contact, misuses the game backup feature to prove a point about weaknesses of
+trusting client in server. We also created a very basic server event, which always rearms itself to never expire.
+
+What do we do next?
+
+At this point, we can start dog-fooding the project. Lets start with whatever ball game throws at us as we progress.
+
+### Contracts
+As we progress the game and start performing prestiges, we unlock a feature called "Contracts" - but disaster strikes as we don't have any contracts we could
+accept. So far we stil see our good friends `/ei/get_periodicals` and `/ei/save_backup` hammering the server at regular intervals.
+
+When we created the periodicals response payload, you might have noticed in the protobuf message an optional field called `ContractsResponse contracts`. Lets see
+what this ContractsResponse message contains.
+
+```
+message ContractsResponse {
+ repeated Contract contracts = 1;
+ optional string warning_message = 4;
+ optional double server_time = 2;
+ optional uint32 max_eop = 3 [default = 1000];
+}
+```
+
+Notice there being an array of Contract messages right off the bat - lets find its message structure next:
+
+```
+message Contract {
+ optional string identifier = 1;
+ optional string name = 9;
+ optional string description = 10;
+ optional Egg egg = 2;
+
+ repeated Goal goals = 3;
+ message Goal {
+ optional GoalType type = 1;
+ optional double target_amount = 2;
+ optional RewardType reward_type = 3;
+ optional string reward_sub_type = 4;
+ optional double reward_amount = 5;
+ optional double target_soul_eggs = 6;
+ }
+
+ repeated GoalSet goal_sets = 16;
+ message GoalSet {
+ repeated Goal goals = 1;
+ }
+
+ optional bool coop_allowed = 4;
+ optional uint32 max_coop_size = 5;
+ optional uint32 max_boosts = 12;
+ optional double minutes_per_token = 15 [default = 60];
+ optional double expiration_time = 6;
+ optional double length_seconds = 7;
+ optional double max_soul_eggs = 13;
+ optional uint32 min_client_version = 14;
+ optional bool debug = 11;
+}
+```
+
+We will need to do a bit of reading. Fortunately, the game has a community wiki, lets look into how contracts should work. I took an
+[older revision of Contracts wiki page from 2021](https://egg-inc.fandom.com/wiki/Contracts?oldid=13015) and did some slight research.
+
+From what I gather, at one point, there was only one set of contract rewards, shared between everyone - then they created a system where
+beginners will get easier contract goals while more advanced players get harder contract goals.
+
+We can put two-and-two together here and infer that `repeated Goal goals` is the legacy contract system - where everyone was on equal footing
+and `repeated GoalSet goal_sets` is the *new* goal system that is split into Standard and Elite.
+
+We also learn that in future game version, they completely reworked how contracts work *yet* again into a grading "bracket" system. Fortunately,
+we do not have to worry about that in our current target revision.
+
+Now to get the ball rolling, there is conveniently a starting point set ahead for us already. The developer of game intended to ease new players into
+contracts by creating a simple & easy contract called [Your First Contract](https://egg-inc.fandom.com/wiki/Contracts/Your_First_Contract?oldid=13547).
+
+This page tells us all the information we need to compose our first Contract, so lets try to make one.
+
+```
+ elif subpath == "get_periodicals":
+ # We don't actually need the information client sends us,
+ # we aren't verifying any stats about client in our server.
+ CurrentPeriodicals = EIProto.PeriodicalsResponse()
+ # [...]
+ Contract = CurrentPeriodicals.contracts.contracts.add()
+ Contract.identifier = "first-contract"
+ Contract.name = "Your First Contract"
+ Contract.description = "We heard you are open to contract work! Help fill this order from the local pharmacy!"
+ Contract.egg = EIProto.Egg.MEDICAL
+ Contract.coop_allowed = False
+ Contract.minutes_per_token = 5
+ # Lets set expiry time to always be 3 days into future
+ Contract.expiration_time = time.time() + (3600.0 * 72.0)
+ Contract.length_seconds = 3600.0 * 4.0
+ # The wiki mentions that you cannot get this contract after you reach 5000 Soul Eggs
+ Contract.max_soul_eggs = 5000.0
+ # We should have the basic metadata set now, lets create the goalsets.
+ FirstSet = Contract.goal_sets.add()
+ Goal = FirstSet.goals.add()
+ # There is only one type of goal in this verison
+ Goal.type = EIProto.GoalType.EGGS_LAID
+ Goal.target_amount = 100000.0
+ Goal.reward_type = EIProto.RewardType.GOLD
+ Goal.reward_amount = 192
+ Goal = FirstSet.goals.add()
+ Goal.type = EIProto.GoalType.EGGS_LAID
+ Goal.target_amount = 500000000.0
+ Goal.reward_type = EIProto.RewardType.PIGGY_FILL
+ Goal.reward_amount = 10000
+ # Lets now add the Elite table, we can pretty much copy-paste the above here.
+ SecondSet = Contract.goal_sets.add()
+ Goal = SecondSet.goals.add()
+ Goal.type = EIProto.GoalType.EGGS_LAID
+ Goal.target_amount = 100000.0
+ Goal.reward_type = EIProto.RewardType.GOLD
+ Goal.reward_amount = 500
+ Goal = SecondSet.goals.add()
+ Goal.type = EIProto.GoalType.EGGS_LAID
+ Goal.target_amount = 500000000.0
+ Goal.reward_type = EIProto.RewardType.PIGGY_FILL
+ Goal.reward_amount = 10000
+ return base64.b64encode(CurrentPeriodicals.SerializeToString())
+```
+
+Lets try that out in-game now - after waiting for a minute, we see our contract prop up, but I immediately noticed one thing amiss.
+The contract goals are swapped! I am getting Elite contract rewards for a Standard contract.
+
+This piece of information now tells us that the first entry in GoalSets refers to Elite rewards and the second entry in GoalSets to Standard rewards.
+After swapping the sets around, we now see a contract with the corrected rewards.
+
+I playtested it a bit and the contract worked as expected.
+
+Now, the above code could be a lot neater. For your homework, if you're not skipping to the public source release in the end, you should try to create
+a contract database and try scheduling them like the game originally did - a "Leggacy" contract every Friday and regular contracts showing up every 1-2 weeks
+for roughly 2 weeks.
+
+## Conclusion so far
+We have created a (rather ugly looking) server emulator for the game. It functions, but it needs a lot of work still before we can call it ready.
+If you have followed this far, give yourself pat on the back - if you actually tried to run this code, give yourself an extra pat on the back.
+
+Before I give you the public source to the project, you might want to try your hand at creating a few more things.
+- "Cloud" save, present a Backup to any new device that just started playing.
+- Contracts Database and scheduler
+- Server Event scheduler
+
+I apologize if my method of documenting this has been messy, but that's also part of the chaos of reverse engineering, you are constantly learning new things
+about the project you are currently doing - refactoring becomes an essential part once you have documented the protocol to a comfortable degree.
+
+I won't give any promises for a part 2 any time soon, but I will be trying to make this feature complete, so without further ado, here are the git repository links:
+[github.com](https://github.com/cernodile/reEgg), [git.based.quest](https://git.based.quest/?p=reEgg.git;a=tree;h=refs/heads/master;hb=refs/heads/master).
+
+Thank you for reading and making it all the way to the end,
+- Cernodile
projects / web-hugo.git / commitdiff