האם באמת אפשר להגן על VBA?

פורסם: 17.05.2026   ·   נבדק לאחרונה: 17.05.2026   ·   מאת נעם ברנד, מייסד Excel Armor

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

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

השאלה הנכונה

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

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

מודל האיום שמשנה בפועל

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

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

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

מה לא עובד (ולמה)

סיסמת פרויקט ה-VBA

סיסמת פרויקט ה-VBA של אקסל אינה בקרת אבטחה, היא דגל ממשק שאומר לעורך אם להציג את עץ הפרויקט. קוד המקור הבסיסי שמור בזרם בינארי המתועד על ידי מיקרוסופט ([MS-OVBA]) וניתן לקריאה ישירה בלי שהסיסמה מעורבת בכלל. כתבה מפורטת: למה סיסמת ה-VBA אינה הגנה.

הגנת גיליון וחוברת עבודה

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

"עירפול VBA"

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

מודולים מוסתרים, גיליונות "very-hidden", טריקי "התגנבות"

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

מה כן עובד: הצינור בן ארבעת השלבים

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

שלב 1: הסרת המקור מהפריט הנשלח חובה

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

  • הידור לקובץ בינארי נייטיב נפרד (DLL). קלאסי, עובד, אבל כתיבת ה-C/C++ בעצמכם היא נקודת כניסה תלולה למפתח VBA.
  • הידור לאסמבלי .NET או XLL. דרך הביניים. .NET קרוב הרבה יותר בסגנון ל-VBA, הכלים חינמיים, ו-Excel-DNA נותן לכם תוספי XLL מקוריים לאקסל מהקופסה.
  • עטיפת חוברת העבודה ב-EXE מכל. בשימוש אצל חלק מהספקים. ה-VBA עדיין קיים, הוא חי בתוך המכל, אבל המכל הוא מה שנשלח.

Excel Armor בוחר בדרך ה-.NET: ה-Migrator שלו ממיר את לוגיקת העסק של ה-VBA ל-VB.NET מקור בתוספת פרויקט MSBuild. הטפסים והרצועה נשארים ב-VBA, כך שחוויית המשתמש המקורית לאקסל נשמרת.

שלב 2: עירפול הקובץ הבינארי חובה

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

מה שעירפול לא עושה הוא להפוך קוד לבלתי הפיך מתמטית. הוא הופך את הפירוק לאיטי ויקר. זו כל המטרה.

שלב 3: חתימה על הקובץ הבינארי מומלץ מאוד

חתימת Authenticode ב-Windows עושה שני דברים. ראשית, היא נותנת למחלקת ה-IT של הלקוח שלכם זהות ניתנת לאימות עבור הקוד שלכם, מה שמשנה לגבי האם יאפשרו לו להיטען. שנית, וחשוב יותר להגנה: קובץ בינארי חתום מסרב להיטען אם הבתים שלו שונו. זה סוגר את הדלת בפני התקפות "תעקפו את בדיקת הרישיון", שאחרת הן הדרך הקלה ביותר דרך כל ההגנות שלמעלה. Excel Armor מפיק פרויקט MSBuild מוכן לחתימת Authenticode; אתם מספקים את התעודה.

שלב 4: קשירת ההרצה לרישיון מומלץ

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

היכן התחום חלוק

מוצרים שונים בתחום הגנת ה-VBA מהמרים אחרת על ארבעת השלבים. אין תשובה יחידה "הכי טובה", יש פשרות כנות:

  • הידור ל-XLL של .NET לעומת עטיפה ב-EXE. XLL שומר על החוויה המקורית לאקסל ושולח קוד מהודר. עטיפת EXE פשוטה יותר לאימוץ אבל שומרת את ה-VBA שלכם בתוך מכל. אנחנו הימרנו על XLL; ראו את הפשרות.
  • מעַרפל חינמי לעומת מעַרפל קנייני. מעַרפלי ה-.NET המרכזיים בקוד פתוח הם חינמיים ובדוקים בקרב; חלק מהספקים משתמשים במעַרפלים קנייניים. שניהם יכולים לעבוד. "מעַרפל מותאם שכתבנו בבית" הוא לפעמים דגל אדום, ולפעמים לא, בקשו מהספק תיאור של מה המעַרפל שלו באמת עושה.
  • רישוי מובנה לעומת רישוי שאתם מביאים בעצמכם. חלק מהספקים מצמידים הגנה ורישוי בחוזקה; אחרים משאירים את הרישוי לכם. אין תשובה נכונה.

טענות שיווק שלא שורדות מגע עם המציאות

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

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

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

מה אנחנו מוכרים, בשפה פשוטה

Excel Armor מבצע אוטומטית את שלב 1 (ה-Migrator ממיר את לוגיקת העסק של ה-VBA ל-VB.NET ומפיק פרויקט MSBuild) ואת שלב 2 (XLL מעורפל תקני בתעשייה הוא הפלט), מספק תשתית לשלב 3 (הידור מוכן ל-Authenticode), וכולל ווים לשלב 4 (רישוי קשור למכונה). אנחנו לא מבטיחים אי פריצות. אנחנו מבטיחים להעביר את הקוד שלכם מ"כלי חינמי, שישים שניות" ל"יריב מיומן, ימים". עבור רוב מפתחי האקסל, זה ההבדל בין להיות מועתק חופשי לבין לקבל תשלום.

ראו את הצינור המלא

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

הורידו את מדריך האבטחה (PDF) ראו איך Excel Armor עובד

קריאה נוספת

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