למה סיסמת ה-VBA אינה הגנה
פורסם: 17.05.2026 · נבדק לאחרונה: 17.05.2026 · מאת נעם ברנד, מייסד Excel Armor
רוב מפתחי האקסל שולחים חוברות עבודה עם סיסמה לפרויקט ה-VBA שהוגדרה בTools → VBAProject Properties → Protection, ומניחים בצדק שזה מגן על הקוד שלהם. זה לא. סיסמת ה-VBA מעולם לא תוכננה כאמצעי אבטחה, וכבר יותר מעשרים שנה שאפשר לעקוף אותה בקלות. זו אינה טענה שנויה במחלוקת, זו התנהגות מתועדת, ונוהל העקיפה נמצא בעמוד הראשון של גוגל.
המאמר הזה אינו מדריך עשה זאת בעצמך. הוא מסביר למה הסיסמה נכשלת, לאיזה מודל איום זה משאיר אתכם חשופים, ומה באמת עובד. אם אתם מחפשים הוראות פיצוח, זה הדף הלא נכון; אנחנו נמנעים במכוון מלפרסם אותן.
מה סיסמת ה-VBA באמת
כשאתם מגדירים סיסמה לפרויקט VBA, אקסל כותב דגל לתוך האחסון הפנימי של חוברת העבודה שאומר "סביבת הפיתוח צריכה לסרב לפתוח את עץ הפרויקט בלי הסיסמה הזו." קוד המקור עצמו שמור בזרם בינארי מתועד (שמכונה בדרך כלל vbaProject.bin בתוך מכל ה-.xlsm הדחוס) בפורמט שאין לו כל קשר לסיסמה. הסיסמה אינה משמשת להצפנת המקור. היא אינה משמשת לעירפול המקור. היא נבדקת על ידי משטח ממשק אחד ספציפי (העורך, VBE) ומתעלמים ממנה בכל מקום אחר.
זה אומר שקוד המקור על הדיסק קריא לכל דבר שמכיר את הפורמט הבינארי, והפורמט הבינארי מתועד ב[MS-OVBA], המפרט הפתוח של מיקרוסופט עצמה. אין כאן סוד לשמור.
שלוש דרכי העקיפה (מתוארות, לא מופעלות)
העקיפות מתחלקות לשלוש קטגוריות. אנחנו מזכירים אותן כדי שתבינו את שטח התקיפה; אנחנו לא מפרסמים הוראות צעד אחר צעד.
- לשקר לעורך. הביט של "מוגן או לא" יושב במקום ידוע בזרם הבינארי. הופכים את הביט, והעורך מפסיק לבקש סיסמה. הסיסמה המקורית לא משוחזרת ולא נחוצה, פשוט הופכים אותה ללא רלוונטית.
- להחליף את הסיסמה. מחליפים את הזרם המוגן בזרם שאת הסיסמה שלו אתם מכירים. העורך מקבל את הסיסמה שלכם ומציג את המקור (שלא השתנה).
- לדלג על העורך לגמרי. מנתחים את
vbaProject.binישירות בעזרת המפרט המפורסם, או בעזרת אחת מתריסר ספריות ציבוריות שעושות זאת ב-50 שורות של פייתון. ה-VBE לעולם לא מעורב. הסיסמה לעולם לא מעורבת.
הקטגוריה השלישית היא זו שהופכת את הסיסמה ללא הגנה ביסודה. גם אם מיקרוסופט תחזק את העורך מחר, קוד המקור עדיין נמצא שם על הדיסק בפורמט מתועד.
מה זה אומר על מודל האיום שלכם
אם אתם שולחים חוברת עבודה מוגנת בסיסמה, הנה מי יכול לקרוא את ה-VBA שלכם כבר היום:
- כל לקוח שמריץ אחד מתריסר הכלים החינמיים שמופיעים בעמוד הראשון של גוגל.
- כל מפתח עם חמש דקות ועורך הקסה.
- כל עוזר בינה מלאכותית שתשאלו "איך אני פותח פרויקט VBA בלי הסיסמה", שיסביר זאת בשמחה.
- כל מי שאי פעם השתתף בקורס מתחילים בהנדסה הפוכה.
האיום הריאלי אינו גורם ממשלתי. הוא המתמחה של הלקוח שלכם, מתחרה שבוחן את חוברת העבודה שלכם, או עובד לשעבר שעזב עם עותק. מול הקהל הזה, סיסמת ה-VBA משיגה אפס. מול תוקף נחוש שמוכן להשקיע שעות, היא משיגה אפס. אין קהל שעבורו סיסמת ה-VBA היא האמצעי הנכון.
"אבל גם נעלתי את מבנה הגיליון"
הגנת גיליון (תאים, גיליונות, מבנה חוברת העבודה) היא תכונה אחרת ושיחה אחרת. גם היא לא תוכננה כאמצעי אבטחה, היא תוכננה כדי למנוע עריכות בשוגג. הסיסמה על התכונות האלו משתמשת בגיבוב חלש שמתנגש מהר, ומיקרוסופט הצהירה במפורש בתיעוד שלה שהגנת גיליון אינה מיועדת לשמור על סודיות נתונים.
הגנת גיליון הגיונית עבור התרחיש שמיקרוסופט בנתה אותה בשבילו: למנוע ממשתמש להקליד בתא הלא נכון. היא אינה מגנה על הקניין הרוחני שלכם.
מה באמת עובד
יש עיקרון אחד: אל תשלחו את קוד המקור. כל שיטת הגנה יעילה היא וריאציה על העיקרון הזה:
1. העבירו את הלוגיקה לבינארי מהודר
הוציאו את לוגיקת העסק מ-VBA והכניסו אותה למשהו שמהודר לקוד מכונה או ל-IL. ה-VBA בחוברת העבודה הופך אז לעטיפה דקה שקוראת לבינארי. המשתמש יכול לראות את העטיפה; הוא לא יכול לראות את הלוגיקה.
הבינארי הזה יכול להיות DLL קלאסי (C++, COM), אסמבלי .NET, או, האפשרות הכי טבעית לאקסל, תוסף XLL שאקסל טוען ישירות.
2. ערפלו את הבינארי
גם קוד מהודר ניתן לפירוק לאחור. עירפול (שינוי שמות, השטחת זרימת בקרה, הצפנת מחרוזות) מעלה את העלות לנקודה שרוב התוקפים לא ישלמו. עבור .NET במיוחד, יש כלי עירפול בקוד פתוח בשלים שנחשבים לסטנדרט התעשייתי לחיזוק IL.
3. חתמו על הבינארי
חתימת Authenticode לא עוצרת הנדסה הפוכה, אבל היא עוצרת תקיפה אחרת: שינוי הקוד. XLL או DLL חתום מסרב להיטען אם שונה, מה שסוגר את הדלת בפני תקיפות מסוג "להוציא את בדיקת הרישוי בעריכה". זה גם נותן לקונים שלכם זהות שניתנת לאימות, מה שחשוב למחלקות IT שמחליטות אם לאשר את התוסף שלכם.
4. קשרו לרישיון
ברגע שהקוד מהודר, יש לכם מקום למקם בדיקות רישוי שלא ניתן להוציא בעורך הקסה. הפעלה הקשורה למכונה, גרסאות ניסיון מוגבלות בזמן, דגלי תכונות, הכול הופך לאפשרי.
מה Excel Armor עושה, בפסקה אחת
Excel Armor הוא צינור דו-שלבי שמבצע אוטומטית את ארבעת הצעדים שלמעלה עבור מפתחי אקסל. ה-Migrator קורא את פרויקט ה-VBA שלכם, ממיר את לוגיקת העסק ל-VB.NET מקור ולפרויקט MSBuild, ומשאיר את ה-UserForms והרצועה ב-VBA. שלב ה-Armor בונה את פרויקט ה-.NET, מיישם עירפול .NET תקני בתעשייה, אורז אותו כ-XLL מקורי לאקסל עם תשתית לחתימת קוד ומנגנוני רישוי, ומפיק תוצר משלוח שבו לוגיקת ה-VBA המקורית כבר לא קיימת. ראו איך זה עובד בדף הבית.
הגבולות הכנים
שום דבר מכל זה לא הופך את הקוד שלכם לבלתי אפשרי לפירוק לאחור. זה הופך אותו ליקר. השאלה הנכונה אינה "האם אפשר לפצח אותו", אלא "האם פיצוח שלו שווה יותר ממחיר הרישיון". עבור רוב תוכנות האקסל, התשובה לשאלה הזו עם XLL מהודר ומעורפל היא "לא", והתשובה עם סיסמת VBA היא "כן".
אם ספק בתחום הזה אומר לכם שהמוצר שלו בלתי פריץ, התגובה הנכונה היא לעזוב. אנחנו לא נגיד לכם את זה. אנחנו נגיד לכם שאנחנו מעבירים את הרף מ"כלי חינמי, שישים שניות" ל"יריב מיומן, ימים של עבודה", שזה הרף שחשוב בפועל.
קבלו את רשימת התיוג המלאה להגנת קניין רוחני
PDF קצר ומעשי למפתחי אקסל: שבעת המקומות שבהם קוד VBA דולף, מטריצת הערכה עצמית, והחלטות ההגנה שבאמת מזיזות את המחט.
הורידו את המדריך (PDF) השוואה: XLS Padlock מול Excel Armor