Cách tốt nhất để ngăn chặn mọi người hack bảng điểm cao dựa trên PHP của trò chơi Flash là gì

Tôi đang nói về một trò chơi hành động không có giới hạn điểm cao hơn và không có cách nào để xác minh điểm số trên máy chủ bằng cách phát lại các động tác, v.v.

Điều tôi thực sự cần là mã hóa mạnh nhất có thể có trong Flash / PHP và là cách để ngăn mọi người gọi trang PHP khác ngoài thông qua tệp Flash của tôi. Tôi đã thử một số phương pháp đơn giản trong quá khứ để thực hiện nhiều cuộc gọi cho một điểm số duy nhất và hoàn thành chuỗi tổng kiểm tra / chuỗi, v.v., và cũng làm xáo trộn SWF với Amayeta SWF Encrypt, nhưng cuối cùng chúng đều bị hack.

Nhờ các phản hồi của StackOverflow, giờ đây tôi đã tìm thấy thêm một số thông tin từ Adobe - http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_12.html và https://github.com/mikechambers/as3corelib - mà tôi nghĩ rằng tôi có thể sử dụng để mã hóa. Không chắc chắn điều này sẽ đưa tôi xung quanh CheatEngine mặc dù.

Tôi cần biết các giải pháp tốt nhất cho cả AS2 và AS3, nếu chúng khác nhau.

Các vấn đề chính dường như là những thứ như tiêu đề TamperData và LiveHTTP, nhưng tôi hiểu có nhiều công cụ hack tiên tiến hơn - như CheatEngine (cảm ơn Mark Webster)

Đây là một vấn đề kinh điển với các trò chơi và cuộc thi trên Internet. Mã Flash của bạn hoạt động với người dùng để quyết định điểm cho trò chơi. Nhưng người dùng không tin cậy và mã Flash chạy trên máy tính của người dùng. Bạn là SOL. Bạn không thể làm gì để ngăn kẻ tấn công giả mạo điểm số cao:

• Flash thậm chí còn dễ dàng hơn để thiết kế đảo ngược so với bạn nghĩ, vì các mã byte được ghi lại tốt và mô tả một ngôn ngữ cấp cao (Actioncript) --- khi bạn xuất bản một trò chơi Flash, bạn sẽ xuất bản mã nguồn của mình, cho dù bạn biết hay không

• Kẻ tấn công kiểm soát bộ nhớ thời gian chạy của trình thông dịch Flash, để bất kỳ ai biết cách sử dụng trình gỡ lỗi lập trình đều có thể thay đổi bất kỳ biến nào (bao gồm cả điểm hiện tại) bất cứ lúc nào hoặc thay đổi chính chương trình.

Cuộc tấn công đơn giản nhất có thể đối với hệ thống của bạn là chạy lưu lượng HTTP cho trò chơi thông qua proxy, bắt lưu điểm số cao và phát lại với điểm số cao hơn.

Bạn có thể cố gắng chặn cuộc tấn công này bằng cách ràng buộc mỗi lần lưu điểm cao vào một phiên bản duy nhất của trò chơi bằng cách gửi mã thông báo được mã hóa đến máy khách khi khởi động trò chơi, có thể giống như:

hex-encoding( AES(secret-key-stored-only-on-server, timestamp, user-id, random-number))

(Bạn cũng có thể sử dụng cookie phiên để có hiệu lực tương tự).

Mã trò chơi lặp lại mã thông báo này trở lại máy chủ với mức lưu điểm cao. Nhưng kẻ tấn công vẫn có thể khởi động lại trò chơi, nhận mã thông báo và sau đó dán ngay mã thông báo đó vào bản lưu điểm số cao được phát lại.

Vì vậy, tiếp theo bạn cung cấp không chỉ mã thông báo hoặc cookie phiên, mà còn là khóa phiên mã hóa điểm cao. Đây sẽ là khóa AES 128 bit, được mã hóa bằng khóa được mã hóa cứng trong trò chơi Flash:

hex-encoding( AES(key-hardcoded-in-flash-game, random-128-bit-key))

Bây giờ trước khi trò chơi đăng điểm cao, nó sẽ giải mã khóa phiên mã hóa điểm cao, điều này có thể làm được vì bạn đã mã hóa khóa mã hóa điểm cao-khóa-giải mã-khóa-mã hóa thành khóa nhị phân Flash. Bạn mã hóa điểm số cao bằng khóa được giải mã này, cùng với hàm băm SHA1 của điểm số cao:

hex-encoding( AES(random-128-bit-key-from-above, high-score, SHA1(high-score)))

Mã PHP trên máy chủ kiểm tra mã thông báo để đảm bảo yêu cầu đến từ một phiên bản trò chơi hợp lệ, sau đó giải mã điểm cao được mã hóa, kiểm tra để đảm bảo điểm cao phù hợp với SHA1 của điểm cao (nếu bạn bỏ qua bước này , giải mã đơn giản sẽ tạo ra ngẫu nhiên, có khả năng rất cao, điểm số cao).

Vì vậy, bây giờ kẻ tấn công dịch ngược mã Flash của bạn và nhanh chóng tìm thấy mã AES, nó giống như ngón tay cái đau, mặc dù ngay cả khi nó không bị theo dõi trong 15 phút với tìm kiếm bộ nhớ và theo dõi ("Tôi biết Điểm của tôi cho trò chơi này là 666, vì vậy, hãy tìm 666 trong bộ nhớ, sau đó bắt bất kỳ thao tác nào chạm vào giá trị đó --- ồ nhìn kìa, mã hóa điểm số cao! "). Với khóa phiên, kẻ tấn công thậm chí không phải chạy mã Flash; cô ấy lấy mã thông báo khởi động trò chơi và khóa phiên và có thể gửi lại điểm cao tùy ý.

Bây giờ bạn đang ở thời điểm mà hầu hết các nhà phát triển chỉ từ bỏ --- cho hoặc mất một vài tháng để gây rối với những kẻ tấn công bằng cách:

• Xáo trộn các phím AES với các thao tác XOR

• Thay thế các mảng byte chính bằng các hàm tính toán khóa

• Phân tán mã hóa khóa giả và bài đăng điểm cao trong toàn bộ nhị phân.

Tất cả điều này chủ yếu là một sự lãng phí thời gian. Không cần phải nói, SSL cũng sẽ không giúp bạn; SSL không thể bảo vệ bạn khi một trong hai điểm cuối SSL là xấu.

Dưới đây là một số điều thực sự có thể làm giảm gian lận điểm cao:

• Yêu cầu đăng nhập để chơi trò chơi, đăng nhập sẽ tạo cookie phiên và không cho phép nhiều lần khởi chạy trò chơi nổi bật trên cùng một phiên hoặc nhiều phiên đồng thời cho cùng một người dùng.

• Từ chối điểm số cao từ các phiên trò chơi kéo dài ít hơn các trò chơi thực tế ngắn nhất từng chơi (đối với cách tiếp cận tinh vi hơn, hãy thử "cách ly" điểm số cao đối với các phiên trò chơi kéo dài dưới 2 độ lệch chuẩn dưới thời lượng trò chơi trung bình). Hãy chắc chắn rằng bạn đang theo dõi thời lượng máy chủ trò chơi.

• Từ chối hoặc cách ly điểm số cao khỏi các thông tin đăng nhập chỉ chơi trò chơi một hoặc hai lần, để kẻ tấn công phải tạo ra một "vệt giấy" chơi trò chơi tìm kiếm hợp lý cho mỗi lần đăng nhập mà chúng tạo.

• Điểm số "Heartbeat" trong khi chơi trò chơi, để máy chủ của bạn nhìn thấy sự tăng trưởng điểm số trong suốt thời gian chơi một trò chơi. Từ chối điểm số cao không tuân theo các đường cong điểm số hợp lý (ví dụ: nhảy từ 0 đến 999999).

• Trạng thái trò chơi "Ảnh chụp nhanh" trong khi chơi trò chơi (ví dụ: số lượng đạn dược, vị trí trong cấp độ, v.v.), mà sau đó bạn có thể điều hòa với điểm số tạm thời được ghi lại. Bạn thậm chí không phải có cách để phát hiện sự bất thường trong dữ liệu này để bắt đầu; bạn chỉ cần thu thập nó, và sau đó bạn có thể quay lại và phân tích nó nếu mọi thứ trông có vẻ tanh.

• Vô hiệu hóa tài khoản của bất kỳ người dùng nào không thực hiện một trong các kiểm tra bảo mật của bạn (ví dụ: bằng cách gửi điểm cao được mã hóa mà không xác thực).

Tuy nhiên, hãy nhớ rằng bạn chỉ ngăn chặn gian lận điểm cao ở đây. Có gì bạn có thể làm để ngăn chặn nếu. Nếu có tiền trong trò chơi của bạn, ai đó sẽ đánh bại bất kỳ hệ thống nào bạn nghĩ ra. Mục tiêu không phải là để ngăn chặn cuộc tấn công này; đó là để làm cho cuộc tấn công trở nên đắt đỏ hơn là chỉ thực sự giỏi trò chơi và đánh bại nó.

Bạn có thể đang hỏi sai câu hỏi. Bạn dường như tập trung vào các phương pháp mà mọi người đang sử dụng để chơi trò chơi theo cách của họ lên danh sách điểm cao, nhưng việc chặn các phương thức cụ thể chỉ đi xa đến vậy. Tôi không có kinh nghiệm với TamperData, vì vậy tôi không thể nói điều đó.

Câu hỏi bạn nên đặt ra là: "Làm thế nào tôi có thể xác minh rằng điểm số đã gửi là hợp lệ và xác thực?" Cách cụ thể để làm điều đó là phụ thuộc vào trò chơi. Đối với các trò chơi giải đố rất đơn giản, bạn có thể gửi điểm số cùng với trạng thái bắt đầu cụ thể và chuỗi các bước di chuyển dẫn đến trạng thái kết thúc, sau đó chạy lại trò chơi ở phía máy chủ bằng cách sử dụng các bước tương tự. Xác nhận rằng điểm số đã nêu giống với điểm được tính và chỉ chấp nhận điểm nếu chúng khớp.

Một cách dễ dàng để làm điều này là cung cấp hàm băm mật mã cho giá trị điểm cao của bạn cùng với điểm số mà nó tự tạo ra. Ví dụ: khi đăng kết quả qua HTTP GET: http://example.com/highscores.php?score=500&checksum=0a16df3dc0301a36a34f9065c3ff8095

Khi tính toán tổng kiểm tra này, nên sử dụng một bí mật chung; bí mật này không bao giờ được truyền qua mạng, nhưng phải được mã hóa cứng trong cả phụ trợ PHP và giao diện flash. Tổng kiểm tra ở trên được tạo bằng cách thêm chuỗi " bí mật " vào điểm " 500 " và chạy qua md5sum.

Mặc dù hệ thống này sẽ ngăn người dùng đăng các điểm tùy ý, nhưng nó không ngăn được "tấn công phát lại", trong đó người dùng đăng lại kết hợp băm và điểm được tính toán trước đó. Trong ví dụ trên, điểm 500 sẽ luôn tạo ra chuỗi băm giống nhau. Một số rủi ro này có thể được giảm thiểu bằng cách kết hợp thêm thông tin (như tên người dùng, dấu thời gian hoặc địa chỉ IP) trong chuỗi cần băm. Mặc dù điều này sẽ không ngăn chặn việc phát lại dữ liệu, nhưng nó sẽ đảm bảo rằng một bộ dữ liệu chỉ có giá trị cho một người dùng tại một thời điểm.

Để ngăn chặn bất kỳ cuộc tấn công phát lại nào xảy ra, một số loại hệ thống phản ứng thách thức sẽ phải được tạo, chẳng hạn như sau:

1. Trò chơi flash ("ứng dụng khách") thực hiện HTTP GET của http://example.com/highscores.php không có tham số. Trang này trả về hai giá trị: giá trị muối được tạo ngẫu nhiên và hàm băm mật mã của giá trị muối đó kết hợp với bí mật được chia sẻ. Giá trị muối này phải được lưu trữ trong cơ sở dữ liệu cục bộ của các truy vấn đang chờ xử lý và phải có dấu thời gian được liên kết với nó để có thể "hết hạn" sau một phút.
2. Trò chơi flash kết hợp giá trị muối với bí mật được chia sẻ và tính toán một hàm băm để xác minh rằng giá trị này khớp với giá trị được cung cấp bởi máy chủ. Bước này là cần thiết để ngăn chặn giả mạo giá trị muối của người dùng, vì nó xác minh rằng giá trị muối thực sự được tạo bởi máy chủ.
3. Trò chơi flash kết hợp giá trị muối với bí mật chung, giá trị điểm cao và bất kỳ thông tin liên quan nào khác (biệt danh, ip, dấu thời gian) và tính toán một hàm băm. Sau đó, nó sẽ gửi thông tin này trở lại phần phụ trợ PHP thông qua HTTP GET hoặc POST, cùng với giá trị muối, điểm cao và các thông tin khác.
4. Máy chủ kết hợp thông tin nhận được theo cách tương tự như trên máy khách và tính toán một hàm băm để xác minh rằng thông tin này khớp với thông tin do khách hàng cung cấp. Sau đó, nó cũng xác minh rằng giá trị muối vẫn còn hiệu lực như được liệt kê trong danh sách truy vấn đang chờ xử lý. Nếu cả hai điều kiện này đều đúng, nó ghi điểm cao vào bảng điểm cao và trả về thông báo "thành công" đã ký cho khách hàng. Nó cũng loại bỏ giá trị muối khỏi danh sách truy vấn đang chờ xử lý.

Xin lưu ý rằng bảo mật của bất kỳ kỹ thuật nào ở trên đều bị xâm phạm nếu bí mật được chia sẻ cho người dùng có thể truy cập được

Thay vào đó, có thể tránh một số lỗi qua lại này bằng cách buộc khách hàng liên lạc với máy chủ qua HTTPS và bảo đảm rằng khách hàng được cấu hình sẵn để chỉ tin tưởng các chứng chỉ được ký bởi cơ quan cấp chứng chỉ cụ thể mà bạn chỉ có quyền truy cập .

Tôi thích những gì tpqf nói, nhưng thay vì vô hiệu hóa tài khoản khi phát hiện gian lận, hãy triển khai honeypot để bất cứ khi nào họ đăng nhập, họ sẽ thấy điểm bị hack của họ và không bao giờ nghi ngờ rằng họ đã bị đánh dấu là một kẻ troll. Google cho "phpBB MOD Troll" và bạn sẽ thấy một cách tiếp cận khéo léo.

Trong câu trả lời được chấp nhận, tqbf đề cập rằng bạn chỉ có thể thực hiện tìm kiếm bộ nhớ cho biến số điểm ("Điểm của tôi là 666 vì vậy tôi tìm số 666 trong bộ nhớ").

Có một cách xung quanh này. Tôi có một lớp học ở đây: http://divillysausages.com/blog/safenumber_and_safeint

Về cơ bản, bạn có một đối tượng để lưu trữ điểm số của bạn. Trong setter, nó nhân giá trị mà bạn truyền cho nó với một số ngẫu nhiên (+ và -) và trong getter, bạn chia giá trị đã lưu cho bộ nhân ngẫu nhiên để lấy lại giá trị ban đầu. Nó đơn giản, nhưng giúp ngừng tìm kiếm bộ nhớ.

Ngoài ra, hãy xem video từ một số kẻ đứng sau công cụ PushButton, người nói về một số cách khác nhau mà bạn có thể chống hack: http://zaa.tv/2010/12/the-art-of-hacking-flash- trò chơi / . Họ là nguồn cảm hứng đằng sau lớp học.

Tôi đã thực hiện một cách giải quyết ... Tôi đã đưa ra điểm số tăng dần (bạn luôn nhận được điểm +1). Đầu tiên, tôi bắt đầu đếm từ số ngẫu nhiên (giả sử là 14) và khi tôi hiển thị điểm số, chỉ hiển thị điểm var trừ 14. Điều này là như vậy nếu các cracker đang tìm kiếm ví dụ cho 20, họ sẽ không tìm thấy nó (nó sẽ là 34 trong bộ nhớ). Thứ hai, vì tôi biết điểm tiếp theo nên là gì ... Tôi đã sử dụng thư viện tiền điện tử adobe, để tạo ra hàm băm của điểm tiếp theo nên là gì. Khi tôi phải tăng điểm, tôi kiểm tra xem băm của điểm tăng có bằng băm không. Nếu cracker đã thay đổi các điểm trong bộ nhớ, thì băm không bằng nhau. Tôi thực hiện một số xác minh phía máy chủ và khi tôi nhận được các điểm khác nhau từ trò chơi và từ PHP, tôi biết rằng gian lận có liên quan. Đây là đoạn mã khi mã của tôi (Tôi đang sử dụng lớp MD5 Adobe Crypto libraty và muối mật mã ngẫu nhiên. CallPhp () là xác thực phía máy chủ của tôi)

private function addPoint(event:Event = null):void{
            trace("expectedHash: " + expectedHash + "  || new hash: " + MD5.hash( Number(SCORES + POINT).toString() + expectedHashSalt) );
            if(expectedHash == MD5.hash( Number(SCORES + POINT).toString() + expectedHashSalt)){
                SCORES +=POINT;
                callPhp();
                expectedHash = MD5.hash( Number(SCORES + POINT).toString() + expectedHashSalt);
            } else {
                //trace("cheat engine usage");
            }
        }

Sử dụng kỹ thuật này + SWF obfustication, tôi đã có thể ngăn chặn các cracker. Ngoài ra, khi tôi gửi điểm đến phía máy chủ, tôi sử dụng chức năng mã hóa / giải mã nhỏ của riêng mình. Một cái gì đó như thế này (không bao gồm mã phía máy chủ, nhưng bạn có thể xem thuật toán và viết nó bằng PHP):

package  {

    import bassta.utils.Hash;

    public class ScoresEncoder {

        private static var ranChars:Array;
        private static var charsTable:Hash;

        public function ScoresEncoder() {

        }

        public static function init():void{

            ranChars = String("qwertyuiopasdfghjklzxcvbnm").split("")

            charsTable = new Hash({
                "0": "x",
                "1": "f",
                "2": "q",
                "3": "z",
                "4": "a",
                "5": "o",
                "6": "n",
                "7": "p",
                "8": "w",
                "9": "y"

            });

        }

        public static function encodeScore(_s:Number):String{

            var _fin:String = "";

            var scores:String = addLeadingZeros(_s);
            for(var i:uint = 0; i< scores.length; i++){
                //trace( scores.charAt(i) + " - > " + charsTable[ scores.charAt(i) ] );
                _fin += charsTable[ scores.charAt(i) ];
            }

            return _fin;

        }

        public static function decodeScore(_s:String):String{

            var _fin:String = "";

            var decoded:String = _s;

            for(var i:uint = 0; i< decoded.length; i++){
                //trace( decoded.charAt(i) + " - > "  + charsTable.getKey( decoded.charAt(i) ) );
                _fin += charsTable.getKey( decoded.charAt(i) );
            }

            return _fin;

        }

        public static function encodeScoreRand(_s:Number):String{
            var _fin:String = "";

            _fin += generateRandomChars(10) + encodeScore(_s) + generateRandomChars(3)

            return _fin;
        }

        public static function decodeScoreRand(_s:String):Number{

            var decodedString:String = _s;
            var decoded:Number;

            decodedString = decodedString.substring(10,13);         
            decodedString = decodeScore(decodedString);

            decoded = Number(decodedString);

            return decoded;
        }

        public static function generateRandomChars(_length:Number):String{

            var newRandChars:String = "";

            for(var i:uint = 0; i< _length; i++){
                newRandChars+= ranChars[ Math.ceil( Math.random()*ranChars.length-1 )];
            }

            return newRandChars;
        }

        private static function addLeadingZeros(_s:Number):String{

            var _fin:String;

            if(_s < 10 ){
                 _fin = "00" + _s.toString();
            }

            if(_s >= 10 && _s < 99 ) {
                 _fin = "0" + _s.toString();
            }

            if(_s >= 100 ) {
                _fin = _s.toString();
            }           

            return _fin;
        }


    }//end
}

Sau đó, tôi gửi biến số cùng với các vars giả khác và nó bị lạc giữa chừng ... Đó là rất nhiều công việc chỉ dành cho trò chơi flash nhỏ, nhưng khi giải thưởng có liên quan đến một số người chỉ tham lam. Nếu bạn cần bất kỳ sự giúp đỡ, viết cho tôi một PM.

Chúc mừng, Ico

Mã hóa bằng khóa đảo ngược đã biết (riêng tư) sẽ là phương pháp đơn giản nhất. Tôi không hoàn toàn tin vào AS nên tôi không chắc có những nhà cung cấp mã hóa nào.

Nhưng bạn có thể bao gồm các biến như độ dài trò chơi (được mã hóa, một lần nữa) và số lần nhấp.

Tất cả những thứ như thế này có thể được thiết kế ngược lại, vì vậy hãy xem xét việc ném vào một loạt các dữ liệu rác để loại bỏ mọi người.

Chỉnh sửa: Nó cũng có thể có giá trị trong một số phiên PHP. Bắt đầu phiên khi họ nhấp vào bắt đầu trò chơi và (như nhận xét cho bài đăng này nói) ghi lại thời gian. Khi họ gửi điểm số, bạn có thể kiểm tra xem họ thực sự đã có một trò chơi mở và họ sẽ không gửi điểm quá sớm hoặc quá lớn.

Có thể đáng để tìm ra một vô hướng để xem điểm số tối đa trên mỗi giây / phút chơi là bao nhiêu.

Cả hai điều này đều không thể kiểm soát được nhưng sẽ giúp có một số logic không có trong Flash nơi mọi người có thể nhìn thấy nó.

Theo kinh nghiệm của tôi, điều này được tiếp cận tốt nhất như là một vấn đề kỹ thuật xã hội hơn là một vấn đề lập trình. Thay vì tập trung vào việc làm cho nó không thể gian lận, hãy tập trung vào việc làm cho nó trở nên nhàm chán bằng cách loại bỏ các ưu đãi để gian lận. Ví dụ: nếu ưu đãi chính được hiển thị công khai điểm cao, chỉ cần đặt độ trễ khi hiển thị điểm cao có thể giảm đáng kể gian lận bằng cách xóa vòng phản hồi tích cực cho người gian lận.

Bạn không thể tin tưởng bất kỳ dữ liệu nào khách hàng trả về. Xác nhận cần phải được thực hiện ở phía máy chủ. Tôi không phải là nhà phát triển trò chơi, nhưng tôi làm phần mềm kinh doanh. Trong cả hai trường hợp, tiền có thể được tham gia và mọi người sẽ phá vỡ các kỹ thuật che giấu phía khách hàng.

Có thể gửi dữ liệu trở lại máy chủ định kỳ và thực hiện một số xác nhận. Đừng tập trung vào mã máy khách, ngay cả khi đó là nơi ứng dụng của bạn sống.

Bất cứ khi nào hệ thống điểm cao của bạn dựa trên thực tế là ứng dụng Flash sẽ gửi dữ liệu điểm cao không dấu / không dấu qua mạng, có thể bị chặn và thao tác / phát lại. Câu trả lời xuất phát từ đó: mã hóa (decently!) Hoặc ký mã hóa dữ liệu điểm cao. Điều này, ít nhất, khiến mọi người khó bẻ khóa hệ thống điểm cao của bạn hơn vì họ sẽ cần trích xuất khóa bí mật từ tệp SWF của bạn. Nhiều người có thể sẽ bỏ cuộc ngay tại đó. Mặt khác, tất cả chỉ cần một người độc thân trích xuất chìa khóa và gửi nó ở đâu đó.

Các giải pháp thực tế liên quan đến giao tiếp nhiều hơn giữa ứng dụng Flash và cơ sở dữ liệu điểm cao để người sau có thể xác minh rằng một số điểm nhất định có phần thực tế. Điều này có thể phức tạp tùy thuộc vào loại trò chơi bạn đã có.

Không có cách nào để làm cho nó hoàn toàn không bị tấn công, vì nó dễ dàng dịch ngược SWF và một hacker phát triển lành nghề sau đó có thể theo dõi mã của bạn và tìm ra cách vượt qua bất kỳ hệ thống mã hóa nào bạn có thể sử dụng.

Nếu bạn chỉ đơn giản muốn ngăn chặn trẻ em gian lận thông qua việc sử dụng các công cụ đơn giản như TamperData, thì bạn có thể tạo một khóa mã hóa mà bạn chuyển đến SWF khi khởi động. Sau đó, sử dụng một cái gì đó như http://code.google.com.vn/p/as3crypto/ để mã hóa điểm số cao trước khi chuyển lại mã PHP. Sau đó giải mã nó ở cuối máy chủ trước khi lưu trữ nó trong cơ sở dữ liệu.

Bạn đang nói về vấn đề được gọi là vấn đề "niềm tin của khách hàng". Bởi vì khách hàng (bằng tiền mặt này, SWF chạy trên trình duyệt) đang làm một việc mà nó được thiết kế để làm. Lưu một số điểm cao.

Vấn đề là bạn muốn đảm bảo rằng các yêu cầu "lưu điểm" đến từ phim flash của bạn chứ không phải một số yêu cầu HTTP tùy ý. Một giải pháp khả thi cho việc này là mã hóa mã thông báo do máy chủ tạo ra vào SWF tại thời điểm yêu cầu (sử dụng flasm ) phải đi kèm với yêu cầu để lưu điểm cao. Khi máy chủ lưu điểm đó, mã thông báo đã hết hạn và không còn có thể được sử dụng cho các yêu cầu.

Nhược điểm của việc này là người dùng sẽ chỉ có thể gửi một số điểm cao cho mỗi lần tải phim flash - bạn phải buộc họ làm mới / tải lại SWF trước khi họ có thể phát lại để có điểm mới.

Tôi thường bao gồm "dữ liệu ma" của phiên trò chơi với mục nhập điểm cao. Vì vậy, nếu tôi đang làm một trò chơi đua xe, tôi bao gồm dữ liệu phát lại. Bạn thường có sẵn dữ liệu phát lại cho chức năng phát lại hoặc chức năng đua ma (chơi với cuộc đua cuối cùng của bạn hoặc chơi với hồn ma của anh chàng # 14 trên bảng xếp hạng).

Kiểm tra đây là lao động thủ công, nhưng nếu mục tiêu là xác minh xem 10 mục hàng đầu trong một cuộc thi có hợp pháp hay không, đây có thể là một bổ sung hữu ích cho kho vũ khí của các biện pháp an ninh mà những người khác đã chỉ ra.

Nếu mục tiêu là giữ danh sách điểm cao trực tuyến cho đến hết thời gian mà không cần ai phải nhìn vào chúng, điều này sẽ không mang lại cho bạn nhiều.

Cách mà một mod arcade phổ biến mới thực hiện là nó gửi dữ liệu từ flash sang php, quay lại flash (hoặc tải lại), sau đó quay lại php. Điều này cho phép bạn làm bất cứ điều gì bạn muốn để so sánh dữ liệu cũng như bỏ qua các hack dữ liệu / giải mã bài đăng và những thứ tương tự. Một cách mà nó thực hiện là bằng cách gán 2 giá trị ngẫu nhiên từ php vào flash (mà bạn không thể lấy hoặc nhìn thấy ngay cả khi chạy trình lấy dữ liệu flash thời gian thực), sử dụng công thức toán học để thêm điểm với các giá trị ngẫu nhiên sau đó kiểm tra nó bằng cách sử dụng cùng một công thức để đảo ngược nó để xem điểm số có khớp với nó hay không khi cuối cùng nó đi đến php ở cuối. Các giá trị ngẫu nhiên này không bao giờ được nhìn thấy cũng như nó cũng nhân đôi giao dịch diễn ra và nếu nó '

Đây có vẻ là một giải pháp khá tốt nếu bạn hỏi tôi, có ai thấy bất kỳ vấn đề nào khi sử dụng phương pháp này không? Hoặc những cách có thể xung quanh nó?

Tôi nghĩ cách đơn giản nhất là thực hiện các cuộc gọi đến một chức năng như RegisterScore (điểm số) mỗi khi trò chơi đăng ký một số điểm để thêm vào và sau đó mã hóa nó, đóng gói và gửi nó đến một tập lệnh php dưới dạng một chuỗi. Các tập lệnh php sẽ biết làm thế nào để giải mã nó đúng. Điều này sẽ dừng mọi cuộc gọi thẳng đến tập lệnh php vì mọi cố gắng ép điểm sẽ dẫn đến lỗi giải nén.

Chỉ có thể bằng cách giữ tất cả logic trò chơi ở phía máy chủ cũng lưu trữ điểm số bên trong mà không có kiến ​​thức về người dùng. Vì lý do kinh tế và khoa học, nhân loại không thể áp dụng lý thuyết này cho tất cả các loại trò chơi ngoại trừ theo lượt. Ví dụ, việc giữ vật lý ở phía máy chủ rất tốn kém về mặt tính toán và khó có thể phản ứng nhanh như tốc độ của bàn tay. Thậm chí có thể, trong khi chơi cờ, bất kỳ ai cũng có thể ghép trò chơi cờ vua AI với đối thủ. Do đó, các trò chơi nhiều người chơi tốt hơn cũng nên chứa sự sáng tạo theo yêu cầu.

Nó không thực sự có thể đạt được những gì bạn muốn. Các phần bên trong của ứng dụng Flash luôn có thể truy cập được một phần, đặc biệt là khi bạn biết cách sử dụng những thứ như CheatEngine , nghĩa là cho dù trang web và trình duyệt của bạn có bảo mật như thế nào, thì nó vẫn sẽ tương đối đơn giản để khắc phục.

Nó có thể là một ý tưởng tốt để giao tiếp với phụ trợ thông qua AMFPHP . Nó nên ngăn cản ít nhất những người lười biếng cố gắng đẩy kết quả thông qua bảng điều khiển trình duyệt.