🥇איך נוצר הקצה האחורי של משחק האקר על השמדת שרת

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

בסך הכל, בקצה האחורי של המשחק היו 6 יחידות ארכיטקטוניות, אותן ננתח במאמר זה:

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

בואו נעבור על כל אחד מהם.

אחורי של ישויות משחק

הקצה האחורי יושם כיישום אתחול קפיצי: היו לו כמה בקרי מנוחה, נקודת קצה של Websocket ושירותים עם היגיון משחק.

היו רק שלושה בקרים:

מגהטרון. עמוד Megatron הנוכחי נשלח דרך בקשות GET: לפני ואחרי הפעלת החשמל. הלייזר נורה דרך בקשת ה-POST.
מיפוי דפי טילדה כך שיוגשו לפי שם העמוד. Tilde מייצרת דפים לייצוא לא עם שמות מקוריים, אלא עם זיהוי פנימי ומידע תאימות.
בקר Captcha לשרת Captcha של שרת פסאודו בעומס גבוה.

נקודת הקצה של Websocket שימשה לשליטה בגאדג'טים: מנורות, זר ואותיות. הוא נבחר להציג באופן סינכרוני לכל השחקנים את המצב הנוכחי של המכשיר: האם הוא דולק או כבוי, פעיל או לא, איזה צבע של האות מואר כרגע על הקיר. על מנת להקשות מעט על משימת הפעלת הלייזר, הוספנו הרשאה לזר וללייזר עם אותו כניסה וסיסמא admin/admin.

שחקנים יכלו לבדוק זאת על ידי הפעלת הזר ולחזור על אותו הדבר עם הלייזר.

בחרנו צמד כניסה-סיסמא טריוויאלי כזה כדי לא לייסר שחקנים בבחירה מיותרת.

כדי להפוך את המשימה למעניינת יותר, מזהי אובייקטים מ-mongodb שימשו כמזהי מכשירים בחדר.

ObjectId מכיל חותמת זמן: שני ערכים אקראיים, אחד מהם נלקח על סמך מזהה המכשיר, והשני מבוסס על ה-Pid של התהליך שיוצר אותו וערך המונה. רציתי לעשות את המזהים שנוצרים במרווחי זמן קבועים ועם תהליכי פיד שונים, אבל עם מונה משותף, כדי שהבחירה במזהה מכשיר לייזר תהיה מעניינת יותר. עם זאת, בסופו של דבר, כולם התחילו עם מזהים שנבדלו רק בערך המונה. ייתכן שזה הפך את השלב לפשוט מדי ואינו מצריך ניתוח של מבנה objectId.

מתרגם מבקשות קצה

סקריפט Python, שעבד על טיימרים ותרגם אותם מהפשטות גיימינג למודל פיזי. לדוגמה, "הדלק את מנורת הרצפה" → "הפעל ממסר N2."

הסקריפט התחבר לתור RabbitMQ והעביר בקשות מהתור לארדואינו. הוא גם יישם את ההיגיון של מיתוג אור מקביל: יחד עם מכשירים מסוימים, האור עליהם הודלק, למשל, כאשר הכוח סופק לראשונה למגהטרון, הוא הואר באור במה. עיצוב תאורה לצילום של הסצנה כולה הוא סיפור נפרד על העבודה הנהדרת של מפיק הפרויקט ומעצב ההפקה השותף שלנו איליה סרוב, ועל כך נספר בפוסט נפרד.

המתרגם היה אחראי גם על ההיגיון של הפעלת המגרסה באמצעות טיימר והעברת התמונה לטלוויזיה: הטיימר להפעלת המגרסה, קפיברה צורחת, פרסומת בסוף המשחק.

כיצד נבנה ההיגיון להפקת אסימון Megatron

זריקת מבחן

כל 25 שניות נוצר אסימון חדש וניתן להשתמש בו כדי להפעיל את הלייזר למשך 10 שניות בעוצמה של 10/255. קישור ל github עם קוד Megatron.

לאחר מכן הלייזר התקרר במשך דקה אחת - במהלך הזמן הזה הוא לא היה זמין ולא קיבל בקשות צילום חדשות.

הכוח הזה לא הספיק כדי להישרף דרך החבל, אבל כל שחקן יכול היה לירות מגטרון ולראות את קרן הלייזר בפעולה.

אלגוריתם הגיבוב MD5 שימש ליצירת האסימון. והתוכנית הסתדרה MD5 מ-MD5 + מונה + סוד עבור אסימון קרב ובלי סוד עבור אסימון מבחן.

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

ירייה קרבית

מצב הלחימה של Megatron הוא 100% כוח לייזר ב-3 וואט. זה מספיק ל-2 דקות כדי לשרוף את החבל שהחזיק את המשקל, לשבור את האקווריום ולהציף את השרת במים.

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

בהכרת הנתונים הללו, ניתן היה למיין את 2 הסמלים האחרונים של המלח ולמעשה לגלות שהמספרים מ-Lost, שהומרו למערכת הקסדצימלית, שימשו עבורו.

לאחר מכן השחקנים היו צריכים לתפוס את ערך המונה (על ידי ניתוח אסימון הבדיקה) ולייצר אסימון לחימה באמצעות ערך המונה הבא והמלח שנבחר בשלב הקודם.

המונה פשוט גדל עם כל זריקת בדיקה וכל 25 שניות. לא כתבנו על זה בשום מקום, זו הייתה אמורה להיות הפתעת משחק קטנה.

שירות אינטראקציה Captcha

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

שירות חישבתי מה להציג בניטור כעומס הנוכחי: טמפרטורה ומאוורר מעבד. מדדים הועברו למסד הנתונים של בסיס הזמן ושורטטו בגראפנה.

אם ב-5 השניות האחרונות התקבלו יותר מ-50 בקשות להציג את ה-captcha, אז העומס גדל במספר קבוע + אקראי של צעדים. החישוב היה שניתן להשיג עומס של 100% תוך שתי דקות.

למעשה, היה יותר היגיון בשירות ממה שהוצג במשחק האחרון: מיקמנו את הצג בצורה כזו שרק הסיבוב של מאוורר המעבד נראה לעין.

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

אפיק אירוח ונתונים

כלי להעברת מידע מה-backend לאתר, שרת ה-VPS עליו פעל RabbitMQ.

הקצה האחורי ואפיק הנתונים נשארו פעילים ה-VPS שלנו. העוצמה שלו הייתה דומה למחשב שראיתם על המסך: VPS 2 ליבות עם שני גיגה-בייט של זיכרון RAM. התעריף נגבה עבור משאבים, שכן עומס השיא תוכנן למספר ימים בלבד - כך עושים לקוחותינו המתכננים להעמיס VPS לפרק זמן קצר. ואז התברר שהעומס גבוה ממה שציפינו, ותעריף קבוע ישתלם יותר. אם אתה עושה קווסט, בחר את תעריפי השורה טורבו.

כדי להגן על השרת מפני DDoSa, השתמשנו ב-Cloudflare.

ראוי לומר שה-VPS עמד בכל בכבוד.

ארדואינו, שהיה אחראי על השליטה בממסרים, קיבל פקודות מהמתרגם ועשה את העבודה בפועל

זה יותר הנושא של המאמר הבא על חלק החומרה של הפרויקט: ה-backend פשוט שלח בקשות להפעיל ממסר מסוים. כך קרה שה-backend הכיר כמעט את כל הישויות והבקשות ממנו נראו כמו "הפעל את הישות הזו". עשינו את זה לבדיקה מוקדמת של האתר (עדיין לא הרכבנו את כל הארדואינו והממסרים), בסוף השארנו הכל ככה.

חזיתי

יצרנו את האתר במהירות ב-tilde, זה לקח יום עבודה אחד וחסך לנו 30 אלף מהתקציב שלנו.

בתחילה, חשבנו פשוט לייצא את האתר ולהוסיף את ההיגיון שחסר לנו, אך נתקלנו בתנאי שימוש שאסרו עלינו לעשות זאת.

לא היינו מוכנים להפר את הרישיון, אז היו שתי אפשרויות: ליישם הכל בעצמנו או לפנות ישירות לטילדה, לדבר על הפרויקט ולבקש רשות לשנות את הקוד.

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

כתוצאה מכך, צירפנו את לוגיקה js ל-frontend לשליחת בקשות למכשירים יסודיים, ושינינו מעט את סגנונות הכפתורים להפעלה וכיבוי של רכיבי משחק.

עיצוב אתר

ההיסטוריה של החיפושים, ששווה פרק נפרד.

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

בהתחלה עשיתי את העיצוב בעצמי, ניסיתי לכלול עוד גיפים ואלמנטים מבריקים. אבל בעלי המעצב מזה 10 שנים הסתכל מעבר לכתפו ודחה את זה כ"טוב מדי". כדי לשבור כללי עיצוב, אתה צריך להכיר אותם.

ישנם מספר שילובי צבעים המעוררים תחושת גועל מתמשכת: ירוק ואדום בעלי עושר שווה, אפור וורוד, כחול פלוס חום. בסופו של דבר הסתפקנו בשילוב של אדום וירוק כצבעי הבסיס, הוספנו גיפים עם חתול ובחרנו 3-4 תמונות של סוקולוב עצמו מתוך תמונת סטוק. היו לי רק כמה דרישות: גבר בגיל העמידה, לובש חליפה לא הולמת במידות גדולות מדי ובפוזת "צילום סטודיו מקצועי". לצורך הבדיקה, הם הראו את זה לחברים ושאלו "איך אתה אוהב את זה?"

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

מכשירים בפועל

המאווררים והאורות הותקנו באמצעות ממסרי מצב מוצק כדי שלא ידלקו בעוצמה מלאה באופן מיידי – כך שההספק יגדל במקביל לניטור.

אבל נדבר על זה בפוסט הבא, על חלק החומרה של המשחק והבנייה בפועל של האתר.

המשך לעקוב!

מאמרים נוספים על המסע להשמדת השרת

מקור: www.habr.com

כיצד נוצר הקצה האחורי של משחק האקר על השמדת שרת