DEV Community: Rezo

პროგრამირების ენა Buk.

Rezo — Wed, 16 Sep 2026 08:00:30 +0000

რატომ კიდევ ერთი სისტემური პროგრამირების ენა?

Rust-მა პრაქტიკაზე დაამტკიცა, რომ უსაფრთხო სისტემური პროგრამირების ენების შექმნა garbage collector-ის გარეშე შესაძლებელია და ეს ნიშა ძალიან მოთხოვნადია.

C/C++-ზე დაწერილმა პროგრამებმა ათწლეულების განმავლობაში ათასობით კრიტიკული შეცდომა დააგროვეს, რის გამოც ხდებოდა უამრავი exploit-ის შექმნა, სისტემების გატეხვა და ასე შემდეგ. მეხსიერების ბაგები არის ექსპლოიტების ერთ ერთი ყველაზე მთავარი წყარო. გარდა ამისა მეხსიერების ბაგების გამო პროგრამები შეიძლება არასტაბილური იყოს, იქრაშებოდეს და ასე შემდეგ.

მაგრამ Rust-ს თავისი ფასი აქვს. ის ძალიან რთულია და მისი იმპლემენტაციის სპეციფიკიდან გამომდინარე უსაფრთხო მეხსიერების რეალიზაცია მხოლოდ კომპილატორის დონეზე არ ხდება, არამედ გადადის თვითონ ენაში და ტიპების სისტემაშიც, რის გამოც ის არ არის კითხვადი და ძალიან რთული ასათვისებელია სემანტიკურად.

Buk-ის შექმნის დროს ჩემს თავს დავუსვი ასეთი კითხვა:

შეიძლება თუ არა Rust-ის მსგავსი compile-time memory safety მივიღოთ უფრო პატარა source-level მოდელით?

ანუ სირთულე კი არ გავაქროთ, რაც შეუძლებელია, არამედ მისი დიდი ნაწილი კომპილატორში გადავიტანოთ. ამასთან ერთად გავასწოროთ Rust-ის მიერ დაგროვებული tech debt-ი.

Ownership და Borrow Checker

სანამ დეტალებზე გადავიდოდეთ, ორი ძირითადი ტერმინი განვმარტოთ.

Ownership ნიშნავს, რომ კონკრეტულ value-ს ჰყავს owner ("მფლობელი"), ანუ პროგრამის ის ნაწილი, რომელიც მასზე და მის რესურსებზეა პასუხისმგებელი.

let document = LoadDocument();

აქ ცვლადი document არის owner (LoadDocument-ის მიერ დაბრუნებული მნიშვნელობის ექსკლუზიური "მფლობელი").

თუ document ცვლადში არსებული მნიშვნელობა სხვა ფუნქციას მთლიანად გადავეცით, ownership-იც მასზე გადადის და ის ხდება ექსკლუზიური მფლობელი.

Publish(take document);

ამის შემდეგ ძველი მფლობელი ამ მნიშვნელობას ვეღარ გამოიყენებს.

Borrowing ნიშნავს მნიშვნელობის დროებით გამოყენებას ownership-ის გადაცემის გარეშე, ანუ "თხოვებას".

მაგალითად:

PrintSummary(document);

აქ ფუნქციას-ს მხოლოდ დროებითი წვდომა აქვს, ხოლო ექსკლუზიური მფლობელი ისევ document ცვლადი რჩება.

Borrow შეიძლება იყოს მხოლოდ წასაკითხად, ან exclusive mutation-ისთვის.

Buk-ში ეს სამი ოპერაცია შემდეგნაირად გამოიხატება:

Look    დროებითი read access (მხოლოდ გამოყენება/წაკითხვა)

Change  დროებითი exclusive mutation (გადავცემთ ექსკლუზიურ წვდომას რათა გამომყენებელმა შეძლოს რესურსის მნიშვნელობის შეცვლა, მისი მუდმივი ფლობის გარეშე)

Take    (ექსკლუზიური მფლობელობის სამუდამო გადაცემა)

კომპილატორი ამ ყველაფერს კომპილაციის დროს აკონტროლებს და ამოწმებს, რომ არც dangling reference შეიქმნას, არც უკვე გადაცემული მნიშვნელობა გამოვიყენოთ და არც conflicting access მოხდეს.

შესაბამისად, კიდევ ეღთხელ:

Buk-ი იყენებს manual memory management-ს, Garbage Collector-ის გარეშე.

Memory safety-ს კომპილატორი აკონტროლებს ownership და borrowing მოდელის საშუალებით.

ყველა owning value-ს ჰყავს owner ("მფლობელი").

კომპილატორი კომპილაციის დროს აკვირდება:

სად შეიქმნა მნიშვნელობა
ვინ ფლობს მას მოცემულ მომენტში
სხვა ფუნქციას ownership გადაეცა თუ მხოლოდ დროებითი access / წვდომა
ვის აქვს read access
ვის აქვს mutation უფლება
არსებობს თუ არა მის storage-ზე დამოკიდებული reference ან view
როდის მთავრდება borrow-ის ბოლო რეალური გამოყენება
შეიძლება თუ არა storage-ის invalidation ან გადაადგილება
ვის ეკისრება საბოლოოდ რესურსზე და მის გათავისუფლებაზე პასუხისმგებლობა

მაგალითად:

let sql = GenerateSQL();

GenerateTableMappings(sql);

Normalize(change sql);

let plan = Compile(take sql);

ერთი შეხედვით ჩვეულებრივი კოდია.

მაგრამ კომპილატორისთვის ამ ოთხ ხაზში სამი განსხვავებული ოპერაცია ხდება.

Look

Look ნიშნავს დროებით shared access-ს ownership-ის გადაცემის გარეშე.

func PrintSummary(document: Document)
{
    Print(document.Title);
}

Call site:

let document = LoadDocument();

PrintSummary(document);
PrintSummary(document);

PrintSummary(document) არ ნიშნავს, რომ Document დაკოპირდა.

არც ownership გადასულა.

ფუნქციამ უბრალოდ მიიღო დროებითი read access.
ფუნქციის დასრულების შემდეგ document ისევ გამომძახებელს ეკუთვნის.

Buk-ში ყველაზე ხშირი ოპერაცია სწორედ Look-ია, ამიტომ ის საერთოდ არ იწერება.

ანუ:

PrintSummary(document);

უკვე ნიშნავს read-only borrow-ს.

არ გვჭირდება:

PrintSummary(look document);

Change

Change ნიშნავს დროებით exclusive mutable access-ს.

Ownership ისევ გამომძახებელს რჩება.

func IncreaseRevision(change document: Document)
{
    document.Revision = document.Revision + 1;
}

Call site:

IncreaseRevision(change document);

change დაახლოებით ასე შეიძლება წავიკითხოთ:

„ეს მნიშვნელობა დროებით შენ გაბარია შესაცვლელად, მაგრამ ownership ჩემი რჩება.“

სანამ ასეთი borrow აქტიურია, კომპილატორი იმავე მნიშვნელობაზე conflicting access-ს არ დაუშვებს.

როგორც კი Change borrow-ის ბოლო რეალური გამოყენება დასრულდება, ორიგინალური მფლობელი მნიშვნელობას ჩვეულებრივად იყენებს.

IncreaseRevision(change document);

PrintSummary(document);

აქ mutation მომენტი კარგად ჩანს როგორც ფუნქციის დეკლარაციაში, ასევე გამოძახების დროსაც.

ეს შეგნებულად ასეა.

კოდის მკითხველმა ფუნქციის გამოძახების დანახვისას უნდა იცოდეს, რომ ამ გამოძახებას document-ის შეცვლა შეუძლია.

Take

Take ownership-ის სრულ გადაცემას ნიშნავს.

func Publish(take document: Document)
{
    // ეს ფუნქცია ახლა ფლობს document-ის სრულ კონტროლს 
}

Call site:

let document = LoadDocument();

PrintSummary(document);

Publish(take document);

ამის შემდეგ ძველი მფლობელი ამ მნიშვნელობას (document-ს) ვეღარ გამოიყენებს:

Publish(take document);

PrintSummary(document); // compile-time error

Runtime error არ ხდება.

კომპილატორმა უკვე იცის, რომ document-ის ownership გადავიდა Publish ფუნქციაში.

take დაახლოებით ნიშნავს:

„ამ მნიშვნელობის ownership მთლიანად შენ გადმოგეცი.“

ეს განსაკუთრებით მნიშვნელოვანია რესურსებთან მუშაობისას, რადგან კომპილატორს ზუსტად შეუძლია იცოდეს, ვის ეკისრება კონკრეტულ resource-ზე საბოლოო პასუხისმგებლობა. პირობითად ოპერაციული სისტემის რომელიმე რესურსზე (პროცესი, HANDLE, სოკეტი ან სხვა).

Look, Change და Take ერთად

ამიტომ ტიპური Buk-ის კოდი შეიძლება ასე გამოიყურებოდეს:

let document = LoadDocument();

Validate(document);
PrintSummary(document);

Normalize(change document);

PrintSummary(document);

Publish(take document);

აქ კომენტარები პრაქტიკულად არც არის საჭირო.

ჩვეულებრივი გამოძახება ნიშნავს "ნახვას" / "გამოყენებას".

change ნიშნავს შეცვლას.

take ნიშნავს ownership-ის გადაცემას.

კოდში პირდაპირ ჩანს სრული სემანტიკა.

Buk vs Rust

Rust-ში დაახლოებით იგივე მაგალითი ასე გამოიყურებოდა:

fn inspect(document: &Document) {}

fn normalize(document: &mut Document) {}

fn publish(document: Document) {}

Call site:

inspect(&document);

normalize(&mut document);

publish(document);

Buk-ში:

func Inspect(document: Document) {}

func Normalize(change document: Document) {}

func Publish(take document: Document) {}

Call site:

Inspect(document);

Normalize(change document);

Publish(take document);

ფუნდამენტური იდეა ორივეგან მსგავსია: ownership, shared borrow და exclusive mutable borrow.

განსხვავება უფრო რეალიზაციის მოდელშია.

Rust-ი კლასიკურ pointer/reference სემანტიკას იყენებს.

&T
&mut T

Buk-ი კი პროგრამისტის განზრახვას ძირითადად ოპერაციის დონეზე აჩვენებს:

value
change value
take value

Lifetimes

Borrow Checker-ის მეორე მნიშვნელოვანი ნაწილი lifetimes-ია.

თუ ფუნქცია მნიშვნელობას არ ფლობს და მხოლოდ "ნათხოვარი" აქვს (უჭირავს როგორც borrow), კომპილატორმა უნდა იცოდეს, რამდენ ხანს შეიძლება ამ borrow-ის გამოყენება და რომელ storage-ზეა დამოკიდებული.

Rust lifetimes-ის უმეტესობას კომპილატორი თავისით ხვდება, მაგრამ ზოგიერთ უფრო კომპლექსურ კოდში Rust-ის კომპილატორს ჭირდება "ჰინტები" რაც კოდში უნდა დაიწეროს როგორც ფუნქციის დეკლარაციაში, ასევე გამოყენებულ ტიპებში. "'"-ის სახით. მაგალითად:

fn pick<'a>(
    a: &'a str,
    b: &'a str,
    first: bool,
) -> &'a str
{
    if first { a } else { b }
}

Buk-ს public lifetime syntax საერთოდ არ აქვს.

არ გვაქვს:

'a
'b
'static

კომპილატორი თვითონ ადგენს, საიდან მოდის მნიშვნელობა და რაზეა მისი lifetime დამოკიდებული.

მაგალითად:

func Name(user: User): StringView
{
    return user.Name.AsView();
}

კომპილატორს შეუძლია დაადგინოს, რომ დაბრუნებული StringView user-ის backing storage-ზეა დამოკიდებული.

პროგრამისტს ამის ხელით აღწერა არ სჭირდება.

მთავარი კომპილატორის მაგია. საიდან მოაქვს Buk-ს ინფორმაცია Lifetime-ების შესახებ, თუ კი კოდში არ ვწერთ "'"-ებს ?

აქ ჩნდება .bki, ანუ Buk Package Interface.

.bki არის კომპლექსური მეტადატის შემცველი ფაილი, რომელსაც კომპილატორი აგენერირებს.

მასში ინახება კოდის სემანტიკური კონტრაქტები.

მაგალითად კომპილატორს შეიძლება დასჭირდეს ცოდნა იმის შესახებ, რომ:

დაბრუნებული მნიშვნელობის შენახვა ხდება რომელიღაც backing storage-ში (მაგალითად კოლექცია "UserList"-ის მეხსიერებაში)

ფუნქცია მხოლოდ კონკრეტულ ველს ცვლის

მნიშვნელობა await-ის იქით ვერ გადავა 

ფუნქცია ownership-ს იღებს

ამ ინფორმაციის ნაწილი .bki-ში ნორმალიზებული მეტადატის სახით გადადის.

ამიტომ Buk-ის კომპილატორი და Borrow Checker-ი ფლობს სრულ სემანტიკურ ინფორმაციას პროგრამის შესახებ და ამის ხარჯზე შეგვიძლია უფრო მარტივი კოდი ვწეროთ. გარდა ამისა ბუკის კომპილატორს შეუძლია ბევრად მეტი ოპტიმიზაცია გააკეთოს ამ ინფორმაციაზე დაყრდნობით.

Explicit allocation

Buk-ში მეხსიერების ალოკაციაც "ხელით" ხდება და სრულ კონტროლს გვაძლევს მეხსიერებაზე. Rust-ში ამის შესაძლებლობა არ გვაქვს და ხელით უნდა გაკეთდეს custom allocator.

მაგალითად:

let users =
    List[User].Create(
        capacity: 64,
        in: arena,
    );

in: ამბობს, სად უნდა შეიქმნას ახალი ownership და სად უნდა ჩაიწეროს ეს მნიშვნელობა. ამ შემთხვევაში გადაცემულ Arena-ში.

func Parse(
    text: StringView,
    in storage: Allocator,
): Document fails ParseError
{
    let tokens = Tokenize(text);

    return BuildDocument(tokens);
}

Caller:

let document = Parse(source, in: requestArena);

Async კოდი ფუნქციების coloring-ის გარეშე

Buk-ის კიდევ ერთი მნიშვნელოვანი მიმართულება colorless async-ია.

C#-ში, Rust-ში, Javascript-ში და სხვა ენებში async API შემდეგნაირად იწერება:

async Task<User> LoadUserAsync()
{
    var data = await ReadAsync();
    return Parse(data);
}

ფუნქცია სპეციალურ Task ტიპს აბრუნებს და გამოძახების მთელი ჯაჭვი უნდა იყოს async.

Buk-ში ფუნქცია სემანტიკურ მნიშვნელობას პირდაპირ აბრუნებს:

func LoadUser(id: UserId): User fails LoadError
{
    let data = await database.Load(id);
    return ParseUser(data);
}

ფუნქციაFuture[User], Task[User] ან Promise[User]-ს არ აბრუნებინებს.

კომპილატორი თვითონ ადგენს ფუნქციის შესრულების ტიპს (ასინქრონულია თუ სინქრონული), გამოძახების მიხედვით.

await მაინც უნდა დავწეროთ იქ სადაც ასინქრონულად გამოძახება ხდება.

თუ ფუნქცია სინქრონულად სრულდება, კომპილატორი საერთოდ გააქრობს async scheduler-ს და state machine-ს და დაბილდავს როგორც უბრალო ფუნქციას.

უფრო დეტალური ინფორმაცია ამის შესახებ გამოქვეყნდება ენის რელიზის დროს, თავის წიგნთან ერთად.

ეს იყო მოკლე აღწერა.
თავის მხრივ უფრო დეტალური აღწერა წიგნთან ერთად გამოვა რელიზის დროს, როგორც ზემოთ აღვნიშნე.

DLL injection of managed code into native process

Rezo — Fri, 27 Dec 2024 10:47:21 +0000

Getting started

Project repository with full code is accessible on GitHub

Link

DLL injection is a powerful technique that allows us to inject custom code into a third-party process. It can be useful in various scenarios.

DLL injection is often used by malware to inject code into running processes, such as system processes like svchost.exe or explorer.exe, and execute malicious functionality within them.

Malware usually resides inside existing process and acts as parasite to be harder to detect. It can use either DLL injection or full PE injection which is much more sophisticated method.

Extending Program Functionality with DLL Injection

DLL injection isn't just for malicious purposes—it can also be a legitimate tool for extending existing program functionality. For example, you can use it to develop plugins for software.

Imagine you want to log every action that happens inside a process, such as:

Network calls
File system writes

By using function hooking, you can intercept method calls within the process after injecting your DLL.

Function hooking allows you to:

Intercept and monitor API calls.
Modify input/output of functions as needed.
Extend a process's behavior dynamically without modifying its source code.

This makes DLL injection a versatile tool for developers, researchers, and security professionals alike.

For instance:

Hook the WriteFile function to capture details about file writes happening inside the process.
Log this information for debugging, monitoring, or analysis.

How WINAPI Works

When a Windows process (PE - Portable Executable) is started by the operating system's PE loader, it loads all essential libraries required for the process into its address space.

This includes libraries such as:

kernel32.dll
ntdll.dll
user32.dll

Each Windows process can obtain access (HANDLE) to libraries loaded into it using the GetModuleHandle method. It can then retrieve individual methods using GetProcAddress and call them.

kernel32.dll: Contains higher-level functions for tasks like memory management, file handling, and threading.
ntdll.dll: Contains lower-level counterparts, usually prefixed with "Nt", such as NtQuerySystemInformation, which retrieves information about running processes in the operating system.

The Flow of a WinAPI Call

When you call a WinAPI function, control is passed to ntdll.dll.
ntdll.dll uses a special routine like KiFastSystemCall to pass control to the Windows kernel.
Inside the kernel, a lookup table called the System Service Dispatch Table (SSDT) is used to locate the actual implementation of the function.
The function executes in kernel mode.
Once complete, control is returned back to user mode.

How DLL Injection Works

Steps to Inject a DLL

Open the Target Process:

Use OpenProcess to get a handle to the target process with sufficient privileges.
Allocate Memory in the Target Process:

Call VirtualAllocEx to reserve space in the target process for the DLL path or custom code.
Write the DLL Path:

Use WriteProcessMemory to copy the DLL path or custom code into the allocated memory.
Load the DLL:

Locate the address of LoadLibraryA or LoadLibraryW using GetProcAddress, and then use CreateRemoteThread to execute it in the target process. This loads the DLL into the process.
Execute the DLL Code:

Once the DLL is loaded, its DllMain function is called by the process's loader.

What Happens After Injection

Your DLL is loaded into the target process's address space via LoadLibrary.
The Windows PE loader calls your DLL’s DllMain entry point.
Any code in your DLL, such as hooks or logging, starts running in the context of the target process.

Full flow of this program

Injects a native C library into a native running process, such as notepad.exe.
The injected library loads the CoreCLR runtime into the target process.
It then loads a managed C# DLL into the process's address space and calls its entry point method (Main).
The C# DLL executes within the unmanaged process and calls the MessageBox function.

This DLL outputs current process information in a MessageBox after being injected into native process, in this case notepad.

After starting injector end result looks like this

NOTES:

To run this example you can clone repository and edit source code to include correct path to CoreCLR and injected library inside source code. Right now everything is hardcoded.
Code for injected DLL:


csharp
using System.Diagnostics;
using System.Runtime.InteropServices;

namespace InjectLib.Managed
{
    public static class InjectLibManaged
    {
        const uint MB_OK = 0x00000000;
        const uint MB_ICONFIRMATION = 0x00000040; 

        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        public static extern int MessageBox(IntPtr hWnd, string text, string caption, uint type);

        public static void Main()
        {
            var proc = Process.GetCurrentProcess();
            MessageBox(
                IntPtr.Zero,
                $"Hello from Process with Id: {proc.Id}, {proc.ProcessName}",
                "Hello from injected DLL",
                MB_OK | MB_ICONFIRMATION
            );

            Thread.Sleep(50000);
        }
    }
}