DEV Community: chsami

Better Reverse Engineering with Frida and Ghidra

chsami — Thu, 10 Apr 2025 04:54:31 +0000

Frida and Ghidra: A Powerful Reverse Engineering Team

Reverse engineering can feel like trying to understand a machine without its instruction manual. Tools like Ghidra are great for taking the machine apart and looking at all the pieces. But sometimes, you need to see the machine running to really get how it works. That's where Frida comes in handy.

Ghidra is a free and open-source tool that lets you see the code and structure of computer programs. It helps you understand the blueprint of the software. Frida, on the other hand, is like a special toolkit that lets you poke around inside a program while it's actually running on a computer, phone, or other device. You can inject little bits of code (using a language called JavaScript) to watch what's happening and even change things as they go.

So, why is using Frida together with Ghidra so helpful for reverse engineering?

They work together to give you a full picture:

Ghidra shows you what the program could do. Frida shows you what it actually does when it's running. You can see the real data being used, which helps confirm what you see in Ghidra.
Some programs try to hide their inner workings. Ghidra can have trouble with these. But Frida can often bypass these tricks by looking at the program after it has already revealed its true form in the computer's memory.
Ghidra can draw maps of how the program flows. Frida can show you the exact path the program takes when you perform a specific action. This makes it easier to understand complicated logic and how different parts of the program connect.

Frida lets you really focus your investigation:

You can "hook" functions. This means you can jump in whenever a specific part of the program (a function) is used. You can see what information goes into the function and what comes out. You can even change the information or make the function do something different. This is super useful for seeing how different parts of a program communicate and for finding potential weaknesses.
You can look at and change the program's memory. Frida lets you peek at the raw data the program is using and even modify it. This can help you understand how information is stored, find hidden secrets, or test if the program is vulnerable to attacks (in a safe, controlled way, of course!).
You can trace what the program is doing. Frida can keep a detailed log of the program's actions – what functions it calls, what system commands it uses, and other important events. This gives you a timeline of the program's activity, making it easier to figure out exactly what's happening.

Using Frida makes Ghidra even more powerful:

The real-world information you get from Frida makes your analysis in Ghidra more accurate. You can add notes to the code in Ghidra based on what you observe with Frida.
If you have an idea about how something works in Ghidra, you can use Frida to test that idea in the running program. This back-and-forth process speeds up your reverse engineering work and makes it more reliable.
Sometimes, parts of a program only run in very specific situations that are hard to figure out just by looking at the code in Ghidra. Frida can help you trigger these situations and see what happens, revealing hidden or less obvious features.

Imagine this example:

You're using Ghidra to look at a mobile app and you find a strange piece of code that seems to handle private user information. With Frida, you could:

See exactly when and how this piece of code is used.
Record the actual private information it's working with.
Look at the information in the app's memory while this code is running.
Try giving it different kinds of information to see if there are any security issues.

This live view, combined with Ghidra's ability to show you the code itself, gives you a much clearer picture of what's going on.

How to get started:

Both Frida and Ghidra have good documentation and helpful communities online. To start using them together:

Install Ghidra: You can download the latest version from the official Ghidra website: https://ghidra-sre.org/. Follow the installation instructions provided on the site.
Install Frida: Frida is typically installed using pip, the package installer for Python. Open your terminal or command prompt and run: pip install frida-tools. You can find more information about Frida installation on their documentation page: https://frida.re/docs/installation/.
Learn a little bit of JavaScript: Frida uses JavaScript for its scripting capabilities. There are many online resources for learning JavaScript, such as the Mozilla Developer Network (MDN) JavaScript guide: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide.
Read Frida's documentation: The official Frida documentation provides a comprehensive guide to its features and API: https://frida.re/docs/home/. Pay particular attention to the sections on "Core Concepts" and the "API Reference."
Start by practicing on simple programs: Try using Frida to look at basic applications on your computer to get a feel for how to hook functions and observe their behavior. There are often tutorials and examples available online that can guide you through your first Frida scripts.

In conclusion:

Ghidra is a fantastic tool for taking software apart and seeing its structure. Frida adds the crucial ability to see that software in action. When you combine these two tools, you get a really powerful way to understand how any program works, find hidden features, and uncover potential security problems. They make the often-difficult job of reverse engineering much more effective and insightful. So, give Frida and Ghidra a try and see what you can discover!

.NET 10 field backed property

chsami — Fri, 28 Feb 2025 04:32:45 +0000

With the update to C# 13 Microsoft introduced a new field keyword

Before – The Old Way

You had two choices:

Auto-Implemented Property (No Validation):

   public class TimePeriod
   {
       public double Hours { get; set; }
   }

This creates a compiler-generated backing field, but you can't inject any logic into the get or set accessors.

Manually Implemented Property (With Validation):

   public class TimePeriod
   {
       private double _hours;

       public double Hours
       {
           get { return _hours; }
           set
           {
               if (value < 0)
                   throw new ArgumentOutOfRangeException(nameof(value), "The value must not be negative");
               _hours = value;
           }
       }
   }

Here, you have full control and can add range checking, but you lose the brevity and clarity of auto-properties.

After – With the New `field` Keyword (C# 13 Preview)

The new contextual keyword field lets you mix the best of both worlds. You can use auto-property syntax and still include custom logic in one accessor without declaring your own backing field:

public class TimePeriod
{
    public double Hours
    {
        get;
        set => field = (value >= 0)
            ? value
            : throw new ArgumentOutOfRangeException(nameof(value), "The value must not be negative");
    }
}

What’s happening here?

Auto-Implemented Backing Field: The compiler still creates the backing field for you.
Custom Set Logic: You add a validation in the set accessor by directly accessing the synthesized backing field via field.
No Redundant Code: There's no need to manually declare the backing field or implement both accessors with full method bodies.

Enjoy!

How do spellcheckers work?

chsami — Fri, 28 Feb 2025 03:16:11 +0000

We all know those wiggly red lines that show up under misspelled words—a small but helpful feature we don’t often think about. It uses a smart system to keep our writing clear. When our team received an intriguing request from the business to implement a spellchecker, it truly captured my attention in a way I never anticipated. Yup... I could've just used an api that does the spellchecking for me, but I was more interested in how things work behind the scene, so this led me to investigating how spellcheckers work.

let's take a look at the timeline

late 1950s and early 1960s

The idea for spellcheckers started in the late 1950s and early 1960s with Herbert Glance in 1957 and Charles Blair in 1960. They came up with a way to check every word someone typed against a list of right spellings, pointing out any that didn’t fit. These early systems couldn’t suggest fixes, but they were important first steps for spellchecking tools.

1965: Levenshtein distance algorithm

In 1965: Vladimir Levenshtein published the Levenshtein distance algorithm.

Let's say you wanted to turn the word "kitten" into "sitting". The goal is to do this in as few steps as possible.

This is where the Levenshtein Algorithm helps you figure out the minimum number of changes needed to transform one word into another. These changes can be:

Inserting a letter (e.g., adding an "s" to "kitten" to make "kittens").

Deleting a letter (e.g., removing the "k" from "kitten" to make "itten").

Replacing a letter (e.g., swapping the "k" in "kitten" with an "s" to make "sitten").

This first implementation matches the naive recursive way. This is later on improved by using dynamic programming.

Early 1970s: Ralph Gorin created "Spell," a program

Early 1970s: Ralph Gorin created "Spell," a program that identified misspelled words and suggested plausible correct spellings with an edit distance of one, meaning corrections involving a single letter insertion, deletion, or substitution. In 1971, Ralph published his program making it publicly available and quickly spreading its use worldwide. A limitation of this program was its inability to calculate plausible words beyond an edit distance of one.

1974: Robert Wagner and Michael Fischer introduced dynamic programming

1974: Robert Wagner and Michael Fischer introduced dynamic programming to improve the efficiency of calculating edit distance. The Wagner-Fischer algorithm broke down complex problems into simpler subproblems, solving each subproblem once and storing the solutions to avoid repetitive work.

Here is a visualization in claude: https://claude.site/artifacts/1bb87561-f087-4ad8-9a95-df5d2a30262e

1980s and 1990s: Microsoft Word

1980s and 1990s: Programs like Word Check and Microsoft Word used more evolved and optimized versions of these algorithms

2000 and beyond Spell Checkers: More Than Just Simple Fixes

Understanding the Sentence

Today’s spell checkers don’t just look at words by themselves. They use smart tricks (called Natural Language Processing, or NLP) to figure out what a whole sentence means. For example, a word might be spelled right on its own, but if it doesn’t make sense in the sentence, the spell checker can catch it. This makes them better at avoiding mistakes and helps them work smoother for us.

Guessing What You Meant

A lot of spell checkers use an idea called the "noisy channel model." It’s like treating a misspelled word as a scrambled version of the right one. Then, it uses math and guesses to pick the word you probably wanted. A guy named Peter Norvig made a simple version of this popular by mixing how often words show up with how close they are to what you typed.

Learning From Tons of Words

Now, spell checkers are getting even smarter with things like machine learning and deep learning. These are like teaching a computer brain (neural networks) to study huge piles of text. This helps them fix tricky stuff—like words that sound the same (like "their" and "there"), mistakes based on the sentence, and even grammar—not just basic typos.

Fitting You Perfectly

Spell checkers today can also change to fit you. You can add your own special words (like job terms or names) to a custom list, and they’ll learn from the fixes you make over time. This way, they keep up with new words or weird spellings you use a lot.

I hope this brief introduction sparked your interest in spell checkers. Give it a try yourself!

Happy coding! :)

Why does clustering with redis suck?

chsami — Thu, 02 Jan 2025 21:42:22 +0000

Semantic search with Azure MS SQL and EF Core

chsami — Wed, 01 Jan 2025 12:41:47 +0000

In May 2024, the first version of the EFCore.SqlServer.VectorSearch extension was released. This was a significant step towards simplifying vector operations for EF Core users working with Azure SQL.
This plugin is currently in prerelease status, so the APIs and features may evolve before the final release. Here's a quick overview of what it offers.

What Does the Plugin Do?

This plugin bridges EF Core and Azure SQL Database's native vector support, enabling developers to:

Perform vector similarity searches using LINQ.
insert and retrieve vector data in Azure SQL.

builder.Services.AddDbContext<ProductContext>(options =>
  options.UseSqlServer("<connection string>", o => o.UseVectorSearch()));

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Product>().Property(p => p.Embedding).HasColumnType("vector(3)");
}

public class Product
{
    public int Id { get; set; }
    public float[] Embedding { get; set; }
}

var someVector = new[] { 1f, 2f, 3f };
var products = await context.Products
    .OrderBy(p => EF.Functions.VectorDistance("cosine", p.Embedding, vector))
    .Take(5)
    .ToArrayAsync();

With this, working with embeddings and vectorized data becomes possible, directly within your EF Core projects.

A full sample using EF Core and vector is available here: https://github.com/Azure-Samples/azure-sql-db-vector-search/tree/main/EF-Core

Azure SQL's Native Vector Support

Since November 2024, Azure SQL Database has been supporting embeddings through its Public Preview of native vector functionality. This development has made it possible to:

Store and manage vector data.
Perform advanced operations like similarity searches directly in SQL.

For more details, check out the official announcement: Public Preview of Native Vector Support in Azure SQL Database.

Learn more about the vector features in Azure SQL in this guide: Azure SQL Vector Public Preview.

For more details, visit the GitHub repository: EFCore.SqlServer.VectorSearch.

More of this on: https://chsami.com

Happy coding!

Stop using try catch in your code

chsami — Wed, 01 Jan 2025 12:34:47 +0000

Have you ever found yourself looking through your code and noticing a lot of try-catch blocks scattered everywhere? It can get messy, hard to maintain, and often feels like a chore to manage. Luckily, there’s a better way to handle this: middleware.

My little guideline for when to throw exceptions:

Use exceptions only for critical issues that require attention.
Keep exceptions aligned with the purpose of the method or class.
Reserve exceptions for rare, unexpected situations.

Why Use Middleware?

Middleware brings several benefits to your project:

Separation of Concerns: Middleware keeps error-handling logic separate from your core application logic, making your code cleaner and easier to understand.
Improved Performance: By centralizing error handling, you reduce repetitive operations.
Better Maintainability: Having one place to manage errors makes it easier to update and debug your application.
Standardized Responses: Middleware ensures your app consistently returns well-structured error messages to users or other services.

How to Implement an Exception Middleware

Here’s a step-by-step guide to implementing an exception middleware in your application.

Step 1: Set Up the Middleware

In your middleware, you’ll catch exceptions that occur anywhere in your application. This helps centralize error management and keeps the rest of your code free from repetitive try-catch blocks.

Step 2: Use the ProblemDetails Convention

The ProblemDetails convention is a standard way to format error responses. It provides a consistent structure for APIs to communicate issues, making it easier for consumers (like front-end apps) to understand what went wrong.

ProblemDetails responses typically include:

Status Code: Indicates the type of error.
Title: A brief explanation of the error.
Detail: A more detailed description of what happened.
Instance: A URI that uniquely identifies the error occurrence.

By using ProblemDetails in your exception middleware, you ensure that all errors are communicated in a clear and standardized format.

Example Implementation

Here’s a basic template for setting up an exception middleware:

public class ExceptionMiddleware
{
    private readonly RequestDelegate _next;

    public ExceptionMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception ex)
        {
            await HandleExceptionAsync(context, ex);
        }
    }

    private Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        var problemDetails = new ProblemDetails
        {
            Status = StatusCodes.Status500InternalServerError,
            Title = "An unexpected error occurred.",
            Detail = exception.Message,
            Instance = context.Request.Path
        };

        context.Response.StatusCode = StatusCodes.Status500InternalServerError;
        context.Response.ContentType = "application/json";

        return context.Response.WriteAsJsonAsync(problemDetails);
    }
}

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-9.0
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/error-handling?view=aspnetcore-9.0

More of this on https://chsami.com

Happy coding!

Configuring a custom domain for your Azure Static Web App

chsami — Sat, 28 Dec 2024 13:04:32 +0000

Configuring a custom domain for your Azure Static Web App is straightforward. Follow these simple steps to get your website running on your own domain.

Step 1: Open the Custom Domains Page

Go to your Azure Static Web App in the Azure Portal. From the left-hand menu, click on Custom domains.

Step 2: Add a Custom Domain

Click the Add button and choose the option for Custom domain on other DNS.

Step 3: Verify Your Domain

To verify your domain, you need to add a TXT record to your DNS provider.

Copy the generated TXT record value and paste it into your DNS provider’s settings. This unique value provides a valid connection between Azure and your DNS provider.

For example, if you use Hostinger, it might look like this:

Step 4: Add a WWW Subdomain

Repeat the process, but this time use www.yourdomain.com instead of yourdomain.com.

Step 5: Configure CNAME Records

In the Azure portal, select CNAME and click the Add button at the bottom of the screen.

In your DNS provider’s settings, add or edit the following CNAME records:

For www.yourdomain.com:

For the root domain (yourdomain.com), add an alias (CNAME):

These configurations make sure your website works with both www and without it.

Done!

That’s it! Your custom domain is now linked to your Azure Static Web App. Enjoy!

TestContainers in .NET with PostgreSQL and PgVector

chsami — Sat, 28 Dec 2024 06:28:19 +0000

What are we solving?

How to include postgresql extension in a docker image through C# for integration tests.

Overview

I’m using C# with the Testcontainers.PostgreSql NuGet package, which makes it easy to spin up PostgreSQL containers for integration testing. The core idea behind this setup is to ensure that each test class gets a clean, isolated database instance. This database is used to execute integration tests and is deleted afterward.

Testcontainers for .NET is a library to support tests with throwaway instances of Docker containers for all compatible .NET Standard versions. The library is built on top of the .NET Docker remote API and provides a lightweight implementation to support your test environment in all circumstances.

Container Configuration

Here’s how I configured the PostgreSQL container:

private const ushort Port = 5432;
private const string Username = "postgres";
private const string Password = "postgres";
private const string Database = "postgres";
private const string Host = "localhost";

private readonly PostgreSqlContainer _dbContainer = new PostgreSqlBuilder()
    .WithImage("pgvector/pgvector:pg16")
    .WithUsername(Username)
    .WithPassword(Password)
    .WithPortBinding(Port, true)
 .WithWaitStrategy(Wait.ForUnixContainer().UntilPortIsAvailable(Port))
    .Build();

Notice that I used the pgvector:pg16 Docker image, as it already comes configured with the pgvector extension.

Adding PostgreSQL Extensions

The project requires three PostgreSQL extensions:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.HasPostgresExtension("vector");  
    modelBuilder.HasPostgresExtension("btree_gin");
    modelBuilder.HasPostgresExtension("pg_trgm");
}

Using HasPostgresExtension ensures that EF Core manages these extensions as part of the migrations or schema setup process. The following SQL commands are automatically generated and executed:

CREATE EXTENSION IF NOT EXISTS "vector";
CREATE EXTENSION IF NOT EXISTS "btree_gin";
CREATE EXTENSION IF NOT EXISTS "pg_trgm";

HasPostgresExtension vs UseVector

There is a distinction between HasPostgresExtension("vector") and using the extension directly through UseVector:

Key Differences:

HasPostgresExtension("vector")

Ensures that EF Core includes the extension during migrations or schema updates.
Manages the database schema and ensures the extension is installed.

UseVector

Configures Npgsql to utilize the vector extension’s functionality, such as advanced type mappings and query capabilities.
Enables application-level usage, like executing vector similarity queries:

SELECT * FROM my_table ORDER BY embedding <-> query_embedding LIMIT 10;

Initializing the Database with Scripts

In addition to setting up extensions through EF Core, I discovered an alternative method to initialize the database in the test container using a SQL script. This is achieved with WithResourceMapping:

WithResourceMapping("./Scripts/extensions.sql", "/docker-entrypoint-initdb.d")

What Does docker-entrypoint-initdb.d Do?

The docker-entrypoint-initdb.d directory allows you to provide SQL or script files that PostgreSQL executes automatically during container initialization. This approach is ideal for preloading extensions or setting up other database configurations without embedding logic directly in the code.

Conclusion

Using EF Core with Testcontainers, I’ve set up a way to make sure each test gets a fresh and clean database. Extensions like vector, btree_gin, and pg_trgm provide useful features, and the automated setup makes it easy to get everything ready without extra work. This keeps tests reliable and maintenance straightforward.