نتورک مارکتینگ

Smart deFi Network کلاهبرداری است؟

smart defi network کلاهبرداری

در این مطلب به بررسی کانترکت یا همان قرارداد هوشمند Smart deFi Network یا Smart deFi DAO یا

Smart Binance Pro (اسمارت بایننس پرو) می پردازیم تا ببنیم smart defi network کلاهبرداری است یا خیر.

توجه داشته باشید که ممکن است از هر قرارداد هوشمند چندین کپی ارائه شود که کپی ها مربوط به گروه سازندگان اصلی قرارداد نمی باشند و شما باید تشخیص دهید که کدام یک قرارداد اصلی است.  ما در اینجا آدرس کانترکت یا قرارداد های اصلی این نتورک را برای شما آورده ایم. د رهمه قراراد ها کیف پول فرد ایجاد کننده قرارداد باید یکی باشد.

آدرس فورک های قبلی این قرارداد رادر زیر مشاهده نمایید:

 Smart_Binance address, Smart_Binance_Pro address, Smart_Binance_Pro_2 address, Smart_Binance_Pro_3 address

Smart_History method Response ]
 Smart_Binance   address :  0x5741da6D2937E5896e68B1604E25972a4834C701
 Smart_Binance_Pro   address :  0xFc46B09bf98858B08C5c5DEeb5c19E609FaBD398
 Smart_Binance_Pro_2   address :  0x8E60F00C14D5BB0B183a8e0a0e97737D254d906e
 Smart_Binance_Pro_3   address :  0x8Aa1055188b407A58dF7d7737314d916A6F4ea24

گروه سازندگان این کانترکت در مرداد ماه 1404 در فورک جدید یا همان فورک 4، نام اسمارت بایننس پرو را به اسمارت دی فای نتورک تغییر دادند.

آدرس کانترکت اسمارت دی فای نتورک : https://bscscan.com/address/0xd341197eE1171D30c0B1685b521C140A6299C200

شما میتوانید از اینجا به این آدرس ها دسترسی داشته باشید.ما در این مقاله صحت و امنیت این کانترکت ها را بررسی می کنیم و به مابقی کانترکت هایی که از روی این کپی شده اند کاری نداریم.

قرارداد هوشمند (Smart Contract) چیست؟

قرارداد هوشمند (Smart Contract) در بستر بلاکچین بایننس (Binance Smart Chain یا BSC) یک برنامه نرم‌افزاری است که به‌صورت خودکار و بدون نیاز به واسطه، شرایط یک توافق را بین طرفین اجرا می‌کند. به عبارت ساده، این قراردادها قوانین و فرآیندهایی را در قالب کد برنامه‌نویسی تعریف می‌کنند و پس از اجرا، هیچ فرد یا سازمانی نمی‌تواند آن را تغییر دهد.

در ادامه توضیح دقیق‌تر:

ویژگی‌های قرارداد هوشمند در بایننس:

  1. خودکار بودن
    قرارداد هوشمند به محض تحقق شرایط تعریف‌شده، اقدامات لازم را بدون دخالت انسان انجام می‌دهد.
    مثال: اگر کاربری مبلغ مشخصی را به قرارداد واریز کند، قرارداد به‌طور خودکار محصول یا توکن مربوطه را به حساب او منتقل می‌کند.

  2. غیرمتمرکز بودن
    قرارداد روی بلاکچین اجرا می‌شود و هیچ نهاد مرکزی آن را کنترل نمی‌کند. همه تراکنش‌ها شفاف و قابل مشاهده‌اند.

  3. امنیت و تغییرناپذیری
    کد قرارداد پس از استقرار روی بلاکچین تغییر نمی‌کند و تراکنش‌ها قابل برگشت نیستند، مگر اینکه کد صریحاً چنین امکانی تعریف کرده باشد.

  4. شفافیت
    همه تراکنش‌ها و قواعد قرارداد به صورت عمومی در بلاکچین قابل مشاهده هستند.

  5. هزینه کم و سرعت بالا
    نسبت به سیستم‌های سنتی که واسطه نیاز دارند، اجرای قرارداد هوشمند سریع‌تر و ارزان‌تر است، به‌خصوص در بایننس اسمارت چین که کارمزد تراکنش پایین‌تر از اتریوم است.

مثال کاربردی:

  • ایجاد یک پلن سرمایه‌گذاری یا سیستم پورسانت شبکه‌ای، مانند همان چیزی که شما قبلاً توضیح داده‌اید، که هر آپارتمان به‌صورت ماهانه مبلغی واریز می‌کند و قرارداد به‌طور خودکار پورسانت را بین اعضای شبکه تقسیم می‌کند.

  • صدور توکن یا NFT به صورت خودکار به کاربران پس از انجام شرایط خاص.

بررسی قرارداد در دی فای اسکنر:

خوب در اینجا به برسی قرارداد در دی فای اسکنر می پردازیم. برای این کار لطفا سایت https://de.fi/scanner را باز کنید.

سپس کد قرارداد اسمارت دی فای نتورک را در آن جستجو کنید. کد قرارداد: 0xd341197eE1171D30c0B1685b521C140A6299C200

برای مشاهده نتایج اسکن اینجا کلیک کنید.

همانطور که در تصویر زیر مشاهده میکنید این قرارداد 99 درصد امن می باشد.

بررسی امنیت Smart_DeFi_NetWork

بررسی امنیت
Smart_DeFi_NetWork

تحلیل قرارداد هوشمند Smart DeFi Network روی BNB Smart Chain

قرارداد هوشمند Smart DeFi Network یکی از پروژه‌های فعال روی بلاکچین BNB Smart Chain (BSC) است که با ساختار ویژه‌ای برای مدیریت پلن‌های باینری و توزیع پاداش طراحی شده است. در ادامه به بررسی مشخصات، ریسک‌ها و نکات مهم این قرارداد می‌پردازیم.

مشخصات کلی قرارداد

  • نام قرارداد: Smart_DeFi_NetWork

  • آدرس قرارداد: 0xd341197eE1171D30c0B1685b521C140A6299C200

  • شبکه استقرار: BNB Smart Chain (BSC)

  • نسخه کامپایلر: Solidity v0.8.22 (بهینه‌سازی فعال – 200 بار اجرا)

  • مجوز نرم‌افزار: MIT

  • تاریخ تأیید کد روی BscScan: 17 آگوست 2025

  • نوع تأیید کد: Exact Match (کد دقیقاً مطابق سورس منتشر شده است)

  • سازنده قرارداد: 0x916D5e71...d8cfE27Bb

  • تعداد تراکنش‌ها تا تاریخ 2 سپتامبر 2025: حدود 7,883 تراکنش

  • دارایی‌های موجود در قرارداد:

    • حدود 95 واحد BSC-USD

    • بیش از 100,000 واحد توکن اختصاصی DW

    • یک NFT با نام uni-voucher

ساختار و هدف قرارداد

نام و عملکرد توابع این قرارداد نشان می‌دهد که طراحی آن بر پایه یک پلن باینری با امتیاز و پاداش انجام شده است. توابعی مانند:

  • BeCome_Owner (ثبت مالکیت/عضویت)،

  • Reward (پاداش‌دهی)،

  • Owner_Left_Right_* (مدیریت سمت‌های چپ و راست شبکه)،

  • Max_Point (مدیریت سقف امتیاز)،

همگی گویای آن هستند که قرارداد برای یک ساختار نتورک با سیستم پاداش‌دهی باینری توسعه یافته است.

ریسک‌ها و کنترل‌های مدیریتی

۱. اختیارات ادمین و تمرکزگرایی (ریسک زیاد)

وجود توابعی مانند _Set_Reward_Fee، _Set_Stable_Coin، _Set_Smart_DeFi_Bank، _Set_Smart_DeFi_Gift و _Write_Road_Map نشان می‌دهد که مدیران قرارداد می‌توانند کارمزدها، توکن‌های مرجع و حتی آدرس‌های مقصد پاداش‌ها را تغییر دهند. این موضوع ریسک تمرکز بالا و احتمال تغییر ناگهانی قوانین را به همراه دارد.

۲. تغییر کیف‌پول کاربران (ریسک متوسط)

توابع _Change_Wallet و _Dont_Change_Wallet این امکان را فراهم می‌کنند که حساب یک کاربر به کیف‌پول جدید منتقل شود. اگرچه این قابلیت برای انعطاف‌پذیری طراحی شده، اما می‌تواند در صورت نبود شفافیت یا حاکمیت مناسب منجر به سوءاستفاده شود.

۳. مدیریت اضطراری و رأی‌گیری (ریسک متوسط)

توابعی مانند _Emergency_Vote و _Emergency__Do نشان می‌دهند که سازوکاری برای تصمیم‌گیری اضطراری پیش‌بینی شده است. با این حال جزئیات آستانه رأی و نحوه اجرای تصمیمات به طور شفاف مشخص نیست و این می‌تواند ریسک مدیریتی ایجاد کند.

۴. تعامل با توکن‌های BEP-20 (ریسک متوسط)

این قرارداد از استانداردهای IERC20 و SafeERC20 استفاده می‌کند. کاربران برای مشارکت نیاز به تأیید (Approve) دارند و قرارداد دارایی‌هایی مانند USDT و BSC-USD را مدیریت می‌کند. این وابستگی به توکن‌های خارجی، ریسک‌های متداول DeFi مانند از دست رفتن نقدینگی یا تغییر قوانین توکن مرجع را دارد.

۵. ارتقاءپذیری (ریسک کم)

الگوی پروکسی در کد مشاهده نشد. بنابراین، قرارداد قابلیت ارتقاء مستقیم ندارد و هرگونه تغییر اساسی نیازمند انتشار نسخه جدید است.

وضعیت فعالیت قرارداد

  • آخرین تراکنش‌ها در تاریخ 2 سپتامبر 2025 ثبت شده‌اند.

  • عملکردها شامل ثبت عضویت جدید (Be Come_Owner)، پاداش‌دهی (Reward)، تغییر کیف‌پول (_Change_Wallet) و توافق‌نامه مسیر (Agreement_Road_Map) بوده است.

  • نشان می‌دهد که قرارداد همچنان فعال بوده و جریان وجوه و عضویت‌ها ادامه دارد.

جمع‌بندی و توصیه‌ها

قرارداد Smart DeFi Network از نظر فنی یک قرارداد تأییدشده روی BNB Smart Chain است که برای ساختار باینری و توزیع پاداش طراحی شده. با این حال:

  • تمرکز اختیارات مدیریتی،

  • ریسک‌های مربوط به تغییرات کیف‌پول،

  • وابستگی به توکن‌های خارجی،
    از جمله مواردی هستند که باید در نظر گرفته شوند.

پیشنهاد می‌شود:

  1. در صورت استفاده، با مبالغ کم شروع کنید.

  2. دسترسی‌های Approve را پس از استفاده لغو (Revoke) کنید.

  3. تغییرات کارمزد، آدرس مقصد یا قوانین توزیع پاداش را به‌طور مداوم رصد کنید.

  4. برای سرمایه‌گذاری یا توسعه سنگین، حتماً یک ممیزی امنیتی مستقل انجام دهید.

شاخص‌های امنیتی و سلامت قرارداد Smart DeFi Network

بررسی‌های امنیتی نشان می‌دهد که قرارداد هوشمند Smart DeFi Network بسیاری از ریسک‌های رایج در قراردادهای دیفای را ندارد و از نظر ساختار کدنویسی و رعایت استانداردها وضعیت مطلوبی دارد. برخی از نتایج کلیدی عبارتند از:

  • برداشت ایمن:
    هیچ تابع برداشت آسیب‌پذیری در قرارداد شناسایی نشد.

  • امنیت در برابر Reentrancy:
    هیچ ریسک بازدرآمدی (Reentrancy) وجود ندارد.

  • بدون قفل شدن سرمایه‌ها:
    هیچ مکانیزم قفل غیرضروری که منجر به بلوکه شدن سرمایه شود، مشاهده نشد.

  • کد منبع تأییدشده:
    سورس‌کد قرارداد به طور کامل روی BscScan تأیید شده است (Exact Match).

  • غیرقابل ارتقاء بودن قرارداد:
    این قرارداد فاقد الگوی پروکسی است و قابل ارتقاء نیست؛ هرگونه تغییر نیازمند انتشار نسخه جدید است.

  • امنیت در Approveهای ERC20:
    هیچ ضعف امنیتی در فرآیند تأیید توکن‌ها (Approve) شناسایی نشده و مالک قرارداد نیز امکان سوءاستفاده از این مجوزها را ندارد.

  • بدون حلقه‌های مسدودکننده:
    در کد قرارداد حلقه‌هایی که موجب مصرف بیش از حد گس یا توقف عملیات شوند، وجود ندارد.

  • عدم امکان بلاک‌لیست کاربران:
    هیچ کاربر یا کیف‌پولی نمی‌تواند از دسترسی به عملکرد خاصی در قرارداد منع شود.

  • غیرقابل توقف بودن عملکرد قرارداد توسط مالک:
    مالک قرارداد نمی‌تواند کل عملکرد قرارداد را متوقف کند (فاقد تابع Pause).

  • مدیریت مالکیت امن:
    هیچ تابع آسیب‌پذیر در حوزه مالکیت وجود ندارد؛ همچنین امکان بازگردانی مالکیت (retrievable ownership) دیده نمی‌شود.

  • سابقه سالم:
    قرارداد اخیراً مستقر نشده، هیچ ارتباطی با میکسرها ندارد و سابقه کلاهبرداری در کیف‌پول مالک آن یافت نشد.

  • فعالیت اخیر:
    این قرارداد در ۳۰ روز گذشته تراکنش داشته و همچنان فعال است؛ نشانه‌ای از رهاشدگی یا متروکه بودن دیده نمی‌شود.

  • ثبات و پایداری عملکرد:
    تعداد اندک Revoke (لغو مجوزها) نشانگر عملکرد پایدار قرارداد است.

  • ایمنی در Initialization:
    بخش initializer قرارداد به درستی ایمن‌سازی شده است تا از مشکلات احتمالی جلوگیری شود.

  • قرارداد فعال و پایدار:
    قرارداد intact بوده و self-destruct نشده است؛ بنابراین عملکرد آن ادامه دارد.

  • تایم‌لاک ایمن:
    تنظیمات تایم‌لاک قرارداد مطابق استاندارد حداقل ۲۴ ساعت یا بیشتر است که موجب افزایش امنیت می‌شود.

  • رعایت بهترین رویه‌ها در Price Feed:
    قرارداد در استفاده از اوراکل‌های قیمتی، استانداردها را رعایت کرده و از داده‌های دقیق و معتبر استفاده می‌کند.

بررسی برخی موارد امنیتی در کانترکت اسمارت دی فای نتورک:

smart defi network کلاهبرداری

smart defi network کلاهبرداری است؟

توضیح مشکل: «کد بدون اثر (Code With No Effects)»

پیغام «Code With No Effects» یعنی قسمتی از کد یا دستوری در قرارداد وجود دارد که عملاً هیچ تأثیری روی وضعیت قرارداد ندارد — یعنی یا متغیری را دوبار با مقادیر متضاد مقداردهی می‌کند یا مقداری نوشته می‌شود که بعداً استفاده نمی‌شود. این حالت معمولاً نشان‌دهندهٔ کد مرده (dead code)، اشتباه منطقی یا نگارش تصادفی است و می‌تواند:

  • باعث سردرگمی خواننده/ممیز کد شود،

  • نشانه‌ی اشکال منطقی باشد (اگر مقدار انتظار می‌رفت تغییر کند ولی تغییر نمی‌کند)،

  • یا در بدترین حالت، منجر به رفتار نامتعین اگر توسعه‌دهنده روی آن حساب کرده باشد.

در گزارش شما:

Smart_DeFi_NetWork.Waiting (Smart_DeFi_NetWork.sol#31) is written in both Waiting = true (Smart_DeFi_NetWork.sol#35) Waiting = false (Smart_DeFi_NetWork.sol#35)

یعنی متغیر/فیلدی با نام Waiting دوبار مقداردهی شده — هم true و هم false — آن‌هم در همان محدودهٔ کد. این معمولاً نشان می‌دهد یکی از این مقداردهی‌ها زائد است یا هدف متفاوتی داشته که به‌درستی پیاده نشده.

پیامدها و سطح ریسک

  • ریسک منطقی/کیفیتی — متوسط: اگر Waiting نقشی در فلوی منطقی قرارداد (مثلاً قفل/صف انتظار یا حالت نگهداری موقت) دارد، مقداردهی متناقض می‌تواند منطق را به‌هم بریزد و رفتار تابعی را تغییر دهد. اگر صرفاً یک باگ نگارشی باشد، ریسک عملیاتی کم است اما باز هم کیفیت کد و قابل اعتماد بودن آن را کاهش می‌دهد.

  • ریسک امنیتی مستقیم — معمولاً کم تا متوسط: خودِ این مسئله لزوماً آسیب‌پذیری امنیتی نیست، ولی می‌تواند نشانهٔ عدم دقت توسعه‌دهنده و احتمال اشکالات بزرگ‌تر باشد. در پروژه‌های مالیِ زنده، این نوع اشتباهات باید برطرف و بازبینی شوند.


تحلیل بخش Tautology or Contradiction قرارداد Smart DeFi Network

در بررسی قرارداد، یک مورد منطقی غیرضروری (Tautology) یا متناقض مشاهده شده است. این مورد در تابع زیر دیده می‌شود:

تابع _Set_Stable_Coin(uint8 R)

function _Set_Stable_Coin(uint8 R) external {
require(_msgSender() == Agent, "Just Agent");
require(R >= 0 && R < 6, "Just 0,1,2,3,4,5");
address[6] memory C = [
0x55d398326f99059fF775485246999027B3197955,
0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d,
0x1AF3F329e8BE154074D8769D1FFa4eE058B1DBc3,
0xc5f0f7b66764F6ec8C8Dff7BA683102295E16409,
0x40af3827F39D0EAcBF4A168f8D4ee67c121D11c9,
0x392004BEe213F1FF580C867359C246924f21E6Ad
];
stableCoin = IERC20(C[R]);
}

📍 مشکل منطقی شناسایی شده

  • شرط زیر در کد آمده است:

require(R >= 0 && R < 6, "Just 0,1,2,3,4,5");
  • چون متغیر R از نوع uint8 تعریف شده، این متغیر هیچ‌گاه مقدار منفی نمی‌گیرد.

  • بنابراین بخش R >= 0 کاملاً بی‌اثر (تواتولوژی = همیشه درست) است.

⚠️ پیامد این موضوع

  • مشکل امنیتی جدی ایجاد نمی‌کند.

  • اما وجود کد اضافه می‌تواند باعث سردرگمی توسعه‌دهندگان یا ممیزان کد شود.

  • بهترین کار حذف قسمت غیرضروری (R >= 0) است و تنها بررسی R < 6 کفایت می‌کند.


تحلیل ریسک Unchecked Transfer در قرارداد Smart DeFi Network

توضیح مشکل (Issue)

در کد قرارداد هوشمند Smart DeFi Network، در تابع DC(address Up) یک انتقال توکن انجام می‌شود:

IERC20(stableCoin).transfer(smart_Gift, 5 * 10 ** 18);

این انتقال بدون بررسی مقدار بازگشتی (return value) انجام می‌شود. در استاندارد ERC20، تابع transfer یک مقدار bool برمی‌گرداند که نشان‌دهنده موفق یا ناموفق بودن تراکنش است. در صورتی که این مقدار بررسی نشود، امکان دارد توکن‌ها منتقل نشوند یا در وضعیت نامشخص باقی بمانند (stuck tokens).

پیامدها (Risks)

  1. گیر افتادن توکن‌ها: اگر قرارداد یا توکن مقصد از استاندارد کامل ERC20 پیروی نکند، توکن‌ها ممکن است در قرارداد گیر کنند.

  2. عدم شفافیت در وضعیت تراکنش: توسعه‌دهندگان و کاربران متوجه نمی‌شوند که آیا انتقال موفقیت‌آمیز بوده یا خیر.

  3. ایجاد ریسک برای سرمایه‌گذاران: در صورت خطا، سرمایه‌گذاران تصور می‌کنند مبلغی پرداخت یا دریافت شده، در حالی که تراکنش واقعی انجام نشده است.

راهکار پیشنهادی (Solution)

برای رفع این مشکل بهتر است از کتابخانه‌های امن مانند SafeERC20 استفاده شود (که در بخش دیگری از قرارداد هم استفاده شده است). به جای:

IERC20(stableCoin).transfer(smart_Gift, 5 * 10 ** 18);

بهتر است کد به شکل زیر تغییر یابد:

stableCoin.safeTransfer(smart_Gift, 5 * 10 ** 18);

این روش هم وضعیت انتقال را بررسی می‌کند و هم در صورت خطا باعث توقف تراکنش می‌شود.

جمع‌بندی (Summary)

  • ✅ قرارداد عملکرد کلی قابل قبول دارد.

  • ⚠️ اما استفاده از transfer بدون بررسی مقدار بازگشتی یک ریسک امنیتی محسوب می‌شود.

  • 🔒 توصیه می‌شود توسعه‌دهنده این بخش را با SafeERC20 بازنویسی کند تا امنیت و شفافیت تراکنش‌ها افزایش یابد.


تحلیل ریسک Uninitialized Local Variables در قرارداد Smart DeFi Network

توضیح مشکل (Issue)

در تابع Owner_Is_My_Line(address Up_Line, address Down_Line) یک متغیر محلی به نام temp تعریف شده است:

bool temp;

این متغیر بدون مقدار اولیه (Uninitialized) تعریف شده و سپس در شرط‌ها استفاده می‌شود. در زبان Solidity، مقدار اولیه متغیرهای محلی bool به صورت پیش‌فرض تضمین نشده است و ممکن است وابسته به کامپایلر یا شرایط باشد.

پیامدها (Risks)

  1. ریسک منطقی (Logic Risk): اگر متغیر temp مقداردهی اولیه نشود، ممکن است در بعضی شرایط مقدار غیرمنتظره داشته باشد.

  2. ایجاد خطا در بررسی سلسله‌مراتب (Hierarchy Check): این تابع وظیفه دارد بررسی کند که آیا یک کاربر در خط (Upline) کاربر دیگر هست یا خیر. اگر مقدار temp به درستی مقداردهی نشود، ممکن است نتیجه تابع نادرست باشد (true/false اشتباه).

  3. ریسک امنیتی غیرمستقیم: هرچند احتمال از دست رفتن مستقیم توکن‌ها پایین است، اما خروجی غلط این تابع می‌تواند منجر به تخصیص اشتباه پورسانت‌ها یا حق عضویت‌ها شود.

راهکار پیشنهادی (Solution)

بهترین روش این است که متغیر temp در همان لحظه تعریف مقداردهی اولیه شود:

bool temp = false;

یا کد بازنویسی شده به شکل زیر باشد:

function Owner_Is_My_Line(address Up_Line, address Down_Line) public view returns (bool) {
if (Up_Line == Down_Line) {
return true;
} else {
address E = KW[Down_Line].UP;
bool temp = false; // مقداردهی اولیه
while (E != address(0)) {
if (E == Up_Line) {
temp = true;
break;
}
E = KW[E].UP;
}
return temp;
}
}

این تغییر کوچک اما حیاتی است و باعث می‌شود خروجی تابع همواره قابل پیش‌بینی و مطمئن باشد.

جمع‌بندی (Summary)

  • ⚠️ متغیر temp بدون مقداردهی اولیه تعریف شده است.

  • 🚨 این موضوع می‌تواند منجر به نتایج غیرمنتظره در بررسی روابط Upline/Downline شود.

  • 🔒 با مقداردهی اولیه (temp = false) می‌توان این ریسک را برطرف کرد.


تحلیل ریسک Missing Zero Address Validation در قرارداد Smart DeFi Network

توضیح مشکل (Issue)

در تابع زیر:

function _Set_Smart_DeFi_Bank(address X) external {
require(_msgSender() == Founder, "Just Founder");
require(Set_Bank == false, "Just 1 Time");
smart_Bank = X;
Set_Bank = true;
}

هیچ بررسی‌ای برای جلوگیری از قرار گرفتن آدرس صفر (0x000...0) به عنوان smart_Bank وجود ندارد.

پیامدها (Risks)

  1. آسیب‌پذیری عملکردی: اگر آدرس صفر به عنوان بانک تنظیم شود، بسیاری از عملیات مرتبط با smart_Bank عملاً غیرفعال یا خراب خواهند شد.

  2. از دست رفتن دارایی‌ها: ارسال توکن‌ها یا کارمزدها به آدرس صفر منجر به سوختن (Burn) دارایی‌ها می‌شود.

  3. ریسک برگشت‌ناپذیر: چون تابع فقط یک بار اجازه تنظیم دارد (Just 1 Time)، اگر آدرس صفر ست شود، هیچ راهی برای اصلاح آن وجود نخواهد داشت.

راهکار پیشنهادی (Solution)

افزودن شرط بررسی آدرس غیر صفر در ابتدای تابع:

require(X != address(0), "Invalid Bank Address");

نسخه اصلاح‌شده:

function _Set_Smart_DeFi_Bank(address X) external {
require(_msgSender() == Founder, "Just Founder");
require(Set_Bank == false, "Just 1 Time");
require(X != address(0), "Invalid Bank Address"); // اضافه شده
smart_Bank = X;
Set_Bank = true;
}

جمع‌بندی (Summary)

  • ⚠️ در تابع _Set_Smart_DeFi_Bank هیچ بررسی برای جلوگیری از استفاده از آدرس صفر وجود ندارد.

  • 🚨 این موضوع می‌تواند باعث از دست رفتن دائمی دارایی‌ها شود.

  • 🔒 با افزودن شرط require(X != address(0)) ریسک به طور کامل برطرف می‌شود.


تحلیل Boolean Constant Comparison در قرارداد Smart DeFi Network

توضیح مشکل (Issue)

در کد زیر داخل تابع DC مشاهده می‌شود که یک متغیر بولین به صورت مستقیم با مقدار ثابت true یا false مقایسه شده است:

require(I_C(_msgSender()) == false, "Just Wallet");

این نوع نوشتار غیرضروری است. چون تابع I_C به صورت ذاتی مقدار true/false بازمی‌گرداند، مقایسه مستقیم با == false یا == true تنها باعث شلوغی کد می‌شود.

پیامدها (Risks)

  1. کاهش خوانایی کد: توسعه‌دهندگان در نگاه اول ممکن است کد را پیچیده‌تر تصور کنند.

  2. کاهش بهینگی گس (Gas): هرچند تاثیر آن اندک است، ولی مقایسه غیرضروری می‌تواند به افزایش مصرف گس در اجرا منجر شود.

  3. افزایش احتمال خطای انسانی: در تغییرات بعدی کد، چنین الگوهایی باعث سردرگمی می‌شوند.

راهکار پیشنهادی (Solution)

شرط بالا را می‌توان ساده‌تر نوشت:

require(!I_C(_msgSender()), "Just Wallet");

یا اگر مقایسه با true باشد:

require(I_C(_msgSender()), "Some Error");

جمع‌بندی (Summary)

  • ⚠️ در بخش‌هایی از قرارداد متغیرهای بولین با مقدار ثابت true و false مقایسه می‌شوند.

  • 🚨 این مسأله امنیتی نیست اما می‌تواند باعث شلوغی و مصرف بیشتر گس شود.

  • 🔒 با ساده‌سازی شرط‌ها (استفاده از ! یا حذف مقایسه مستقیم) کد خواناتر و بهینه‌تر خواهد شد.


تحلیل Low Level Calls در قرارداد Smart DeFi Network

توضیح مشکل (Issue)

در قرارداد Smart DeFi Network از Low Level Call برای انتقال اتر استفاده شده است. بخش مورد نظر در کد:

(success) = recipient.call{value: amount}();

این خط از کد در تابع Address.sendValue (خط 9 قرارداد) دیده می‌شود.

پیامدها (Risks)

استفاده از call به صورت مستقیم می‌تواند پیامدهای زیر را داشته باشد:

  1. عدم مدیریت صحیح خطا (Error Handling): اگر انتقال ناموفق باشد، کنترل خطا به درستی انجام نمی‌شود و این موضوع می‌تواند به از دست رفتن دارایی یا عملکرد غیرمنتظره منجر شود.

  2. حمله Reentrancy: فراخوانی سطح پایین می‌تواند به مهاجم اجازه دهد دوباره به قرارداد وارد شود (Re-Enter) و از توابع سوءاستفاده کند.

  3. کاهش خوانایی و امنیت: به دلیل پیچیدگی مدیریت call، احتمال بروز باگ یا سوءاستفاده بیشتر می‌شود.

راهکار پیشنهادی (Solution)

برای جلوگیری از این مشکلات بهتر است از روش‌های ایمن‌تر استفاده شود:

  • استفاده از transfer یا send (با مدیریت خطا).

  • یا استفاده از کتابخانه‌های استاندارد مانند OpenZeppelin’s Address library که مدیریت خطا و امنیت را در نظر گرفته‌اند.

نمونه ایمن‌تر:

Address.sendValue(payable(recipient), amount);

یا اگر نیاز به مدیریت دقیق خطا هست:

(bool sent, ) = payable(recipient).call{value: amount}("");
require(sent, "Transfer failed");

جمع‌بندی (Summary)

  • ⚠️ قرارداد از call سطح پایین استفاده کرده که ناامن محسوب می‌شود.

  • 🚨 این موضوع می‌تواند باعث حمله Reentrancy یا انتقال ناموفق وجوه شود.

  • 🔒 پیشنهاد می‌شود از ابزارهای استاندارد و ایمن مانند کتابخانه OpenZeppelin برای انتقال وجوه استفاده گردد.


تحلیل Incorrect Solidity Version در قرارداد Smart DeFi Network

توضیح مشکل (Issue)

در ابتدای قرارداد خط زیر وجود دارد:

pragma solidity >=0.4.22 <0.9.0;

این محدوده نسخه‌ها:

  • بسیار وسیع است (از نسخه ۰.۴.۲۲ تا زیر ۰.۹.۰)

  • باعث می‌شود کامپایلرها و ابزارهای تحلیل نتوانند رفتار دقیق کد را پیش‌بینی کنند

  • برخی نسخه‌های قدیمی ممکن است باگ‌های شناخته‌شده یا آسیب‌پذیری‌های امنیتی داشته باشند.

پیامدها (Risks)

  1. ریسک سازگاری: قرارداد روی نسخه‌های مختلف کامپایلر ممکن است رفتار متفاوتی داشته باشد.

  2. ریسک امنیتی: نسخه‌های قدیمی Solidity می‌توانند باگ یا آسیب‌پذیری‌هایی داشته باشند که در نسخه‌های جدید رفع شده‌اند.

  3. مشکل در تحلیل و ممیزی: ابزارهای خودکار تحلیل کد یا فریمورک‌های تست ممکن است نتایج غیر دقیق بدهند.

راهکار پیشنهادی (Solution)

  • محدوده نسخه را محدود و به یک نسخه پایدار جدیدتر ارتقا دهید، مثلاً:

pragma solidity ^0.8.20;
  • استفاده از نسخه‌های ۰.۸.x توصیه می‌شود، زیرا بسیاری از مشکلات امنیتی نسخه‌های قدیمی‌تر در آن‌ها رفع شده‌اند.

  • همچنین با این کار می‌توان از ویژگی‌های جدید Solidity مثل overflow/underflow خودکار و ابزارهای تحلیل بهتر استفاده کرد.

جمع‌بندی (Summary)

  • ⚠️ استفاده از نسخه قدیمی و محدوده وسیع باعث ریسک سازگاری و امنیت می‌شود.

  • 🔒 پیشنهاد: انتخاب یک نسخه جدیدتر و محدود (^0.8.x) برای افزایش امنیت و پایداری قرارداد.


تحلیل Public Functions Should be Declared External در قرارداد Smart DeFi Network

توضیح مشکل (Issue)

در قرارداد Smart DeFi Network تابع زیر مشاهده شده است:

function All_Owner_Number() public view returns (uint64) {
return JK;
}

این تابع تنها از بیرون قرارداد فراخوانی می‌شود و هیچ فراخوانی داخلی ندارد.
در Solidity، توابع که فقط از خارج قرارداد فراخوانی می‌شوند بهتر است با کلمه کلیدی external تعریف شوند.

پیامدها (Risks / Impacts)

  1. مصرف گس بیشتر: تعریف تابع به صورت public به جای external باعث مصرف گس بالاتر هنگام فراخوانی از خارج می‌شود.

  2. بهینه‌سازی ناکافی: هر فراخوانی خارجی به تابع public از طریق delegatecall یا memory کپی اضافه انجام می‌دهد، در حالی که external این هزینه را کاهش می‌دهد.

  3. تاثیر عملکرد قرارداد: در قراردادهایی با تعداد فراخوانی بالا، مصرف اضافی گس می‌تواند هزینه‌ها را افزایش دهد.

راهکار پیشنهادی (Solution)

تغییر تعریف تابع به external view باعث کاهش مصرف گس و بهینه‌سازی عملکرد می‌شود:

function All_Owner_Number() external view returns (uint64) {
return JK;
}

نکته: اگر تابع توسط توابع داخلی قرارداد هم فراخوانی شود، باید فراخوانی داخلی با this.All_Owner_Number() انجام شود.

جمع‌بندی (Summary)

  • ⚠️ توابعی که فقط از خارج قرارداد فراخوانی می‌شوند بهتر است external تعریف شوند.

  • 💡 این تغییر باعث کاهش هزینه گس و بهینه‌سازی عملکرد قرارداد می‌شود.

  • 🔒 امنیت تابع تغییری نمی‌کند، صرفاً بهینه‌سازی است.

دانلود فایل PDF گزارش:

56@0xd341197ee1171d30c0b1685b521c140a6299c200_express_audit

جمع بندی و نتیجه گیری نهایی:

این قرارداد هوشمند نیز مثل هزاران قرارداد هوشمند توسط انسان نوشته شده است و شما باید 100 تتر در این قرارداد واریز کنید تا بتوانید در آن شبکه سازی کنید و سایر افراد را به این قرارداد دعوت کنید . به ازای دعوت هر دو نفر و به شرط رعایت تعادل، رد یک پنل باینری شما به صورت متوسط 20 دلار پورسانت دریافت می کنید. در این قرارداد تسویه حساب هر یک ساعت با شما انجام می شود بنابر این هیچ پولی در شبکه باقی نمی ماند که کسی بخواهد کلاهبرداری کند. یعنی اگر شما یک نفر سمت چپ و یک نفر سمت راست خود دعوت و ثبت نام کنید، در کمتر از یک ساعت پورسانت به کیف پول شما واریز می گردد.

همچنین با ثبت نام  در این کانترک، مقداری ارز SBT به شما هدیه داده می شود که پس از اینکه پشتوانه آن به 1 میلیون دلار رسید، لیست می گردد و ارزش می گیرد.

همچنین یک کانترک به نام کانترک گیفت تعریف شده است که شما می توانید پس از 3 ماه از تاریخ ثبت نام خود ، در آن شرکت کنید و به شرطی که تعادل نزده باشید، گیف های 5 دلاری تا سقف 90 دلار دریافت نمایید و بدین ترتیب 90 دلار از پولی که سرمایه کردید بازخواهد گشت و جایگاه شما نیز حذف نخواهد شد.

سازنده اصلی این قرارداد مشخص نیست ولی مهم این است که کد های قرارداد شفاف است و این قرارداد همراه با ورژن های قبلیش خودش بیش از سه سال است که فعال است و این یعنی مشکلی در مورد کلاهبرداری این کانترک فعلا وجود ندارد.

ولی پیشنهاد می کنیم از قسمت چت و پشتیبانی همین سایت به ما پیام دهید تا اطلاعات بیشتری در اختیار شما قرارد دهیم. برای این کار از سمت چپ پایین سایت به ما پیام دهید.

تیم های زیادی در ایران در این کانترکت فعال هستند. ما چند تیم فعال با لیدرشیپ قوی را می شناسیم. جهت ثبت نام در این کانترکت و کسب راهنمایی بیشتر و عضویت در قوی ترین تیم های این کانترکت به ما پیام دهید. زیرا اگر تیم قوی نباشد امکان رسد سریع در نتورک وجود نخواهد داشت.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *