Fill the whole signature #643
Conversation
|
Why remove the option to set data and the default iPhone data to replace it with hardcoded data limited to a single device? Wouldn't this be better as an alternative or fallback? |
|
👎 |
|
Edit, just found them! gonna re-add them back and rework it! Still, DeviceInfos is the unique field it is filling right? SensorInfo still need to be filled? @LoungeKatt agreed for fallback since with this I'm passing an unique ID instead of a random one for each session. |
|
That's the wrong way. You should just find out what Sensor Infos are setted. |
|
Don't destroy the current logic. |
|
there are much better ways to generate the id. |
|
@FabianTerhorst So, Im logging the device infos passed with the library without this commit and they are always null. I assume you are set them on your custom application elsewhere? I can see they are written in the DeviceInfo class, but I can't find any reference to it. They are just always null. In any case, I set a fallback into them if the id im generating fail. "There are much better ways to generate the id." in example? |
|
Api.setDeviceInfo() |
|
DeviceInfo default is using the uuid object. |
|
That's it, so you have to call the setDeviceInfo() in your app (that implement the library)? |
|
You can save the generated device Info in the storage and Reuse it. |
|
Or create it deterministically based on username + other static info |
|
Allright, i tought at it. I was also think in a way to save a random one but since the library doesn't have a context itself im unable to save a random one. We could feed it with a context but im not sure it's good. Also, if you clean install back your app this uuid will change. Isn't better to build it inside the library by giving a seed? |
|
@jabbink good think! i may can access with reflections to other fields like device model! we can build a fake id based on it! (edit, negative.. to much common) |
|
The uuid is a seed. And you can get this back from the builded device Info. |
|
@FabianTerhorst as @jabbink said, maybe we can user the username or some other static fields! |
|
The random object gets the uuid. |
|
@FabianTerhorst i'll try to build it with the username on the system prop |
|
I will look into a way to generate a good seed for the user when I'm back in my laptop in a few hours. |
|
In a few hours i hope to already have it |
|
Im not sure if this fits in the library. There is nothing Bad on a different device on every Start. |
|
Also just mentioning that SensorInfo is never passed on Android. Or at least I have yet to see one on both the devices I am gathering data from |
|
That isn't SensorInfo, thats GPSInfo.... It's different |
|
Oh wait I see it now, I don't get that on my devices |
|
Someone told me that he got some sensorinfos setted in iOS. |
|
i will move to fake the sensor infos once i find a seed to generate an unique id for the device id. In my opinion, this is still wort to do |
|
It's possible to integrate this into an App becuase the device Infos are settable. |
|
@iGio90 Do you have AR enabled? I wonder if it is set when that is enabled maybe? |
|
@FabianTerhorst i dont want them settable. I want them generated :P is that so bad? |
|
There are generated. When you use the defaults. |
|
@iGio90 got it |
|
@Paul776 gonna mitm again now |
|
Ok, explored a bit and looks really good! can you confirm? |
|
{ device_id: 'H3IxFnrBavhlkqScfYUZzL5j5D3B3f0K', "Every iPhone, iPod touch and iPad has a unique identifier number associated with it, known as a UDID (Unique Device ID). Your UDID is a 40-digit sequence of letters and numbers that looks like this: 0e83ff56a12a9cf0c7290cbb08ab6752181fb54b" the one you set is neither 40 and has capital letters |
|
they are not using udid! wait im attaching you the one they are using... @LoungeKatt posted the link this morning |
|
loungekatt [3:04 AM] |
|
mhhhh we are not sending unknown25? |
|
thanks for the link. I don't have the original request (the one sent by the actual game, do you have that somewhere?) https://possiblemobile.com/2013/04/unique-identifiers/ In the Advertiser ID section, the example ID doesn't look like the one you send (it has dashes in it) edit: ok I'm reading that without dashes is also valid but I'm go to sleep in peace if I see that the original request matches the one you attached :D |
|
i got both ios and android dumps! but you should reach me on slack for them :D |
|
aah good. if you have and compared that's cool then! |
|
@Paul776 The link explains it's 36 characters including 4 dashes but the iPhone dumps are returning a 32 character value, implying they parsed out the dashes. It's the only "official" udid iPhone has now that Apple restricted the use of the original udid and removed the call to it after iOS 5. |
|
@LoungeKatt would you mind on telling me why we aren't sending unk25? O.O |
|
@LoungeKatt got it. I just checked the dump and that's fine now |
|
@iGio90 I don't know any more than you about that. There are no secret meetings. |
|
if (select unk25 from users == null) { fuckOff(); } xD |
|
When the signature was first introduced in the API i swear i saw somewhere the setUnknown25 thing must have been removed in one of the cleanup pr? Edit: naaa sorry it was unk22 |
|
nope... it has never been built... and it's static................. |
|
Do we know what it is? |
Here is my way, discussed a lot with the other guys, to fill in the whole signature. Sensor info and Location fixes has randomed (good? feel free to edit) in a good range. Sensor infos are supposed to be faked with the device hold on your hands (just like you are walking in the street and playing). Location fixes is built in a very sick way, but this is the best way i found according to the analysis of all my data. Activity status is pretty simple and for last, but not for last, the device info. I literaly change the whole approach that has been used till now. With this implementation, you will now have to feed the constructor with the unique device id (randomized) that will also be used to feed the whole device info (thanks @FabianTerhorst). This is the best way we found (optional, i leave the default constructor but it's not suggested because it will send an empty device info), since the other possible way (using the username to internally feed the device id) can't be applied due to the very first request (getPlayer) that require the signature, and that will give us the needed username (basically, the first request would have the signature without a device info).