The stat pots from this are soulbound anyways. I also doubt they are going to let hundreds of mules run away with a free vault and char slot. They probably have a detection system like they do for mass package purchasing.
New Packets!
Originally Posted by toddddd
I promise that deca didnt just decide to do this over night. Im sure it was a long and thought out decision where they have gone over the pros and cons of its impact. To me it seems this new addition is their answer to the constant complaints from the "free to play" players. People are always complaining about not having any way to unlock extra character slots/vaults without money, and now there is. So unless there is some huge unforeseen consequence to the game as a result of this new addition, dont expect it to go anywhere anytime soon.
The problem is all my mules have 8 full slots.. so now what.. haha!
Originally Posted by toddddd
I already incorporated this into my clientless code and was able to run through my entire muledump accounts list (200+ mules) and claim the daily rewards on all of them.
Also it seem like they've made a mistake in the nonconsecutive calendar. I didn't claim the reward yesterday on one of my mules and now the only claimable prize is the day 1 prize although my main account is already on day 2.
Edit: That is how the calendar works. You have to log in a total of 20 times a month to get the 20th reward.
Originally Posted by CrazyJani
From what I've tested you have to be in the daily quest room to be able to claim the rewards. Is this true?
Also it seem like they've made a mistake in the nonconsecutive calendar. I didn't claim the reward yesterday on one of my mules and now the only claimable prize is the day 1 prize although my main account is already on day 2.
Also it seem like they've made a mistake in the nonconsecutive calendar. I didn't claim the reward yesterday on one of my mules and now the only claimable prize is the day 1 prize although my main account is already on day 2.
Originally Posted by CrazyJani
From what I've tested you have to be in the daily quest room to be able to claim the rewards. Is this true?
Also it seem like they've made a mistake in the nonconsecutive calendar. I didn't claim the reward yesterday on one of my mules and now the only claimable prize is the day 1 prize although my main account is already on day 2.
Also it seem like they've made a mistake in the nonconsecutive calendar. I didn't claim the reward yesterday on one of my mules and now the only claimable prize is the day 1 prize although my main account is already on day 2.
and like Kushala Daora already said, my understanding of both is that the NonConsecutive calendar works where each time you login and claim a reward it moves up a square. So if you miss a day, the next day when you login it will still be at the same square as before. This is why they have the best rewards at the end of it, that way you have to login every day to get those, not just login at the end of the month. The consecutive calendar, as far as i can understand, works basically the same, but if at any point you forget to claim a reward one day, it will reset back to the first reward (i think?). Or it might work like you were thinking where it will continue to change the reward/day regardless of the claim status on the previous days. Guess we will have to see as the month goes on.
edit: more claimKey hex, still cant figure out what the values represent. You can clearly see there is only a few things different between ecah one. Its dirving me crazy not knowing what the hell it could be:
Code:
6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 F5 9C B8 08 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 88 9D 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 96 BD E0 09 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 A9 F6 80 B1 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 F5 9C D8 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 93 EA AB 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 AD F8 A4 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 8B A3 94 08 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 C9 93 D9 C9 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 CE EE 81 08 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 FA E8 CA 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 88 9D 0A 0C
Originally Posted by aseikin
This sounds kind of dangerous to add, I bet some people will create 10,000 mules to log in and get 10,000 free def pots.
Originally Posted by aseikin
Dangerous for deca, will encourage people to make massive amounts of mules which will cause them performance issues. Also flood the market potentially....
Originally Posted by brennanfull
The login reward pots are soul bound -_- Deca isn't THAT stupid.
I cant edit my old posts so guess ill post a new one...
I was looking over the client again and noticed that there are extra url parameters for the fetchCalendar, although it seems they arent needed, but best to include them if you want to fake being the client. These are the functions that show this:
Code:
override protected function startTask() : void
{
this.logger.info("FetchPlayerCalendarTask start");
this.requestData = this.makeRequestData();
this.sendRequest();
}
private function sendRequest() : void
{
this.client.complete.addOnce(this.onComplete);
this.client.sendRequest("/dailyLogin/fetchCalendar",this.requestData);
}
public function makeRequestData() : Object
{
var _loc1_:Object = {};
_loc1_.game_net_user_id = this.account.gameNetworkUserId();
_loc1_.game_net = this.account.gameNetwork();
_loc1_.play_platform = this.account.playPlatform();
_loc1_.do_login = Parameters.sendLogin_;
MoreObjectUtil.addToObject(_loc1_,this.account.getCredentials());
return _loc1_;
}
Code:
http://realmofthemadgodhrd.appspot.com/dailyLogin/fetchCalendar?game_net_user_id=&game_net=rotmg&play_platform=rotmg&do_login=1&guid=[EMAIL]&password=[PASS]
Okay the claimKey...the claimKey!!!! Talked with 059 a lot yesterday about the claimKey and we were trying to decode how it is created. Still havent figured much out honestly, there is 2 obviously different sections for the claimKey between accounts/days, but then there are also times when the claimKey is really fucked up and strange.
For anyone else interested in trying to figure this out ill post some keys i have recorded that show day 2 and day 3 from the same account. Each pair of rows is from the same account, the top row is day 2 bottom row is day 3. This is 5 different mules here that i used:
Code:
6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E0 A7 E1 CD 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 FA 93 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E0 A7 E1 CD 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 AB 86 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 A0 A3 AA D5 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 E1 8A 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 A0 A3 AA D5 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 DF 97 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 92 DC 85 F6 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 E1 8A 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 92 DC 85 F6 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 DF 97 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 A9 E7 DD 83 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 A9 E7 DD 83 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 B5 9B 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 F2 E4 E3 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 9C 82 0A 0C 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E9 F2 E4 E3 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 B5 9B 0A 0C
Some observations me and 059 made last night in regards to a few keys:
He broke these out so the ascii value is above the hex value, kind of helps see what you are looking at for parts of it.
Code:
j . s ~ r e a l m o f t h e m a d g o d h r d r / . . . A c c o u n t . € € ° à § á Í . . . . . D a i l y L o g i n D a t a . € € € € À ú “ . . 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E0 A7 E1 CD 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 FA 93 0A 0C j . s ~ r e a l m o f t h e m a d g o d h r d r / . . . A c c o u n t . € € ° à § á Í . . . . . D a i l y L o g i n D a t a . € € € € À « † . . 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 E0 A7 E1 CD 0B 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 AB 86 0A 0C j . s ~ r e a l m o f t h e m a d g o d h r d r / . . . A c c o u n t . € € ° ’ Ü … ö . . . . . D a i l y L o g i n D a t a . € € € € À á Š . . 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 92 DC 85 F6 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 E1 8A 0A 0C j . s ~ r e a l m o f t h e m a d g o d h r d r / . . . A c c o u n t . € € ° ’ Ü … ö . . . . . D a i l y L o g i n D a t a . € € € € À ß — . . 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 92 DC 85 F6 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 C0 DF 97 0A 0C
Along with the 2 strings having their length in front of them, both of these strings have a hex value of 0x18 directly after them. Not sure what that is, but its interesting they both have this. I also made the observation today that along with both strings ending with the same byte directly after, each string has the same 2 bytes before the length, 0x0b 0x12.
I also noticed today that after account there is the 0x80 (which is 126) x 2 = 256, and then after dailylogindata there is 0x80 x 4 = 512. Interesting numbers, see those alot with encryption keys or something but dont think that is the case here.
I have also observed that generally the only data that will be different between most keys is the data between account and dailylogindata, and then data after dailylogindata. These are the only two areas of the key that seem to change.
059 also pointed out to me that sometimes keys will have an underscore "_" in them, and when that happens it messes up the base64 decoding. These keys clearly have the first half with the "Account" string in them and the following bits, but because of the underscore the text becomes all jumbled where the "DailyLoginData" string is normally at. We still havent really figured out what this is about.
And again, these are all just observations. We still are not sure what the keys mean or how they are being generated. The byte values in the key's dont seem to match anything we can find.
The potions are soulbounded. Tbh the only thing that can cause potential havoc is the Stanly Easter Bunny Skin.
Originally Posted by iliketrainz
The potions are soulbounded. Tbh the only thing that can cause potential havoc is the Stanly Easter Bunny Skin.
every changes to the client
changes I documented
Code:
\scripts\kabam\rotmg\questrewards\view\QuestRewardsPanel.as changed x position \scripts\kabam\rotmg\chat\view\ChatMediator.as added remove for the chat registrer \scripts\com\company\assembleegameclient\ui\panels\PartyPanel.as changed x, y position \scripts\com\company\assembleegameclient\screens\ScoringBox.as added new dungeons for dungeonscompleted \scripts\com\company\assembleegameclient\parameters\Parameters.as changed build version \scripts\com\company\assembleegameclient\objects\ObjectLibrary.as added 'dailyloginrewards' map data \scripts\com\company\assembleegameclient\map\Map.as added 'Daily Login Room' map data \scripts\WebMain.as added the map in the 'mvcbundle' \scripts\kabam\rotmg\ui\UIConfig.as added 'fetchplayercalendartask' task \scripts\kabam\rotmg\promotions\view\AlreadyPurchasedBeginnersPackageDialog.as added show daily calender popup on beginner package close (note : commented it out) \scripts\kabam\rotmg\packages\view\PackageOfferDialog.as added show daily calender popup on packageoffer close (note : commented it out) \scripts\kabam\rotmg\messaging\impl\GameServerConnection.as Life's a everyday hustle : this is where it gets interesting. They added 3 packets CLAIM_LOGIN_REWARD_MSG:int = 102; LOGIN_REWARD_MSG:int = 103; QUEST_ROOM_MSG:int = 104; \scripts\kabam\rotmg\chat\view\ChatInputNotAllowed.as put variable creation and declaration on the same line \scripts\kabam\rotmg\chat\control\ParseChatMessageCommand.as added dailyloginmodel in parsechatmessagecommands \scripts\kabam\rotmg\account\AccountConfig.as added purchase confirmation for slot configuration \scripts\kabam\rotmg\account\core\BuyCharacterSlotCommand.as added slot purchase confirmation dialog \scripts\kabam\rotmg\packages\view\PackageOfferDialogMediator.as added dailycalendarpopup on package close (note : commented it out) \scripts\kabam\rotmg\packages\view\PackageInfoMediator.as added dailycalendarpopup on packageinfomediator (note : commented it out) \scripts\kabam\rotmg\core\commands\SetScreenWithValidDataCommand.as added fetchplayercalendar task \scripts\com\company\assembleegameclient\util\ColorUtil.as added function 'randomSmart' in ColorUtil \scripts\com\company\assembleegameclient\game\GameSprite.as added if map == nexus, dispatch daily calender popup signal (note : commented it out) \scripts\kabam\rotmg\account\web\commands\WebLoginCommand.as added getmysteryboxestask \scripts\com\company\assembleegameclient\screens\charrects\BuyCharacterRect.as made variable name declaration and value on same line \scripts\kabam\rotmg\promotions\view\BeginnersPackageOfferDialogMediator.as added beginnerspackageoffermediator open daily login calendar (commented out) \scripts\com\company\assembleegameclient\objects\particles\CircleEffect.as added a color effect in circle particle \scripts\kabam\rotmg\messaging\impl\GameServerConnectionConcrete.as added buy confirmation, goto quest room packet, \scripts\kabam\rotmg\messaging\impl\GameServerConnectionConcrete.as Undocumented ,sowy :(
Originally Posted by Alde.
changes I documented
Code:
\scripts\kabam\rotmg\questrewards\view\QuestRewardsPanel.as changed x position \scripts\kabam\rotmg\chat\view\ChatMediator.as added remove for the chat registrer \scripts\com\company\assembleegameclient\ui\panels\PartyPanel.as changed x, y position \scripts\com\company\assembleegameclient\screens\ScoringBox.as added new dungeons for dungeonscompleted \scripts\com\company\assembleegameclient\parameters\Parameters.as changed build version \scripts\com\company\assembleegameclient\objects\ObjectLibrary.as added 'dailyloginrewards' map data \scripts\com\company\assembleegameclient\map\Map.as added 'Daily Login Room' map data \scripts\WebMain.as added the map in the 'mvcbundle' \scripts\kabam\rotmg\ui\UIConfig.as added 'fetchplayercalendartask' task \scripts\kabam\rotmg\promotions\view\AlreadyPurchasedBeginnersPackageDialog.as added show daily calender popup on beginner package close (note : commented it out) \scripts\kabam\rotmg\packages\view\PackageOfferDialog.as added show daily calender popup on packageoffer close (note : commented it out) \scripts\kabam\rotmg\messaging\impl\GameServerConnection.as Life's a everyday hustle : this is where it gets interesting. They added 3 packets CLAIM_LOGIN_REWARD_MSG:int = 102; LOGIN_REWARD_MSG:int = 103; QUEST_ROOM_MSG:int = 104; \scripts\kabam\rotmg\chat\view\ChatInputNotAllowed.as put variable creation and declaration on the same line \scripts\kabam\rotmg\chat\control\ParseChatMessageCommand.as added dailyloginmodel in parsechatmessagecommands \scripts\kabam\rotmg\account\AccountConfig.as added purchase confirmation for slot configuration \scripts\kabam\rotmg\account\core\BuyCharacterSlotCommand.as added slot purchase confirmation dialog \scripts\kabam\rotmg\packages\view\PackageOfferDialogMediator.as added dailycalendarpopup on package close (note : commented it out) \scripts\kabam\rotmg\packages\view\PackageInfoMediator.as added dailycalendarpopup on packageinfomediator (note : commented it out) \scripts\kabam\rotmg\core\commands\SetScreenWithValidDataCommand.as added fetchplayercalendar task \scripts\com\company\assembleegameclient\util\ColorUtil.as added function 'randomSmart' in ColorUtil \scripts\com\company\assembleegameclient\game\GameSprite.as added if map == nexus, dispatch daily calender popup signal (note : commented it out) \scripts\kabam\rotmg\account\web\commands\WebLoginCommand.as added getmysteryboxestask \scripts\com\company\assembleegameclient\screens\charrects\BuyCharacterRect.as made variable name declaration and value on same line \scripts\kabam\rotmg\promotions\view\BeginnersPackageOfferDialogMediator.as added beginnerspackageoffermediator open daily login calendar (commented out) \scripts\com\company\assembleegameclient\objects\particles\CircleEffect.as added a color effect in circle particle \scripts\kabam\rotmg\messaging\impl\GameServerConnectionConcrete.as added buy confirmation, goto quest room packet, \scripts\kabam\rotmg\messaging\impl\GameServerConnectionConcrete.as Undocumented ,sowy :(
Sweet post, thanks for tracking all this.
Just wanted to throw out a few more things found related to the claimKey.
Thanks to some code in the client, i was able to figure out that when the claimKey has a "-" or "_" in it (which are not valid base64 characters) they actually get replaced with "+" and "/" respectively. So:
ahVzfnJlYWxtb2Z0aGVtYWRnb2RocmRyLwsSB0FjY291bnQYgI DQ-dvXzgsMCxIORGFpbHlMb2dpbkRhdGEYgICAoNDcgQoM
becomes:
ahVzfnJlYWxtb2Z0aGVtYWRnb2RocmRyLwsSB0FjY291bnQYgI DQ+dvXzgsMCxIORGFpbHlMb2dpbkRhdGEYgICAoNDcgQoM
And then you can correctly base64 decode the string to get the correct values.
Another observation: the last 5 bytes will often be the same across accounts when claiming the same reward if claiming within a similar timeframe. I feel the time plays some roll in this value otherwise it would be consistent throughout all claimkeys for rewards of the same day. To understand what i mean by this, you first have to look at the decoded string + hex (as posted earlier). Looking at it again (i used "." for all the really weird characters):
Code:
j . s ~ r e a l m o f t h e m a d g o d h r d r / . . . A c c o u n t . . . . . . . . . . . . . D a i l y L o g i n D a t a . . . . . . . . . . 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 EA AC 87 D6 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 A0 FD 89 0A 0C
I havent been spending as much time looking at the claimKey, mostly because im stuck on those bytes after each string, but hopefully the more data i collect the easier it will become to figure out. If anyone would like, i currently have a file with day 2 - day 8 claimKeys (the decrypted hex value) for about 100 accounts. just ask and ill send it to you if you want to take a look and see if you can figure this out.
Originally Posted by toddddd
i currently have a file with day 2 - day 8 claimKeys (the decrypted hex value) for about 100 accounts. just ask and ill send it to you if you want to take a look and see if you can figure this out.
Originally Posted by toddddd
Sweet post, thanks for tracking all this.
Just wanted to throw out a few more things found related to the claimKey.
Thanks to some code in the client, i was able to figure out that when the claimKey has a "-" or "_" in it (which are not valid base64 characters) they actually get replaced with "+" and "/" respectively. So:
ahVzfnJlYWxtb2Z0aGVtYWRnb2RocmRyLwsSB0FjY291bnQYgI DQ-dvXzgsMCxIORGFpbHlMb2dpbkRhdGEYgICAoNDcgQoM
becomes:
ahVzfnJlYWxtb2Z0aGVtYWRnb2RocmRyLwsSB0FjY291bnQYgI DQ+dvXzgsMCxIORGFpbHlMb2dpbkRhdGEYgICAoNDcgQoM
And then you can correctly base64 decode the string to get the correct values.
Another observation: the last 5 bytes will often be the same across accounts when claiming the same reward if claiming within a similar timeframe. I feel the time plays some roll in this value otherwise it would be consistent throughout all claimkeys for rewards of the same day. To understand what i mean by this, you first have to look at the decoded string + hex (as posted earlier). Looking at it again (i used "." for all the really weird characters):
Each decoded claimKey has 2 (3 i guess) distinct strings, "Account" and "DailyLoginData". If you log the claimKeys between various accounts you will notice that the bytes between Account and DailyLoginData are different, but they remain the same for an account regardless of day. That means that these bytes are somehow related to the account. If you use this same logic, you can then make the conclusion that the bytes after DailyLoginData are related to the reward for the day. This can be backed up when you see the same exact bytes after DailyLoginData across multiple accounts. Although it does change through the day, which is why i believe time plays some roll in the value. The bytes dont contain a raw timestamp, but whatever that value is has to involve time in some way. Both of these areas (the bytes after Account and the bytes after DailyLoginData) dont seem to be just raw values, it is as if the bytes are either encrypted again somehow or they are a combination of values mixed together/structure/something.
I havent been spending as much time looking at the claimKey, mostly because im stuck on those bytes after each string, but hopefully the more data i collect the easier it will become to figure out. If anyone would like, i currently have a file with day 2 - day 8 claimKeys (the decrypted hex value) for about 100 accounts. just ask and ill send it to you if you want to take a look and see if you can figure this out.
Just wanted to throw out a few more things found related to the claimKey.
Thanks to some code in the client, i was able to figure out that when the claimKey has a "-" or "_" in it (which are not valid base64 characters) they actually get replaced with "+" and "/" respectively. So:
ahVzfnJlYWxtb2Z0aGVtYWRnb2RocmRyLwsSB0FjY291bnQYgI DQ-dvXzgsMCxIORGFpbHlMb2dpbkRhdGEYgICAoNDcgQoM
becomes:
ahVzfnJlYWxtb2Z0aGVtYWRnb2RocmRyLwsSB0FjY291bnQYgI DQ+dvXzgsMCxIORGFpbHlMb2dpbkRhdGEYgICAoNDcgQoM
And then you can correctly base64 decode the string to get the correct values.
Another observation: the last 5 bytes will often be the same across accounts when claiming the same reward if claiming within a similar timeframe. I feel the time plays some roll in this value otherwise it would be consistent throughout all claimkeys for rewards of the same day. To understand what i mean by this, you first have to look at the decoded string + hex (as posted earlier). Looking at it again (i used "." for all the really weird characters):
Code:
j . s ~ r e a l m o f t h e m a d g o d h r d r / . . . A c c o u n t . . . . . . . . . . . . . D a i l y L o g i n D a t a . . . . . . . . . . 6A 15 73 7E 72 65 61 6C 6D 6F 66 74 68 65 6D 61 64 67 6F 64 68 72 64 72 2F 0B 12 07 41 63 63 6F 75 6E 74 18 80 80 B0 EA AC 87 D6 0A 0C 0B 12 0E 44 61 69 6C 79 4C 6F 67 69 6E 44 61 74 61 18 80 80 80 80 A0 FD 89 0A 0C
I havent been spending as much time looking at the claimKey, mostly because im stuck on those bytes after each string, but hopefully the more data i collect the easier it will become to figure out. If anyone would like, i currently have a file with day 2 - day 8 claimKeys (the decrypted hex value) for about 100 accounts. just ask and ill send it to you if you want to take a look and see if you can figure this out.
Originally Posted by Kushala Daora
I can try looking into this
Originally Posted by BlackRayquaza
do you have more data?
Here is the fist half of the data. This half is a little less organized, theres a few times its repeated, the layout is "[serverTime]: key". Also, at the start of this data i was having it output both the encrypted string and then the next line was that string decoded and the hex value. This data is from about Day 2 - Day 3 or 4 for various accounts:
http://pastebin.com/jU4x2bUT
This is the rest of the data i have sofar. This data has a little more data and organization. So its laid out like "[serverTime][day]: key". If the key could be decrypted, then it would just output the hex key here. But if the key couldnt be decrypted (because i didnt know about the "-" to "+" and "_" to "/" until a few days ago) then i would just output the encrypted key and move on. So no more having the same key on 2 rows. Although there are a few places where i ran the program twice on the same day so the data might be repeatedin a few places:
http://pastebin.com/VGiGzVVt
I have all this data with the account in the row too so its easier to put keys together...but i dont really want to give that data out to everyone lol. So this is the best i can do for now. Hope this data helps because ive pretty much given up on this haha
Similar Threads
General Game Hacking[W.I.P]BeatIt - brand new Packet Editor.BE 2 General Game Hacking[W.I.P]BeatIt - brand new Packet EditorBE 2 Realm of the Mad God Help & RequestsAnyone know these new packet ids?HA 4 Realm of the Mad God Tutorials & Source CodeNew Packets for Realm RelayCO 6 Realm of the Mad God DiscussionsNew Packets 21.0.0HA 10