הגרסה ההנדסית המלאה

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

TL;DR

• תוקפים צריכים לחשוב במונחים של העברת מידע, לא של מאפייני מוצר.
• ב-Citrix וב-VDI, אודיו הוא לא רק פלט קול. הוא ערוץ תקשורת.
• האתגר האמיתי לא היה כתיבת קוד. הוא היה להבין מה הערוץ משמר ומה הוא הורס.
• הערוץ, לא ההעדפה, הכתיב את הארכיטקטורה הסופית.
• אם אתם רוצים את הטיפול ההנדסי-תקשורתי המלא, קראו את הצלילה לעומק: /he/2026/07/21/think-like-an-attacker-when-the-speaker-becomes-a-communication-channel/.

מבוא

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

זו לעיתים קרובות נקודת מבט הגנתית שימושית. זה לא איך שתוקף חושב.

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

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

סביבות Citrix הן דוגמה טובה. אפשר לנטרל את ה-clipboard, לחסום drive mapping, למנוע USB passthrough, ועדיין להשאיר כמה נתיבים שחייבים להישאר זמינים לתפעול תקין. משתמשים עדיין צריכים לראות את שולחן העבודה המרוחק. הם עדיין צריכים לשמוע התראות. הם עדיין צריכים להזין קלט. כל אחד מהנתיבים האלה הוא צורה של העברת מידע.

זה הרעיון המרכזי שמאחורי המחקר הזה. אודיו לא היה מעניין כי הוא היה מאפיין נשכח. הוא היה מעניין כי הוא עדיין היה ערוץ חי.

איור 1 - חסימת מאפיינים לא תמיד חוסמת ערוצים

שינוי התפיסה

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

בהתחלה, הבעיה נראתה כמו שאלה של אבטחה התקפית: האם אפשר להעביר נתונים מעבר לגבול VDI דרך קול?

מהר מאוד, זו הפסיקה להיות השאלה האמיתית.

השאלה האמיתית הפכה לזו: אם מתייחסים לאודיו של Citrix כאל ערוץ תקשורת, מה הערוץ הזה באמת משמר? אילו חלקים של אות שורדים את המסע? אילו חלקים נהרסים על ידי ה-codec, מערכת ההפעלה, נתיב התעבורה, וה-audio stack בקצה?

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

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

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

עובדה 01

המודולציה הטובה ביותר אינה זו שנושאת הכי הרבה מידע, אלא זו ששורדת את הערוץ הכי טוב.

מה נשבר ראשון

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

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

זה לא מה שקרה כאן.

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

המדידה השתלטה.

עובדה 02

לא אני בחרתי את הארכיטקטורה. הערוץ בחר אותה בשבילי.

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

איור 2 - הערוץ הכתיב את הארכיטקטורה יותר מההעדפה התיאורטית

למה המדידות היו חשובות

הלקח העמוק ביותר מהעבודה הזאת לא היה על Citrix ספציפית. הוא היה על מתודולוגיה.

כמעט בכל שלב, האינטואיציה הייתה פחות שימושית ממדידה ישירה.

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

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

עובדה 03

מדידות תמיד עדיפות על אינטואיציה.

מה יצא מזה

התוצאה לא הייתה רק proof of concept גולמי. עם הזמן, זה הפך למערכת תקשורת מלאה: דחיסה, framing, סנכרון, מודולציה, תיקון שגיאות, interleaving, ולידציה ושחזור.

המערכת הזו הפכה ל-VDI Bridge.

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

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

• צלילה לעומק מלאה: /he/2026/07/21/think-like-an-attacker-when-the-speaker-becomes-a-communication-channel/
• קוד: https://github.com/danieloz147/VDI-Bridge/

איור 3 - המימוש היה תוצאה של אילוצים, לא של העדפה

מה כדאי לזכור

• תוקפים צריכים לחשוב על ערוצים, לא רק על מאפיינים בעלי שם.
• מערכת יכולה להישאר מגבילה ברמת המוצר ועדיין לחשוף נתיבים שמישים להעברת מידע.
• מדידות טובות שוות יותר מהנחות אלגנטיות.
• הארכיטקטורה של מערכת תקשורת מוכתבת לעיתים קרובות על ידי הערוץ עצמו.
• אם אתם רוצים את הניתוח ההנדסי המלא, המשיכו לצלילה לעומק: /he/2026/07/21/think-like-an-attacker-when-the-speaker-becomes-a-communication-channel/.