חשוב על זה: כשאתה פורס חוזה מאגר נזילות של AMM, בדיקות יחידה עוברות, מגבלות החלקה מוגדרות נכון, מבקר מוצא כמה באגים—אתה מתקן אותם. חודש לאחר מכן, מישהו מרוקן 90% מהנזילות בעסקה אחת באמצעות שילוב של שלוש קריאות שלא היו צפויות. מסתבר שהאינווריאנט k = x * y נשבר במחירים מסוימים. ככל שיש יותר פונקציות ותלויות הדדיות, כך קיימות יותר "פינות אפלות" כאלה. פיזינג (Fuzzing) מאלץ את החוזה לעבור מיליוני תרחישים אקראיים ולוכד את הרצף הספציפי האחד ששובר את הלוגיקה. בפרויקט טיפוסי, פיזינג מוצא בממוצע 8.5 נקודות תורפה—פי שלושה יותר מבדיקת אודיט ידנית. אלה לא רק מספרים; אלה מניעת הפסדי נזילות ופרוטוקולים שנשמרו. המתודולוגיה שלנו לפיזינג חוזים חכמים מנצלת את Echidna fuzzing ואת Foundry fuzz test לבדיקת אינווריאנטים, וחושפת נקודות תורפה של DeFi שאודיט אבטחה טהור של Solidity עלול לפספס.
למה פיזינג הוא הכרחי?
בדיקת יחידה טיפוסית מכסה נתיב ביצוע אחד. אם userA קורא ל-withdraw עם סכום 100, היתרה יורדת ב-100. אבל במציאות עסקאות משתלבות: שתי הלוואות בזק (flash loans), שינוי מחיר אורקל, קריאה ישירה לפונקציה מקורית, ו-reentrancy. כל אחד מהגורמים האלה יכול לחפוף. פיזינג משלב אותם באקראיות, וחושף שילובים שאינם ברורים לאדם. אנחנו מחפשים:
- הפרות אינווריאנטים: totalSupply == sum(balances), k = x * y עבור מאגרים.
- גלישות uint256 בפעולות בדיוק גבוה.
- תנאי מרוץ במהלך שדרוגי חוזה (התנגשות אחסון).
- שגיאות עיגול בפרוטוקולי DeFi עם נפחים גדולים.
- אפשרויות הוצאה כפולה באמצעות reentrancy ו-delegatecall.
אילו כלים מפעילים את הפיזינג שלנו?
Echidna — בדיקות מבוססות מאפיינים (Property-Based Testing) ליבה
Echidna (שפותח על ידי Trail of Bits) הוא מזין (fuzzer) לחוזים חכמים של Ethereum. אנחנו כותבים אינווריאנטים כ-asserts בתוך החוזה או בחוזי בדיקה נפרדים. התיעוד של Echidna מדגיש שבדיקות מבוססות מאפיינים יעילות למציאת הפרות אינווריאנטים.
contract TestLiquidityPool is Test {
LiquidityPool pool;
// инвариант: суммарная ликвидность не может быть отрицательной
function echidna_test_total_supply_nonnegative() public view returns (bool) {
return pool.totalSupply() >= 0;
}
// инвариант: k = x * y не уменьшается необоснованно
function echidna_test_k_invariant() public view returns (bool) {
(uint112 x, uint112 y, ) = pool.getReserves();
uint256 k = uint256(x) * uint256(y);
return k >= pool.MIN_K();
}
}Echidna מייצר רצפי קריאות, משנה ארגומנטים, ובודק אינווריאנטים לאחר כל בלוק. אם נמצאה הפרה, הוא מוציא את רצף העסקאות המינימלי שמוביל אליה.
Foundry — בדיקות אינווריאנטים מהירות
Foundry (בדיקות fuzz) מאפשר להריץ בדיקות עם ארגומנטים אקראיים ולבדוק תנאים לאחר מכן (postconditions). אנחנו משלבים את Foundry עם Echidna: Foundry לבדיקות מקומיות מהירות, Echidna לחקירה עמוקה.
contract InvariantTest is StdInvariant {
LiquidityPool pool;
function setUp() public {
pool = new LiquidityPool();
targetContract(address(pool));
}
// инвариант: баланс пула соответствует sum позиций
function invariant_totalSupplyEqualsSumBalances() public {
(uint112 x, uint112 y, ) = pool.getReserves();
assertApproxEqRel(pool.totalSupply(), x + y, 1e15);
}
} Slither + Echidna — ניתוח סטטי ודינמי
Slither מנתח סטטית את פריסת האחסון, מוצא התנגשויות אחסון ואחסון לא מאותחל. Echidna בודק דינמית אם ניתן לנצל בעיות אלה. הצמד הזה יעיל במיוחד לבדיקת חוזים הניתנים לשדרוג, ומספק כיסוי אודיט אבטחה עמוק של Solidity. סקירת החוזים עם ניתוח סטטי שלנו מפחיתה עוד יותר תוצאות חיוביות שגויות.
בחירת כלים לפיזינג
| כלי | סוג | מהירות | עומק | מורכבות הגדרה |
|---|---|---|---|---|
| Echidna | מבוסס מאפיינים | בינונית | גבוה | בינונית |
| Foundry | Fuzz + אינווריאנטים | גבוהה | בינוני | נמוכה |
| Slither | סטטי | מהיר | נמוך (סטטי) | נמוכה |
Echidna מוצא פי 3 יותר מקרי קצה מאשר אודיט ידני, אך דורש כתיבת אינווריאנטים. Foundry מריץ 10 מיליון בדיקות בשעה, פי שניים מהר יותר מ-Hardhat. בפרקטיקה שלנו, פיזינג חושף בממוצע 8.5 נקודות תורפה לפרויקט—לעומת 2–3 מאודיט ידני בלבד. סקירת החוזים עם ניתוח סטטי שלנו מפחיתה עוד יותר תוצאות חיוביות שגויות.
תהליך: מאודיט לדוח
- ניתוח ארכיטקטורה (2–3 ימים). סקירת קוד, זיהוי פונקציות קריטיות ומשתני מצב. הגדרת אינווריאנטים במשותף עם הלקוח.
- פיתוח מזין (fuzzer) (5–7 ימים). כתיבת חוזי בדיקה עם אינווריאנטים ב-Echidna ו-Foundry. הגדרת מוטציית רצפים ומזין מותאם אישית ללוגיקה מורכבת (לדוגמה, נתיבי החלפה אקראיים).
- ביצוע וניתוח (5–10 ימים). הרצת לפחות 50 מיליון מקרי בדיקה. לכל כשל: ניפוי באגים, סיווג (קריטי/גבוה/בינוני). הרצה חוזרת לאחר תיקונים.
- דוח והמלצות (3–5 ימים). תיעוד מפורט של כל הבעיות שנמצאו, רצפי עסקאות וקוד תיקון. הערכת סיכון שיורי לאחר תיקונים.
| שלב | משך | פעילות |
|---|---|---|
| ניתוח | 2-3 ימים | הגדרת אינווריאנטים |
| פיתוח מזין | 5-7 ימים | כתיבת בדיקות |
| ביצוע | 5-10 ימים | 50 מיליון מקרי בדיקה |
| דוח | 3-5 ימים | תיעוד והמלצות |
דוגמת קטע דוח
מזהה: INV-001 | חומרה: גבוהה תיאור: אינווריאנט totalSupply == sum(balances) הופר לאחר withdraw עם reentrancy. רצף: addLiquidity(100, 200) -> transferFrom(...) -> withdraw(50) -> withdraw(50) עם קריאת חזרה של reentrancy. המלצה: השתמש בתבנית Checks-Effects-Interactions.
תוצרים (מה כלול)
- הגדרת סביבה (Docker, Foundry, Echidna) עם גישה למכלים ניתנים לשחזור.
- הגדרה וקידוד של 10–30 אינווריאנטים המותאמים לפרוטוקול שלך.
- הרצת מזין עם איסוף כשלים אוטומטי (מינימום 50 מיליון מקרי בדיקה).
- אימות ידני של כל כשל (ללא תוצאות חיוביות שגויות).
- ייעוץ לתיקון נקודות תורפה עם המלצות ברמת קוד.
- דוח PDF סופי עם ממצאים מפורטים והערכת סיכונים.
- תמיכה לאחר מסירה למשך 30 יום למענה על שאלות וסקירת תיקונים.
למה לבחור בנו לפיזינג?
עם 5+ שנים בשוק ו-50+ פרויקטים שנבדקו (כולל פרוטוקולי DeFi עם TVL משמעותי), מנענו הפסדים פוטנציאליים של למעלה מ-10 מיליון דולר. לצוות שלנו יש 10+ שנות ניסיון משולב באבטחת בלוקצ'יין. הצוות שלנו מתהדר ב-5+ שנים באבטחת חוזים חכמים, 50+ אודיטים שהושלמו, ומניעת הפסדים של למעלה מ-10 מיליון דולר. המתודולוגיה שלנו לפיזינג חושפת פי 3 יותר נקודות תורפה מאשר אודיטים ידניים מסורתיים. שילוב של Echidna ו-Foundry מניב בדיקות מהירות פי 2 מאשר שימוש ב-Hardhat בלבד. מתודולוגיה קניינית המשלבת ניתוח סטטי, פיזינג ואימות פורמלי. אחריות: אנחנו לא סוגרים את האודיט עד שנמצאה לפחות נקודת תורפה אחת מאומתת, או שנחזיר כסף (התנאים ניתנים למשא ומתן). חיסכון בתיקונים עתידיים יכול להגיע ל-200,000 דולר ומעלה. עלות התקשרות טיפוסית מתחילה ב-12,000 דולר, עם שיעור שביעות רצון של 95%.
לוח זמנים ועלות
בין 15 ל-30 ימי עסקים בהתאם להיקף הקוד ולמספר החוזים. העלות מחושבת באופן אישי—אנחנו לא מצטטים בעיוורון. צור קשר, נעריך את הפרויקט שלך תוך 1–2 ימים.
טעויות נפוצות בפיזינג וכיצד להימנע מהן
- רגנרציית מצב: אם המזין לא יכול לקרוא לפונקציות עם פרמטרים שונים, הוא נתקע בתרחיש אחד. פתרון: השתמש במזין רצפים.
- חוסר בדיקות מחיר אורקל: המזין עשוי להזין כל מחיר, אבל אם הם מחוץ לטווח המותר, החוזה צריך לדחות אותם. פרוטוקולים רבים מתעלמים מכך.
- התעלמות ממגבלת גז: חלק מהאינווריאנטים מתקיימים רק בצריכת גז ספציפית. המזין צריך לשנות את מגבלת הגז.
צור קשר כדי לדון בפרטים ולקבל ייעוץ לפרויקט שלך. הזמן בדיקות פיזינג—נעזור לך לחסל נקודות תורפה נסתרות לפני שתוקפים ימצאו אותן.







