Crappy quick PA client hack

[Ramihyn]

http://pirate.planetarion.com/showpo...22&postcount=4

Might be of interest for some here. Its only a proof of concept but shows how a rather simple language like PureBasic can do more serious stuff with a rather very small executable footprint and on the top of it all, its a PA stand alone windows client

I am a utter n00b on windows programming and only tinker with purebasic since a few days so be very afraid about the sourcecode

[Androme]

I remember the good old days of simply adding some variables (basically username and password) to the login URL and it would log you in... was handy when you were woken up with "INCOMING" messages while asleep and needed to quickly login regardless of your low concentration levels :|

Is this not the case anymore?

Btw, I don't know anything about PureBasic but I have sufficient knowledge in DarkBasic and VisualBasic if that helps.

[Ramihyn]

Originally Posted by Androme2

I remember the good old days of simply adding some variables (basically username and password) to the login URL and it would log you in... was handy when you were woken up with "INCOMING" messages while asleep and needed to quickly login regardless of your low concentration levels :|

Is this not the case anymore?

I dont know it that would still be possible but you would have to answer the bot-stopper question anyway. With a little client like this it would be 5 minutes of work anyway to make it login automatically(*) but things like that are topics where some people would yell "cheater" and others would raise issues that the client may steal logins/passwords

(*) - without going around the botstopper question

ps: the botstopper question rendering was changed as i noticed, but it is still as easy as before to get the question from the grafik. Most of the distortion elements have absolutely zero effect on the detection, only one new distortion breaks my old detection and that one would also be easy to adjust.

[Androme]

Seems a shame that there just can't be an automatic login ie: like I have with all my forum accounts & e-mails (a la sessions & cookies etc.).

[queball]

Apart from the that sourcecode would be restricted and that disassembly would be difficult, what's to stop anyone just bypassing the client and sending the URLs with machine check ID? How can MachineID ever prove that it hasn't been tampered with? (without digital rights management).

[Phil^]

embedding a timestamp retrieved from a random ntp server?

[Ramihyn]

Originally Posted by Phil^

embedding a timestamp retrieved from a random ntp server?

Preferable sync the timestamp with the webserver so a little script can check if the MachineID timestamp and the server log entry time roughly match. Would be elegant to sync the timestamp seamlessly through the HTTP headers DATE field

ps: from doing a little manual test a moment ago, it wouldnt only be "elegant" but it would be necessary as your webservers clock is way off

[queball]

Originally Posted by Phil^

embedding a timestamp retrieved from a random ntp server?

Nothing stops me doing this myself.

[Ramihyn]

Originally Posted by queball

Nothing stops me doing this myself.

Only if you break/imitate the algo which creates the MachineID by debugging it.

For example to create a MachineID i would do the following:

- create a empty buffer of for example 512 bytes length
- collect all machine dependant info you can get into a reserved area of the buffer, if a field doesnt exist on a specific configuration (like a serial number of the OS), just keep it empty
- add a continuously changing value like a timestamp or a serial counter
- use a hashing algorithm like MD5 or SHA-1 to create a unique checksum across the buffer. Use a algo which has a initiation vector or where a specific step works with a transformation table. You manipulate the initiation vector or one of the transformation tables slightly so the algorithm is incompatible to the original algo. If you are really mean, you arent using a static initialisation vector change but a dynamic one but this can be tricky so you dont break the algo.

For verification reasons you may need to make two hashes. For example you build a second buffer including (part of) the hash of the first buffer, add the timer or serial number and build a second hash across this buffer. Now the MachineID you transfer consists of (part of) the hash of the second buffer plus (every part of) the first hash which was used to build the second hash. This way no concrete data of the machine is actually transfered, the MachineID changes everytime (avalanche effect of the hashing algo across the serial number/timer value), the generated ID can be checked to be consistent to your rules.

There are easier ways to do all this like using a init-field to a custom random generator, XOR the result with the transfered data, include a hash across part of the data and inject the init-field into the transfered MachineID, but they can be much easier broken. Then again this isnt the GOST challenge

Anyhow - what we need here is "a little less talk and a lot more action" (i just love that song phrase

ps: hope it makes sense - i can hardly concentrate because of headache :/

[kaos]

and what prevents me from generating the first hash fully random (which is actually what it is, kindof), and generate the second hash from the first one so it can be verified by the server ?

[Ramihyn]

Originally Posted by kaos

and what prevents me from generating the first hash fully random (which is actually what it is, kindof), and generate the second hash from the first one so it can be verified by the server ?

I dont know under which assumption you ask this question.

If you know how to do the hashes and how they compose the MachineID, you can freely fake both of them.

If you dont know how to do the hashes but did break into the pa client to use its code to generate a valid MachineID with a fake first hash, you also did beat this system.

There are ways how to avoid the debugging/hacking problem (apart from anti-debugging code), but for different reasons i dont want to go into that here.

[Heartless]

The system is still flawed.

How does PA actually know it is a valid ID? And does PA know it is used by one person only?

If we hash the ID with SHA-1 (or any other hashing algorithm) we'd be unable to reproduce the original ID and thus we are unable to validate it - except by brutforce which is bloody unlikely to happen.

And still, what if I setup the client on 5 local machines? Assuming we would get an unique ID we'd still be unable to know if it is 5 different people playing or only one.

[Phil^]

by having a log of all ids in a db serverside, generated by the first login of the client. all subsequent ones use the hashing on both sides to verify?

[Heartless]

Originally Posted by Phil^

by having a log of all ids in a db serverside, generated by the first login of the client. all subsequent ones use the hashing on both sides to verify?

So the game is still unable to tell if there is one person running the software for multiplate accounts or not.

[Ramihyn]

Originally Posted by Heartless

How does PA actually know it is a valid ID?

As i mentioned earlier:

Originally Posted by Ramihyn

For verification reasons you may need to make two hashes. For example you build a second buffer including (part of) the hash of the first buffer, add the timer or serial number and build a second hash across this buffer. Now the MachineID you transfer consists of (part of) the hash of the second buffer plus (every part of) the first hash which was used to build the second hash.

You simply redo the second hash serverside and verify if it matches the transfered part of the MachineID.

Originally Posted by Heartless

And does PA know it is used by one person only?

I'm not sure what you mean exactly. If everything works as expected, this ID can increase the identification of a planet by a specific hardware/software dependant ID. It is a matter of the MHs how to interprete the log entries with IP and MachineID to their rules.

For example it could be found out that different planets from different IPs (but same ISP for example) are controlled by the same computer/installation at different times. Something you dont even notice now and it would be up to the MHs how to use this knowledge.

Originally Posted by Heartless

And still, what if I setup the client on 5 local machines? Assuming we would get an unique ID we'd still be unable to know if it is 5 different people playing or only one.

Thats true. If you have two computers in a room behind a router running on the "same" IP (to the internet) this client and the MachineID wouldnt help finding out how many people are in the room and if different of them control the two machines.

My suggestion didnt ever claim to make multiing impossible - in fact it was originally meant not to catch more multis but to avoid innocent users beeing flagged as multis and therefore beeing closed - as some people on these boards have claimed is happening. Right now you can happily control a dozen planets on the same computer at the same time and it doesnt take that much work. If something like this client and the MachineID would be mandatory, this would become way more difficult - but thats not what the original suggestion was about.

[Methedrine]

Originally Posted by Ramihyn

As i mentioned earlier:

You simply redo the second hash serverside and verify if it matches the transfered part of the MachineID.

I'm not sure what you mean exactly. If everything works as expected, this ID can increase the identification of a planet by a specific hardware/software dependant ID. It is a matter of the MHs how to interprete the log entries with IP and MachineID to their rules.

How does the PA Server want to validate a MachineID which is dependant upon the users hardware/software without actually submitting this information?
Yes, you can go with your secondary hash but that would, for someone with the intention to abuse this program for 'legal' (non-detectable) multiing, just mean he'd have to trace those two hashes and can then use them "fixed". However, it might not be entirely impossible to implement.

Originally Posted by Ramihyn

As i mentioned earlier:
For example it could be found out that different planets from different IPs (but same ISP for example) are controlled by the same computer/installation at different times. Something you dont even notice now and it would be up to the MHs how to use this knowledge.

Actually the client won't be able to deliver more information on this issue than it can be gathered now already: IP will be logged anyways and can thus be traced to the ISP. And, due to the nature of dynamic-ip's, every planet will be accessed by different IP's at different times. That IS already noticed now, it's just nothing you can use for multi-hunting purposes.

Originally Posted by Ramihyn

As i mentioned earlier:
Thats true. If you have two computers in a room behind a router running on the "same" IP (to the internet) this client and the MachineID wouldnt help finding out how many people are in the room and if different of them control the two machines.

My suggestion didnt ever claim to make multiing impossible - in fact it was originally meant not to catch more multis but to avoid innocent users beeing flagged as multis and therefore beeing closed - as some people on these boards have claimed is happening. Right now you can happily control a dozen planets on the same computer at the same time and it doesnt take that much work. If something like this client and the MachineID would be mandatory, this would become way more difficult - but thats not what the original suggestion was about.

Long story short: Your program would allow those people, which want to multi, to multi easier.

[Ramihyn]

It is really becoming rather silly by now, but on we go...

Originally Posted by Methedrine

How does the PA Server want to validate a MachineID which is dependant upon the users hardware/software without actually submitting this information?
Yes, you can go with your secondary hash but that would, for someone with the intention to abuse this program for 'legal' (non-detectable) multiing, just mean he'd have to trace those two hashes and can then use them "fixed". However, it might not be entirely impossible to implement.

a) no you CANT sniff or "trace" two hashes and then happily reuse them "fixed". The answer why that doesnt work is in this thread already.

b) What you call "might not be entirely impossible to implement" is a matter of 5 minutes if you have the hashing function and simply go with doing what i described in this thread.

Originally Posted by Methedrine

Actually the client won't be able to deliver more information on this issue than it can be gathered now already: IP will be logged anyways and can thus be traced to the ISP. And, due to the nature of dynamic-ip's, every planet will be accessed by different IP's at different times. That IS already noticed now, it's just nothing you can use for multi-hunting purposes.

If that paragraph refers to the specific "issue" i wrote and which you cited, then you just affirmed what i said regarding an example about what this MachineID IS NOT made for. What the intention of the client and the MachineID is and the limitations have been listed repeatedly in the original suggestion thread and in here.

If you want to do a serious discussion about in which cases the MachineID additionally helps spotting cheaters, then you should do that in the thread in the suggestion forum and probably with the MHs (if they even remotely consider this). Kloopy made his own "derived" suggestion and i could think of at least another useful different one.

Originally Posted by Methedrine

Long story short: Your program would allow those people, which want to multi, to multi easier.

On a pure philosophical approach that statement is discussable but on a technical/practical view it is complete and utter bullsh*t.

On a philosophical view on any additional security mechanism you could indeed argue that the more secure and tamper-resistant a security measure is, the more safety it gives to a cheater who manages to break the system. Simply because people trust the system much more. However you are completely ignoring the increasing difficulty to break a system.

The information value of the MachineID has way more meaning then any "IP" you get and even without much knowledge of the internet, that should be pretty obvious by now. Plus it is an additional measure coming into play if several IPs are indeed the same.