PDA

View Full Version : Decoding lockbox opens



mxz
09-14-2012, 12:33 PM
I have a couple theories on how these work, but in light of some new evidence I'm trying to bring in - let's open it up for discussion.

Here are portions of two server calls during lockbox opens. Scenario 1 produced a BLNT. Scenario 2 produced $50,000.

Scenario 1 - client call to server
lockboxes.lockboxes open_lockbox |E1347641366
Scenario 2 - client call to server
lockboxes.lockboxes open_lockbox |V1347645639

Breaking this down, the client is calling on the lockboxes class method open_lockbox, with an input of a generated string (E1347641336/V1347645639).

Scenario 1 - server response
CommandResponseservice 'lockboxes.lockboxes
method open_lockbox
sequence_num E
return_value success
lockbox_result
/lockboxes.LockboxResult
did_open
loot_type
loot_id
loot_quantity
reward_type
reward_id
reward_quantity 9
current_player_lockbox_event 9

lockboxes.PlayerLockboxEvent
event_id
lockbox_tokens !
lockboxes_opened '
leaderboard_rewards /
is_leaderboard_rewarded !
leaderboard_rank /
time_lockbox_unlockable '2012-09-14 10:49:34
iddatabase_id U
unique_id
player_id '*REMOVED*
payloadtime_created '2012-09-11 13:56:30
time_updated '2012-09-14 08:48:05
version N7
leaderboard_item_reward_id s

Scenario 2 - server response
CommandResponseservice 'lockboxes.lockboxes
method open_lockbox
sequence_num V
return_value success
lockbox_result
/lockboxes.LockboxResult
did_open
loot_type money
loot_id
loot_quantity P
reward_type
reward_id
reward_quantity 9
current_player_lockbox_event 9

lockboxes.PlayerLockboxEvent
event_id
lockbox_tokens !
lockboxes_opened '
leaderboard_rewards /
is_leaderboard_rewarded !
leaderboard_rank /
time_lockbox_unlockable '2012-09-14 12:00:47
iddatabase_id U
unique_id
player_id '*REMOVED*
payloadtime_created '2012-09-11 13:56:30
time_updated '2012-09-14 09:49:34
version O7
leaderboard_item_reward_id s


So we know these things:
The server determines the loot type (in Scenario 2: money)
The server determines the loot qty (in Scenario 2: P, which meant $50,000)
The server likely determines if you have enough opened items (5/10/15/20) for a reward
The server tells the client when the next time it can open a box is

Some other interesting things to consider:
time_updated changed, but it either has a different clock or is delayed. Is this the time the leaderboard was last updated? If so, Funzio is delaying it, possibly to make it look like you're closer to the top 25/250 than you really are.

G Wiz
09-14-2012, 12:40 PM
1. Wow

2. So things aren't as random as we thought?

Ramshutu
09-14-2012, 12:46 PM
I wouldn't expect the leaderboard to update too regularly, the database activity would be fairly prohibitive.

Dr BoneCrusher
09-14-2012, 12:55 PM
So, how would this effect the leader board locking 1hr before the end of the event.

mxz
09-14-2012, 12:56 PM
I wouldn't expect the leaderboard to update too regularly, the database activity would be fairly prohibitive.It appears to have updated between the two opens (if that's what we're looking at), about once an hour - but they delay public posting of the leaderboard by 3 hours.

Ramshutu
09-14-2012, 01:00 PM
It appears to have updated between the two opens (if that's what we're looking at), about once an hour - but they delay public posting of the leaderboard by 3 hours.

Assuming that the the time unlocked is the time at which the next box becomes available, the leaderboard is only an hour and 10 minutes behind.

mxz
09-14-2012, 01:10 PM
Assuming that the the time unlocked is the time at which the next box becomes available, the leaderboard is only an hour and 10 minutes behind.Oh yeah...looked at the wrong field. So the other thing with this is the database appears to have finished compiling at the same time I opened the first box (09:49:34). So maybe it wasn't as delayed as I first thought.

Unfortunately my latest capture didn't work because it switched my wifi networks on me and came up with an empty trace. Grr

Murda
09-14-2012, 01:17 PM
I am not a programmer and never ever want would claim to understand some of this jargon......but what I take from that is that in Scenario 1 you ran at 09:49:34 because your next open is listed at 10:49:34.

In Scenario two it is listing the last time it updated from Scenario 1 - which was: time_updated '2012-09-14 09:49:34

So by that logic if you capture your next update in the sequence it should read: time_updated '2012-09-14 11:00:47 because that's when you opened the item in Scenario 2.

Ramshutu
09-14-2012, 01:22 PM
I am not a programmer and never ever want would claim to understand some of this jargon......but what I take from that is that in Scenario 1 you ran at 09:49:34 because your next open is listed at 10:49:34.

In Scenario two it is listing the last time it updated from Scenario 1 - which was: time_updated '2012-09-14 09:49:34

So by that logic if you capture your next update in the sequence it should read: time_updated '2012-09-14 11:00:47 because that's when you opened the item in Scenario 2.

Someone give that man a biscuit. Good catch. Well have you debugging recursive mutex deadlocks in no time.

Murda
09-14-2012, 01:29 PM
Well have you debugging recursive mutex deadlocks in no time.

you could have said detangling repulsive mutant dreadlocks and I would have the same understanding:)

JohnDough
09-14-2012, 01:30 PM
Sooooooooooooooooooo?

Olly1
09-14-2012, 01:38 PM
I'm sure the update time of the leader board used to be 15 or 30 minutes when the event was first launched.

They close the leader board in the last hour for obvious panic gold opens but if it's now over an hour then I imagine that's just to cut down on so much data being pushed to each device. Lagging it to 1h+ with the intent to urge panic buying doesn't really seem like the reason as people with more grenades/cards than others will stop spending as they're ahead. Balance that with the people that do spend to catch up and you're back at a happy medium.

P.S great detective work as always mxz. If you could now figure out how the server determines the open that would be great ;)

PawnXIIX
09-14-2012, 01:42 PM
Are you guessing these variables exist or are these actually in the data?

DenZ1
09-14-2012, 02:20 PM
1. Wow

2. So things aren't as random as we thought?

I've been telling it for months now... Everyone scream "random". There's no random here anymore. Old events are gone.

_dan_
09-14-2012, 03:03 PM
I've been telling it for months now... Everyone scream "random". There's no random here anymore. Old events are gone.

It is random but under-control.

Deluxe
09-14-2012, 03:09 PM
you could have said detangling repulsive mutant dreadlocks and I would have the same understanding:)

I tee hee hee'd right there...glad the forum can still produce a laugh

PawnXIIX
09-14-2012, 03:24 PM
Are you guessing these variables exist or are these actually in the data?

Was this the decryption of a packet or was this just speculation D:

mxz
09-14-2012, 03:42 PM
Was this the decryption of a packet or was this just speculation D:From a series of packet traces.

I traced one where I got $10,000. Similar story, but instead of loot_quantity "P" there was no value. Here's there response:

CommandResponseservice'lockboxes.lockboxes
methodopen_lockbox
sequence_num .
return_value
success
lockbox_result /
lockboxes.Lockbox Result
did_open
loot_type money
loot_id
loot_quantity
reward_type
reward_id
reward_quantity 9
current_player_lockbox_event 9

lockboxes.PlayerLockboxEvent
event_id
lockbox_tokens !
lockboxes_opened '
leaderboard_rewards /
is_leaderboard_rewarded !
leaderboard_rank /
time_lockbox_unlockable '2012-09-14 15:24:39
iddatabase_id U
unique_id
player_id '*REMOVED*
payloadtime_created '2012-09-11 13:56:30
time_updated '2012-09-14 13:23:38
version R7 (third opening after the last posted one (I think), so this appears to count up from the first bit)
leaderboard_item_reward_id s

Ramshutu
09-14-2012, 04:30 PM
To be frankly honest, the game isn't particularly complex in its own right. The problems you have to solve setting it up is not the data, but the way you have to control it to be fast and minimal (mobile friendly) and protected (difficult to spoof the server) The server-client communication is pretty much what i expect to see from this type of system.

There isn't really any mystery with what the server and client do. The interesting bits are the algorithms, secret multiplier and probabilities of different features. These can only be found by trial and error and number crunching!

Sometimes its difficult for a non programmer to understand what is and isn't practical with systems like this. Sometimes little suggestion could mean weeks of implementation and be slow as well.

I think with talk of random and non random, as if gree are being all sneaky misses the real point. Gree does a lot of stuff that spurs people into spending money. And it is all very in your face and all obvious. There's no real marketing need to do much more.

mxz
09-14-2012, 04:37 PM
That's what makes the spamming of the goals list every lockbox opening so weird to me. There's a lot of extraneous information in each packet that makes me wonder what the heck the programmers were thinking.

Another fun thing at looking at packet captures is seeing who is in your hood at any given time. It would appear every time someone enters, attacks or robs you the server sends you a personal notification (I previously assumed this would be handled all at the server level). However, I've also noticed building collections don't get their own update (not new info), but rather get bundled into the next action (opening of the leaderboard, banking, possibly refreshing the rivals list). My guess is in case someone tries to rob you before the collection information is sent to the server, the server sends a new message from the attack/rob.

_dan_
09-14-2012, 04:53 PM
simply setup a proxy, handle messages transfer and ....

PawnXIIX
09-14-2012, 04:57 PM
From a series of packet traces.

I traced one where I got $10,000. Similar story, but instead of loot_quantity "P" there was no value. Here's there response:

CommandResponseservice'lockboxes.lockboxes
methodopen_lockbox
sequence_num .
return_value
success
lockbox_result /
lockboxes.Lockbox Result
did_open
loot_type money
loot_id
loot_quantity
reward_type
reward_id
reward_quantity 9
current_player_lockbox_event 9

lockboxes.PlayerLockboxEvent
event_id
lockbox_tokens !
lockboxes_opened '
leaderboard_rewards /
is_leaderboard_rewarded !
leaderboard_rank /
time_lockbox_unlockable '2012-09-14 15:24:39
iddatabase_id U
unique_id
player_id '*REMOVED*
payloadtime_created '2012-09-11 13:56:30
time_updated '2012-09-14 13:23:38
version R7 (third opening after the last posted one (I think), so this appears to count up from the first bit)
leaderboard_item_reward_id s

I always try to see how different developers do things differently. To other people this may look like nothing important but to me it's a look into the eyes of a professional programmer :P

Ramshutu
09-14-2012, 05:22 PM
That's what makes the spamming of the goals list every lockbox opening so weird to me. There's a lot of extraneous information in each packet that makes me wonder what the heck the programmers were thinking.

Another fun thing at looking at packet captures is seeing who is in your hood at any given time. It would appear every time someone enters, attacks or robs you the server sends you a personal notification (I previously assumed this would be handled all at the server level). However, I've also noticed building collections don't get their own update (not new info), but rather get bundled into the next action (opening of the leaderboard, banking, possibly refreshing the rivals list). My guess is in case someone tries to rob you before the collection information is sent to the server, the server sends a new message from the attack/rob.

I can understand a lot of what is being done and why, it has changed quite a lot in the last six months as people were exploiting some of these mechanics.

The problem with running on a phone, is that you can get a lot more data drop outs than you may think, combined with round trip time latency, which can be excessive when running on 2g or fully loaded 3G cells, you really want to minimise communication with the server. You really dont want each collection of, say, 25 buildings in the morning to go back and forth with the server for each building when you can simply cache it and send it as a single transaction in the background.

The data transfer mechanics have their own assorted issues and limitations than you would find on, say, an Internet company LAN. And remember, there is always the hidden trade off between the best way of organising the data, and the ease if implementation. Remember, Engineering isn't about finding the "best" solution to a problem, it's a out finding the "most appropriate" solution for your given situation.

Veezy
09-14-2012, 05:29 PM
good info...great post. Thanks

_dan_
09-14-2012, 09:40 PM
simply setup a proxy, handle messages transfer and ....

... rewrite your fortune.

BOS
09-14-2012, 10:04 PM
... rewrite your fortune.

Thanks to mxz for the thread and good to see you back Ramshutu.

mxz
09-14-2012, 11:02 PM
... rewrite your fortune.I don't think that strategy would work since the server would know what you were supposed to get. Whether they're still using the cheat detection scripts or not, though....

_dan_
09-15-2012, 01:02 AM
this is not the good place to discuss about such possible action..