NEW BOT Телеграм, страница

نکته‌

اگر دیدید چند فیلد int پشت‌سر همن تقریبا همیشه یک struct است نه آرایه

اگر یک offset یهو زیاد شد مثل 16 یعنی وجود double / pointer / align

This section is used in reverse malware unpacking analysis of C++ functions and Libs

Struct inside struct

Example C:

struct B {
int x;
int y;
};

struct A {
int id;
struct B pos;
double score;
};

In memory it looks like this:

offset 0 id (int)

offset 4 pos.x (int)

offset 8
pos.y (int)

offset 12 padding
(to align double)

offset 16 score (double)

In assembly:

mov eax, DWORD PTR [rdi] ; id
mov eax, DWORD PTR [rdi + 4] ; pos.x
mov eax, DWORD PTR [rdi + 8] ; pos.y
movsd xmm0, [rdi + 16] ; score

Tip

If you see multiple int fields in a row, it's almost always a struct, not an array

If an offset suddenly increases, like 16, it means there's a double / pointer / align

@reverseengine

❤1

102 viewsedited 21:00

ReverseEngineering

بخش سیزدهم بافر اورفلو

مفهوم ret2libc و چطور از توابع libc برای هدایت اجرا استفاده میکنیم

چرا وقتی استک مال ما قابل اجرا نیست NX یا آدرس‌ ها جا به‌ جا میشن به جای گذاشتن شل‌ک د روی استک میریم سراغ توابع آماده libc مثل puts یا printf یا در حالت خطرناک system

وقتی نمیتونم کد بذاریم و اجراش کنیم NX یا آدرس‌ها متغیرن ASLR میایم از کتابخونه سیستم استفاده میکنیم به جای اینکه RIP رو بندازیم روی شل‌ کد خودمون RIP رو میندازیم روی آدرس تابعی تو libc که قبلا هم خود برنامه ازش استفاده کرده puts و آرگومان مناسب رو هم جوری کنار میذاریم که puts یه رشته دلخواه رو چاپ کنه
این ایده دو مرحله اصلی داره

1 نشت آدرس libc یا یک آدرس ثابت پیدا میکنیم

2 از اون آدرس استفاده میکنیم تا آدرس توابع libc را محاسبه کنیم و بعد RIP رو به آن تابع ببریم

Code C:

file9_demo.c

#include <stdio.h>
#include <string.h>

char secret[] = "this is a libc string for demo";

void vuln(char *s) {
    char buf[32];
    strcpy(buf, s);   /* unsafe but دمو */
    puts("returned from vuln");
}

int main(int argc, char **argv) {
    if (argc < 2) {
        printf("usage %s input\n", argv[0]);
        return 1;
    }
    vuln(argv[1]);
    puts("program finished");
    return 0;
}

ret2libc
یعنی استفاده از توابع آماده libc به جای اجرای شل‌ کد روی استک

معمولا دو قدم لازمه:
نشت آدرس و بعد پر کردن استک جوری که وقتی برگشت تابع libc اجرا بشه با آرگومان مناسب

امنیت: NX و ASLR و PIE ترکیبی هستند که کار رو پیچیده میکنن

Part 13 Buffer Overflow

The concept of ret2libc and how we use libc functions to direct execution

Why when our stack is not executable NX or addresses are moved instead of putting shellcode on the stack we go to ready libc functions like puts or printf or in dangerous mode system

When we can't write code and execute it NX or addresses are variable ASLR we use the system library Instead of putting RIP on our shellcode we put RIP on the address of a function in libc that the program has already used puts and we leave the appropriate argument in such a way that puts prints a desired string

This idea has two main steps

1 We find a libc address leak or a fixed address

2 We use that address to calculate the address of libc functions and then put RIP to that function

Code C:

file9_demo.c

#include <stdio.h>
#include <string.h>

char secret[] = "this is a libc string for demo";

void vuln(char *s) {
    char buf[32];
    strcpy(buf, s);   /* unsafe but demo */
    puts("returned from vuln");
}

int main(int argc, char **argv) {
    if (argc < 2) {
        printf("usage %s input\n", argv[0]);
        return 1;
    }
    vuln(argv[1]);
    puts("program finished");
    return 0;
}

ret2libc
i.e. using ready-made libc functions instead of executing shellcode on the stack

Usually two steps are required:
Leak the address and then fill the stack so that when the libc function returns it is executed with the appropriate arguments

Security: NX, ASLR and PIE are a combination that complicates the task

@reverseengine

👍2

105 viewsedited 21:15

ReverseEngineering

پاکسازی ردپای پردازشی Process Artifacts

Process Artifact

هر برنامه‌ ای که اجرا میکنید حتی ساده‌ ترین اسکریپت یه سری اثر پردازشی از خودش میذاره:

چه ساعتی اجرا شد

چه Threadهایی ساخت

چه Handle هایی باز کرد

چه Module هایی لود شدن

چه مقدار RAM مصرف کرد

چه Parent داشت

چه Token استفاده کرد

این چیزاست که DFIR و EDR عاشقشن چون با همین‌ ها مسیر حمله رو از اول تا اخر reconstruct میکنن

مهم‌ ترین ردپاهای پردازشی که معمولا جا میمونه

Process Creation Info

مثل یک پرونده:
StartTime CommandLine ParentProcess، IntegrityLevel

Modules / DLLs

لیست DLL هایی که لود شدن معمولا کاملا مشخصه

Thread Artifacts

حتی اگه بعدا پاک بشه،اطلاعات Thread Creation یه مدت زنده میمونه

Handle Table

فایل‌ها pipeها registry ها mutex ها
هر کدوم روی handle اثر میذاره

Memory Layout

حتی اگر inject کرده باشید footprint بخش تزریقی تو Virtual Memory Table مشخصه

Token Artifacts

نوع توکن privilege هایی که borrow شده بودن Owner/Group

چطور باید کاهش شون بدیم

عمر پروسه رو کوتاه نگه داری

بیشتر artifact ها بر اساس زمان بالا بودن پروسه جمع میشن

تا جای ممکن کار های خارجی لود نکنید

هر DLL اضافه = یک trace

Thread نسازید مگر لازم باشه

Thread
کمتر یعنی footprint کمتر

Handle Hygiene

هرچیزی باز شد خیلی زود ببندید

خیلیا کدشون رو handle باز میذارن و همون میشه سند جرم

Memory Hygiene

Buffer
های بزرگ الکی نسازید

Memory section
های عجیب نذارید و حتما free کنید

رفتار Parent-Child منطقی باشه

اگه ParentSpoofing ناقص باشه artifact ش تو توکن و timestamps مشخصه

هرچی زنجیره عجیب‌ تر باشه
لو رفتن بیشتر میشه

Process Artifacts Cleanup

Process Artifact

Every program you run, even the simplest noscript, leaves behind a series of process traces:

What time it was run

What threads it created

What handles it opened

What modules were loaded

How much RAM it consumed

What parent it had

What token it used

This is what DFIR and EDR love because they reconstruct the attack path from start to finish

The most important process traces that are usually left

Process Creation Info

Like a file:

StartTime CommandLine ParentProcess, IntegrityLevel

Modules / DLLs

List of DLLs that were loaded is usually quite specific

Thread Artifacts

Even if it is later cleared, Thread Creation information remains alive for a while

Handle Table

Files, pipes, registries, mutexes

Each of which affects the handle

Memory Layout

Even if you have injected the footprint of the injected part In the Virtual Memory Table, it is specified

Token Artifacts

Type of borrowed privilege tokens Owner/Group

How to reduce them

Keep the process life short

Most artifacts are accumulated based on the time the process is up

Do not load external tasks as much as possible

Each additional DLL = a trace

Do not create threads unless necessary

Fewer threads means less footprint

Handle Hygiene

Close everything that is opened very quickly

Many people leave their code handles open and that is evidence of the crime

Memory Hygiene

Do not create excessively large buffers

Do not leave strange memory sections and be sure to free them

Parent-Child behavior should be logical

If ParentSpoofing is incomplete, the artifact is specified in the token and timestamps

The stranger the chain, the more leakage

@reverseengine

❤1

92 viewsedited 21:28

About

Blog

Apps

Platform