🔵 عنوان مقاله
Ad and PR Giant Dentsu Says Hackers Stole Merkle Data (3 minute read)
🟢 خلاصه مقاله:
شرکت ژاپنی Dentsu اعلام کرد زیرمجموعهاش Merkle دچار نفوذ داده شده که اطلاعات حساس مشتریان، تأمینکنندگان و کارکنان را افشا کرده است. این رویداد پس از مشاهده فعالیت غیرعادی در شبکه Merkle شناسایی شد و برای مهار آن برخی سیستمها موقتاً از مدار خارج شدند. بررسی برای تعیین دامنه و نوع دادههای افشاشده ادامه دارد و احتمال اختلال موقت در سرویسها و افزایش ریسک فیشینگ و سوءاستفاده از اطلاعات برای ذینفعان وجود دارد.
#حمله_سایبری #نفوذ_داده #امنیت_اطلاعات #نشت_اطلاعات #Dentsu #Merkle #تبلیغات_دیجیتال #حریم_خصوصی
🟣لینک مقاله:
https://www.securityweek.com/ad-and-pr-giant-dentsu-says-hackers-stole-merkle-data/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Ad and PR Giant Dentsu Says Hackers Stole Merkle Data (3 minute read)
🟢 خلاصه مقاله:
شرکت ژاپنی Dentsu اعلام کرد زیرمجموعهاش Merkle دچار نفوذ داده شده که اطلاعات حساس مشتریان، تأمینکنندگان و کارکنان را افشا کرده است. این رویداد پس از مشاهده فعالیت غیرعادی در شبکه Merkle شناسایی شد و برای مهار آن برخی سیستمها موقتاً از مدار خارج شدند. بررسی برای تعیین دامنه و نوع دادههای افشاشده ادامه دارد و احتمال اختلال موقت در سرویسها و افزایش ریسک فیشینگ و سوءاستفاده از اطلاعات برای ذینفعان وجود دارد.
#حمله_سایبری #نفوذ_داده #امنیت_اطلاعات #نشت_اطلاعات #Dentsu #Merkle #تبلیغات_دیجیتال #حریم_خصوصی
🟣لینک مقاله:
https://www.securityweek.com/ad-and-pr-giant-dentsu-says-hackers-stole-merkle-data/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
SecurityWeek
Ad and PR Giant Dentsu Says Hackers Stole Merkle Data
Japan’s Dentsu has disclosed a Merkle data breach impacting clients, suppliers, and employees.
👍1
🔵 عنوان مقاله
Architecture Tests
🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرحشدهای رفته است: تستهای معماری. او توضیح میدهد که این تستها مجموعهای از قواعد اجراییاند که مرزهای معماری، وابستگیهای مجاز، نبود حلقههای وابستگی و قواعد نامگذاری/لایهبندی را بررسی میکنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان میدهد چگونه میتوان این قواعد را کنار تستهای معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آنها را به شکستپذیر کردن بیلد گره زد. توصیههای عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگامسازی با تصمیمهای معماری و بهروزرسانی مداوم تستهاست. نتیجهٔ نهایی: تستهای معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل میکنند و بهعنوان گاردریلهای ماندگار، ساختار سالم کد را حفظ میکنند.
#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality
🟣لینک مقاله:
https://cur.at/WG4foAM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Architecture Tests
🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرحشدهای رفته است: تستهای معماری. او توضیح میدهد که این تستها مجموعهای از قواعد اجراییاند که مرزهای معماری، وابستگیهای مجاز، نبود حلقههای وابستگی و قواعد نامگذاری/لایهبندی را بررسی میکنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان میدهد چگونه میتوان این قواعد را کنار تستهای معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آنها را به شکستپذیر کردن بیلد گره زد. توصیههای عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگامسازی با تصمیمهای معماری و بهروزرسانی مداوم تستهاست. نتیجهٔ نهایی: تستهای معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل میکنند و بهعنوان گاردریلهای ماندگار، ساختار سالم کد را حفظ میکنند.
#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality
🟣لینک مقاله:
https://cur.at/WG4foAM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Architecture Tests
Architecture tests are an essential part of maintaining a healthy architecture. First time hearing? No worries, we will explore what those…
به اون کاری که امروز کردی نگو "ریفکتور" (Refactor). اگه تست نداره، اون فقط یه "گندکاریِ تمیزه".
این فقط یه جملهی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ️ تو یه پروژهی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکهتیکهاش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفهای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد. کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطقهای تجاری پنهان و وابستگیهای زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کمبهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تلهی کد تمیز"ئه. مهمترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تستهای مشخصهیابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همهی باگهاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.
<Hossein Moradi/>
این فقط یه جملهی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ️ تو یه پروژهی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکهتیکهاش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفهای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد. کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطقهای تجاری پنهان و وابستگیهای زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کمبهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تلهی کد تمیز"ئه. مهمترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تستهای مشخصهیابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همهی باگهاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.
<Hossein Moradi/>
❤1👍1
🔵 عنوان مقاله
Understanding Playwright Agents
🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمونهای مرورگری است: بهجای نوشتن تکتک گامها، هدف را توصیف میکنید و عاملها با برنامهریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا میکنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخابگرهای پایدار—زمان ساخت تست را کاهش میدهد و نگهداری را آسانتر میکند. معماری هسته شامل سه بخش برنامهریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدلمحور تلاش میکند هم انعطافپذیر باشد و هم قابلیت بازپخش و مشاهدهپذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عاملها، الگوی حلقه تصمیمگیری، ساخت مدل از DOM و مثالهای عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح میدهد و در کنار آن، محدودیتها و بهترینروشها را نیز بیان میکند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پینکردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تستهای اولیه و سپس تثبیت آنها به اسکریپتهای قطعی Playwright است.
#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools
🟣لینک مقاله:
https://cur.at/NqUSz5D?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Understanding Playwright Agents
🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمونهای مرورگری است: بهجای نوشتن تکتک گامها، هدف را توصیف میکنید و عاملها با برنامهریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا میکنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخابگرهای پایدار—زمان ساخت تست را کاهش میدهد و نگهداری را آسانتر میکند. معماری هسته شامل سه بخش برنامهریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدلمحور تلاش میکند هم انعطافپذیر باشد و هم قابلیت بازپخش و مشاهدهپذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عاملها، الگوی حلقه تصمیمگیری، ساخت مدل از DOM و مثالهای عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح میدهد و در کنار آن، محدودیتها و بهترینروشها را نیز بیان میکند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پینکردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تستهای اولیه و سپس تثبیت آنها به اسکریپتهای قطعی Playwright است.
#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools
🟣لینک مقاله:
https://cur.at/NqUSz5D?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Awesome Testing
Understanding Playwright Agents
A deep dive into Playwright Agents and the Model Context Protocol (MCP) — how Microsoft’s latest AI-powered Playwright release automates test planning, script generation, and self-healing browser tests across Chrome, Firefox, and WebKit.
Forwarded from Gopher Job
A Data Structure Algorithms Low Level Design and High Level Design collection of resources.
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
GitHub
GitHub - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD: A Data Structure Algorithms Low Level Design and High Level Design collection…
A Data Structure Algorithms Low Level Design and High Level Design collection of resources. - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
👍1
🔵 عنوان مقاله
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
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
GitHub
signature-base/yara/apt_cn_brickstorm_sep25.yar at master · Neo23x0/signature-base
YARA signature and IOC database for my scanners and tools - Neo23x0/signature-base
🔵 عنوان مقاله
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
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
Medium
Debugging Mobile Web Apps Shouldn’t Be This Hard — So I Built a Logger
The Nightmare Scenario
🔵 عنوان مقاله
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
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
Krebs on Security
Google Sues to Disrupt Chinese SMS Phishing Triad
Google is suing more than two dozen unnamed individuals allegedly involved in peddling a popular China-based mobile phishing service that helps scammers impersonate hundreds of trusted brands, blast out text message lures, and convert phished payment card…
🔵 عنوان مقاله
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
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
SecurityWeek
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks
On Android, the out-of-bounds write issue can be triggered during the processing of media files without user interaction.
🔵 عنوان مقاله
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
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
Medium
How I Automated Test Scope Analysis with a CLI Tool
A Node.js tool that uses GitHub APIs to instantly analyze code changes, and generate AI-powered test recommendations
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
با رشد مدلهای زبانی بزرگ و پیشرفته، هزینه و زمان پاسخدهی هم به شدت افزایش پیدا کرده. مدلهایی مثل 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