Software Engineer Labdon
625 subscribers
43 photos
4 videos
2 files
804 links
👑 Software Labdon

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Improved BRICKSTORM YARA Rules (GitHub Repo)

🟢 خلاصه مقاله:
به‌روزرسانی تازه‌ای از سوی Florian Roth بر پایه گزارش Google درباره بدافزار BRICKSTORM منتشر شده که مجموعه قوانین YARA را در یک مخزن GitHub به‌طور شفاف‌تر، سریع‌تر و قابل اتکاتر می‌کند. او با حذف regexهای غیرضروری، کاهش خطای مثبت و بهبود کارایی اسکن را هدف گرفته و با شفاف‌سازی encoding رشته‌ها و توالی‌های بایتی، از رفتار یکسان قوانین در حالت‌های مختلف اطمینان داده است. همچنین با ساده‌سازی و یکپارچه‌سازی قواعد، نگهداشت و فهم آن‌ها آسان‌تر شده است. افزوده‌شدن metadata شامل ارجاع به گزارش Google، اطلاعات نویسنده و نسخه، شفافیت و قابلیت پیگیری را افزایش می‌دهد و استقرار و بهبود مستمر قوانین را برای تیم‌های دفاعی ساده‌تر می‌کند.

#YARA #BRICKSTORM #MalwareDetection #ThreatIntel #Google #FlorianRoth #CyberSecurity #GitHub

🟣لینک مقاله:
https://github.com/Neo23x0/signature-base/blob/master/yara/apt_cn_brickstorm_sep25.yar?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
Debugging Mobile Web Apps Shouldn't Be This Hard, So I Built a Logger

🟢 خلاصه مقاله:
به‌گفته‌ی Nishant Bhandari، دیباگ اپلیکیشن‌های وب موبایل بیش از حد دشوار شده است؛ ابزارهای دسکتاپ و ریموت همیشه شرایط واقعی دستگاه را نشان نمی‌دهند. او برای ساده‌سازی این روند، ابزار متن‌باز interactive-logger را معرفی می‌کند؛ ابزاری سبک که با افزودن یک قطعه کوچک، لاگ‌ها و خطاها را همان‌جا روی دستگاه و به‌صورت لحظه‌ای نمایش می‌دهد تا بازتولید و اشتراک‌گذاری باگ‌ها سریع‌تر و دقیق‌تر انجام شود. تمرکز این راهکار روی سادگی و کارکرد در سناریوهای رایج وب موبایل (مانند PWA و WebView) و بدون وابستگی به فریم‌ورک است.

#MobileWeb #Debugging #DevTools #OpenSource #Logging #WebDev #JavaScript #Frontend

🟣لینک مقاله:
https://cur.at/vp45Wp0?m=web


👑 @software_Labdon
🔵 عنوان مقاله
Google Sues to Disrupt Chinese SMS Phishing Triad (2 minute read)

🟢 خلاصه مقاله:
Google در دادگاه Southern District of New York علیه ۲۵ نفر مرتبط با ابزار چینی Lighthouse شکایت کرده است؛ ابزاری از نوع phishing-as-a-service که با پیامک‌های جعلی به نام USPS، اپراتورهای عوارض جاده‌ای، پلتفرم‌های تجارت الکترونیک و مؤسسات مالی، بیش از یک میلیون قربانی را در ۱۲۰ کشور هدف قرار داده است. این شبکه با هدایت کاربران به وب‌سایت‌های موبایلی جعلی، داده‌های کارت پرداخت را جمع‌آوری می‌کند و سپس با سوءاستفاده از فرایندهای ثبت‌نام قانونی Apple Pay و Google Pay، از طریق فریب کاربران برای ارائه کدهای یکبارمصرف، کارت‌های سرقت‌شده را به کیف‌پول‌های موبایلی متصل می‌سازد. هدف شکایت، مختل‌کردن زیرساخت این عملیات و بازدارندگی از الگوهای مشابه در مقیاس جهانی است.

#Cybersecurity #Phishing #SMSPhishing #Google #ApplePay #GooglePay #PhaaS #Fraud

🟣لینک مقاله:
https://krebsonsecurity.com/2025/11/google-sues-to-disrupt-chinese-sms-phishing-triad/?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks (2 minute read)

🟢 خلاصه مقاله:
پژوهشگران Google's Project Zero یک آسیب‌پذیری ناشی از buffer overflow را در Dolby's Unified Decoder پیدا کرده‌اند؛ مولفه‌ای که در Android برای decode کردن محلی تمام پیام‌ها و پیوست‌های صوتی به‌کار می‌رود. این نقص می‌تواند به remote code execution منجر شود و به‌دلیل اجرای خودکار فرآیند decode در مسیر رسانه‌ای سیستم، امکان حملات zero-click را فراهم می‌کند؛ بدون اینکه کاربر کاری انجام دهد. از آنجا که بسیاری از اپ‌ها در Android برای پردازش‌های پس‌زمینه (مثل پیش‌نمایش یا استخراج اطلاعات صوتی) به همین decoder تکیه می‌کنند، سطح حمله گسترده است. توصیه می‌شود به‌محض انتشار، به‌روزرسانی‌های امنیتی Android و سازندگان دستگاه اعمال شود و از سخت‌سازی مسیرهای رسانه‌ای، sandboxing و شیوه‌های ایمن حافظه استفاده شود.

#Android #Security #Vulnerability #ZeroClick #RCE #Dolby #ProjectZero #Cybersecurity

🟣لینک مقاله:
https://www.securityweek.com/vulnerability-in-dolby-decoder-can-allow-zero-click-attacks/?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
How I Automated Test Scope Analysis with a CLI Tool

🟢 خلاصه مقاله:
** Josphine Job روند ساخت یک ابزار CLI با Node.js را توضیح می‌دهد که با استفاده از GitHub API تغییرات کد را به‌سرعت تحلیل می‌کند و پیشنهادهای هوشمند برای محدودهٔ تست ارائه می‌دهد. این ابزار با دریافت اطلاعات PR و commitها، فایل‌های تغییرکرده را بررسی و وابستگی‌ها را تحلیل می‌کند و سپس با لایهٔ هوش مصنوعی، سناریوهای تست اولویت‌دار (از واحد تا یکپارچه) پیشنهاد می‌دهد. خروجی می‌تواند در ترمینال، به‌صورت Markdown/JSON، یا به‌عنوان کامنت CI روی PR نمایش داده شود. ملاحظاتی مانند کش‌کردن، رعایت حریم خصوصی، و fallback آفلاین در نظر گرفته شده و هدف، کوتاه‌کردن چرخهٔ بازخورد و افزایش پوشش و اعتماد به تغییرات کد است.

#TestAutomation #CLI #NodeJS #GitHubAPI #AIinTesting #DevTools #CICD #SoftwareQuality

🟣لینک مقاله:
https://cur.at/SDG4cgz?m=web


👑 @software_Labdon
Forwarded from Linux Labdon
کاهش هزینه سیستم‌های هوش مصنوعی با Semantic Caching

با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب می‌شه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث می‌شه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.

یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور می‌شه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.

در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت می‌کنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق می‌کنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.

اینجاست که Semantic Caching وارد می‌شه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه می‌کنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر می‌شه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.

روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل می‌شه. بعد با بردارهای موجود در کش با Semantic Search مقایسه می‌شه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده می‌شه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره می‌شه تا دفعه بعدی قابل استفاده باشه.

پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست می‌ده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.

معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون می‌ده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص می‌کنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.

یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.

<Reza Jafari/>

👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
2