CheatEngine actually modifies your variables while they’re in memory. That’s why I suggested multiple variables holding the same values, offsetted variables etc. You can also use encrypted variables (base64 or simple xor/NOT/rot-13 encryption would do). CheatEngine won’t do anything with your saved scores, it’ll actually edit them in memory while your game is running, tricking it into thinking that the player actually gained that score by directly editing your variables.
I don’t know of anything that can change data in embedded XMLs really apart from a decompiler. I suppose a determined cheater could download your SWF (or grab it from their temp files), decompile, edit your XML (say, to make the levels really easy), recompile, upload to their own server and play. But for that to work you’d need to be using a centralised leaderboard system which isn’t site-specific (mochi or whatever). The workaround here is probably just to use a ‘sitelocking’ type bit of code to disable high scores on any sites where they’re not expected; eg the big name sites like newgrounds, kong, your primary sponsor site, your own site etc. However, it’s far more likely they’ll just try to use cheat engine to force your score variable to be lots of 9’s, in which case offsetted, mirrored and simply encrypted variables with some MD5 checks would probably ward off 95% of these script kiddies.
Bear in mind that any kind of anti-cheat/encryption is a system of diminishing returns. The more time you spend implementing, the less return of investment you get in terms of stopping hackers. Just doing a simple offset of variable values for important variables will send away 80% of hackers. Encrypting those variables with a simple rot-13 will up that to 90%. MD5 hash checking? 95%. Mirrored variables, base64 and sitelocking stuff? 96%. Hours and hours and hours of complex encryption schemes, hard work, blood, sweat and tears? Maybe 96.5% etc etc