LinuxBaya

Common Security Flaws in C and C++

2025-05-07T23:31:00.000-07:00

In this post, we’ll walk through some of the most common and dangerous security flaws in C and C++ programming: buffer overflows, integer overflows, format string vulnerabilities and massive 25+ point checklist of potential C/C++ vulnerabilities. Understanding these issues is the first step toward writing safer and more secure code.

Buffer Overflows (Stack & Heap)
Integer Overflows
Uncontrolled Format String Vulnerabilities
Use-After-Free
Memory Leaks
Double Free
Uninitialized Memory
Insecure Temp Files
Race Conditions
Command Injection
Poor Error Handling
Type Confusion
Dangling Pointers
Improper Bounds Checking
Insecure Deserialization
Volatile Keyword Misuse
Signal Handler Vulnerabilities
Type Conversion Issues
TOCTOU
Dangerous Macros
Unchecked Return Values
Thread Safety Issues
Dangerous Functions
Environment Variable Abuse
Stack Exhaustion
General Undefined Behavior

1. Buffer Overflows

What is a Buffer Overflow?

A buffer overflow happens when data exceeds the boundaries of a fixed-size buffer and overwrites adjacent memory. This can cause unexpected behavior, program crashes, and even allow attackers to execute arbitrary code.

Buffer overflows can occur in various memory regions:

Stack (stack-based buffer overflow)
Heap (heap-based overflow)
Memory-mapped files

Stack-Based Buffer Overflow: A Classic Attack

Let’s consider this scenario:

void smash_stack(char *userInput) {
    char buffer[32];
    strcpy(buffer, userInput);  // No bounds checking!
}

If userInput is longer than 32 characters, it will overwrite memory beyond buffer, including potentially the function's return address.

Why is this dangerous?

When a function is called, the system creates a stack frame that contains local variables and the return address. If an attacker controls the overflow and knows the memory layout, they could:

Overwrite the return address with the address of malicious code.
Hijack the execution flow of the program.

This can result in arbitrary code execution, data leaks, system crashes, or even a full system compromise.

Heap-Based Buffer Overflow

Unlike stack overflows, heap overflows affect dynamically allocated memory. Here’s a simplified example:

char* buffer = new char[32];
char* secret_password = new char[32];
strcpy(secret_password, "password");strcpy(buffer, long_user_input);

If long_user_input is larger than 32 characters, it overflows into secret_password, potentially altering sensitive data.

While heap overflows are typically less dangerous in terms of executing shellcode, they can still lead to security breaches—especially if critical values like authentication tokens or pointers are overwritten.

How to Prevent Buffer Overflows:

Always validate input sizes.
Use safer functions like strncpy, snprintf, or modern C++ constructs like std::string.
Enable compiler protections like stack canaries.
Take advantage of OS-level defenses like ASLR and non-executable stacks.

2. Integer Overflows

What is an Integer Overflow?

An integer overflow occurs when a calculation results in a number outside the range that can be represented by the data type.

Example:

int c = INT_MAX;
c = c + 1;  // Wraps around to INT_MIN

The result can be surprising: instead of throwing an error, C/C++ silently wraps around the value. This leads to undefined behavior.

Why is this a problem?

An overflowed value might be used to allocate memory:

    int size = get_user_input();
    char* buffer = new char[size];

It might cause infinite loops, incorrect bounds checking, or even allow buffer overflows if the logic assumes the value is within bounds.

How to Prevent Integer Overflows:

Validate arithmetic operations before executing them.
Use safer arithmetic functions or libraries with built-in overflow checks (e.g., __builtin_add_overflow in GCC).
Prefer unsigned types for sizes (with caution).
Perform careful range checking when working with user input.

3. Uncontrolled Format String Vulnerabilities

What is a Format String Vulnerability?

This happens when a program passes unchecked user input as a format string to functions like printf.

Example of unsafe code:

void vulnerable_function(char *userInput) {    
    printf(userInput);  // DANGER: userInput could contain format specifiers
}

If an attacker enters %x %x %x, printf will print values from the stack. Even worse, using %n allows writing to arbitrary memory locations, which can be exploited to alter program behavior or gain code execution.

Safer Alternatives:

Fix the code by specifying a format string:
```
printf("%s", userInput);  // Safe
```
Use cout instead of printf when working in C++:
```
std::cout << userInput;
```

How to Avoid Format String Attacks:

Never pass user input directly as a format string.
Sanitize and validate input rigorously.
Disable risky specifiers like %n using compiler flags or secure coding guidelines.

4. Use-After-Free

What is it?

Use-After-Free (UAF) occurs when a program continues to use a pointer after the memory it points to has been freed.

char* buffer = new char[100];
delete[] buffer;
strcpy(buffer, "This is unsafe!");  // Using freed memory

Why it matters:

Can lead to undefined behavior, crashes, or execution of malicious code.
Attackers may exploit UAF to control program behavior by reallocating memory in the same location.

How to prevent it:

Always set pointers to nullptr after freeing.
Use smart pointers (std::unique_ptr, std::shared_ptr) to manage memory automatically.

5. Memory Leaks

What is it?

Memory that is allocated but never deallocated leads to memory leaks.

char* buffer = new char[256];
// Forgot to call delete[]

Why it matters:

Causes increased memory usage over time.
In long-running systems, can lead to slowdowns or crashes due to exhaustion of system memory.

Prevention:

Use RAII (Resource Acquisition Is Initialization) with smart pointers.
Always pair new with delete, and new[] with delete[].
Use tools like Valgrind or ASan (Address Sanitizer) to detect leaks.

6. Double Free

What is it?

Calling delete or free() on the same memory block more than once.


char* data = new char[50];
delete[] data;
delete[] data;  // Dangerous!

Risks:

May corrupt the heap.
Can be exploited to gain control over the heap metadata in certain allocators.

Fix:

Set pointers to nullptr immediately after deletion.

7. Uninitialized Memory Access

What is it?

Using variables or memory that hasn’t been initialized.

int a;
cout << a;  // Value is undefined

Why it matters:

Leads to unpredictable behavior.
Might leak sensitive data left in memory from other processes or operations.

Prevention:

Always initialize variables before use.
Use tools like Valgrind or compiler flags like -Wuninitialized to detect it.

8. Insecure Temporary Files

What is it?

Creating predictable temp file names can allow attackers to create files with those names in advance (race condition attacks).

FILE* f = fopen("/tmp/mytempfile", "w");

Risk:

Attackers can create symbolic links to redirect writes to other files.

Fix:

Use mkstemp() instead of tmpnam() or hardcoded paths.

9. Race Conditions

What is it?

When two threads/processes access shared data simultaneously and the result depends on the sequence of access.

Risk:

Can lead to unpredictable bugs.
Security implications if the race condition affects authentication, permissions, or data integrity.

Example:

Time-of-check to time-of-use (TOCTOU) vulnerabilities in file handling.

10. Command Injection via `system()` or `popen()`

What is it?

Passing unsanitized input to system-level commands.

system(userInput);  // BAD if userInput = "rm -rf /"

Risk:

Full command execution by attackers.
Leads to privilege escalation or data destruction.

Fix:

Avoid using system() when possible.
Use safer APIs or at least validate/escape input properly.

11. Poor Error Handling

What is it?

Ignoring or mishandling return values from critical functions (e.g., malloc, fopen, read).

Why it matters:

Can lead to null pointer dereferences or logic failures.
Hides issues that attackers can exploit.

12. Type Confusion / Casting Errors

What is it?

Using incorrect type casts, especially when using void pointers or complex class hierarchies in C++.

Risk:

Results in undefined behavior.
Can be exploited to execute arbitrary code in complex systems.

In addition to secure coding, code reviews, static analysis tools (like Cppcheck, Clang-Tidy, or Coverity), and dynamic testing tools (like Valgrind, ASan, Fuzzers) are critical in identifying and mitigating these issues before they make it into production.

13. Dangling Pointers

What is it?

A dangling pointer is a pointer that continues to reference memory after it has been deallocated.

int* ptr = new int(5);
delete ptr;
*ptr = 10;  // Dangling: accessing freed memory

Why it’s dangerous:

Can lead to undefined behavior, crashes, or accidental corruption of unrelated memory.
If attackers can predict or control memory reuse, they may exploit the dangling pointer to hijack execution flow.

How to prevent it:

Set pointers to nullptr immediately after deletion.
Use smart pointers like std::unique_ptr or std::shared_ptr in C++ for automatic memory management.

14. Improper Bounds Checking

What is it?

Failing to ensure that indices or values fall within expected limits when accessing arrays, buffers, or memory.

int arr[5];
arr[5] = 10;  // Out-of-bounds write

Why it matters:

Can cause buffer overflows, memory corruption, or logic bugs.
Common source of CVEs in both user-space and kernel-space programs.

How to prevent it:

Always validate indices before access.
Prefer safer containers like std::vector with .at() method in C++.
Enable compiler flags like -fsanitize=address or use static analysis tools.

15. Insecure Deserialization (C++)

What is it?

In insecure deserialization, untrusted data is used to rebuild objects, potentially allowing attackers to manipulate object state or execute code.

// Example pseudocode
MyClass obj;
ifstream file("data.ser");file >> obj;  // Deserializing untrusted input

Risk:

Attackers can craft malicious serialized objects to:

Modify program logic
Trigger unexpected behavior
Possibly execute arbitrary code depending on how deserialization is implemented

Prevention:

Avoid deserializing data from untrusted sources.
Use safe and verified serialization libraries with schema validation.
Implement input validation and integrity checks (e.g., signatures, checksums).

16. Volatile Keyword Misuse

What is it?

Using the volatile keyword incorrectly or assuming it provides thread safety.


volatile bool done = false;
void worker() {    while (!done) {
        // do something
    }
}

Why it's problematic:

volatile only prevents compiler optimizations; it does not guarantee memory visibility across threads.
Misuse can lead to subtle multi-threading bugs.

Proper alternative:

Use proper synchronization primitives like std::atomic, std::mutex, or std::condition_variable in C++.
Understand memory models and concurrency implications.

17. Signal Handler Vulnerabilities

What is it?

Improper use of signal handlers can introduce race conditions, inconsistent program state, or unsafe behavior.

void handler(int sig) {
    printf("Signal received\n");  // Not safe in signal context
}
signal(SIGINT, handler);

Why it’s dangerous:

Only async-signal-safe functions (like write) can be used inside signal handlers.
Unsafe function calls (like malloc, printf, etc.) may lead to deadlocks or crashes.

Safe signal handling:

Minimize logic inside the handler.
Set a flag or use sig_atomic_t to signal the main thread to take action later.

18. Type Conversion Issues (Signed/Unsigned Mismatch)

What is it?

Mixing signed and unsigned types in expressions can lead to logic errors or unexpected behavior.

unsigned int a = 1;
int b = -2;
if (a > b) {    // True? Yes, due to implicit conversion!
}

Risk:

Leads to incorrect comparisons and logic bugs.
Can be used by attackers to bypass input validation or overflow checks.

Prevention:

Avoid mixing signed and unsigned types.
Use explicit casts with care and always validate ranges.

19. Time-of-Check to Time-of-Use (TOCTOU)

What is it?

When a resource (file, permission, etc.) is checked and then used later, a window opens where an attacker can change it.

if (access("file.txt", R_OK) == 0) {
    // Attacker swaps file before we open it
    int fd = open("file.txt", O_RDONLY);
}

Prevention:

Avoid using access() and open() separately.
Use O_CREAT | O_EXCL or secure file APIs that combine check and use.
Use file descriptors directly when possible.

20. Improper Use of Macros

What is it?

Macros may expand in unexpected ways, leading to side effects or incorrect evaluations.

#define SQUARE(x) x * x
int result = SQUARE(1 + 2);  // Expands to 1 + 2 * 1 + 2

Fix:

Use inline functions or constexpr in C++ for safe behavior.

21. Unchecked Return Values

What is it?

Ignoring return values from standard library or system calls can lead to missing failures.

fwrite(data, sizeof(data), 1, file);  // But did it succeed?

Prevention:

Always check the return values of functions that can fail, especially I/O, memory allocation, and system calls.

22. Thread Safety Issues

What is it?

Using shared data across threads without proper synchronization.

int shared = 0;
void thread_func() {
    shared++;  // Race condition!
}

Fix:

Use std::mutex, std::atomic, or higher-level thread-safe structures.
Always protect shared resources in multi-threaded environments.

23. Use of Dangerous Functions

What is it?

Functions like gets(), strcpy(), sprintf() are inherently unsafe and prone to buffer overflows.

Risk:

Many have been deprecated or removed from modern standards, but they still exist in legacy code.

Safer Alternatives:

Use fgets(), strncpy(), snprintf(), and consider C++ abstractions (std::string, std::stringstream).

24. Environment Variable Attacks

What is it?

Programs relying on environment variables (e.g., for paths, passwords, or config) may be tricked into unsafe behavior.

char* path = getenv("PATH");

Risk:

Attackers can manipulate the environment (especially in setuid programs) to control program behavior.

Fix:

Validate and sanitize environment variables.
Drop privileges when they are no longer needed.

25. Stack Exhaustion / Deep Recursion

What is it?

Unbounded recursion or large local variable allocations can overflow the stack.

void recurse_forever() {
    recurse_forever();  // Boom!
}

Fix:

Use iteration instead of deep recursion.
Allocate large data on the heap or use std::vector.

26. Undefined Behavior in General

C/C++ has hundreds of forms of undefined behavior (UB), and many bugs arise from:

Dereferencing null/invalid pointers
Modifying const objects
Violating object lifetimes
Using shifted values out of range (x << 32)
Modifying and reading the same variable without a sequence point

Fix:

Use modern compilers with flags like -Wall, -Wextra, -Werror, -fsanitize=undefined, and -pedantic.
Use static analysis tools like Clang Static Analyzer, Coverity, or SonarQube.

Essential C++ Coding Practices for Readability and Maintainability

2025-05-07T23:20:00.000-07:00

There are certain rules and best practices that can significantly improve the readability, maintainability, and overall quality of your code, when coding in C++. By committing to these guidelines, you can create cleaner, more efficient code that is easier to debug, maintain, and scale. Whether you’re a beginner or an experienced developer, following these coding standards can improve your programming workflow and help you avoid common mistakes.

1. Use Meaningful and Descriptive Names

One of the most important practices in C++ programming is choosing clear, descriptive names for variables, functions, and classes. Names should accurately represent the purpose and functionality of your code elements, making it easier for others (and your future self) to understand the code. Avoid cryptic abbreviations or single-letter names, unless they are well-accepted conventions (e.g., i for loop counters).

For example:

Instead of int x, use int age if the variable represents a person’s age.
Instead of calculate(), use calculateTotalAmount() if the function calculates a total amount.

2. Consistent Indentation and Formatting

Proper indentation and consistent formatting are crucial for making your code readable. Consistently indented code is much easier to follow, especially in larger projects. Use braces {} to define code blocks even if they are optional for single-line statement. This practice enhances code to provide clarity and reduces the chances of errors when modifying or adding new code.

A simple example:

if (condition) {
    // Do something
} else {
    // Do something else
}

3. Comment Your Code

Specially for complex logic or algorithms, comments are your opportunity to explain why certain decisions were made in your code. A good comment should describe the purpose of the code, its inputs, outputs, and any assumptions or limitations. However, avoid over-commenting or explaining obvious code. Comments should be clear, concise, and easy to understand.

For example:

// Calculate the total amount after tax
double totalAmount = amount * (1 + taxRate);

4. Follow a Consistent Naming Convention

Choosing a consistent naming convention is key to ensuring that your code remains organized and easy to navigate. Popular naming conventions in C++ include:

CamelCase (e.g., myVariableName)
snake_case (e.g., my_variable_name)
PascalCase (e.g., MyClassName)

Whatever naming convention you choose, ensure that it remains consistent throughout your project to maintain a uniform coding style.

5. Organize Your Code into Functions and Classes

A well-organized program is easier to debug, maintain, and extend. Break your code into small, reusable functions and classes. This promotes modularity, helps with code reuse, and makes it simpler to test and debug individual pieces of functionality. A small function or class should do one thing and do it well.

For example:

void calculateTax(double amount, double taxRate) {
    double totalAmount = amount * (1 + taxRate);
    // Additional logic here
}

6. Avoid Using Global Variables

Global variables can make code harder to understand and maintain, especially in large projects. They can create hidden dependencies, making it challenging to track how changes in one part of the program affect other parts. Whenever possible, avoid global variables and instead pass data as function parameters or encapsulate it within classes.

7. Initialise Variables Before Use

Uninitialised variables can lead to undefined behavior, making your program unreliable. Always initialise variables before you use them to ensure predictable and correct behavior. This is especially important when dealing with variables that hold critical data.

For example:

int count = 0; // Initialise variable before use

8. Handle Errors and Exceptions Properly

Good error handling is essential to prevent your program from crashing unexpectedly. In C++, you can use try-catch blocks to catch exceptions and handle errors gracefully. Always ensure that your catch blocks log or deal with exceptions appropriately rather than leaving them empty.

For example:

try {
    // Code that may throw an exception
} catch (const std::exception& e) {
    std::cerr << "Error: " << e.what() << std::endl;
}

9. Use `const` and `constexpr` Where Applicable

Using const and constexpr helps enforce immutability and can make your code more robust. Declaring variables as const indicates that their values should not be modified, while constexpr can be used for compile-time constants. This helps the compiler with optimizations and prevents accidental modifications.

For example:

const double pi = 3.14159;
constexpr int MAX_SIZE = 100;

10. Be Mindful of Memory Management

When dealing with dynamic memory allocation, it's important to properly manage memory to avoid memory leaks. Using smart pointers (std::unique_ptr, std::shared_ptr) or RAII (Resource Acquisition Is Initialization) principles ensures that memory is automatically released when it’s no longer needed.

For example:

std::unique_ptr<int> ptr = std::make_unique<int>(10);

11. Write Readable Code

Readable code is easier to maintain and debug. Use whitespace effectively, break long lines into multiple lines, and avoid overly complex or deeply nested logic. Writing clean and readable code helps future developers (including yourself) understand the program's flow quickly.

12. Regularly Test Your Code

Testing is a fundamental part of writing reliable software. Regularly test your code to ensure it works as expected. Implement unit tests, integration tests, and perform manual testing to catch potential issues early in the development process. Automated tests can save you a lot of time in the long run.

13. Follow Best Practices and Coding Standards

Familiarise yourself with widely accepted C++ coding standards, such as the C++ Core Guidelines or the Google C++ Style Guide. Following these standards not only improves code quality but also ensures consistancy across projects and teams. It’s important to communicate and align with the coding standards of your specific project or organisation.

By follow these C++ coding practices, you can ensure that your code is both readable and maintainable, ultimately leading to high quality software and a smoother development process. While these rules serve as a strong foundation, remember that every project may have its own unique conventions. Always communicate and align with your team to ensure a consistent and efficient coding environment.

Writing Secure Code in C and C++: A Practical Guide for Developers

2025-05-07T22:24:00.000-07:00

C and C++ are very powerful programming languages, known for their speed, low-level access to memory, and flexibility. But with great power comes great responsibility, especially when it comes to security.

Unlike many high-level languages, C and C++ provide direct control over memory and system resources exposes developers to numerous security pitfalls if not handled with care. Here, we’ll break down some of the key areas where C and C++ developers must pay close attention to write secure, stable, and reliable code.

1. Memory Management Pitfalls

One of the defining features of C and C++ is manual memory management. You get control, but that also means you’re responsible for allocating and deallocating memory correctly. Failing to do so can lead to:

Memory leaks: When dynamically allocated memory isn't released, leading to wasted resources and potential denial-of-service vulnerabilities.
Buffer overflows: Writing beyond the allocated memory space, allowing attackers to corrupt memory or inject malicious code.
Dangling pointers: When a pointer references memory that has already been freed, which can cause crashes or unpredictable behavior.

Best Practices:

Always free memory once it’s no longer needed.
Use safe string manipulation functions and perform bounds checks.
Prefer smart pointers in C++ (like std::unique_ptr and std::shared_ptr) to automate memory management and prevent leaks.
Remember: C doesn't have smart pointers, so extra care is needed.

2. The Danger of Pointers

Pointers give you powerful capabilities in C and C++, but misuse can lead to some of the most severe vulnerabilities:

Null pointer dereferencing can crash your program or create denial-of-service risks.
Uninitialized pointers may point to arbitrary memory, leading to corruption or data exposure.
Dangling pointers, again, are a common cause of undefined behavior.
Pointer arithmetic can easily go wrong, especially when iterating through arrays or buffers.

Best Practices:

Initialize pointers when declaring them.
Always check for null before dereferencing.
Match every malloc/new with a free/delete.
Avoid pointer arithmetic if possible—use STL containers like std::vector or std::array for safer alternatives.

3. Low-Level Access and Privilege Management

C and C++ allow access to low-level system resources, which can be both a blessing and a curse. Without careful handling, this access can open the door to privilege escalation attacks.

Key Principles:

Least Privilege: Only grant the permissions necessary for the code to function. Don't give write or admin access unless required.
Fail-Safe Defaults: Deny access by default. Only allow access if it’s explicitly granted and safe.

These principles ensure your application doesn’t expose more surface area than needed, reducing the risk of exploitation.

4. Risky Type Conversions

Despite having a static type system, C and C++ allow implicit type conversions and dangerous casts. These can lead to:

Loss of precision
Data truncation
Memory corruption

Best Practices:

Avoid implicit conversions whenever possible.
Use explicit casting operators (static_cast, reinterpret_cast) for clarity and safety.
Be mindful of type sizes and platform-specific differences.
Always validate external input to prevent type-related errors.

5. Unsafe Standard Library Functions

The C standard library includes many functions (e.g., strcpy, sprintf, gets) that don’t perform bounds checking. Using them without caution can leave your code vulnerable.

What to Do Instead:

Replace unsafe functions with safer alternatives, like strncpy, snprintf, or fgets.
Perform manual input validation and length checks.
Always remember: just because it's in the standard library doesn’t mean it’s safe by default.

6. Error Handling: Don’t Ignore It!

Many vulnerabilities stem from improper error handling. Ignoring error codes or exposing too much information through error messages can:

Leave the system in an inconsistent state
Leak sensitive internal details
Create paths for attackers to exploit

Best Practices:

Always check the return values of system and library calls.
Keep error messages vague in production, but log detailed info securely.
Ensure all resources (files, memory) are properly released to avoid leaks.

7. Race Conditions and Concurrency Issues

Concurrency is great for performance but introduces complexity and risk.

A race condition occurs when two threads access shared data simultaneously without proper synchronization.
This can cause data corruption, undefined behavior, or unauthorized access.

Best Practices:

Use mutexes, std::lock_guard, and other synchronization mechanisms.
Avoid shared state where possible.
Design thread-safe data structures or use existing ones from modern libraries.

8. Secure Coding Principles

Beyond specific vulnerabilities, a mindset of defensive programming and following secure design principles is critical.

Key Principles to Follow:

Minimize Attack Surface: Reduce the number of entry points and limit access.
Input Validation: Sanitize and validate all input before processing.
Secure Memory Practices: Use RAII and smart pointers where possible.
Code Reviews: Get a second pair of eyes on critical code.
Avoid Unsafe Functions: Use modern, safer alternatives.
Apply Least Privilege: Whether it's file permissions or user roles, less is more.
Fail-Safe Defaults: Restrict by default, open access only when safe.

C and C++ give developers immense control, but that power comes with the responsibility to write robust, secure, and maintainable code. By understanding the common pitfalls—such as memory mismanagement, risky type conversions, and poor error handling—and adopting best practices, you can significantly reduce the risk of vulnerabilities in your software.

Whether you're building embedded systems, performance-critical applications, or systems software, secure coding in C and C++ is not optional—it’s essential.

Stay tuned for upcoming posts where we’ll dive deeper into specific vulnerabilities and explore safe alternatives and security-focused coding patterns.

BINARY ANALYSIS(PART 4): BINARY HACKING

2021-08-25T08:14:00.006-07:00

From the previous two posts, we got some basic ideas about all 4 parts of an ELF binary i.e. executable header, program header, section, and section header. Now we will try to modify the binary as per our need. But that is not easy as it sounds, because any wrong modification in ELF can corrupt the whole binary.

There are many ways to hack a binary, for example, modifying binary upcode with hex editor, or modifying shared library behavior using the "LD_PRELOAD" environment variable. But this post will be dedicated to the code section injection technique. In this technique, we will add some extra code inside the existing binary and we redirect the call to the starting address of the injected code, so it can be called throughout the execution. Just adding some extra bytes at the end of the binary will not work, we also need to add a section and program header for the newly injected section to make it work. But there is a problem that the program header is located right after the executable header as we discussed in part-2. So adding a new program header would shift all the sections and headers that come after it. To avoid such complex shifting we can simply overwrite the existing section and program headers (which are non-essential) with the new one. let’s explore how to inject a completely new code section into an ELF binary.

Making of an injectable section:-

Before injecting the code section, it's important to know how to make the injectable code section. Because a full-fledged ELF binary that contains headers and other overhead is not needed for the injection. we just need the .text section of an elf file as we are considering overwriting an existing program and section header. we'll write a simple assembly code that prints a hello message in Intel syntax, intended to be assembled with the nasm assembler in 64-bit mode.

BITS 64

SECTION .text

global main

main:

push rax ; save all clobbered registers

push rcx ; (rcx and r11 destroyed by kernel)

push rdx

push rsi

push rdi

push r11

mov rax,1 ; sys_write

mov rdi,1 ; stdout

lea rsi,[rel $+hello-$] ; hello

mov rdx,[rel $+len-$] ; len

syscall

pop r11

pop rdi

pop rsi

pop rdx

pop rcx

pop rax

push 0x4049a0 ; jump to original entry point

ret

hello: db "Hey LinuxBaya!",33,10

len : dd 15

The first few assembly instructions save the rax, rcx, rdx, rsi, and rdi registers by pushing them onto the stack. The next instructions set up the arguments for a sys_write system call, which will print hey linuxbaya! to the screen. For sys_write, the syscall number is 1(which is placed in rax), and there are three arguments: the file descriptor to write to (1 for stdout), a pointer to the string to print, and the length of the string. Now that all the arguments are prepared, the syscall instruction invokes the actual system call, printing the string. After invoking the sys_write system call, the code restores the registers to their previously saved state. It then pushes the address 0x4049a0 of the original entry point (which can be found using readelf -h <binary>) and returns to that address, starting execution of the original program.

To make the code suitable for injection, we need to assemble it into a raw binary file that contains nothing more than the binary encodings of the assembly instructions and data. To assemble hello.s into a raw binary file, we will use the nasm assembler’s -f bin option, as shown below.

$ nasm -f bin -o hello.bin hello.s

This creates the file hello.bin, which contains the raw binary instructions and data suitable for injection.

Injection of code section:-

There is one existing program header that we can always safely overwrite is the PT_NOTE header, which describes the PT_NOTE segment containing auxiliary information about the binary. For example, it’s a GNU/Linux binary, kernel version required for binary, and so on. The PT_NOTE segment contains this information in two sections called .note.ABI-tag and .note.gnu.build-id. If this information is missing, the loader simply assumes it’s a native binary, so it’s safe to overwrite the PT_NOTE header without fear of breaking the binary. This trick is commonly used by malicious parasites to infect binaries.

Changes required for Section Header:-

1. The sh_name from .note.ABI-tag to .injected and sh_type from SHT_NOTE to SHT_PROGBITS to denote that the header now describes a code section.

2. Change the sh_addr, sh_offset, and sh_size fields to describe the location and size of the new .injected section instead of the .note.ABI-tag section.

3. Change the section alignment (sh_addralign) to 16 bytes to ensure that the code will be properly aligned when loaded into memory, and add the SHF_EXECINSTR flag to the sh_flags field to mark the section as executable.

And for Program Header:-

1. Change the p_type from PT_NOTE to PT_LOAD to indicate that the header now describes a loadable segment. So the loader will load the segment into memory when the program starts.

2. Change the required address, offset, and size fields: p_offset, p_vaddr (and p_paddr, not shown), p_filesz, and p_memsz.

3. Set p_flags to mark the segment as readable and executable, instead of just readable.

4. Fix the alignment (p_align). And it’s nice to also update the string table to rename the old .note.ABI-tag section to .injected.

To make all the above changes, I am using a tool called elfenject, which is implemented using libelf, a popular open-source library for parsing ELF binaries.

Now let’s use elfinject to inject this file and redirect the ELF entry point using a hex editor so that the injected code runs on startup of the binary.

./elfinject ls.entry hello.bin ".injected" 0x800000 -1

List of sections in an injected executable ELF

We have perfectly injected a code section into an existing binary and it is also noticeable that the section header ".note.ABI-tag" is missing which is actually replaced by the ".injected" section header. So finally we hack one binary. But still, the new injected code will never run unless we redirect some calls from the original .text section to injected code. The idea is something similar to an interrupt call, first set the starting address of the injected section where we want to call the injected code, then after complete execution of injected code, we need to transfer the call to the next address of the original binary for which we need to set a return call.

1. Entry point hacking:-

Above picture, I changed the e_Entry field in the ELF executable header to point to an address in the new .injected section instead of the original entry point, which is usually somewhere in the .text, which we must call after returning from the injected code. For this, we will open the Assembly file and there we add a line to the end of the file before return.

The executable header of a modified ELF

If we see the address of the injected section in the section header with readelf -h ls.entry, it is exactly the same as mentioned in the Executable header.

The output of a modified binary

This creates the file hello.bin, which contains the raw binary instructions and data suitable for injection. Now let’s use elfinject to inject this file and redirect the ELF entry point using a hex editor so that the injected code runs on startup of the binary.

There is another technique called constructor/destructor hijacking that allows the injected code to run only once at startup or at the termination of the binary. For this, we don't need the hardcoded original entry address ( push 0x4049a0 ) in hello.s file. And just replace the next address of ".init_array" or ".fini_array" section with injected section entry address (800e78) using hexedit.

Entry point of section .init_array and .fini_array

If we want to invoke the injected function repeatedly, then we need to hack a GOT or PLT entry to replace a library call with an injected function.

2. Hack .GOT section:-

With GOT hijacking, we'll completely replace a library function, so there’s no need to transfer control back to the original implementation when the injected code completes. Thus, the assemblly shouldn’t contain any hard-coded address to which it transfers control at the end. It simply ends with a normal return. Let’s take a look at how to implement the GOT hijacking technique in practice.

Use of tool elfinject with option -1

Remove the instruction "push 0x4049a0" from the hello.s file and make a fresh hello.bin file using nasm tool as shown in the above picture and create a fresh copy of ls and inject our code into it.

Part of PLT section

Now we can use objdump to view the binary’s PLT entries (where the GOT entries are used) and find the one for fwrite_unlocked that is responsible for sys_write system call. It starts at address 0x402800, and the GOT entry it uses is located at address 0x61e2a0, which is in the .got.plt section. Using objdump to view the .got.plt section, you can see the original address stored in the GOT entry: 402806 (encoded in little-endian format).

After and before modifying the .got.plt section

As explained in part-3 lazy binding concept, this is the address of the next instruction in fwrite_unlocked’s PLT entry, which we want to overwrite with the address of the injected code. Open the ls.got file with hexedit and search for string 062840 and replace it with 780e80 (0x800e78). After changing the GOT entry to point it into our “Hey LinuxBaya!” function, the ls program now prints “Hey LinuxBaya!” every time it invokes fwrite_unlocked, replacing all of the usual ls output with copies of the “Hey LinuxBaya!” string. Of course, in real life, you’d want to replace fwrite_unlocked with a more useful function.

The output of modified binary

A benefit of GOT hijacking is that it’s straightforward and .got.plt is writable at runtime. As a result, GOT hijacking is a popular technique for exploits that aim to change the behavior of a running process (Ex:- Dynamic Instrumentation).

Instead of changing the function address stored in a GOT entry used by a PLT stub, you change the PLT stub itself. Because this technique involves changing the PLT, which is a code section, it’s not suitable for modifying a binary’s behavior at runtime.

3. Redirecting Direct and Indirect Calls:-

So far, we’ve learned how to run injected code at the start or end of a binary or when a library function is invoked. But when we want to use an injected function to replace a nonlibrary function, hijacking a GOT or PLT entry doesn’t work. In that case, we can use a disassembler to locate the calls we want to modify and then overwrite them, using a hex editor to replace them with calls to the injected function instead of the original.

The hex editing process is the same as for modifying a PLT entry. When redirecting an indirect call (as opposed to a direct one), the easiest way is to replace the indirect call with a direct one. However, this isn’t always possible since the encoding of the direct call may be longer than the encoding of the indirect call. In that case, we’ll first need to find the address of the indirectly called function that we want to replace, for instance, by using gdb to set a breakpoint on the indirect call instruction and inspecting the target address.

Once we know the address of the function to replace, we can use objdump or a hex editor to search for the address in the binary’s .rodata section. If we're lucky, this may reveal a function pointer containing the target address. We can then use a hex editor to overwrite this function pointer, setting it to the address of the injected code. If we're unlucky, the function pointer may be computed in some way at runtime, requiring more complex hex editing to replace the computed target with the address of the injected function.

BINARY ANALYSIS(PART 3): INSIDE A BINARY

2021-05-31T22:24:00.004-07:00

In the previous post, we discussed the executable header and the section header. Now we are familiar with the structure of the section header, let’s discuss the sections and the program header in this post.

3. Sections

Sections are basically classified into two parts, data, and code. Where the data section contains variables and program data, these sections are writable but the code section only contains instruction bits, so it is marked as nonwritable to avoid any kind of vulnerability attack. The below image specifies the sections found in a "Hello World" program ELF binary compiled by gcc version 4.8.5.

List of sections in an executable ELF

The readelf output shows the relevant basic information of each section, including the index (in the section header table), name, and type, virtual address, file offset, and size in bytes of the section. For sections containing a table (such as symbol tables and relocation tables), there’s also a column showing the size of each table entry. Finally, readelf also shows the relevant flags for each section, as well as the index of the linked section (if any), additional information specific to the section type, and alignment requirements. Here we will only cover some important sections instead of all.

The .init and .fini Sections

The .init section (index 11) contains executable code that performs initialization tasks and needs to run before transferring control to the main entry point of the binary. Thus, if you’re familiar with object-oriented programming, you can think of this section as a constructor. The .fini section (index 14) is analogous to the .init section, except that it runs after the main program completes, essentially functioning as a kind of destructor.

The .text Section

The .text section (index 13) is where the main code of the program resides. The .text section has the type SHT_PROGBITS because it contains user-defined code and also the section flags indicate that the section is executable but not writable.

In general, executable sections should almost never be writable (and vice versa) because it would make it easier for an attacker to exploit the vulnerability to modify the program's behavior by directly overwriting the code.

Besides the application-specific code, the .text section contains a number of standard functions that perform initialization and finalization tasks, such as _start, register_tm_clones, and frame_dummy. For now, Let's see how control goes to the main from _start function.

Part of .text section

When you write a C program, there’s always the main function where your program begins. But if you inspect the entry point of the binary(you can refer to the output of readelf -h a.out from PART 2), you’ll find that it doesn’t point to main at address 0x40052d. Instead, it points to address 0x400440, the beginning of _start. So, how does execution eventually reach the main?

Start of .text section

If you look closely at the _start function it contains an instruction at address 0x40045d which moves the address of main into the rdi register, which is used to pass parameters to function calls on x64 platforms. Then, _start calls a function called __libc_start_main. It resides in the .plt section, which is part of a shared library. The function __libc_start_main finally calls the address of the main to begin the execution of user-defined code.

The .bss, .data, and .rodata Sections

Since code sections are generally not writable, the variables are placed in one or more dedicated sections, which are writable. Constant data is usually also kept in its own section to keep the binary neatly organized. This can make clear which bytes represent instructions and which represent data.

The not writable .rodata section, which stands for “read-only data,” is dedicated to storing constant values. The default values of initialized variables are stored in the .data section, which is marked as writable since the values of variables may change at runtime.

Finally, the writable .bss section stands for “block started by symbol” reserves space for uninitialized variables. The .bss section has type SHT_NOBITS unlike .rodata and .data, which have type SHT_PROGBITS. This is because .bss doesn’t occupy any bytes in the binary as it exists on disk, it’s simply a directive to allocate a block of memory for uninitialized variables when setting up an execution environment for the binary. Typically, variables that live in .bss are zero-initialized.

The .plt, .got, and .got.plt Sections and lazy binding

The .plt(Procedure Linkage Table) is a code section that contains executable code, just like .text, while .got(Global Offset Table) is a data section. ELF binaries often contain a separate GOT section called .got.plt for use in conjunction with .plt in the lazy binding process.

Dynamically Resolving a Library Function Using the PLT

To understand the above lazy binding flow, let’s take an example of calling the puts function from libc library. It makes a call to the corresponding PLT stub, puts@plt (step 1). The PLT stub begins with an indirect jump instruction, which jumps to an address stored in the .got.plt section (step 2). Initially, before the lazy binding has happened, this address is simply the address of the next instruction in the function stub, which is a push instruction. Thus, the indirect jump simply transfers control to the instruction directly after it (step 3). The push instruction pushes an integer (in this case, 0x0) onto the stack that serves as an identifier for the PLT stub. Subsequently, the next instruction jumps to the common default stub shared among all PLT function stubs (step 4). The default stub pushes another identifier (taken from the GOT), identifying the executable itself, and then jumps (indirectly, again through the GOT) to the dynamic linker (step 5).

Using the identifiers pushed by the PLT stubs, the dynamic linker figures out that it should resolve the address of puts, then looks up the address at which the puts function is located in the library and plugs the address of that function into the GOT entry associated with puts@plt. At this point, the lazy binding process is complete. For any subsequent calls to puts@plt, the GOT entry already contains the appropriate (patched) address of puts so that the jump at the start of the PLT stub goes directly to puts without involving the dynamic linker (step 6).

The .dynamic Section

The .dynamic section functions is a “road map” for the operating system and dynamic linker when loading and setting up an ELF binary for execution.

Dynamic section

Tags of type DT_NEEDED inform the dynamic linker about the dependencies of the executable. For instance, the binary uses the puts function from the libc.so.6 shared library, so it needs to be loaded when executing the binary. the .dynamic section also contains pointers to other important information required by the dynamic linker (for instance, the dynamic string table, dynamic symbol table, .got.plt section, and dynamic relocation section pointed to by tags of type DT_STRTAB, DT_SYMTAB, DT_PLTGOT, and DT_RELA, respectively). The DT_VERNEED and DT_VERNEEDNUM tags specify the starting address.

The .init_array and .fini_array Sections

The .init_array is a data section that can contain as many function pointers used as constructors. Each of these functions is called when the binary is initialized before the main is called. In GCC, you can mark functions in your C source files as constructors by declaring them with __attribute__((constructor)). The .fini_array contains pointers to destructors rather than constructors. The pointers contained in .init_array and .fini_array can be changed to modify its behavior. Binaries produced by older GCC versions may contain sections called .ctors and .dtors instead of .init_array and .fini_array.

The .shstrtab, .symtab, .strtab, .dynsym, and .dynstr Sections

The .shstrtab section contains the names of all the sections in the binary to allow tools like readelf to find out the names of the sections. The .symtab section is the main symbol table used in compile-time linking or runtime debugging. The symbol names (as NULL-terminated strings) are stored in .strtab section. .dynsym and .dynstr sections are analogous to .symtab and .strtab, except that they contain symbols and strings needed for dynamic linking rather than static linking. Command "readelf --wide --syms a.out" can be used to see the static and dynamic symbol strings.

4. Program Headers

The Program Headers are used during execution (ELF's "execution view"), as opposed to the section view provided by the section header table. It tells the kernel or the runtime linker what to load into virtual memory and how to find dynamic linking information.

Program header structure

The p_type Field

The p_type field identifies the type of the segment. Important values for this field include PT_LOAD, PT_DYNAMIC, and PT_INTERP. Segments of type PT_LOAD, as the name implies, are intended to be loaded into memory when setting up the process. The size of the loadable chunk and the address to load it at are described in the rest of the program header. As you can see in the readelf output, there are usually at least two PT_LOAD segments—one encompassing the nonwritable sections and one containing the writable data sections. The PT_INTERP segment contains the .interp section, which provides the name of the interpreter that is to be used to load the binary. In turn, the PT_DYNAMIC segment contains the .dynamic section, which tells the interpreter how to parse and prepare the binary for execution. It’s also worth mentioning the PT_PHDR segment, which encompasses the program header table.

Program headers and the segment map view

The p_flags Field

The flags specify the runtime access permissions for the segment. Three important types of flags exist: PF_X, PF_W, and PF_R to specify the segments are executable, writable, and readable respectively.

The p_offset, p_vaddr, p_paddr, p_filesz, and p_memsz Fields

The p_offset, p_vaddr, and p_filesz fields specify the file offset at which the segment starts, the virtual address at which it is to be loaded, and the file size of the segment, respectively. most of the cases p_filesz and p_memsz are the same*.

The p_align Field

The p_align field indicates the required memory alignment (in bytes) for the segment.

BINARY ANALYSIS(PART 2): INSIDE A BINARY

2021-05-23T06:02:00.006-07:00

Now that we have a high-level idea of what binaries look like and how they work, we’re ready to dive into a real binary format. Executable and Linkable Format (ELF) is the default binary format on Linux-based systems and Portable Executable (PE) format is on Windows system. But in this series, we will discuss the Linux-based ELF format. ELF is used for executable files, object files, shared libraries, and core dumps. we’ll focus on ELF executables here, but the same concepts apply to other ELF file types. Let's take a look at ELF binary inner view.

1. Executable header:

Every ELF file starts with an executable header, which is just a structured series of bytes telling you that it’s an ELF file, what kind of ELF file it is, and wherein the file to find all the other contents. The below figure shows the type definition for the 64-bit ELF executable header from /usr/include/elf.h.

e_ident: The executable header (and the ELF file) starts with a 16-byte array called e_ident. The e_ident array always starts with a 4-byte “magic value” identifying the file as an ELF binary. The magic value consists of the hexadecimal number 0x7f, followed by the ASCII character codes for the letters E, L, and F. Having these bytes right at the start is convenient because it allows tools such as a file, as well as specialized tools such as the binary loader, to quickly discover that they’re dealing with an ELF file.

The EI_CLASS byte really denotes is whether the binary is for a 32-bit or 64-bit architecture. In the former case, the EI_CLASS byte is set to the constant ELFCLASS32 (which is equal to 1), while in the latter case, it’s set to ELFCLASS64 (equal to 2).

The EI_DATA byte indicates the endianness of the binary. A value of ELFDATA2LSB (equal to 1) indicates a little-endian, while ELFDATA2MSB (equal to 2) means a big-endian.

The EI_VERSION indicates the version of the ELF specification used when creating the binary. Currently, the only valid value is EV_CURRENT, which is defined to be equal to 1.

The EI_OSABI and EI_ABIVERSION bytes denote information regarding the application binary interface (ABI) and operating system (OS) for which the binary was compiled. If the EI_OSABI byte is set to nonzero, it means that some ABI- or OS-specific extensions are used in the ELF file. The default value of zero indicates that the binary targets the UNIX System V ABI.

The EI_ABIVERSION byte denotes the specific version of the ABI indicated in the EI_OSABI byte that the binary targets. You’ll usually see this set to zero because it’s not necessary to specify any version information when the default EI_OSABI is used.

The EI_PAD field(9 - 15) actually reserved for possible future use but currently set to zero.

You can see the e_ident array of any ELF binary by using readelf.

The e_ident array is shown on the line marked Magic. It starts with the familiar four magic bytes, followed by a value of 2 (indicating ELFCLASS64), then a 1 (ELFDATA2LSB), and finally another 1 (EV_CURRENT). The remaining bytes are all zeroed out since the EI_OSABI and EI_ABIVERSION bytes are at their default values; the padding bytes are all set to zero as well. The information contained in some of the bytes is explicitly repeated on dedicated lines, marked Class, Data, Version, OS/ABI, and ABI Version, respectively.

e_type: It specifies the type of the binary. It could be ET_REL (indicating a relocatable object file), ET_EXEC (an executable binary), and ET_DYN (a dynamic library, also called a shared object file).

e_machine: which denotes the architecture that the binary is intended to run on. Here it set to EM_X86_64. Other values include EM_386 (32-bit x86) and EM_ARM (for ARM binaries).

e_version: This field serves the same role as the EI_VERSION byte in the e_ident array.

e_entry: This field denotes the entry point of the binary; this is the virtual address at which execution should start, which means where the interpreter (typically ld-linux.so) will transfer control after it finishes loading the binary into virtual memory.

e_phoff: This indicates the file offsets to the beginning of the program header table, which means the number of bytes you should read into the file to get to the header.

e_shoff: This indicates the file offsets to the beginning of the section header table.

e_flags: This field provides room for flags specific to the architecture for which the binary is compiled. For x86 binaries, e_flags is typically set to zero.

e_ehsize: This field specifies the size of the executable header, in bytes. For 64-bit x86 binaries, the executable header size is always 64 bytes, as you can see in the readelf output, while it’s 52 bytes for 32-bit x86 binaries.

e_phnum: Number of program header in the binary.

e_phentsize: Size of each program header.

e_shnum: Number of section header in the binary.

e_shentsize: Size of each section header.

e_shstrndx: This field contains the index (in the section header table) of the header associated with a special string table section, called .shstrtab which stores the names of all the sections in the binary.

To make the following discussion easier to follow, we’ll discuss section headers and sections before program headers.

2. Section Headers:

The code and data in an ELF binary are logically divided into contiguous non-overlapping chunks called sections. Sections don’t have any predetermined structure. So the properties of the section are described by a section header, which allows you to locate the bytes belonging to the section. Let’s begin by discussing the format of the section headers.

sh_name: Section name (string tbl index). If set, it contains an index into the string table. If the index is zero, it means the section doesn’t have a name.

sh_type: Section type tells the linker something about the structure of a section’s contents. If it is SHT_PROGBITS, then it contains program data, such as machine instructions or constants. SHT_SYMTAB for static symbol tables and SHT_DYNSYM for symbol tables used by the dynamic linker and string tables (SHT_STRTAB). Sections with type SHT_REL or SHT_RELA contain relocation entries. Sections of type SHT_DYNAMIC contain information needed for dynamic linking.

sh_flags: Section flags describe additional information about a section. SHF_WRITE indicates that the section is writable at runtime. The SHF_ALLOC flag indicates that the contents of the section are to be loaded into virtual memory when executing the binary. Finally, SHF_EXECINSTR tells you that the section contains executable instructions, which is useful to know when disassembling a binary.

sh_addr: Section virtual address at execution. Sections that aren’t intended to be loaded into virtual memory have sh_addr value of zero.

sh_offset: Section file offset, file offset (in bytes from the start of the file

sh_size: Section size in bytes,

sh_link: The sh_link field makes the relationships between sections explicit by denoting the index of the related section, that the linker needs to know about.

sh_info: This field contains additional information about the section. For instance, for relocation sections, sh_info denotes the index of the section to which the relocations are to be applied.

sh_addralign: Some sections may need to be aligned in memory in a particular way for efficiency of memory accesses. For instance, if this field is set to 16, it means the base address of the section (as chosen by the linker) must be some multiple of 16. The values 0 and 1 are reserved to indicate no special alignment needs.

sh_entsize: Some sections, such as symbol tables or relocation tables, contain a table of well-defined data structures (such as Elf64_Sym or Elf64_Rela). For such sections, the sh_entsize field indicates the size in bytes of each entry in the table. When the field is unused, it is set to zero.

The section headers for all sections in the binary are contained in the section header table. We will discuss the section and program header in the next part not to make this post so long.

BINARY ANALYSIS(PART 1): BINARY CREATION

2021-05-21T03:45:00.001-07:00

A binary file is an executable file containing only "0" and "1". In this series of posts, we are going to analyze the binary file. Every programmer should know how to create binary. Of course, it is not the case that we open an editor, write 1 and 0, and try to execute the file. We need a compiler like gcc, clang, msvc etc. to create a binary file. The compiler creates a binary file from the source files that are written in any programming language. Before we delve deeper into the binary, let's recall the creation and its loading process in memory for the execution.

Four stages of the compilation process start with the preprocessing phase by expanding all #define and #include directives in the source file. After the preprocessing phase is complete, all we get inside is pure code that is ready to be compiled. The compilation phase takes the preprocessed code and translates it into assembly language. (Most compilers also perform heavy optimization in this phase, typically configurable as an optimization level through command line switches such as options -O0 through -O3 in gcc. In the assembly phase, we finally get to generate some real machine code! The input of the assembly phase is the set of assembly language files generated in the compilation phase, and the output is a set of object files. We can tell the compiler to stop the compilation process after a particular phase, by providing command-line switches like -E, -S, and -c for the preprocessed, compiled, and assembled file, respectively.

The term relocatable in the file output tells that you’re dealing with an object file and not with an executable. Object files are compiled independently from each other, so the assembler has no way of knowing the memory addresses of other object files when assembling an object file. That’s why object files need to be relocatable. So we can link them together in any order to make a complete binary executable. If object files were not relocatable, this won't be possible.

Most compilers, including gcc, automatically call the linker at the end of the compilation process. The linker’s job is to take all the object files belonging to a program and merge them into a single coherent executable, typically intended to be loaded at a particular memory address. Now that the arrangement of all modules in the executable is known, the linker can also resolve most symbolic references. References to libraries may or may not be completely resolved, depending on the type of library.

Static libraries are merged into the binary executable, allowing any references to them to be resolved entirely. There are also dynamic (shared) libraries, which are shared in memory among all programs that run on a system. In other words, rather than copying the library into every binary that uses it, dynamic libraries are loaded into memory only once, and any binary that wants to use the library needs to use this shared copy.

During the linking phase, the addresses at which dynamic libraries will reside are not yet known, so references to them cannot be resolved. Instead, the linker leaves symbolic references to these libraries even in the final executable, and these references are not resolved until the binary is actually loaded into memory to execute.

When you decide to run a binary, the operating system starts by setting up a new process for the program to run in, including a virtual address space.7 Subsequently, the operating system maps an interpreter into the process’s virtual memory. This is a user space program that knows how to load the binary and perform the necessary relocations. On Linux, the interpreter is typically a shared library called ld-linux.so. On Windows, the interpreter functionality is implemented as part of ntdll.dll. After loading the interpreter, the kernel transfers control to it, and the interpreter begins its work in userspace.

The interpreter loads the binary into its virtual address space (the same space in which the interpreter is loaded). It then parses the binary to find out (among other things) which dynamic libraries the binary uses. The interpreter maps these into the virtual address space (using mmap or an equivalent function) and then performs any necessary last-minute relocations in the binary’s code sections to fill in the correct addresses for references to the dynamic libraries. In reality, the process of resolving references to functions in dynamic libraries is often deferred until later. In other words, instead of resolving these references immediately at load time, the interpreter resolves references only when they are invoked for the first time. This is known as lazy binding. After relocation is complete, the interpreter looks up the entry point of the binary and transfers control to it, beginning normal execution of the binary.

In the next part, we will see what exactly we find inside the executable file.

SENSOR DATA VISUALIZATION USING GRAFANA AND MQTT

2020-11-14T06:12:00.006-08:00

In our last post, we have seen how to fetch sensor data from the edgex foundry to the server-side using the Rest API. Here we will discuss how to use the MQTT protocol to get the sensor data and visualize them using Grafana. While this is not a part of EdgeX Foundry, it can be useful to know how to capture, save, and visualize data.

If you don't have prior knowledge about MQTT for a quick understanding will give an example of an eCommerce website like Amazon or Mytra, if a product goes out of stock then a Notify Me button will appear instead of Buy Now. If you press the notify button, it will get you noticed whenever the product will be available.

Similarly, MQTT protocol has two clients (at least) like seller and buyer, one who publish the data called the publisher and the other who subscribe to the same data called subscriber and both clients depend on one platform like Amazon called MQTT-Broker who can manage multiple publishers and subscribers. Whenever a publisher publishes or sends data to the broker, the broker's job is to immediately send the data to all the subscribers who subscribe to the same publisher topic/data.

Here we are going to do the same process using edgex foundry(publisher), Mosquitto (Broker), and a messenger application(subscriber).

Four new containerized applications will be added to the same VM running EdgeX Foundry for this demo (Or you can use a different VM in the same network). Follow these steps:-

These are:-

1. Mosquitto: A MQTT broker that can be run locally.

Download and run:-

docker pull eclipse-mosquitto

docker run --name mosquitto -d -p 1883:1883 -p 9001:9001 eclipse-mosquitto

2. InfluxDB: A time-series database perfect for capturing sensor data over time. We need to configure it with grafana.

Download and run:-

docker pull influxdb

docker run \

-d \

--name influxdb \

-p 8086:8086 \

-e INFLUXDB_DB=sensordata \

-e INFLUXDB_ADMIN_USER=root \

-e INFLUXDB_ADMIN_PASSWORD=toor \

-e INFLUXDB_HTTP_AUTH_ENABLED=true \

influxdb

3. Grafana: A graphical dashboard which supports InfluxDB

Download and run:-

docker pull grafana/grafana

docker run -d --name=grafana -p 3000:3000 grafana/grafana

Attach the Influx DB to Grafana:-

Step1: Open grafana dashboard from browser using "ipaddress:3000"

Step2: It will ask to set a new password.

Step3: Set the influx DB as your first data source.

Step4: Do the following settings:

url: <influx db ip>:8086

database: sensordata

user: root

password: toor

4. Messenger: A python script in a container that captures MQTT messages and sends them into the InfluxDB. To run the script inside the container, follow the below steps.

Step1:- Download the file from here, extract it, and go to the subscriber folder.

Open the file “app.py’ in an editor and replace “mqtt-ip-adderss” with the actual IP address of the VM where the Mosquitto installed, the "topic-name" with the name of your topic (this should be unique), and the "Influx-ip-address" with IP address of the VM where the Influx Data base installed (Likely the EdgeX Foundry VM IP address in my case).

Note: There are two entries! Don’t use the loopback address (127.0.0.1) as the ports will clash with the mosquitto MQTT broker.

Step2:- Build the container for the messenger app

docker build -t subscriber .

Note: Make sure to execute the “docker build” command in the

“subscriber” directory.

Step3:- Run the messenger app

docker run -d --name subscriber subscriber:latest

Now all four containers are running.

Go to the Edgex setup and add the below service to the docker-compose.yml file to run mqtt on edgex.

app-service-mqtt:

image: edgexfoundry/docker-app-service-configurable:1.1.0

ports:

- "0.0.0.0:48101:48101"

container_name: edgex-app-service-configurable-mqtt

hostname: edgex-app-service-configurable-mqtt

networks:

edgex-network:

aliases:

- edgex-app-service-configurable-mqtt

environment:

<<: *common-variables

edgex_profile: mqtt-export

Service_Host: edgex-app-service-configurable-mqtt

Service_Port: 48101

MessageBus_SubscribeHost_Host: edgex-core-data

Binding_PublishTopic: events

# Added for MQTT export using app service

WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_ADDRESSABLE_ADDRESS: "mqtt-broker-ip"

WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_ADDRESSABLE_PORT: 1883

WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_ADDRESSABLE_PROTOCOL: tcp

WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_ADDRESSABLE_TOPIC: "topic-name"

WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_PARAMETERS_AUTORECONNECT: "true"

WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_PARAMETERS_RETAIN: "true"

WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_PARAMETERS_PERSISTONERROR: "false"

# WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_ADDRESSABLE_PUBLISHER:

# WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_ADDRESSABLE_USER:

# WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_ADDRESSABLE_PASSWORD:

# WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_PARAMETERS_QOS: ["your quality or service"]

# WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_PARAMETERS_KEY: [your Key]

# WRITABLE_PIPELINE_FUNCTIONS_MQTTSEND_PARAMETERS_CERT: [your Certificate]

depends_on:

- consul

# - logging # uncomment if re-enabled remote logging

- data

Or download the updated docker-compose.yml file from here.

And replace the "mqtt-broker-ip" with your VM IP where the mosquitto broker is installed. And the "topic-name" with your unique topic.

Note:- Topic name should be same in both app.py and docker-compose.yml.

Now run the same python script to get sensor data and send it to edgex foundry used in the previous post. (Watch the demo video)

After the script runs you can create a panel in Grafana to see the collected sensor data with the following settings.

Same you can create for Temperature data.

The summary of the data flow will be:-

1. Data goes from sensor to edgex by an HTTP request.

2. MQTT client(publisher) on edgex will be sending the real-time data to the MQTT broker(Mosquitto).

3. Another MQTT client (Subscriber) on messenger will get the sensor data and send it to the Influx database.

4. Grafana dashboard will show you the real-time data structure that is updating frequently to the influx database.

Here is the video demonstration of this post:-

This is how the MQTT protocol is useful for the Edgex foundry service.

SENDING SENSOR DATA TO SERVER USING EDGEX FOUNDERY

2020-09-27T01:55:00.017-07:00

From the previous post, we are clear about the installation and accessing of edgex foundry. Now using that edgex we can send sensor data to the server/cloud or to any devices like smartphones. For example, if we want to control our home IoT devices like light, fan, AC, TV, refrigerator, etc.(Anything that can act as an IoT device) using our smartphone, we can do that also using MQTT protocol. Anyways I will discuss the MQTT pub-sub model and its working mechanism in the next post. Let's talk about the usage of edgex foundry by one example.

Here I am discussing to send and fetch the sensor data to and from the edgex foundry respectively using the Http service.

In order to send data to edgex first, we need to set up a device on edgex using UI or the rest API. So setting up a device means, let the edgex be aware of the existence of the device, be able to receive data from the device, understand the type and format of data, etc. The following steps are used to set up a device.

Before that make sure the edgex foundry is accessible by its IP address. If not, then you can change the port of all services from "127.0.0.1" to "0.0.0.0" in the docker-composer.yml file and restart all services.

1. Create value descriptors

2. Upload the device profile

3. Create the device

1. Create value descriptors

Value descriptors describe a value. They tell EdgeX what format the data comes in and what to label the data with. Here I am creating value descriptors for temperature and humidity values.

Open Postman and use the following values:

Method: POST

URI: http://<edgex ip>:48080/api/v1/valuedescriptor

Payload settings: Set Body to “raw” and “JSON”

Payload data:

{

"name": "humidity",

"description": "Ambient humidity in percent",

"min": "0",

"max": "100",

"type": "Int64",

"uomLabel": "humidity",

"defaultValue": "0",

"formatting": "%s",

"labels": [

"environment",

"humidity"

]

}

Tip: Use the very excellent feature “Beautify” on the “Body” tab in Postman to fix any indentation issues with the JSON payload.

Watch for the return code of “ 200 OK ” and the ID of the newly created value descriptor.

There is no need to make note of the ID.

Update the body and issue the command again for temperature::

Method: POST

URI: http://<edgex ip>:48080/api/v1/valuedescriptor

Payload settings: Set Body to “raw” and “JSON”

Payload data:

{

"name": "temperature",

"description": "Ambient temperature in Celsius",

"min": "-50",

"max": "100",

"type": "Int64",

"uomLabel": "temperature",

"defaultValue": "0",

"formatting": "%s",

"labels": [

"environment",

"temperature"

]

}

Viewing value descriptors through Postman

2. Upload the device profile

EdgeX incorporates device profiles as a way of easily adding new devices. A device profile is essentially a template that describes the device, its data formats, and supported commands. It is a text file written in YAML format which is uploaded to EdgeX and later referenced whenever a new device is created. Only one profile is needed per device type. Some vendors provide pre-written device profiles for their devices. In this case, I am using a custom device template.

Get a copy of the device profile from here:

In Postman use the following settings:

Method: POST

URI: http://<edgexip>:48081/api/v1/deviceprofile/uploadfile

Payload settings: This part is a bit tricky:

● Set Body to “form-data”

● Hover over KEY and select “File”

● Select the yaml file: sensorClusterDeviceProfile.yaml

● In the KEY field, enter “file” as key

Or you can upload the device profile using the UI.

3. Create the device

Now EdgeX is finally ready to receive the device creation command in Postman as

follows:

Two items are particularly important in this JSON body:

● The device service “edgex-device-rest” is used since this is a REST device.

● The profile name “TestSensorData” must match the name in the device profile yaml file uploaded in the previous step.

Feel free to change values for description, location, labels, etc. if desired.

In Postman use the following settings:

Method: POST

URI: http://<edgex ip>:48081/api/v1/device

Payload settings: Set Body to “raw” and “JSON”

Payload data:

{

"name": "Temp_and_Humidity_sensor_data",

"description": "DTH11 sensor data",

"adminState": "unlocked",

"operatingState": "enabled",

"protocols": {

"example": {

"host": "dummy",

"port": "1234",

"unitID": "1"

}

"labels": [

"Humidity sensor",

"Temperature sensor",

"DHT11"

"location": "India",

"service": {

"name": "edgex-device-rest"

"profile": {

"name": "TestSensorData"

}

If the above commands completed successfully a new sensor device will have been registered and EdgeX is ready to receive data from it.

Demonstration:

Here I am trying to demonstrate the above things with the below setup but you can use a Raspberry pi for the edge node:-

Send data:-

Here I am getting the temperature and humidity data from my host machine(edge node) serial port through the Arduino nano and sending these to data to the edgex foundry using an Http POST request. The Arduino code to get the sensor data and the python code for POST Http request can found here.

The POST command to send data:-

http://<edgex ip>:49986/api/v1/resource/Temp_and_Humidity_sensor_data/temperature

You can send the value as payload and every POST call make an event count. So you can see that using this URL on your web browser:-

http://<edgex ip>:48080/api/v1/event/count

Fetch data:-

Making the HTTP GET request from the host machine (which will be acting as a server now) to get the saved data from edgex foundry.

The GET command to fetch the data:-

http://<edgex ip>:48080/api/v1/reading

Here is the video demo of DTH11 sensor:-

Download Resources which contains the Arduino and python script shown in the video.

EDGEX FOUNDRY AND IT'S SETUP

2020-09-22T23:10:00.047-07:00

EdgeX Foundry:-

All the different types of IoT devices speak different languages and follow different protocols like BACnet, OPC-UA, MQTT, and REST. EdgeX foundry brings data from all different sources to a single platform and makes it available for the cloud. It a software solution that takes all that data in and normalized into a single format for the cloud and it's also able to control things.

It can also be configured to match individual data formats used by devices from different vendors by using device profiles. EdgeX Foundry is made up of a collection of microservices, each of which runs in a container. That you can see in the above picture. Microservices communicate with each other over REST API interfaces. It is able to convert source data from proprietary data formats into XML or JSON, encrypt, compress, and finally forward that data to an external source over MQTT or other protocols.

Installation of EdgeX Foundry would generally be done close to the sensors/data being generated. For example on an edge gateway appliance. There could be thousands of these, each with its own EdgeX installation, ingesting, converting, and forwarding data to a central location. While EdgeX runs as a collection of containerized microservices it doesn’t currently support k8s. Note that since the overhead for k8s can be prohibitive for low-powered edge nodes, lack of k8s support isn’t necessarily a concern.

Below we are going to discuss the installation setup of EdgeX foundry on Ubuntu 20.04 (VM).

Step 1: Installing Docker and docker-compose

If you are not aware of docker, you can read from here.

WHAT IS DOCKER AND HOW IT WORKS?

Follow the process to install docker-engine.

Run these command to update the system

$ sudo apt update

$ sudo apt upgrade -y

Now install the Docker-CE by verifying the certificate

$ sudo apt install apt-transport-https ca-certificates curl software-properties-common -y

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Note: Match “ focal ” below with your distribution if different from 20.04 (check with “lsb_release -a” if unsure about the version):

$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"

$ sudo apt update

$ sudo apt install docker-ce -y

Now give permission to the current user to run docker binary and after that, log out and back in again to get the effect of new permissions.

$ sudo usermod -aG docker ${USER}

Now install docker-compose with the below command.

$ sudo apt install docker-compose -y

Step 2: Running EdgeX Foundry

We are going to run EdgeX using a docker-composer that manages the containers in the YAML file as a group. basically, it specifies how each microservice should run, its ports, volumes, and all dependencies.

First, create a directory for the EdgeX Foundry docker-compose.yml file.

$ mkdir edgex

$ cd edgex

Download the docker-compose.yml file from the link

$ wget https://raw.githubusercontent.com/edgexfoundry/developer-scripts/master/releases/geneva/compose-files/docker-compose-geneva-redis.yml

$ cp docker-compose-geneva-redis.yml docker-compose.yml

Pull the containers and list the newly downloaded images

$ docker-compose pull

$ docker image ls

Start EdgeX Foundry using docker-compose

$ docker-compose up -d

List the running containers

$ docker-compose ps

Note that the ports used by EdgeX are listed for each container. These ports are defined in the docker-compose.yml file along with many other settings.

Step 3: Accessing EdgeX Foundry

We can interact with edgex either from the command line (using cURL, postman, etc..) or from the web browser(chrome, firefox, etc..).

To list out the registered device in edgex foundry we can run the curl command on the CLI.

$ curl http://<edgex ip>:48082/api/v1/device

Or to get a structured output run:

$ sudo apt install jq

$ curl http://<edgex ip>:48082/api/v1/device | jq

Similarly, we can make a POST method to send the sensor data and the GET method to get the data from EdgeX using any REST API libs like cURL or postman.

Note: The command “docker-compose ps” is helpful to find out the port number to get interact with that service.

We can also interact with EdgeX through UI. There are many UI available for EdgeX Foundry but we are using its own golang UI for this example.

a. Open the docker-compose.yml file in an editor

b. Add an entry for the golang ui under the “services” section as per the below:

ui:

container_name: edgex-ui-go

hostname: edgex-ui-go

image:

nexus3.edgexfoundry.org:10004/docker-edgex-ui-go:master

networks:

edgex-network: null

ports:

- "0.0.0.0:4000:4000/tcp"

read_only: true

Note: compare the entries above and match the indentation.

c. Save and exit the editor

d. Start EdgeX Foundry

$ docker-compose up -d

e. The EdgeX UI can now be accessed in a browser at:

http://<edgex ip>:4000

Note: If asked, use “admin” / “admin” for username / password.

Step 4: Stopping EdgeX Foundry

The commands in this section need to be issued from the folder containing the docker-compose.yml file (“edgex” in this example).

To just stop the containers:

$ docker-compose stop

To stop and remove the containers:

$ docker-compose down

To stop and remove containers + volumes (the original images will remain):

$ docker-compose down -v

Here is the video demonstration:-

In the next post, we will see how to send the sensor data to any server or cloud using the EdgeX foundry.

CROSS-PLATFORM DEVELOPMENT TOOLCHAIN

2020-09-17T21:50:00.000-07:00

Cross-compilation

In a Linux system, if we write a simple "Hello world" program in c/c++ programming language, and compile it using gcc/g++ compiler, it will generate an executable binary file that can only be executed in Linux platform. We can't run that binary on the Windows platform. To make a Windows executable binary on the Linux system we need a different compiler. One thing to be noticed here is the host machine where we run the compiler (Linux) and the target machine for which we make the compilation (Windows) both are different platforms. And this is called cross-platform-compilation or cross-compilation.

This is typically used in the Embedded development systems. They required this cross-compiler in a faster platform like Linux or PowerPC to build the source code for a slower platform like ARM/AVR.

Toolchain

To make a cross-compiler we need a set of development tools that are linked together by specific stages called toolchain.

A lot of prebuilt cross-platform toolchains are available. You may choose to use such packages instead of carrying out the procedure explained here. I suggest you read the book 'Building Embedded Linux Systems' 2nd edition to know the detailed procedure.

You can download the components of the GNU toolchain from the FSF's FTP site at ftp://ftp.gnu.org/gnu/ or any of its mirrors. The binutils package is in the binutils directory, the gcc package is in the gcc directory, and the glibc package is in the glibc directory.

With the appropriate tools in place, let us take a look at the procedure used to build the toolchain. These are the five main steps:

1. Kernel headers setup

2. Binary utility setup

3. Bootstrap compiler setup

4. C library setup

5. Full compiler setup

Before developing the toolchain we need to create new directories and set some environmental variables to make our configuration easy. Since we were logged in as non-root user, we should create new directories under the user folder to avoid any kind of permission error.

The below command will create all directories required for this toolchain development.

$ mkdir toolchain toolchain/tools toolchain/kernel toolchain/build-tools toolchain/build-tools/build-binutils toolchain/build-tools/build-boot-gcc toolchain/build-tools/build-glibc toolchain/build-tools/build-gcc

Put below lines inside a script and source the script to set the environment variables.

export PROJECT=toolchain

export PRJROOT=/home/linuxbaya/demo-module/${PROJECT}

export TARGET=arm-linux

export PREFIX=${PRJROOT}/tools

export TARGET_PREFIX=${PREFIX}/${TARGET}

export PATH=${PREFIX}/bin:${PATH}

cd $PRJROOT

The TARGET variable defines the type of target for which your toolchain will be built. For PowerPC it would be powerpc-linux, for ARM it would be arm-linux, for SuperH4 it would be sh4-linux. The PREFIX variable provides the component configuration scripts with a pointer to the directory where we would like the target utilities to be installed. Conversely, TARGET_PREFIX is used for the installation of target-dependent header files and libraries.

Now move to the build-tool directory and download four packages binutils, gcc, and glibc from the FSF's FTP site at ftp://ftp.gnu.org/gnu/ or any of its mirrors. Everything is now almost ready for building the actual toolchain.

1. Kernel Headers Setup

As I said earlier, the setup of the kernel headers is the first step in building the toolchain. Select a kernel from the main kernel repository at http://www.kernel.org/ or any other mirror site, the first thing you need to do is download a copy of that kernel into the directory ${PRJROOT}/kernel.

$ tar xvzf linux-5.8.9.tar.gz

$ cd linux-5.8.9

$ make ARCH=arm INSTALL_HDR_PATH=headers/ headers_install

This will display a menu in your console where you will be able to select your kernel's configuration. Simply save and exit will create a .config file in your current working directory. We can now create the include directory required for the toolchain and copy the kernel headers to it:

$ cp -r headers/include/asm /usr/include

$ cp -r include/linux/ /usr/include

$ cp -r include/asm-generic/ /usr/include

Kernel headers are required; usually during the compilation of glibc.

2. Binutils Setup

The binutils package includes the utilities most often used to manipulate binary object files. The two most important utilities within the package are the GNU assembler, as, and the linker, ld, and others are gasp, ar, nm, objcopy, objdump, ranlib, readelf, etc.

The first step in setting up the binutils package is to extract its source code from the archive we downloaded earlier:

$ cd ${PRJROOT}/build-tools

$ tar xvzf binutils-2.10.1.tar.gz

$ cd build-binutils

$ ../binutils-2.10.1/configure --target=$TARGET --prefix=${PREFIX}

With the Makefiles now ready, we can build the actual utilities:

$ make

With the package now built, we can install the binutils:

$ make install

The binutils have now been installed inside the directory pointed to by PREFIX. You can check to see that

$ ls ${PREFIX}/bin

3. Bootstrap Compiler Setup

Again, we start by extracting the gcc package from the archive we downloaded earlier:

$ cd ${PRJROOT}/build-tools

$ tar xvzf gcc-9.2.0.tar.gz

This will create a directory called gcc-9.2.0 with the package's content. Move to the directory and download the prerequisites.

$ cd gcc-9.2.0

$ ./contrib/download_prerequisites

We can now proceed to the configuration of the build in the directory we had prepared for the bootstrap compiler:

$ cd ../build-boot-gcc

$ ../gcc-9.2.0/configure --target=$TARGET --prefix=${PREFIX} \

> --without-headers --with-newlib --enable-languages=c

With the Makefiles ready, we can now build the compiler:

$ make all-gcc

$ make install-gcc

The bootstrap compiler is now installed alongside the binutils, and you can see it by relisting the content of ${PREFIX}/bin. The name of the compiler is called arm-linux-gcc in our example.

4. C Library Setup

In our cross-platform development toolchain, This package is the most delicate and lengthy package build. It is made up of many libraries.

As with the previous packages, we start by extracting the C library from the archive we downloaded earlier:

$ cd ${PRJROOT}/build-tools

$ tar xvzf glibc-2.32.tar.gz

This will create a directory called glibc-2.32 with the package's content. We can now proceed to preparing the build of the C library in the build-glibc directory:

$ cd build-glibc

$ CC=arm-linux-gcc ../glibc-2.32/configure --host=$TARGET \

> --prefix="/usr" --enable-add-ons \

> --with-headers=${TARGET_PREFIX}/include

Along with the other components of the C library, the link script has been installed in the ${TARGET_PREFIX}/lib directory. In its original form, libc.so looks like this:

/* GNU ld script

Use the shared library, but some functions are only in

the static library, so try that secondarily. */

GROUP ( /lib/libc.so.6 /lib/libc_nonshared.a )

Modify it to:

/* GNU ld script

Use the shared library, but some functions are only in

the static library, so try that secondarily. */

GROUP ( libc.so.6 libc_nonshared.a )

Before modify, I suggest you to make a copy of it.

$ cd ${TARGET_PREFIX}/lib

$ cp ./libc.so ./libc.so.orig

By modifying it now we are forcing the linker to use the libraries found within the same directory as the libc.so script, instead of the native ones found on your host.

5. Full Compiler Setup

We are now ready to install the full compiler for your target with both C and C++ support.

$ cd ${PRJROOT}/build-tools/build-gcc

$ ../gcc-9.2.0/configure --target=$TARGET --prefix=${PREFIX} \

> --enable-languages=c,c++

The options we use here have the same meaning as when building the bootstrap compiler. Notice that there are fewer options and that we now add support for C++ in addition to C. With the full compiler properly configured, we can now build it:

$ make all

Notice that we didn't use all-gcc as with the bootstrap compiler, but rather all. This will result in the build of all the rest of the components included with the gcc package, including the C++ runtime libraries. If you didn't properly configure the libc.so link script file as previously explained, the build will fail during the compilation of the runtime libraries.

With the full compiler now built, we can install it:

$ make install

This will install the full compiler over the bootstrap compiler we had previously installed.

Using the Toolchain

You now have a fully functional cross-development toolchain, which you can use very much as you would a native GNU toolchain, save for the additional target name prepended to every command you are used to. Instead of invoking gcc and objdump for your target, you will need to invoke arm-linux-gcc and arm-linux-objdump.

The following is a Makefile for the control daemon on a test module that provides a good example of the cross-development toolchain's use:

The first part of the Makefile specifies the names of the toolchain utilities we are using to build the program. The second part of the Makefile defines the build settings. CFLAGS provides the flags to be used during the build of any C file. If you wish to link your application statically, you need to add the -static option to LDFLAGS. This generates an executable that does not rely on any shared library. But given that the standard GNU C library is rather large, this will result in a very large binary. A simple program that uses printf( ) to print "Hello World!", for example, is less than 12 KB in size when linked dynamically and around 350 KB when linked statically and stripped.

The make rules themselves are very much the same ones you would find in a standard, native Makefile. I added the install rule to automate the install process.

WHAT IS VoIP AND SIP?

2020-09-03T23:35:00.002-07:00

VoIP (Voice Over Internet Protocol) is a term that used to any end-to-end call over the internet service instead of any cellular network or the traditional telephonic line. Using VoIP we can make any kind of calls (audio, video) without any prepaid or postpaid recharges. It requires internet connectivity. We just have to make sure that our application is connected to the internet for which the voice or video data packets generated from one end could be transmitted to the other end through the internet. That is what Skype, WhatsApp, like applications, and many companies (for its internal communication between employees) do nowadays.

This is possible because of the application layer protocol "SIP". It is a signaling protocol that allows two clients to establish a media session with each other. It mostly uses UDP protocol to transfer packets, although it can use both TCP and UDP protocol for packet transfer.

SIP stands for Session Initiation Protocol which is used to initiate, modify, and terminating sessions (maybe text, voice, video, or a combination of these) with one or more participants in an IP network. Basically, it's of two entities, one is the client, and the other is the server.

1. SIP Client:- Clients are the entities who make requests.

2. SIP Server:- Server is the entity that accepts the client request and sends a response to the respective request.

There are some individual servers present inside the SIP server like- Proxy server, Registrar, Redirect Server, Location server.

Proxy Server:- When a client generates a SIP request message, it goes to the proxy server. Then the proxy server forwards the request to another proxy server or to the recipient. And a SIP request message could be:-

1. INVITE ---> Request a session

2. ACK ---> Final response to the INVITE

3. OPTIONS ---> Ask for server capability (In order to support voice, video text)

4. CANCEL ---> Cancel a pending request

5. BYE ---> Terminate a session

6. REGISTER ---> Send user address to the server

7. NOTIFY ---> To send event notice

Registrar:- It used to register any new client into the SIP server.

Redirect Server:- It redirects back the client request in case the recipient is missing from the location server.

Location Server:- The addresses registered to the registrar are stored in the location server.

The workflow of SIP:-

Here is an example of two SIP clients communicate with each other through the SIP server given below. Here both clients are already registered with the server and client 1 is trying to initiate the voice call with client 2.

When client 1 tries to initiate a conversation session by sending an "INVITE" request to client 2, then the request goes to the proxy server. The proxy server tries to check the registered address of client 2 from the location server if it failed to get the client 2 address it simply redirects back the request otherwise it sends a 100 Trying response to client 1 and then sends the "INVITE" request to client 2 and waiting for the client 2 response. When the server gets the "180 ringings" response from client 2, it sends the same response to client 1. When client 2 receives the call, the server gets a "200 OK" response from client 2 and acknowledges it. Then the client 1 gets the "200 OK" response from the server followed by an acknowledgment and starts their conversation.

Here is a picture of the server logs of a video call session made from client id 4002 to client id 4000.

After the completion of the conversation, client 1 tries to end the call by sending a "BYE" request that is answered by "200 OK" from the server and the server sends a "BYE" request message to client 2 and the session is closed. The last two lines of the above picture show that both clients have left the conversation. Now close the session.

Watch this VoIP video demo to clarify more:-

Here I am using the open-source software for both server and client i.e Asterisk and LinPhone respectively and trying to show the sip server logs of a video call session.

SYSTEM CALLS IN LINUX

2020-08-02T16:32:00.000-07:00

What is the System Call?

Before we know what is it, we should know why it is. In that way, we can get more involved in any topic.

As we know the Operating System(OS) is the interface between hardware and user-level applications and the OS controls all the hardware resources (like hard disk, display, keyboard, etc.). When a user-level application let's say VLC media player wants to use the 'display' resource to project/show a video on the screen. then it makes a request to the operating system for the 'display' resource. After that, the operating system reserves that particular resource for the VLC media player for the requested time period. Then only the VLC can use the screen to display contents. This request to acquire resources is called a system call. So in order to use any resources managed by the operating system, we need a system call.

How the system call works:-
System calls are like function calls (Not exactly the same). There is a separate piece of code written to access the system hardware through the device driver, which suppose to be accessed by kernel only (Device drivers are another piece of software without which hardware can't interact with OS). The declarations and definitions of these functions are present in the POSIX library. That's why we include the header file from the library to our code in order to use any system calls. For e.g, we include "sys/types.h" header file to use "fork" system call to create a child process and likewise.

The starting address of all functions is saved in a table with there respective APIs. Whenever we call a system function, it looks for its API address from the table and jumps to that address to perform the operation. After successful execution, the control returns back to the caller function. This complete process is called a system call. Because we use the system code to make a kernel-level task complete through an API call.

System calls are basically written in High-Level languages like C/C++. There are different system calls made for different Operating Systems, like:-

1. POSIX API for POSIX based system (Unix, Linux, macOS).

2. Win32 API for Windows.

3. Java API for Java Virtual Machine (JVM)

Below are some examples of system calls written with respect to their tasks for POSIX Operating System. you can get all Linux system calls from here.

1. Process control:-
a) Create and terminate the process.
b) Get and set process attributes.
c) Load and execute.
d) Wait for time.
e) Wait and signal event.
f) End and abort.
g) Allocate and free memory.

2. File manipulation:-
a) Open and close file
b) Create and delete a file
c) Read and write
d) Get and set file attributes

3. Device manipulation:-
a) Request and release device
b) Logically attach and detach a device
c) Read, write and reposition
d) Get and set device attributes

4. Information maintenance:-
a) Get and set time
b) Get and set date
c) Get and set system data

5. Communication:-
a) Create and delete a communication connection
b) Transfer status information
c) Attach and detach a remote device
d) Send and receive messages

Actually, we can create our own system call. There are several blogs written on how to create a system call and compile it with the Linux kernel source code. Here is a video on the practical demo of system call creation.

The video will be coming soon.

WHAT IS DOCKER AND HOW IT WORKS?

2020-07-12T04:06:00.003-07:00

To understand the docker concept better, we need some prior knowledge of the virtualization concept. Read WHAT IS VIRTUALIZATION..?

Even this post will try to explain both the concepts.

Read the story to understand the concept behind docker:-

Once upon a time, there was a guy named 'Baya' who lived somewhere in Germany. One day he thought to run a process/program for his user-level application stuff. So he placed the process in a computer and executed it. Everything went fine. But one day the process got stuck without any reason (God knows) and it crashed. And the whole system went down with that process.

Then he decided to place an inner computer inside the main computer (Virtualization) to execute the process. If anything goes wrong with the process then it won't affect the outer computer. And it worked. The requirement of processes increased over time and he created multiple inner computers inside that system and placed multiple processes to run. Resources were getting low with increasing inner computers. At a point of time, the outer system went down because of insufficient resources. And everything got stuck.

Virtualization Vs. Containerization

And here the Linux namespace plays a great role to overcome this situation. The namespace is a feature of Linux kernel which partitions kernel resources such that each set of processes can see a different set of resources. There is no need to create an inner system to virtualize the outer system resources. There are few namespaces:-

Mount(mnt):- It isolates file access to a given directory. The process running in this namespace can see the files that are allowed to see.

Process Id(PID):- It limits the other process that can be seen by the running process.

Network(net):- It limits the network interfaces for the running process.

Inter-Process-Communication(IPC):- It prevents processes to establish a range of shared memory between multiple processes.

UNIX Timesharing System(UTS):- It isolates the hostname and domain. It allows a single system to appear to have different hostname and domain to different processes.

User Id(UID):- It separates the user id from other user ids. Be root in the container but not on the host.

The process which isolates any process running inside it is called Container. Docker is a solution that manages all containers. And finally, Mr. Baya found a solution to his problem.

How it works?

Docker works in a similar way that defines a namespace for each process and runs that process under its namespace. If any process got crashed, it dead inside the container which won't affect other containers and the outside world.

How to make it work?

To run a program inside a container, you need to install the Docker binary from its repository. And that's it. Now you can run any process/program using docker by this command:-

docker run <program name>

If the program name is not available locally, it searches the program in the docker repository and pulls the image to local, then runs the program.

Watch this video to install docker binary and manage containers

Images:- Docker creates a file type of the running program is called images. There are lots of images available in the Docker repository. It can be easily transferable to anyone. This is one of the reasons to make the Docker popular.

Docker file:- It is used to build a docker image (like Makefile). Suppose you have your own written program (helloworld.py) that you want to run inside a docker container, then you need to make this program file into a docker image which will be possible using docker file.

WHAT IS ARDUINO AND HOW TO USE IT? CLEARLY EXPLAINED!!!

2020-07-05T06:21:00.001-07:00

Arduino is a piece of electronics board used to create a digital interactive device that can interact with the physical world around like sense and control the outside environment by using an almost unlimited range of input and output devices. we can program the needed interactions required to create some functional device that is performing a specific task.

We can make our Arduino device a connected system. It can be connected to the internet using wireline like Ethernet, wireless like Wi-Fi, Bluetooth, or whatever. Now if you think about it for a second this is what the internet of things (IoT) is all about. Building smart devices that are acting as connected entities and are sharing real-time information with the internet cloud. By doing these we can turn the Arduino into endless electronics applications

Looking at the Arduino board, I can say, it is some printed circuit board (PCB). That is specifically designed to use a microcontroller chip as well as all kind of other connectors and components that allows us to attach inputs and outputs data.

Arduino is an open-source hardware platform. That means Anyone can download the design files and create the same product or a new one and this is why we will see that some companies are selling the Arduino official products and other companies are selling “compatible Arduino” products.

From a developer's point of view to program the Arduino microcontroller, they provide us a very nice integrated development environment (IDE) for free and we can download from the internet and the code itself is based on a C/C++ programming language.

1. Arduino Software:-

Arduino IDE (Download)

2. Arduino Hardware:-

Arduino Kit (Amazon)

Arduino Uno (Amazon)

Why this Arduino platform is so popular?

Probably because it is a really affordable low-cost product so people around the world can easily buy and start play and try building all kinds of applications around it.

Also Check:-

MAKE YOUR FIRST PROJECT WITH RASPBERRY PI !!!

LINUX FILE STRUCTURE

2020-06-21T07:46:00.003-07:00

This post is about the file structure or directory structure of the Linux operating system. The file structure is nothing but how an individual computer organizes its data and store it. Linux file structure is somehow different than the Windows and Macintosh operating systems.

When you install Windows OS, it directly gives you the C drive, D drive and you keep your data inside it. But you never know where the system files, configuration files, program files, device files, etc are store. Being open-source, Linux operating system keeps everything in a completely different way to show its file structure.

Linux operating system represents every device like hard drives, keyboard, display, etc., everything as a file or a folder. You just need to mount the device in an empty folder, so that you can access the device.

The “official” rules of a root filesystem are contained in the Filesystem Hierarchy Standard (FHS) that u can get from here.

we are going to discuss some important files rather than all the directories.

So let's understand the file system hierarchy of Linux:-

/:- This is the default and only mount point for all file and folder. Inside this, you can get all the system and user data.

/bin/:- It contains the basic binary files, which a user can use to run as Linux commands. Example:- bash, cat, chmod, cp, date, echo, grep, kill, ls, mkdir, mv, mount, more, ping, pwd, rm, sh, uname, umount, etc.

/boot/:- It contains the boot loader file i.e grub or grub2. Linux kernel and other files required for the boot process. It is similar to the system reserved partition for Windows OS.

/dev/:- It contains all the device files for the drive, keyboard, mouse, etc. Here you can find the file for your device. like:- vda, vdb, etc.

/etc/:- This is an important folder that contains configuration files for the system. Sometimes you want to change some configuration of your network or system, you can found the file here and can change the configuration parameter of the respective file. It contains files like:- fstab, hostname, hosts, init, init.d, networks, passwd, profile, resolve.conf, services, shell, timezone, etc.

/home/:- user’s personal files like- Documents, Downloads, Music, Video, etc.

/lib/:- It contains the basic library files used by the system. Like DLL (Dynamic Link Library) in windows.

/media/:-Its a default mount point for removable media devices (CD-ROM, USB keys, and so on). If you plug in a USB drive to your Linux system, it will automatically show on your desktop.

/mnt/:- temporary mount point that can be used by root or user having access to it.

/opt/:- It contains data of external applications provided by third parties. like Chrome, Skype, etc.

/root/:- It contains the administrator’s (root’s) personal files.

/proc/:- All files in this folder contains information about the active/running processes.

/sbin/:- It contains the system binaries that can only access by root.

/srv/:- All the service-related data are found here like- the services are started after boot and data used by servers hosted on this system.

/tmp/:- temporary files to store data (this directory is often cleaned at boot)

/usr/:- applications (this directory is further subdivided into bin, sbin, lib according to the same logic as in the root directory)

/var/:- variable data of any Services. like every service has its own data and configuration. For configuration, the default folder is /etc/ and similarly /var/ is for data.

This is the basic file structure and structure information about the Linux operating system that we should know before using it.

FIND WINDOWS 10 PRODUCT KEY USING COMMAND PROMPT

2020-06-14T04:37:00.000-07:00

Here am going to share a working method to find Windows 10 Product Key using Command Prompt.

This is a very simple and easy process, and you just need to follow some of the steps given below.

Step 1:-

First of all, Press Windows Key + S to open the Windows search. You need to search for CMD.

Step 2:-

You need to right-click on the ‘CMD’ and select ‘Run as administrator.’

Step 3:-

On the command prompt window, you need to type in the given command –

wmic path softwarelicensingservice get OA3xOriginalProductKey

Step 4:-

The 25- digit product key will appear on the screen.

You can copy the code from the Command prompt Window.

This is how you can find your Windows 10 Product Key via Command Prompt.

NETWORK HACKING (PART-1: PREREQUISITE)

2020-05-16T07:33:00.000-07:00

Now, before we start talking about network hacking, you need to have a basic understanding of how networks work. We all know that a network usually contains a number of clients connected to each other, and clients usually connect to a network in order to share data or share a resource. A really good example of a resource that we all have connected to networks in order to access is the internet.

So, we connect to Wi-Fi networks and even wired networks all the time just to access the internet. All networks work on the same principle. They have a device that is considered as a server. Now, in many cases, for example, in your home network, this server is your router. This is also referred to as an access point. Now, this router or server or access point is the only device that has access to the resource. So, none of these clients have direct access to the resource, even after connecting to the network. The only way they can access the resource is through the access point.

So, let's say, for example, you're host 3 and you connected to your home network over Wi-Fi or over ethernet, over a cable and then you opened your browser and you typed facebook.com. What happens is your computer will send the request to the access point asking for facebook.com. The access point has access to the resource, which is the internet in this example, so it's gonna go and look for facebook.com. It will receive facebook.com, and it'll forward that response to your computer, and as a result, you will see the website loading on your browser. So if you actually go to your router at home and look at it, you'll see at the back it's connected through a cable to the wall and this is how it's getting its internet access. Therefore, it is the only device in your network that has direct access to the resource and none of your computers, none of the computers connected to the network can access the resource or can access the internet without the router, without the access point.

So the only way for all of the connected clients to access the resource is to go through the router. Now, the data is transferred between clients and the access point as packets. So you can think of all of these arrows as a series of packets being transmitted between the client and the router as requests and responses. Now, in Wi-Fi networks, these packets are transmitted in the air. Therefore, if you have a wireless card and you're within range, you'll be able to capture all of these requests and responses. So, basically, you'll be able to see anything that any computer connected to the same network as you, thus on the internet, because they will have to send all of these data to the access point, and because they're sending this data in the air because you're in a WiFi network, you'll basically be able to capture these requests and responses. And you'll be able to see the URLs they visit, the usernames, the passwords they enter, the chat messages. Anything they do on the internet will be sent as packets and therefore you'll be able to capture it and analyze it.

To capture packet data, we need an external WiFi card connected to our attack machine. Because in internal network card does not support some features to capture the packet. So we need the following changes in our machine.

1. Change the MAC address of the wireless card.

MAC address stands for Media Access Control, it's a permanent, physical, and unique address assigned to network interfaces by the device manufacturer. So whether you have a wireless card, or a wired, or Ethernet card, each one of these network cards come with a specific address that is unique to this card. So there are no two devices in the world that would have the same MAC address. And this address will always be the same to this specific device, even if you unplug it from your computer, connect it to another computer, then this network device will always have the same address.

So being able to change your MAC address to another device's MAC address will allow you to impersonate this device and allow you to do things that you might not be able to do. So you'd be able to bypass filters or connect to networks that only specific devices with specific MAC addresses can connect to, and you will also be able to hide your identity.

How to do:-

1. Run the following command to see the list of network cards connected to your device.

ifconfig

2. Disable the wireless card to change it's MAC address. (wlan0 is the name of the wireless interface)

ifconfig wlan0 down

3. Change it's MAC with any number.

ifconfig wlan0 hw ether 00:11:22:33:44:55

4. Enable the interface.

ifconfig wlan0 up

5. Check the MAC address of that interface.

ifconfig

Remember the MAC address will revert back to its original address once you restart your machine because we only change the MAC address in memory not physically.

2. Change the mode of the wireless card.

As we discussed the wireless data transfer happens in the form of a packet. So each packet has a source MAC and a destination MAC and it flows from the source to the destination. If you're within range, then you'll be able to capture all of this communication because these packets are literally sent in the air. So we can just capture them even if they do not have our MAC address as the destination MAC.

To do this, we need to change the mode of operation of our wireless interface so that it operates in monitor mode.

How to do:-

1. Run below command to check the mode of the wireless adapter.

iwconfig

2. Disable the wireless card. (wlan0 is the name of the wireless adapter)

ifconfig wlan0 down

3. Run below command to kill any process that could interfere with using your interface in monitor mode.

airman-ng check kill

Now you'll notice when you're on this command, it'll actually kill the network manager. we will only need to be in monitor mode when we are running pre-connection attacks so attacks that do not require us to connect to any network. So we actually do not need an internet connection to run any of the attacks that require monitor mode.

4. Enable monitor mode.

iwconfig wlan0 mode monitor

5. Enable the wireless card.

iwconfig wlan0 up

6. Check interface mode.

iwconfig

Now, this is enough to get you going through some network attacks so that you can sniff data, analyze it, and start launching some cool pre-connection attacks. We'll discuss more networks attack.

LAB SETUP FOR ETHICAL HACKING

BEFORE GOING TO START ETHICAL HACKING!

LAB SETUP FOR ETHICAL HACKING

2020-02-29T05:26:00.000-08:00

HACKING LAB: -
A lab is a place where you can practice and experiment with things. It is essential for hackers also because let's say you discovered a new attack or you want to experiment with a new attack or you learned something new online and you want to test it, then the perfect place for you to test this and practice hacking.

Now, to create a lab, you just need a number of computers with different operating systems and you'll need a number of networks if you're testing network attacks and if you're testing website attacks, then you will need to install websites on these computers. Or you can do all of this inside your computer, inside one machine and install everything else as virtual machines and this is what we're going to do. This computer might be running Windows, OS X, or Linux. It doesn't really matter, it can run any operating system. You can keep all the programs that you like and install a virtualization software such as VirtualBox or VMware.

After setup, our system will look like:-

WHAT IS VIRTUALIZATION 😨..? [ CLEARLY EXPLAINED ]

These following steps you need to do for a hacking lab:-

Download and install virtual box
Download and setup Kali Linux for the attacker.
Download and setup Metasploit OS for the server-side attack
Download and setup Windows OS for the client-side attack.

STEP 1:-
You can download it from this page. It supports all operating systems. Just pick your operating system from here, download the relevant installer, and install it.

After installation, you'll see a program similar to this

You will not have any virtual machines here so it will be empty and I will show you how to install all of these machines. One more thing to do, as soon as you install VirtualBox is to download and install the Extension Pack. This will give you better compatibility and it'll allow you to use USB devices on the virtual machines so you'll be able to use a USB mouse, USB keyboard, and USB wireless adapters.

You just have to click on the download link. It has to be the same version which is the same version as the version of the VirtualBox that you downloaded. otherwise, it will not work.

So now you can go ahead and install virtual machines in VirtualBox.
But before that just set a NAT Network.

NAT Network:-

NAT network setting will basically create a virtual network where your host machine is going to be the router for this network and then all the virtual machines are going to be clients connected to this network. So they're going to get an Internet connection from your host machine. And at the same time, all of your virtual machines will be connected to the same virtual network. This is very handy because all virtual machines will be able to communicate with each other.

So this setting will first allow your virtual machines to have an Internet connection and it'll also allow them to communicate with each other through this virtual NAT network. Now this virtual network will rely on the connection of your host computer. So it will not need any extra interfaces. It will not need any extra adapters. And as far as the virtual machines are concerned they are connected to on either nat network but in reality, they are connected through the host machine.

Watch how to set NAT Network.

Step 2:-
We're going to use an operating system called Kali Linux. The only difference between Kali and the actual original Debian Linux distro is the fact that Kali has a lot of hacking and penetration testing tools pre-installed and pre-configured in it. Therefore once you install Kali you will have access to so many hacking tools without the need to install or configure any of them which will save you a lot of time and a lot of effort.

Click on the Download Link. Go to Kali Linux virtual box images.

If you have a 64-bit computer make sure you download the 64-bit version. If you have a 32-bit computer download the 32 version.

After download, you can see a file like this

All you have to do is literally double click the file as you can see this will automatically run the file in the virtual box and you'll get a window which you can use to modify the settings of this virtual machine. For now, you just keep everything the same. And click on import. Give it some time. And you can see this will be imported into your virtual box.

Before start, do modify some settings. So click on the virtual machine that you want to modify its settings which is Kali Linux. Then click on the settings icon.

Click on the system and first of all, modify the amount of RAM. You can get away with one gigabyte but it might be a little bit slow. So you can make it at two.

Click on the processors and as you can see by default it's only given to course. Again you can give it more or less. You can get away with one core. It will be too slow. Two is good enough. The more the better. Again it all depends on how much resources you have and can't afford to give to virtual machines.

Now go to the network settings and set this to use NAT Network.

After all these settings you can go ahead and try to start it.

Step 3:-
The machine that we're gonna use is called Metasploitable and it's a virtual machine that's built on Linux. And it contains a number of services that are typically used by servers. It also contains a number of web applications that act exactly like normal web applications and use the same technologies used by normal servers and normal web applications, so you are gonna install this machine by click here.

Follow the video and download the Metasploitable OS with the registration of your details.

After Download you got an image that is actually designed for VMware Player. So you are gonna import the hard disk file or the hard disk image so that you are gonna have an already installation without having to install it, the way you installed Kali Linux.

Both username and password of metasploitable os is:- msfadmin

Make sure that both Kali and Metasploitable OS having the same NAT Network setting else you can't ping from either.

Step 4:-
Similarly, you can download Windows OS from HERE and install it as a virtual machine. and make the Network to NAT Network.

If I was not able to explain it better, then watch this full lab setup video.

COMING SOON...
READ ALSO👇

BEFORE GOING TO START ETHICAL HACKING!

MOST USED FUNCTION IN C LIBRARY (STRING_H)

2020-02-07T21:19:00.000-08:00

What is Library in the programming world?
It is the same as our study library. But here we store functions instead of books. You can simply develop your own library by adding more than one function to it. All you just need to do is, write a method, and keep it inside your library. whenever you want to use that method in your program, you can include that library as a file header and just make a call to that method. definition of that method is inside of your library. So no need to write a bunch of code for the same method. As many times you can call the method and can get the return value without defining it in your program.

There are two types of libraries. Static library and Dynamic library. We can discuss it in a later post. This is for some important methods used in string.h library.

There are several library functions to manipulate strings and the prototypes for these functions are in header file string.h. In this Page we will discuss how to use some of the most commonly used string functions like strlen(), strcpy(), strcmp(), strcat(). and see how these functions are created.

strcat:-

Synopsis:

char *strcat(char *dest, const char *src);

Description:

The strcat() function appends the src string to the dest string, overwriting the terminating null byte ('\0') at the end of dest, and then adds a terminating null byte. The strings may not overlap, and the dest string must have enough space for the result. If dest is not large enough, program behavior is unpredictable; buffer overruns are a favorite avenue for attacking secure programs.

Implementation:

char* strcat(char* destination, const char* source){

char* ptr = destination ;
while(*destination++)
ptr++;
while(*ptr++ = *source++);
return destination;
}

strcmp:-

Synopsis:

int strcmp(const char *s1, const char *s2);

Description:

The strcmp() function compares the two strings s1 and s2. It returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be less than, to match, or be greater than s2.

Implementation:

int strcmp(const char *l, const char *r){

while ( *l++==*r++ && *l);
return *(unsigned char *)l - *(unsigned char *)r;
}

strcpy:-

Synopsis:

char *strcpy(char *dest, const char *src);

Description:

The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0'), to the buffer pointed to by dest. The strings may not overlap, and the destination string dest must be large enough to receive the copy. Beware of buffer overruns!

Implementation:

char* strcpy(char* destination, const char* source){

char *ptr = destination;
while (*destination++ = *source++);
return ptr;
}

strlen:-

Synopsis:

size_t strlen(const char *s);

Description:

The strlen() function calculates the length of the string s, excluding the terminating null byte ('\0').

Return value:

The strlen() function returns the number of bytes in the string.

Implementation:

int strlen(char *str){

int len=0;
while(*str++) len++;
return(len);
}

These are some most important library functions in string.h library. Comments for code explanation and stay tuned for more updates.

I2C PROTOCOL

2019-12-24T07:52:00.000-08:00

Inter-Integrated Circuit:-

The I2C protocol is a half-duplex synchronous two wired multi-master serial communication protocol invented by Philips Semiconductor in 1989.

We discuss each word in the above sentence.

Half Duplex:- It says that the data flow is either form Master to slave or from Slave to Master not in both directions simultaneously.

Synchronous:- It means the sender always gets the acknowledgment response from the receiver after successful data received.

Two wired:- To successful transfer data it required only two wires (SDA and SCL).

SDA:- To transfer data bit.

SCL:- To transfer clock bit (SCL gives the synchronous to I2C)

Multi-Master:- It means multiple devices can be connected on a single bus. You can see the above figure where two Microcontrollers are connected to a single bus. They can communicate with any slave.

Serial Communication:- It means the data transfer from the sender to the receiver is bit by bit up to one byte.

Before the master sending the actual data to the slave master needs to configure the BUS by sending the start bit, Address of slave and Read/Write bit, Then master gets an ACK bit from the slave, After that, the master starts sending the data and after successful sent it receives an ACK bit and then sends another packet of data. When it successfully sends all data master terminates the communication by sending the stop bit.

Start, Stop bits are the conditions of the flow of 1 and 0 in SDA and SLC line.

START occurs when the SCL is 1 and SDA goes 0 to 1.
END occurs when the SCL is 1 and SDA goes 1 to 0.
ACK occurs when the SDA is 1 and SCL goes 0 to 1.
(Ack bit always flows opposite towards the data bit.)

The diagram shows how the bus achieves 0 or 1.

There are two pull up resistors and two open collector BJT transistors are connected to two bus lines. Let's consider the transistors are switches when the transistor goes OFF the current flow from the Vdd makes the bus active. when the transistor goes ON transistor grounded the Vdd current and makes inactive to the BUS.

How Multi-master works on a single bus at the same time?

Arbitration:- By constantly monitoring the bus a master can determine the bus condition either it is ideal or busy. If busy it delays its transfer until the stop bit. If multiple masters start transferring the data at the same time, whoever sends zero first that wins. This is called Arbitration.

In the above figure, 3 Masters are try to send the slave address through the bus simultaneously. So All 3 masters send the first MSB. Although all having their MSB 1, so no one can lose its arbitration. When any master sends the 0 bit first then it wins the arbitration and able to send its slave address through the bus.

Clock Stretching:- Slave device may hold the clock line low after receiving a byte. Which indicates slave is not ready to receive data. So the master waits until the clock goes high.

Advantage:- Due to device addressing no chip select pin is required. Better error handling with ACK bit.

Disadvantage:- Slow-speed because of the frame overhead due to device address bit and ACK bit. Speed is up to 3.4MHz clock(high-speed mode).

PROTOCOLS IN ELECTRONICS

ADDRESSING MODES IN ARM 7

2019-12-23T03:46:00.000-08:00

The manner in which an operand is given in the instruction is called addressing mode. The operand is the value on which you want to operate.

We can add 25 with the register R0 and put the result inside R0, or we can move the value to a register and then add the two register. Or we put the value into any memory and give its address to add and so on and so forth,

For Example:-

ADD R0, #25H;

MOV R1, #25H;

ADD R0, R1;

MOV 45H, #25H;

ADD R0, 45H;

So how do I tell the processor that my operand is 25 that is called addressing mode. There is various addressing modes are possible.

1. Immediate Addressing Mode:-

When the data is given in the instruction. ADD R0, #25H, Here the data 25 is given in that instruction. so no extra time required to search for the data. hence it is called immediate addressing mode.

MOV R0, #25H; R0 gets data value 25H

ADD R0, R1, #25H; R0 gets Value of R1 + data value 25H

Note:- If there is '#' at the beginning of any number then is a data or else it is an address.

We know that every instruction is of 32bit so we can only put the 8bit value inside the instruction. because the total size of one instruction is 32bit. If we put a 32bit value inside the instruction then the value itself take all size of instruction there is no space for upcode and register. So in immediate addressing mode always the 8bit value us allowed.

2. Register Addressing:-

Now instead of giving data in the instruction, we give the data using the register.

MOV R0, R1; R0 gets R1 value

ADD R0, R1, R2; R0 gets the sum of R1 and R2

From now we give the data using the memory address.
As we know the only operations are performed by memory are load and store. Hence next 5 Addressing modes are only applicable for Load and Store operations.

Now the address is going to give the data. When data is in memory.

3. Direct Addressing modes:-

Here the address is going to give the data, When data is in memory. "Var" is the variable that may be assigned with some value. Then Assembler will substitute the address. Remember the address is 32 bit. So assembler will not put the 32bit address. It put the 12-bit Offset. Offset not gives the actual address, it gives the distance from the current location to the location of the variable. 12bit can give the value up to 4k location.

LDR R0, Var; R0 gets data from memory location “Var”

STR R0, Var; R2 will be stored at the memory location “Var”

Note: “Var” is a variable defined in memory

4. Indirect Addressing modes:-

If the variable address is out of the range 4k then put the address in a register and give the register in indirect addressing mode.

R1: - It gives the value.

[R1]: - It gives the address.

LDR R0, [R1]; R0 gets the value pointed by the address inside the register R1.

STR R0, [R1]; The address inside the register R1 is going to get the value of R0.

And another use of Indirect addressing mode is while we use in a loop and increment the Address for each loop, It is sure that each time it can access the next location.

The next 3 Addressing modes are just the extension of the indirect Addressing mode. And each mode has 3 versions.

5. Register Relative Addressing modes:-

Here address of the memory operand is given by a register plus a numeric displacement.

Eg: LDR R0, [R1, #05H] ;

R0 gets data from the memory location pointed by (R1 + 05H)

R1 remains unchanged.

Eg: LDR R0, [R1, #05H]! ;

First: R1 gets R1 + 05H

Then: R0 gets data from the new memory location pointed by R1.

This is called PRE-INDEX Addressing.

Eg: LDR R0, [R1], #05H ;

First: R0 gets data from memory location pointed by R1

Then: R1 gets R1 + 05H

This is called POST-INDEX Addressing.

6. Base Indexed Addressing modes:-

Here address of the memory operand is given by a sum of two registers, where one register

acts as the base, and the other acts as the index register.

Eg: LDR R0, [R1, R2];

R0 gets data from the memory location pointed by (R1 + R2)

R1 remains unchanged.

Eg: LDR R0, [R1, R2]! ;

First: R1 gets R1 + R2

Then: R0 ç data from the new memory location pointed by R1.

This is called PRE-INDEX Addressing.

Eg: LDR R0, [R1], R2; First: R0 get data from the memory location pointed by R1

Then: R1 gets R1 + R2

This is called POST-INDEX Addressing.

7. Base with scaled Index Addressing modes:-

Here address of the memory operand is given by a sum of two registers

The first register acts as a base register. The second register can be scaled by shifting left.

Eg: LDR R0, [R1, R2, LSL #2];

R0 gets data from the location pointed by (R1 + R2 left-shifted by 2)

R1 remains unchanged.

Eg: LDR R0, [R1, R2, LSL #2]!;

First: R1 gets R1 + R2 left-shifted by 2

Then: R0 gets data from the new memory location pointed by R1.

This is called PRE-INDEX Addressing.

Eg: LDR R0, [R1], R2, LSL #2;

First: R0 gets data from the memory location pointed by R1

Then: R1 gets R1 + R2 left-shifted by 2

This is called POST-INDEX Addressing.

Use of base with scaled index:- for example, we want data from location 0x1256. Then we assign a register r1 with 12 and register r2 with 56 then we use the addressing mode.

LDR R0, [R1, R2, LSL #8];

It first left shift the 12 by 8bits and the add the register r2 with r1. now, r1 is pointing to the address 0x1256. Hence r0 get the value from the address 0x1256 that pointed by r1.

REGISTERS IN ARM 7

2019-11-03T01:30:00.000-07:00

There are 7 modes of operations. In each mode, the programmer has access to 16 GPRS (R0 – R15) and a CPSR (Flag Reg). Additionally, a Saved PSR (SPSR) is also available in all modes except User/ System mode. All registers are of 32 bits. In all modes, the three registers have common functions.

R15: PC (Program Counter)

PC gives a 32-bit address of the instruction to be fetched. This address is put on the address bus and the instruction is fetched from the memory through the 32-bit data bus. PC is periodically incremented after every instruction is fetched. Since all instructions are of 32-bits and are stored at 32-bit aligned locations (multiples of 4), the lowest two bits of PC are insignificant (XX).

R14: LR (Link Register)

It stores the return address (value of PC) when we perform a BL instruction (Branch with the link, like a CALL instruction). While returning back to the main program the value of LR will be put back

into PC.

R13: SP (Stack Pointer)

Holds the address of the top of the stack.

CPSR (Current program status register):

It holds the current status of the program. When an exception/ interrupt occurs, the value of CPSR is saved into SPSR (Saved Program Status Register), before invoking the ISR. While returning back to the main program, the value of SPSR is put back into CPSR to restore the previous state of the original program.

CPSR (Current program status register) holds the current status of the program. When an exception/ interrupt occurs, the value of CPSR is saved into SPSR (Saved Program Status Register), before invoking the ISR. While returning back to the main program, the value of SPSR is put back into CPSR to restore the previous state of the original program.

Mode Bits:

ARM7 can operate in 7 different operating modes.

These bits indicate the current operating mode of the processor.

All modes except User mode, are called “Privileged Modes”.

T: Thumb State
If T = 1, then the processor is in Thumb state
If T = 0, then the processor is in normal ARM7 state.
Thumb state is a special state where the “Thumb” instruction set, having 6-bit instructions are used.
This is useful if the memory is implemented as a 16-bit memory.

F: Fast interrupt Mask
If F = 1, then Fast Interrupts are disabled (masked).
If F = 0, then Fast Interrupts are enabled (un-masked).
A fast interrupt occurs through the nFIQ pin.

I: Interrupt Request Mask
If I = 1, then normal Interrupts are disabled (masked).
If I = 0, then normal Interrupts are enabled (un-masked).
A normal interrupt occurs through the nIRQ pin.

Condition Flags:-
V: Overflow Flag
V = 1 means signed overflow occurred
V = 0 means signed overflow hasn’t occurred

C: Carry Flag
C = 1 means carry after MSB
C = 0 means no carry after MSB

Z: Zero Flag
Z = 1 means the result is zero.
Z = 0 means the result is non-zero.

N: Negative Flag
If N = 1, the result is negative
If N = 0, the result is positive.
(Note: This flag always indicates the correct sign in spite of an overflow, unlike Intel’s Sign flag.)

Bit No 27: Saturation Flag / Q flag
In “E” versions of ARM7 (DSP Extensions), this flag indicates if a “saturation” has occurred.
If Q = 1, then arithmetic saturation has occurred. (All 1s rolls over to All 0s)
If Q = 0, then no such saturation has occurred.
This is useful in some signal processing applications.

(Note: Not applicable in ARM7TDMI, hence not shown in the diagram)

Additionally, there are some Banked Registers that are available in specific operating modes.

FIQ mode:

R8 – R14 provides a fresh set of GPRS. This eliminates the need to store the original values of these registers elsewhere and hence makes the execution of the ISR faster.

All the other privileged modes get their own versions of SP and LR (R13 and R14).

This gives a total of 37 registers all 32-bits each.

Also, Read👇

INTRODUCTION TO ARM 7

CISC VS. RISC ARCHITECTURE

OPERATING MODES IN ARM 7

WORKFLOW OF ARM 7

INTERRUPTS IN ARM 7

ADDRESSING MODES IN ARM 7

PROTOCOLS IN ELECTRONICS

2019-10-06T09:36:00.000-07:00

Protocol Meaning:-

Generally, protocol means a set of rules and regulations that should be obeyed for communication.

For example:- Two people A and B want to communicate with each other. But A is from German and B is from France. For a better conversation, they must have to follow one rule i.e they need to communicate over a common language(e.g:- English) which is a common protocol between them. Similarly, in Software, there are different protocols for different communication. Like for network or internet communication there some protocols called TCP/IP, HTTP, FTP, SMTP, etc.

In Electronics, they have some set of rules and regulations (protocol) to communicate between two electronic devices and exchange data between them.

There are two types:-

1. Inter System protocols

2. Intra system Protocols

Inter System protocols:-

The communication between two different Electonic devices. Like communication between laptops and smartphones is called inter-system communication. And the protocol used for this kind of communication is called inter-board communication protocols. For example:-

UART Protocol

USART Protocol

USB Protocol

Intra System protocols:-

The communication between two electronic devices within a circuit board. Like communication between motherboard and harddisk inside your laptop, microcontroller and LED is called intra-system communication. And the protocol used for this kind of communication is called intra-board communication protocols. For example:-

I2C protocol

SPI protocol

CAN Protocol

The above table describes the difference between all three IntraSystem protocols.

See Next Topics:-

I2C PROTOCOL

PIPELINING CONCEPT IN ARM 7

2019-09-01T10:20:00.000-07:00

Pipelining means dividing the process of instruction into an independent section and overlap them to get better performance. And the 3 stage Pipelining defines fetch-decode-execute. First, fetch the instruction, then decode the instruction, third execute that instruction. this is the complete process.

How does ARM acquire the Pipelining concept..?

It divides the total work complete to 3 independent parts (fetch, decode, execute) and overlap them.

Fetch the first instruction in one cycle, then decode the fetching instruction and fetch the next instruction in one cycle. Now execute the decoded instruction and decode the fetching instruction in one cycle and also fetch the 3rd instruction in the same cycle. It is only possible when each of the three only needs one cycle for its operation. Then only we can fetch, decode, and execute 3 different instructions in one cycle. It gives better performance. On the above diagram, you can see the ARM process seven instructions where normal processor executes only 3.

The concept of the Pipeline only gives efficiency when all independent jobs (fetching, decoding, and executing) are done at the same time (1 cycle). Suppose there are 3 instructions, only the second instruction needs 2 cycles to decode. When the execution of first instruction will finish, the decode of second instruction is supposed to finish, but it requires one more cycle to fully decode for which that stage not able to execute the second instruction.

That's why ARM supports almost all instructions that require only one cycle to fetch, decode, and execute. And am going to prove that all these stages require only one cycle.

Fetching:- Instruction sets of ARM are 32 bit. And the most important is everything in ARM memory is in aligned form. Databus is also 32 bit. So Everything needs only 1 cycle to fetch.

Decoding:- ARM is a RISC processor. All instructions are reduced and simplified. Upcodes are simple. They are decoded using the hardwired control unit which is very fast. Hence the decode needs only one cycle.

Execution:- ARM supports memory-based operation only load and store. Load means getting data. The size of the data can be 32 bit(maximum). The data bus is 32 bit. So load requires one cycle. All arithmetic and logical operations happen on the register. Registers are 32-bit Operations are 32 bit and ALU is 32 bit. So every operation requires one cycle. Store means to store the data of register to memory through the data bus. All registers are 32 bit and the data bus is also 32 bit. so the store also requires one cycle. Hence all kinds of execution require only one cycle to execute.

Of course, there are one or two exceptions like multi-load and multi-store that require more than one cycle. But we can say 95% of ARM instructions are required one cycle for fetching, one cycle for decoding, and one cycle for executing. If anything takes more time then the 3 times multiplication performance will not happen.

The advantage of the Pipeline in ARM is fast execution. The disadvantage in ARM is Pipeline fails if there is a branch. for example, the second instruction is executing and the expectation is in the next stage the third instruction will be executed because side by side it is decoded. if the third instruction takes a jump to any other instruction then all are wasted. Again we need to fetch the new instruction and again we need to decode that instruction. So this is called the pipeline bubble. Whenever a branch takes place the pipeline can not give the performance that we expect. This is a drawback of the ARM pipeline. But there is an Algorithm called branch prediction algorithm it can avoid the that used in the Pentium processor.

LinuxBaya

Common Security Flaws in C and C++

1. Buffer Overflows

What is a Buffer Overflow?

Stack-Based Buffer Overflow: A Classic Attack

Why is this dangerous?

Heap-Based Buffer Overflow

How to Prevent Buffer Overflows:

2. Integer Overflows

What is an Integer Overflow?

Why is this a problem?

How to Prevent Integer Overflows:

3. Uncontrolled Format String Vulnerabilities

What is a Format String Vulnerability?

Safer Alternatives:

How to Avoid Format String Attacks:

4. Use-After-Free

What is it?

Why it matters:

How to prevent it:

5. Memory Leaks

What is it?

Why it matters:

Prevention:

6. Double Free

What is it?

Risks:

Fix:

7. Uninitialized Memory Access

What is it?

Why it matters:

Prevention:

8. Insecure Temporary Files

What is it?

Risk:

Fix:

9. Race Conditions

What is it?

Risk:

Example:

10. Command Injection via system() or popen()

What is it?

Risk:

Fix:

11. Poor Error Handling

What is it?

Why it matters:

12. Type Confusion / Casting Errors

What is it?

Risk:

13. Dangling Pointers

What is it?

Why it’s dangerous:

How to prevent it:

14. Improper Bounds Checking

What is it?

Why it matters:

How to prevent it:

15. Insecure Deserialization (C++)

What is it?

Risk:

Prevention:

16. Volatile Keyword Misuse

What is it?

Why it's problematic:

Proper alternative:

17. Signal Handler Vulnerabilities

What is it?

Why it’s dangerous:

Safe signal handling:

18. Type Conversion Issues (Signed/Unsigned Mismatch)

What is it?

Risk:

Prevention:

19. Time-of-Check to Time-of-Use (TOCTOU)

What is it?

Prevention:

20. Improper Use of Macros

What is it?

Fix:

10. Command Injection via `system()` or `popen()`

9. Use `const` and `constexpr` Where Applicable