renderhjs is correct. It's very easy to sniff all traffic between a Flash client and the server. For instance, you can download and install Ethereal from http://www.ethereal.com/ and have a very powerful packet sniffer for free. We often use it to track down protocol problems. Just tell it to monitor all HTTP traffic and then play the game. It will capture the high score messages no problem. Then you just use a tool (or even a browser) to submit a fake score.

The easiest fix for this problem is to use SSL. It will fully encrypt everything. The SSL session is established with the server PRIOR to the URL being invoked so they wont be able to packet-sniff your message OR URL. There is a reason that SSL is considered secure enough for pretty much anything online

You also said you used encoding for the score. Is it something obvious like XOR or Base64? If so, then you might as well leave it plain text. Any hacker interested in breaking it will have no trouble recognizing those schemes. SSL is your friend here too. You can send it "plain-text" and it's still protected.

-=-

So assuming the problem is NOT packet sniffing then it could be they are doing as you say with a memory tool. A good one that's again free is Art Money. It can be used to search the memory of a running process and find specific data type + value combinations.

For instance, let's say I just played the game and am at the "submit score" screen. I then fire up the tool and search for my score in memory. I find it, then update it's value to a new number and submit the score. It's a little more complicated then that, but not much. The end result is that I just submitted a score I didn't get.

C++ games often combat this by encrypting the score in memory. So they never save a raw number that can be retrieved and modified. Anything important and potentially secure is stored encrypted in different parts in different locations. Then they simply do an update at all locations to create the new score. To make this easier on themselves they use templates and macros to inject this functionality in the code rather then explicitly coding it themselves. This makes it VERY hard for the hacker to just update some variables and go.

Since you are obfuscating and such, you could do a ghetto version of this in Flash. Store the score as two parts in two different variables. Each one of em contains an encrypted string or some such. The string decrypts to a part of the score. You can have an updateScore function (assuming the obfuscator renames methods and such) that retrieves the two variables, decrypts them, combines them and applys the delta before splitting em up and storing em again. You could be clever and store them in different variables every update too (that would help a LOT). Then to add a little misdirection, go ahead and scatter the score all over as normal integer variables. You just don't use them in the end. The hackers will spend forever tracking them down and updating them to no effect.

You will want to send the data to the server encrypted if possible. So the client DOESNT decrypt it to send. Additionally, adding a lot more data into the request helps too. This makes it much harder for the hacker to determine what variables matter and what don't. If they are all encrypted in memory and you update many of them every time the score changes, they will have to tweak em all to make it work.

Additionally, your code on the server should adobt a "no-tolerance" policy for hackers. An invalid score should get their IP address banned from submitting another score for say 20 minutes. So every time they submit a bad score, you can lock them out. This makes it almost impossible to do a real trial-and-error approach.

I know it's a great deal of work but it is possible to make a system in Flash that's hard to hack. You just need to think it through.

P.S. All of this assumes they are attacking the client and not the server. You should be certain your high score system itself is not vulnerable to SQL Injection and other common problems. Lazy PHP coders create more security holes then you can imagine. Sadly, most PHP coders don't even realize they are doing it. That's why PHP has such a bad rap for security.