כל נושאי הזיהוי

ארכיטקטורה דו-שכבתית: איך Raven Anticheat מריץ זיהוי בצד הלקוח ובצד השרת יחד

Raven מריץ זיהוי בצד הלקוח ובצד השרת במקביל כברירת מחדל. עקיפה של אחת השכבות משאירה את השנייה צופה, וזה מה שעוצר את רוב הצ'יטים המודרניים של פייבאם מלהישאר בלתי מזוהים.

למה שכבה אחת לא מספיקה

רוב האנטי-צ'יטים לפייבאם נשענים על שכבת זיהוי אחת: או מערך בצד הלקוח שמחפש DLL-ים מוזרקים, פונקציות API עם הוק וחתימות תפריטים מוכרות, או מערך בצד השרת שמאמת אירועים ודוחה מעברי מצב משחק בלתי אפשריים. לכל שכבה יש מצב כשל ידוע. AC של צד לקוח בלבד נכשל ברגע שצ'יט מסתיר את הלואדר שלו מבדיקות חתימה. AC של צד שרת בלבד נכשל ברגע שצ'יט מכבד את משטח האירועים החוקי אבל משתמש בהאקים בצד הלקוח (silent aim, ESP, וולהאקים) שאף פעם לא מפעילים אירוע שרת. זיהוי דו-שכבתי אומר שהשכבה שכן רואה את הצ'יט תופסת אותו, והשכבה שלא רואה אותו עדיין מייצרת סיגנל התנהגותי שאדמינים יכולים לבדוק.

על מה שומרת שכבת הלקוח

בצד הלקוח Raven מנטר מודולים מוזרקים, פונקציות מנוע עם הוק, מצב NUI DevTools, שלמות קבצי הריסורס של עצמו ונוכחות ריצה של לואדרים מוכרים של צ'יטים. חתימות למשפחות מוד המניו הפעילות ביותר (Eulen, Redengine, HamMafia, Susano, TZ, TZX, Skript, Phaze, Lumia) נשמרות מעודכנות בקצב הפצה של 1-7 ימים (ראה /changelog). כשחתימה מוכרת נדלקת, נאספות ראיות (צילום מסך + עקבות זיהוי) ונשלחות לפאנל הענן. כשהחתימה לא נדלקת אבל אנומליות כן, ציון האמון של אותו שחקן יורד והוא צף במפה החיה לבדיקת אדמין.

על מה שומרת שכבת השרת

בצד השרת Raven מריץ מעבר אימות על כל אירוע שרת שהשחקן מפעיל. שמות אירועים שלעולם לא אמורים להגיע מלקוח נחסמים על הסף. מטעני אירועים שחורגים מגבולות סבירים (כמויות פריטים, שינויי כסף, ספאון רכבים לדקה) נדחים ונרשמים. רצפי אירועים שתואמים דפוסי אקספלויט מוכרים, כמו רצף האירועים המשורשר של גרסאות Redengine, נחסמים ברמת הדפוס. הזיהוי בצד השרת רץ גם אם כל בדיקה בצד הלקוח נעקפה, ולכן כיסוי בצד השרת הוא לא נתון למשא ומתן.

איך שתי השכבות עובדות יחד

לולאת heartbeat מחברת בין השכבות. הלקוח מדווח לשרת מדי פרק זמן על האש חתום של מצב הריצה הקריטי שלו. אם ה-heartbeat נפסק, השרת מתייחס ללקוח כמשובש ומפעיל את התגובה שהוגדרה (אזהרה, קיק או באן אוטומטי). אם ה-heartbeat ממשיך להגיע אבל המטען שלו כבר לא תואם לערכים הצפויים, השרת רושם את הסטייה ומזין אותה למודל ציון האמון. כך או כך, לשרת יש קריאה רציפה על השאלה אם שכבת הלקוח עדיין מתפקדת, וצ'יט שמכבה את שכבת הלקוח נעשה מיד גלוי מצד השרת.

למה זה משנה לעניין “עמידות לבייפס”

אף אנטי-צ'יט לא חסין לבייפס. כדי לעקוף AC חד-שכבתי צריך לנצח מערך אחד. כדי לעקוף את Raven הדו-שכבתי צריך לנצח שני מערכים בו זמנית, ובנוסף את ה-heartbeat ואת מודל ציון האמון שמצף אנומליות התנהגותיות. העלות של בייפס מוצלח ובלתי מזוהה גבוהה משמעותית, והזמן עד שיוצא תיקון קצר יותר, כי השכבה שכן שמה לב לצ'יט מעבירה את נתוני הלכידה שלה לצוות שמוציא את עדכון החתימה הבא.

שאלות נפוצות

מה זה זיהוי דו-שכבתי באנטי-צ'יט לפייבאם?

זיהוי דו-שכבתי אומר שהאנטי-צ'יט מריץ במקביל בדיקות בצד הלקוח ובצד השרת כברירת מחדל. שכבת הלקוח מחפשת מודולים מוזרקים וחתימות תפריטים מוכרות. שכבת השרת מאמתת אירועים ומעברי מצב משחק. לעקוף את שתי השכבות בו זמנית קשה בהרבה מלנצח אחת מהן לבד.

האם Raven Anticheat רץ בצד הלקוח או בצד השרת?

בשניהם. Raven מריץ זיהוי בצד הלקוח ובצד השרת יחד כברירת מחדל, בתוספת לולאת heartbeat נגד שיבוש שמחברת ביניהם, ובתוספת מודל ציון אמון שמצף אנומליות התנהגותיות גם כשאף חתימה ספציפית לא נדלקת.

מה קורה אם שכבת הלקוח נעקפת?

שכבת השרת ממשיכה לרוץ ולולאת ה-heartbeat שמה לב שההאשים של מצב הלקוח כבר לא תואמים לערכים הצפויים. שני הסיגנלים מפעילים איסוף ראיות ומזינים את מודל ציון האמון. הבייפס נעשה גלוי מצד השרת גם אם חתימת הלקוח נוצחה.

נושאי זיהוי נוספים

רוצה שזה יגן על השרת שלך?

התקנה של שתי דקות. זיהוי אוטומטי של ESX, QBCore, vRP ו-QBox. החל מ-$20.