
نوشته شده توسط
B-Vedadian
تکنيک بکار رفته طبق اون چيزي که تو MUP آخري بود، nanomite نيست.
نانومايت روشيه که در اون، کد اصلي که اجرا ميشه شامل خيلي از jmpهاي لازم نيست. بجاي اونها وقفه ديباگ قرار گرفته. اين يعني اگه هم بتوني برنامه رو دامپ کني، عملا به هيچ دردي نمي خوره، مگر اينکه مکانهاي پرش به درستي پيدا بشه و با پرشهاي مناسب جايگزين بشه. البته اين تکنيک هم قابل شکستنه ولي خوب، کار سخت تره.
روش کار نانوميت به اين صورته که در ابتدا يک برنامه تهيه ميشه و در محلهايي که توسط يک کارشناس مناسب تشخيص داده شدن، يک علامت کنار پرشها(يا پرشهاي شرطي) گذاشته ميشه. در مرحله بعد يک برنامه ديگه اين مکانها رو تو فايل اصلي پيدا کرده و بعدش مقادير پرشها رو با int3 عوض ميکنه. به ازاي هر کدوم از اين پرشها تو يه جدول که به همين منظور طراحي شده، مشخصاتش رو يادداشت ميکنه. حالا يک stub به برنامه اضافه ميشه که در ابتدا مجوز ديباگ رو براي پروسه خودش فعال ميکنه و بعدش به عنوان يک ديباگر برنامه اصلي رو اجرا ميکنه.
هر وقت به يکي از اون پرشهاي کذايي برسيم، حالا جاش int3 هستش و بنا بر اين، پروسه پدر فراخواني ميشه. پروسه پدر با توجه به context پروسه فرزند (خصوصا مقدار EIP) از جدول محل مناسب پرش رو پيدا کرده و پروسه فرزند رو به اون هدايت ميکنه.
براي اينکه محافظت قوي باشه، تمام احتياطهاي لازم تو پروسه پدر بايد بکار گرفته بشه. جدول مربوط به پرشها هم بايد طي يک رويه کاملا مبهم شده (obfuscated) جستجو بشه. علاوه بر اون جدول رو با کلي اطلاعات الکي و چرت و پرت مخلوط ميکنن.
براي باز سازي اينجور تصاوير اجرايي، بايد يج جوري از شر روتينهاي شناسايي ديباگر و ... خلاص شد و بعدش سر بزنگاه موقع فراخواني GetThreadContext و SetThreadContext يقه پروسه پدر رو گرفت و از اونجا جدول پرش رو بازسازي کرد.