godhive: چارچوبی نوظهور بر پایه Rust برای سرقت رمزارز و استخراج

TLP:CLEAR. مجاز برای انتشار عمومی. ثبت‌شده توسط شبکه حس‌گرهای هانی‌پات Kinryū Labs. شاخص‌های زیر بی‌خطرسازی شده‌اند.

خلاصه مدیریتی

• 6,946درخواست Docker-API در یک رشته خودکار
• 946ماژول منبع Rust در فایل اجرایی
• 8+بلاک‌چین که ماژول تخلیه کیف‌پول آن هدف می‌گیرد
• 9نوع کانال فرمان

godhive یک چارچوب کرم‌گونه، سرقت‌کننده رمزارز و استخراج‌کننده است که با Rust کامپایل شده و از طریق یک Docker Remote API در معرض دسترس به شبکه هانی‌پات ما رسید. یک گرداننده واحد کارزاری خودکار و پرحجم را علیه یک Docker API در معرض دسترس اجرا کرد و زنجیره کامل حمله را 21 بار تکرار نمود. Kinryū Labs با اطمینان بالا ارزیابی می‌کند که godhive یک جرم‌افزار ساخته‌شده برای هدفی مشخص است و نه یک استخراج‌کننده عمومی و در دسترس همه: برند اختصاصی خود را دارد، نامش در هوش تهدید عمومی دیده نمی‌شود، و فایل اجرایی بازیابی‌شده 946 ماژول منبع مجزای Rust و ماه‌ها کار توسعه را در خود دارد.

گرداننده هیچ‌گاه چارچوب را از یک URL دریافت نکرد. آن‌ها فایل ELF را به صورت base64 و با printf قطعه‌قطعه و درون‌خطی به یک کانتینر منتقل کردند. فایل اجرایی به طور کامل از همان قطعه‌های درون‌خطی خودِ گرداننده بازسازی شد: 215 قطعه که به یک ELF از نوع x86-64 با حجم 6.2 MB بازچینی شدند (SHA-256 4194f2337c2b261ed6e1fd0b6d18f0ba75388bdc91a2658eb827a154ed784f36) و در VirusTotal موجود نیست.

یافته متمایزکننده این است که godhive در اصل یک استخراج‌کننده نیست. استخراج، گزینه پشتیبان آن است. کار اصلی‌اش سرقت است: برداشت‌های خودکار از شش صرافی بزرگ و جاروب کردن وجوه در بیش از هشت بلاک‌چین، و استخراج Monero تنها زمانی انجام می‌شود که هیچ کیف‌پولی یافت نشود.

مسیر تحویل: یک Docker API در معرض دسترس

نقطه ورود، قدیمی‌ترین نقطه ورود در دنیای کانتینر است: یک Docker Remote API بدون احراز هویت روی TCP/2375. از آن نقطه به بعد، زنجیره یک تسخیر کلاسیک میزبان است که از درخواست‌های Docker API گرداننده استخراج شده است.

گرداننده از alpine:latest کانتینری می‌سازد که privileged: true است، از network_mode: host استفاده می‌کند و تمام سیستم‌فایل میزبان را به صورت خواندنی-نوشتنی bind-mount می‌کند (/:/host:rw). همان یک تنظیم کانتینر، خودِ فرار است: mount کردن ریشه میزبان در یک کانتینر privileged معادل کنترل root روی ماشین است. سپس استخراج‌کننده‌های رقیب را پاک می‌کند (pkill -9 xmrig; pkill -9 lolMiner; pkill -9 minerd; pkill -9 godhive_c2)، دایرکتوری پایداری خود را در میزبان در /etc/godhive می‌نویسد، و اسرار میزبان را مستقیماً از طریق همان mount می‌خواند و /etc/shadow و /root/.ssh/authorized_keys را بیرون می‌کشد.

فقط پس از آن است که کریپتوجکینگ آشنا پدیدار می‌شود. godhive یک نسخه ساخته‌شده از XMRig را از یک میزبان فایل ناشناس دریافت می‌کند، آن را مستقر می‌کند، یک تونل ngrok برای دسترسی خارج از مسیر اصلی باز می‌کند و نتایج را به یک بات Telegram می‌فرستد. کار را با پرس‌وجو از سرویس فرادادهٔ ابری (169.254.169.254) برای یافتن اعتبارنامه‌ها و کاوش برای Kubernetes، Elasticsearch و Kibana به منظور گسترش دامنه دسترسی به پایان می‌برد. گرداننده این زنجیره را در آن رشته حمله 21 بار تکرار کرد.

استخراج، کم‌اهمیت‌ترین بخش ماجراست

فایل اجرایی بازیابی‌شده بسیار بزرگ‌تر از آن زنجیره‌ای است که اجرای آن را دیدیم. 946 ماژول Rust آن و رشته‌های ساخت‌شان یک جعبه‌ابزار تهاجمی گسترده را ترسیم می‌کنند. بخشی از آن با کد کامپایل‌شده پشتیبانی می‌شود (مقادیر ثابت تکراری ناشی از monomorphisation در Rust، مسیرهای مدیریت خطا و دایرکتوری‌های ساخت crate)؛ بخش‌های دیگر فقط نام ماژول و قطعه‌های ناتمام تنظیمات‌اند، پس فهرست زیر را به همان اندازه که کارکرد اثبات‌شده است، نشانه‌ای از قصد بخوانید.

خط لوله کسب درآمد هسته ماجراست. یک harvester سیستم‌فایل را برای wallet.dat، .env، کلیدهای SSH و wp-config.php می‌کاود؛ یک scorer قیمت BTC، XMR، ETH و Ravencoin را در برابر CoinGecko می‌سنجد و قربانیان را بر پایه ارزش رتبه‌بندی می‌کند؛ یک مرحله اعتبارنامه، ورودهای دزدیده‌شده را با یکپارچه‌سازی 2CAPTCHA برای عبور از چالش‌های ورود، تزریق انبوه می‌کند؛ و یک drainer وجوه را از طریق کتابخانه صرافی CCXT و جاروب‌های زنجیره‌ای DeFi بیرون می‌کشد، کلیدها را از عبارت‌های بازیابی دزدیده‌شده مشتق می‌کند و ارزان‌ترین زنجیره را برای هر برداشت انتخاب می‌کند. یک کامنت توسعه‌دهنده که در فایل اجرایی جا مانده، برداشت استیبل‌کوین‌ها را برای پرهیز از هزینه gas در Ethereum بهینه می‌کند؛ همین سطح از دقت است که یک drainer کارآمد را از یک اثبات مفهوم جدا می‌کند.

پیرامون آن هسته، بقیه جعبه‌ابزار قرار دارد: کرمی که با Masscan و Nuclei پویش می‌کند و از Docker، Redis، Kubernetes، Elasticsearch، WordPress و مجموعه‌ای از آسیب‌پذیری‌های Windows و Java از جمله Log4Shell بهره‌جویی می‌کند؛ یک ماژول از کار انداختن EDR که نُه فروشنده امنیت نقطه پایانی را بر پایه نام فرایند هدف می‌گیرد؛ پنج لایه پایداری تا حد یک bootkit در سطح UEFI با دست‌کاری TPM؛ یک سامانه افزونه WASM برای فرستادن قابلیت‌های تازه به کل ناوگان بدون دست زدن به C2؛ باج‌افزاری که تنها بالاتر از آستانه ارزش 1,000 دلار آمریکا فعال می‌شود؛ یک ربایندهٔ کلیپ‌بورد؛ یک ماژول DDoS؛ و قابلیت‌های ضدجرم‌یابی که wtmp، btmp و لاگ‌های journal را حذف می‌کند و نوفه جعلی syslog می‌کارد تا وقت تحلیل‌گر را تلف کند. هر ماژول را زیر نام فرایند جعلی sysd پنهان می‌کند و ترافیک خود را با قرض گرفتن نام‌های میزبان واقعی SNI از googlevideo.com به شکل پخش YouTube در می‌آورد.

دو نکته این تصویر را تعدیل می‌کند. این چارچوب قابلیت شناسایی پانزده بستر هانی‌پات و مجموعه‌ای از سندباکس‌ها و هایپروایزرها را دارد. و چند مورد از تنظیماتش ناتمام است: استخر استخراج پیش‌فرض در سال 2022 تعطیل شده، یک نام ENS برای کلیپ‌بورد هرگز ثبت نشده، و یک کلید رمزنگاری هنوز همان مقدار جانگهدار CHANGE_ME است. قابلیت‌ها کامپایل‌شده و واقعی‌اند؛ بخش‌هایی از آن هنوز به هم وصل نشده است.

ngrok و اینکه چرا ابزار نفوذ به شمار می‌آید

نمونه‌ای که نخستین بار این کارزار را برجسته کرد، همان فایل اجرایی قانونی و امضاشدهٔ ngrok است که از CDN خودِ ngrok دریافت شده بود. این بدافزار نیست. یک ابزار تجاری تونل‌زنی معکوس است و موتورهای ضدویروس دقیقاً به این دلیل آن را ابزار نفوذ برچسب می‌زنند که پس از یک نفوذ بسیار کاربردی است. به محض آنکه godhive اجرای کد را درون یک کانتینر privileged به دست آورد، ngrok به ابر ngrok وصل می‌شود و یک سرویس محلی دلخواه را از طریق یک URL عمومی در معرض دسترس قرار می‌دهد، بدون باز شدن هیچ پورت ورودی و بدون آنکه چیزی برای متوقف کردنش در اختیار فایروال محیطی یا NAT فقط-خروجی باشد. گرداننده با پرس‌وجو از API عامل محلی ngrok (127.0.0.1:4040/api/tunnels) برپایی تونل را تأیید کرد و URL عمومی حاصل را به بات Telegram خود فرستاد و بدین ترتیب هر میزبان تازه‌تسخیرشده را به دستگیره‌ای برای اتصال با یک کلیک تبدیل کرد.

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

godhive به یک C2 واحد تکیه نمی‌کند. کانال‌ها را به ترتیب دشواری حذف هر یک روی هم می‌چیند. در پایین‌ترین لایه یک شبکه همتا‌به‌همتای Kademlia با چالش‌های اثبات کار برای پیوستن و عبور از NAT قرار دارد که هیچ نقطه مرکزی برای توقیف ندارد. بالاتر از آن EtherHiding قرار می‌گیرد که در آن نشانی جاری بک‌اند در یک قرارداد هوشمند بلاک‌چینی ذخیره می‌شود که قابل ابطال نیست و در زمان اجرا از طریق یک رله فعال Cloudflare Workers (c2-proxy.operator.workers[.]dev) که بک‌اند را از دید مدافعان پنهان می‌کند، تفکیک می‌شود. بالاتر از آن دامنه‌های پشتیبان تولیدشده به شکل الگوریتمی هستند که از طریق DNS-over-HTTPS با SNI جعلی دریافت می‌شوند، یک سرویس مخفی Tor، نقاط رهاسازی در gistهای GitHub، هشت کانال نرم‌افزار به عنوان سرویس، و Telegram به عنوان کانال اصلی گرداننده. سنجش سوختگی، رشته‌ای از پرس‌وجوهای بی‌پاسخ فرمان را می‌پاید و به طور خودکار گرداننده را با یک پشتیبان رمزشده از تنظیمات به زیرساخت تازه منتقل می‌کند، و یک قابلیت فدراسیون از هماهنگی میان چندین بات پشتیبانی می‌کند.

ما رله Cloudflare Workers را از بیرون انگشت‌نگاری کردیم و تأیید شد که فعال است و درخواست‌ها را پردازش می‌کند: نقاط پایانی ثبت‌نام، توزیع وظیفه و داشبورد به یک بک‌اند مسیریابی می‌شوند، در حالی که ورودی بدون احراز هویت رد می‌شود؛ این با توکن‌های رمزشده AEAD که فایل اجرایی برای احراز هویت C2 به کار می‌برد سازگار است. گرداننده همچنین یک داشبورد مدیریتی سخت‌سازی‌شده را پشت آن اجرا می‌کند، با درهم‌سازی گذرواژه Argon2، احراز هویت چندعاملی، دسترسی مبتنی بر نقش و حتی گزینه‌های پساکوانتومی در تنظیمات TLS آن. این کارِ کسی است که با یک بات‌نت مانند زیرساخت محصول نهایی رفتار می‌کند، تا حد صادر کردن سنجه‌های Prometheus برای آن.

نیمه دیگر: عملیات آماتور

با وجود همه این مهندسی، شیوه استقرار به گونه‌هایی بی‌احتیاط است که اهمیت دارد. کارزار از یک اتصال موبایل خانگی Verizon Wireless در ایالات متحده آمد (174.230.35[.]232، DNS معکوس 232.sub-174-230-35.myvzw.com، Gainesville، فلوریدا)، نه از یک میزبان ضدگلوله یا یک VPS، و در یک رشته خودکار فشرده و بدون استفاده مجدد از زیرساخت. توکن بات Telegram به صورت متن آشکار در کد درج شده است؛ یک نقطه واحد برای توقیف. بار مخرب XMRig از یک میزبان فایل ناشناس عمومی سرو می‌شد. و با همه کدهای شناسایی هانی‌پات، در یک رشته پرسروصدا از یک نشانی قابل ردیابی به کار گرفته شد.

فایل اجرایی روی macOS، زیر کاربری با نام dev، در دایرکتوری‌ای به نام research/godhive ساخته شده است. در کنار ناشناس‌سازی عامدانه هویت Telegram گرداننده، تنظیمات ناتمام و استقراری که خود را افشا می‌کند، صرفه‌جویانه‌ترین خوانش این است که یک توسعه‌دهنده تنهای ماهر در حال آزمایش و اجرای چارچوب خودش است، نه مشتری یک بستر بدافزار به عنوان سرویس. برند پرداخته است، با لوگوی اختصاصی کندوی طلایی و شعار «one mind, one purpose, one hive»؛ عملیات چنین نیست.

انتساب

کارزار از طریق زیرساخت Telegram به یک گرداننده واحد گره می‌خورد. godhive اعتبارنامه‌های دزدیده‌شده، URLهای تونل و تأییدیه‌های آلودگی را به یک بات درج‌شده در کد، @godhive_bot (شناسه بات 8836117161)، می‌فرستد. chat_id ثبت‌شدهٔ آن به یک حساب شخصی، @godhive77 (شناسه کاربر 7659611777)، می‌رسد که نام نمایشی‌اش چند زیرخط است و عکس نمایه ندارد؛ تلاشی برای ناشناسی که خودِ شناسه godhive77 آن را نقض می‌کند. همان گرداننده یک کانال رزرو متناظر هم در اختیار دارد، @godhive (یک مشترک، بدون پست عمومی، بازفرست غیرفعال)، و شناسه کاربری ترتیبی Telegram، زمان ساخت حساب را اواخر 2024 نشان می‌دهد. شناسه godhive77 قوی‌ترین نقطه چرخش برای انتساب بیشتر است.

شاخص‌های نفوذ

زیرساخت مهاجم بی‌خطرسازی شده است. سرویس‌های قانونی شخص ثالث که بدافزار از آن‌ها سوءاستفاده می‌کند، برای امکان شناسایی دست‌نخورده مانده‌اند.

شبکه و میزبان

شاخص	زمینه
c2-proxy.operator.workers[.]dev	رله فعال C2 روی Cloudflare Workers (به Cloudflare گزارش شود)
hxxps://files.catbox.moe/p46h39.gz	بار مخرب XMRig روی یک میزبان فایل ناشناس (SHA-256 cb49ae0793b2…)
bin.equinox.io/c/.../ngrok-v3-stable-linux-amd64.tgz	دانلود ngrok (CDN قانونی)؛ خروج ترافیک به bin.equinox.io از یک سرور همان نشانه است
127.0.0.1:4040/api/tunnels	پرس‌وجو از عامل محلی ngrok (خواندن URL عمومی تونل اختصاص‌یافته)
169.254.169.254/latest/meta-data/	SSRF علیه فرادادهٔ ابری برای سرقت اعتبارنامه
api.telegram.org	C2 و خروج داده از طریق بات Telegram؛ خروج ترافیک از بارکاری‌های سروری نشانه شکار است
gitlab.com/nzyme/	مرحله‌بندی ابزارهای استاتیک (sshpass، redis-cli، wget، tor، proxychains)
2captcha.com، hashes.org، nitrxgen.net	سرویس‌های حل CAPTCHA و شکستن درهم‌سازه که در خط لوله اعتبارنامه مورد سوءاستفاده قرار می‌گیرند
r[1-20]---sn-*.googlevideo.com، manifest.googlevideo.com	نام‌های میزبان واقعی CDN یوتیوب که برای جعل SNI در TLS به کار می‌روند؛ هنگام تفکیک به IPهای غیرگوگل هشدار دهید

عامل، هویت C2 و مسیر دریافت وجه

شاخص	زمینه
174.230.35[.]232	منبع کارزار (موبایل Verizon Wireless، 232.sub-174-230-35.myvzw.com، Gainesville FL)؛ یک نشانی پویای اپراتور با ارزش مسدودسازی پایین
@godhive_bot (شناسه بات Telegram 8836117161)	بات C2 و خروج داده بدافزار؛ توکن به صورت درج‌شده در فایل اجرایی (راز در اینجا حذف شده؛ برای توقیف به Telegram گزارش شد)
@godhive77 (شناسه کاربر Telegram 7659611777)	حساب خروج داده گرداننده و قوی‌ترین نقطه چرخش برای انتساب
@godhive (شناسه کانال Telegram -1002105830453)	کانال رزرو گرداننده
49aXwwgXBKRKTUVgYuLy3fZkTeLP3PWgMhwiyK55Ur7WhgYXJ33N8JZG87vzUV1UyVdZzPGLvx1w9YQHk7faWPn1UzJte2R	کیف‌پول تأییدشدهٔ دریافت Monero (جفت‌شده با تنظیمات فعال XMRig)
pool.minexmr.com:4444	استخر در تنظیمات XMRig؛ توجه کنید که minexmr در سال 2022 تعطیل شد، پس این مقدار پیش‌فرض ناکام می‌ماند

فایل‌ها و آثار

• فایل اجرایی godhive (بازسازی‌شده): SHA-256 4194f2337c2b261ed6e1fd0b6d18f0ba75388bdc91a2658eb827a154ed784f36 (ELF از نوع x86-64 با حجم 6.2 MB، در VirusTotal موجود نیست). سرآیندهای ELF آن عامدانه مخدوش شده‌اند تا حجم را حدود 106 MB اعلام کنند و کد را به نقطه‌ای پس از پایان فایل ارجاع دهند و بدین ترتیب ابزارهای استاندارد را ناکام بگذارند.
• پایداری روی میزبان: /etc/godhive، /host/usr/local/bin/sysd (فایل اجرایی جعلی systemd)، /host/tmp/godhive_deployed.txt، فرایند godhive_c2، ایمیج سفارشی درون‌کانتینری godhive:latest.
• امضای فرار از کانتینر: کانتینری که با Privileged:true، network_mode:host و یک bind از نوع /:/host:rw ساخته شده باشد.
• اثر ساخت: مسیرهای cargo زیر /Users/dev/.cargo/registry/src/ و یک دایرکتوری ساخت research/godhive (توسعه‌دهنده macOS).
• نشانه سخت‌سازی میزبان: گذرواژه Redis تنظیم‌شده روی CHANGED_BY_GODHIVE؛ یک وب‌شل b374k.php در کنار فعالیت جست‌وجوی فراگیر علیه WordPress.

رفتاری

• pkill -9 xmrig|lolMiner|minerd|godhive_c2 و پس از آن mkdir /host/etc/godhive.
• خواندن /host/etc/shadow و /host/root/.ssh/authorized_keys از یک mount کانتینری.
• فرایندی با نام sysd که systemd واقعی نیست؛ نوشتن‌های efibootmgr که یک ورودی بوت EFI با برچسب “System Core” می‌سازد.
• دایرکتوری کاری Nuclei به نام /tmp/.nuclei_assault-t*.

شناسایی

• برای ترافیک خروجی به bin.equinox.io و هر میزبان *.ngrok* از سرورها، و برای پرس‌وجوی API عامل ngrok روی 127.0.0.1:4040/api/tunnels هشدار تنظیم کنید.
• برای هر کانتینری که با Privileged:true و یک bind از نوع /:/host ساخته می‌شود هشدار تنظیم کنید؛ این جفت شدن تقریباً به یقین تلاش برای فرار است.
• برای خروج ترافیک بارکاری‌های سروری به api.telegram.org، c2-proxy.operator.workers[.]dev، gitlab.com/nzyme/، 2captcha.com و سرویس‌های شکستن درهم‌سازه هشدار تنظیم کنید.
• برای فرایند sysd، برای از کار افتادن یا متوقف شدن عامل‌های EDR (falcon-sensor، SentinelOne، cbdefense، sophos-edr، cylancesvc) و برای CONFIG SET requirepass CHANGED_BY_GODHIVE هشدار تنظیم کنید.
• ترافیک TLS با SNI مربوط به googlevideo.com که به IPهای غیرگوگل تفکیک می‌شود، و manifest.googlevideo.com از فرایندهای غیرمرورگر را به عنوان شکل‌دهی ترافیک تلقی کنید.

اقدامات کاهشی

• هرگز Docker API را روی 2375 بدون احراز هویت در معرض دسترس قرار ندهید. آن را به localhost مقید کنید و احراز هویت کلاینت با TLS را فعال کنید. این علت ریشه‌ای است.
• no-new-privileges را الزامی کنید، --privileged را حذف کنید و bind mountهای میزبان را محدود کنید، یا Docker بدون root یا gVisor را اجرا کنید.
• دسترسی کانتینرها به سرویس فرادادهٔ ابری (169.254.169.254) را مسدود کنید و IMDSv2 را الزامی سازید.
• خروج ترافیک را فیلتر کنید: بارکاری‌های سروری نباید به میزبان‌های فایل ناشناس، ngrok، Telegram، حل‌کننده‌های CAPTCHA یا مسیرهای مرحله‌بندی ابزار استاتیک که در بالا آمد دسترسی داشته باشند.
• Secure Boot را فعال کنید تا پایداری UEFI کم‌اثر شود، و حفاظت ضددست‌کاری را روی عامل‌های نقطه پایانی فعال کنید، چرا که godhive می‌کوشد آن‌ها را از کار بیندازد.
• اگر احتمال می‌دهید میزبانی نفوذ کرده است، کلیدهای API صرافی‌ها را بی‌درنگ بچرخانید؛ godhive برداشت‌ها را خودکار می‌کند.

نگاشت MITRE ATT&CK

تاکتیک	تکنیک
دسترسی اولیه	T1190 Exploit Public-Facing Application (Docker API؛ و Redis، Kubernetes، WordPress، Log4Shell در زرادخانه)
اجرا	T1610 Deploy Container؛ T1059.004 Unix Shell
ارتقای سطح دسترسی	T1611 Escape to Host (کانتینر privileged، mount میزبان)
پایداری	T1543 Create or Modify System Process (sysd)؛ T1542.003 Bootkit (UEFI)؛ T1014 Rootkit
گریز از دفاع	T1562.001 Impair Defenses (از کار انداختن EDR)؛ T1070 Indicator Removal (حذف لاگ)؛ T1497 Virtualization/Sandbox Evasion (شناسایی هانی‌پات و ماشین مجازی)؛ T1036 Masquerading (sysd، SNI یوتیوب)؛ T1027 Obfuscated Files (ELF مخدوش)
دسترسی به اعتبارنامه	T1003.008 /etc/passwd و /etc/shadow؛ T1552.004 Private Keys؛ T1552.005 Cloud Instance Metadata API
کشف	T1046 Network Service Scanning (Masscan، Nuclei)
فرمان و کنترل	T1572 Protocol Tunneling (ngrok)؛ T1090 Proxy؛ T1071.001 Web Protocols (Telegram، Cloudflare Workers)؛ T1102 Web Service (gistهای GitHub، کانال‌های SaaS)
اثر	T1496 Resource Hijacking (XMRig)؛ T1486 Data Encrypted for Impact (باج‌افزار)؛ T1657 Financial Theft (تخلیه صرافی و DeFi)؛ T1498 Network Denial of Service

روش‌شناسی و یادداشت‌ها

• تحلیل، تحلیل ایستای فایل اجرایی ELF است که به طور کامل از قطعه‌های درون‌خطی base64 خودِ گرداننده که هانی‌پات ثبت کرده بود بازسازی شد، همراه با بازبینی ترافیک ثبت‌شدهٔ Docker-API و شناسایی بیرونی مجاز روی رله فعال Cloudflare Workers گرداننده. هیچ بدافزاری اجرا نشد و هیچ تلاشی برای احراز هویت در C2 صورت نگرفت.
• شاخص‌ها بی‌خطرسازی شده‌اند و سرویس‌های قانونی شخص ثالث که بدافزار از آن‌ها سوءاستفاده می‌کند برای امکان شناسایی دست‌نخورده مانده‌اند.
• نمونه‌ها در صورت درخواست در اختیار سایر پژوهشگران و مدافعان قرار می‌گیرد. به contact@kinryu.sh ایمیل بزنید و در چند خط بنویسید که چه کسی هستید و نمونه‌ها را برای چه می‌خواهید.