ID:132639
 
http://www.byond.com/games/Kisioj/90seconds
Read the Standings. I did not earn that.
If BYOND has a medal / Score system they should have more security in the system now to prevent simple memory editing.
Also: flying pigs.
Security is owners/programmers matter, BYOND only provides basic functionality, else goes to you.
In response to Ripiz
They added security against packet editing.
Even though it was easy to find what they did for it it still makes it a lot harder for people to randomly go and continue using it against games.
In response to Leur
To encode ANY number, it's size in memory will increase up to 5 times, so instead of 100 MB, it would take like 300MB to host game. It's not really worth, just make own encoding/protection.
In response to Ripiz
Good job making up numbers!

For a more pertinent point, let me point out that both Valve and Blizzard need to use external applications specifically in an attempt to stop cheaters, because you cannot stop somebody from screwing around with their own computer.

You're not going to get a catch-all solution to this.
In response to Garthor
There is one good way.
I saw some anti-cheating demo before, it used to add objects to list, 2 objects - 2 skills points, 7 objects - 7 skill points, and etc.
It's hard to hack that one
In response to Ripiz
I found a way of keeping strings out of the memory awhile back but meh took way to long ascii2text() <- replace ever letter of a sentence with it and it wont show in memory.
In response to Leur
Every bit of data you have in your game is either on the HDD, or the memory of your computer, else your computer could never use it. You're not keeping the string out of memory, you're simply obfuscating and thus adding a low security layer.
In response to Schnitzelnagler
yea, but at least it isn't visible in most memory editors without people having to work, and that will keep out 80% of the people looking to do something simple. The other 20% may try a bit harder. 8)
In response to Leur
Leur wrote:
yea, but at least it isn't visible in most memory editors without people having to work, and that will keep out 80% of the people looking to do something simple. The other 20% may try a bit harder. 8)

In other words, the end result is that people will still cheat and you've just wasted a bunch of effort adding extra security.

What about sending an md5ed value along with anything that sends info to the hub, so if the info doesn't match the hash it is rejected?

Where exactly along the line is the memory being edited?
In response to Foomer
The problem he is referring to are downloadable single player games, which are vulnerable due to being executed on the player's computer.

You can not deliver 100% secure local software.
You can certainly try to annoy the people playing with altering the game, but that's about it. Thus it is advisable to evaluate gain versus effort.
In response to Schnitzelnagler
I think that's essentially what I just said without answering any of my questions.
In response to Foomer
I'm sorry and would like to apologise. I fear I have expressed myself in a bad way.

Foomer wrote:
What about sending an md5ed value along with anything that sends info to the hub (...)
Where exactly along the line is the memory being edited?

They are editing the local memory (e.g. providing themselves with unlimited money/health/whatever) and thus win the game.
Sending an hashed value along would only help with editing the packages, but that is far less often the case with BYOND just now.
In response to Schnitzelnagler
What about game developers using a hashed value for record the value for things which will determine the player's score? You can change your score from 55 to 5000, but if the hashed value is still for 55, when it comes to scoring time it would see that the values have been modified.

Isn't there an article or a thread somewhere on things you can do to minimize cases of memory editing like this?
In response to Foomer
http://www.byond.com/games/Leur/FindThePassword
A simple challenge for everyone to try. There is no prize but try for the fun anyways.
Good luck to those who try it.
Tekken you are not allowed to play since I showed (shown?) you the source for proof there is a password.

Edit: The code does not get hashed. there is no brute forcing required.

Edit2: I just found the password, darn. Hey at least it made it insanely harder to find. xP
Memory editing is difficult to impossible to defend against in an automated manner. There are ways of mitigating it, but basically they require the author to be aware of which values are sensitive and act accordingly. It isn't the kind of thing that BYOND could implement as a native security measure. There are no known non-hacky means of preventing this kind of thing and I would consider none of them reliable; and there is no known foolproof method at all. I'm all for raising the bar, the the only method I understand to be relatively decent also could seriously degrade system performance, and may still not work for some editors.

What this points to instead is that it'd be nice for authors to have a very convenient means of removing bogus scores via the web interface.

Lummox JR
In response to Lummox JR
Would it be possible to have some kind of new variable type, or something to that effect, that would add extra security measures? Then even if it degraded performance, it would only be by a small amount if only a small number of variables use it.
In response to Foomer
Well .dll can be used then, they execute much faster than DM, so it can be used to encrypt and decrypt value. But it's not best solution
In response to Foomer
Foomer wrote:
Would it be possible to have some kind of new variable type, or something to that effect, that would add extra security measures? Then even if it degraded performance, it would only be by a small amount if only a small number of variables use it.

In theory yes, it would be possible to add this to something like user-defined object vars--but it could degrade performance across the board for all object var accesses, at least slightly. I can think of one method that would be relatively low-impact and might be acceptable. The bigger trick would be making sure this could get set up in the compiler, which seems like a steep challenge although not an insurmountable one.

However I should point out that the data that's safe from editing via this method would be very limited. Specifically it would interfere with editing numbers, but not so much with strings.

Lummox JR