📖 VENOM Memory Tracker Usage Guide - Full Version

🎯 Overview

VENOM is an advanced memory issue detection system for C. It tracks allocations, detects leaks, and provides detailed reports on 48 different vulnerability types, plus 8 new security and analysis features (Stack Canary, ASLR, Profiler, etc.).

⚡ Quick Start

The fastest way to start - just 3 lines:

#define CENOM_ENABLE_INTERCEPTION  // ✨ Magic Trick
#include "venom/memory_tracker.h"

int main() {
    cenom_mem_tracker_init();
    cenom_advanced_detector_enable(true);
    
    // Normal C code - No changes!
    int *data = malloc(1000);
    free(data);
    
    cenom_mem_tracker_shutdown();
    return 0;
}

Compilation:

gcc -DCENOM_ENABLE_INTERCEPTION -I./include main.c src/memory_tracker.c src/advanced_detector.c -o program -lpthread

Every malloc and free automatically becomes protected! ✅

Alternative Option: Using Unified Header

To access advanced security features (like Profiler and Security Monitor), it is preferred to use the modern method:

#include <cenom/cenom_security.h>

int main() {
    CENOM_SECURITY_FULL_INIT(); // Initialize everything (Tracker + Detector + Monitor + Profiler)
    
    // ... your code ...
    
    CENOM_SECURITY_FULL_SHUTDOWN();
    return 0;
}

Compilation: make -f Makefile.security all

📊 Supported Types: 48 Vulnerability Types (and 8 Security Features)

Group 1: Basic Types (9)

Type	Description
`MEM_ALLOC`	Memory allocation operation
`MEM_FREE`	Memory deallocation
`MEM_REALLOC`	Memory reallocation
`MEM_LEAK`	Memory leak
`MEM_USE_AFTER_FREE`	Use after free
`MEM_OVERFLOW`	Buffer overflow
`MEM_DOUBLE_FREE`	Double free
`MEM_INVALID_FREE`	Invalid free
`MEM_UNINITIALIZED`	Uninitialized memory use

Group 2: Boundary Issues (5)

Type	Description
`MEM_BUFFER_UNDERFLOW`	Access before buffer start
`MEM_STACK_OVERFLOW`	Stack overflow
`MEM_HEAP_CORRUPTION`	Heap corruption
`MEM_GUARD_VIOLATION`	Guard pattern violation
`MEM_MEMORY_CORRUPTION`	General memory corruption

Group 3: Pointer Issues (4)

Type	Description
`MEM_NULL_POINTER_DEREF`	Null pointer dereference
`MEM_DANGLING_POINTER`	Dangling pointer (pointing to freed memory)
`MEM_INVALID_POINTER_VALUE`	Invalid pointer value
`MEM_POINTER_MISALIGNMENT`	Misaligned pointer

Group 4: Performance Issues (4)

Type	Description
`MEM_EXCESSIVE_ALLOCATION`	Excessive allocations
`MEM_LEAK_PROGRESSIVE`	Progressive leak from same location
`MEM_INEFFICIENT_REALLOC`	Inefficient reallocation
`MEM_MEMORY_WASTE`	Memory waste

Group 5: Initialization Issues (4)

Type	Description
`MEM_PARTIAL_INITIALIZATION`	Partial initialization only
`MEM_USE_BEFORE_INIT`	Use before initialization
`MEM_CLEANUP_NOT_CALLED`	Cleanup function not called
`MEM_DOUBLE_INITIALIZATION`	Double initialization

Group 6: Concurrency Issues (3)

Type	Description
`MEM_DEADLOCK`	Thread deadlock
`MEM_MEMORY_VISIBILITY`	Memory visibility issue without synchronization
`MEM_ATOMIC_OPERATION_FAIL`	Atomic operation failure

Group 7: Advanced C Issues (4)

Type	Description
`MEM_FORMAT_STRING_VULN`	Format string vulnerability
`MEM_SIGNED_UNSIGNED_MISMATCH`	Signed/unsigned mismatch
`MEM_CAST_PROBLEM`	Type casting problem
`MEM_STRUCT_PACKING_ISSUE`	Struct packing issue

🆕 Group 8: Critical Security

Type	Description	Severity
`MEM_TYPE_CONFUSION`	Type confusion (Dangerous Casting)	🔴 Critical
`MEM_INTEGER_UNDERFLOW`	Integer underflow	🔴 Critical
`MEM_OVERLAPPING_MEMCPY`	Overlapping memory copy (Undefined Behavior)	🔴 Critical

🆕 Group 9: Memory Safety

Type	Description
`MEM_TEMPORAL_SAFETY`	Temporal safety (Use timing)
`MEM_SPATIAL_SAFETY`	Spatial safety (Pointer bounds)
`MEM_ALLOC_DEALLOC_MISMATCH`	Mismatch (e.g., `delete` with `malloc`)
`MEM_VLA_OVERFLOW`	Variable Length Array overflow

🆕 Group 10: Advanced Performance

Type	Description
`MEM_POOL_CORRUPTION`	Memory Pool corruption
`MEM_REALLOC_ZERO`	`realloc(ptr, 0)` undefined behavior
`MEM_ALIASING_VIOLATION`	Strict Aliasing violation

🆕 Group 11: Advanced Detection

Type	Description
`MEM_RETURN_TO_LIBC`	Ret2Libc attack detection
`MEM_FLEXIBLE_ARRAY_MISUSE`	Incorrect Struct Hack usage
`MEM_UNALIGNED_ACCESS`	Unaligned memory access

🆕 Group 12: Security Hardening

Type	Description
`MEM_SENSITIVE_DATA_EXPOSURE`	Sensitive data remnants in memory
`MEM_SCRUBBING_MISSING`	Missing memory scrubbing before free

🛡️ Active Monitors - New!

These systems work in the background to protect the application from exploitation:

Feature	Function	Manual Call (Optional)
Stack Canary	Detect stack smashing/overflow	`CENOM_CHECK_CANARY()`
ASLR Protection	Detect address randomization bypass attempts	`CENOM_CHECK_ASLR(ptr)`
Heap Spray	Detect heap spraying patterns (Shellcode)	(Automatic with allocation)
CFI	Control Flow Integrity check before calls	`CENOM_CFI_CALL(func_ptr)`
TOCTOU 🆕	Time-of-Check to Time-of-Use detection	`CENOM_CHECK_PATH()` / `CENOM_USE_PATH()`
ABA Problem 🆕	ABA problem detection in atomic ops	`CENOM_CAS_CHECK()`
Stack Clash 🆕	Detect Stack-Heap collision	`CENOM_CHECK_STACK_CLASH(size)`
Use-After-Scope 🆕	Detect use of variables out of scope	`CENOM_SCOPE_VAR()` / `CENOM_SCOPE_END()`

📊 Advanced Profilers - New!

Feature	Description
Memory Profiler	Track consumption in ms and export to CSV/JSON
Allocation Heatmap	Heatmap (HTML) showing highest consumption/leak areas
Leak Trend Analysis	Linear regression analysis to predict OOM (Out Of Memory)
Memory Graph	Graph (Graphviz) showing object relationships and leak roots

🧵 Phase 2: Advanced Security Features (8 New Features!) 🆕

1. Data Race Detector

Uses Vector Clocks algorithm to track Happens-Before relationships between threads:

#include <cenom/security/race_detector.h>

cenom_race_detector_init();
CENOM_READ(ptr, sizeof(*ptr));   // Record read
CENOM_WRITE(ptr, sizeof(*ptr));  // Record write
CENOM_LOCK(mutex);               // Record lock
CENOM_UNLOCK(mutex);             // Record unlock
cenom_race_detector_shutdown();

2. HoneyPot Allocator

Places "traps" in memory to detect attacks with 100% accuracy:

#include <cenom/security/honeypot.h>

cenom_honeypot_init();
void *ptr = malloc(1024);
CENOM_GUARD(ptr, 1024);          // Add guard zones
CENOM_CHECK_HONEYPOTS();         // Check traps
cenom_honeypot_shutdown();

Type	Function
`HONEYPOT_OVERFLOW`	Detect Heap Overflow
`HONEYPOT_UNDERFLOW`	Detect Underflow
`HONEYPOT_UAF`	Detect Use-After-Free
`HONEYPOT_SPRAY`	Detect Heap Spray

3. Shadow Memory (Like ASan)

Tracks the state of every byte in memory:

#include <cenom/security/shadow_mem.h>

cenom_shadow_init();
CENOM_SHADOW_ALLOC(ptr, size);       // Record allocation
CENOM_SHADOW_CHECK_READ(ptr, size);  // Check read
CENOM_SHADOW_CHECK_WRITE(ptr, size); // Check write
CENOM_SHADOW_DEALLOC(ptr, size);     // Record deallocation
cenom_shadow_shutdown();

State	Meaning
`SHADOW_ADDRESSABLE`	Accessible
`SHADOW_HEAP_RIGHT`	Heap Overflow!
`SHADOW_HEAP_FREED`	Use-After-Free!
`SHADOW_UNINITIALIZED`	Uninitialized

4. Taint Tracking (Injection Detection)

Tracks data flow from external sources to sensitive operations:

#include <cenom/security/taint.h>

cenom_taint_init();
char *input = fgets(...);
CENOM_TAINT_STDIN(input, strlen(input));  // Mark as "tainted"

// Before system() - Detects Command Injection!
CENOM_CHECK_SYSTEM(input, strlen(input));

// Before SQL - Detects SQL Injection!
CENOM_CHECK_SQL(query, strlen(query));

cenom_taint_shutdown();

Source	Meaning
`TAINT_STDIN`	User input
`TAINT_NETWORK`	Network data
`TAINT_ARGV`	Command line arguments
`TAINT_FILE_READ`	File content

Sink	Vulnerability Type
`SINK_SYSTEM`	Command Injection
`SINK_SQL_QUERY`	SQL Injection
`SINK_FORMAT_STRING`	Format String Attack

🚀 Usage Method

Step 1: System Initialization

#include "venom/memory_tracker.h"

int main() {
    // Initialize Tracker
    cenom_mem_tracker_init();
    
    // Enable Advanced Detector (Optional)
    cenom_advanced_detector_enable(true);
    
    // ... Your code here ...
    
    // Shutdown System
    cenom_mem_tracker_shutdown();
    
    return 0;
}

Step 2: Using Monitored Allocation Functions

Traditional Method (Manual):

// Instead of malloc - use cenom_malloc
int *arr = cenom_malloc(100 * sizeof(int), __FILE__, __LINE__, __func__);

// Instead of calloc - use cenom_calloc
int *arr2 = cenom_calloc(100, sizeof(int), __FILE__, __LINE__, __func__);

// Instead of realloc - use cenom_realloc
int *arr3 = cenom_realloc(arr, 200 * sizeof(int), __FILE__, __LINE__, __func__);

// Instead of free - use cenom_free
cenom_free(arr, __FILE__, __LINE__, __func__);
cenom_free(arr2, __FILE__, __LINE__, __func__);
cenom_free(arr3, __FILE__, __LINE__, __func__);

🪄 Magic Method (Auto-Intercept) - Best Choice!

No need to change a single line of code! Just add one define:

#define CENOM_ENABLE_INTERCEPTION  // ✨ Just add this!
#include "venom/memory_tracker.h"

int main() {
    cenom_mem_tracker_init();
    cenom_advanced_detector_enable(true);
    
    // All malloc/free now automatically work with venom!
    int *arr = malloc(100 * sizeof(int));      // ✅ Becomes cenom_malloc
    int *arr2 = calloc(100, sizeof(int));      // ✅ Becomes cenom_calloc
    int *arr3 = realloc(arr, 200);             // ✅ Becomes cenom_realloc
    free(arr);                                 // ✅ Becomes cenom_free
    free(arr2);
    free(arr3);
    
    cenom_mem_tracker_shutdown();
    return 0;
}

How to Compile:

# Without Magic Trick
gcc -I./include your_program.c src/memory_tracker.c src/advanced_detector.c -o your_program -lpthread

# With Magic Trick (Recommended!)
gcc -DCENOM_ENABLE_INTERCEPTION -I./include your_program.c src/memory_tracker.c src/advanced_detector.c -o your_program -lpthread

Golden Benefit: ✨ No code modification needed - just add -DCENOM_ENABLE_INTERCEPTION in the compile line and everything works automatically!

Step 3: Advanced Detection

// Detect null pointer
void *ptr = NULL;
cenom_detect_null_pointer_dereference(ptr, __FILE__, __LINE__, __func__);

// Detect buffer underflow
int *buf = cenom_malloc(100, __FILE__, __LINE__, __func__);
cenom_detect_buffer_underflow(buf, 100, -5, __FILE__, __LINE__, __func__);

// Detect dangling pointer
cenom_free(ptr, __FILE__, __LINE__, __func__);
cenom_detect_dangling_pointer_access(ptr, __FILE__, __LINE__, __func__);

// Detect other issues
cenom_detect_stack_overflow(6000, __func__);
cenom_detect_excessive_allocation(150 * 1024 * 1024, __FILE__, __LINE__, __func__);

📈 Reading the Report

1. General Memory Statistics

╔════════════════════════════════════════════════════════════╗
║             VENOM MEMORY TRACKER STATISTICS                ║
╠════════════════════════════════════════════════════════════╣
║ Total Allocated:           52547524 bytes                  ║  ← Total allocated
║ Total Freed:                 16104 bytes                   ║  ← Total freed
║ Current Usage:            52531420 bytes                   ║  ← Current usage
║ Peak Usage:               52532420 bytes                   ║  ← Peak usage
║ ─────────────────────────────────────────────────────────────║
║ Allocations:                   160                         ║  ← Allocation count
║ Deallocations:                   7                         ║  ← Deallocation count
║ Reallocations:                  98                         ║  ← Reallocation count
║ Issues Detected:                 3                         ║  ← Detected issues count
╚════════════════════════════════════════════════════════════╝

How to read:

If Current Usage > 0, there is a memory leak.
Peak Usage tells you the maximum memory usage reached.
Issues Detected > 0 means problems were found.

2. Detected Vulnerabilities Report

════════════════════════════════════════════════════════════
            ALL DETECTED VULNERABILITIES & ISSUES
════════════════════════════════════════════════════════════

📊 VULNERABILITY SUMMARY BY TYPE:
─────────────────────────────────────────────────────────────
🔴 DOUBLE FREE                   : 2 unique locations, 2 total occurrences
🔴 USE AFTER FREE                : 1 unique locations, 1 total occurrences

🔍 DETAILED VULNERABILITY LIST:

🔴 ISSUE #1: DOUBLE FREE
   ├─ File:        examples/extended_test.c:45
   ├─ Function:    test_guard_violation()
   ├─ Severity:    CRITICAL
   ├─ Pointer:     0x5c154b3f7c38
   ├─ Size:        10 bytes
   ├─ Occurrences: 1 times
   └─ Details:     Double free detected

How to read:

🔴 = CRITICAL
🟠 = HIGH
🟡 = MEDIUM
🟢 = LOW

Important Info:

File: Where the issue happened
Line: Exact line number
Severity: Risk level
Occurrences: How many times it happened

3. Leak Report

═══════════════════════════════════════════════════════════
               MEMORY LEAK DETECTION REPORT
═══════════════════════════════════════════════════════════

🔴 LEAK LOCATION #1
   ├─ File:     examples/extended_test.c:23
   ├─ Function: stress_test_small_allocations()
   ├─ Count:    666 occurrences
   └─ Size:     10656 bytes total

───────────────────────────────────────────────────────────
Total Leaks: 3463 | Total Size: 1779360 bytes | Unique Locations: 6
═══════════════════════════════════════════════════════════

How to read:

Count: How many times leaked from this location
Size: Total bytes leaked
Unique Locations: Number of distinct places leaks originated

4. Risk Assessment

⚡ RISK ASSESSMENT:
════════════════════════════════════════════════════════════
🔴 CRITICAL (5 issues): Must fix immediately
🟠 HIGH (52 issues):     Fix as soon as possible
🟡 MEDIUM:               Fix in next update
🟢 LOW:                  Monitor and review
════════════════════════════════════════════════════════════

Priorities:

CRITICAL: Fix now (may cause crash)
HIGH: Very dangerous (may cause issues)
MEDIUM: Important (but not urgent)
LOW: Just monitor

5. Advanced Statistics

╔════════════════════════════════════════════════════════════╗
║         ADVANCED MEMORY ISSUE STATISTICS                  ║
╠════════════════════════════════════════════════════════════╣
║ Leaks:                                                   ║
║   ├─ Simple Leaks:             50                        ║
║   ├─ Partial Leaks:             0                        ║
║   ├─ Leak Chains:               0                        ║
║   └─ Cyclic Leaks:              0                        ║
║                                                          ║
║ Access Issues:                                           ║
║   ├─ Out of Bounds:             1                       ║
║   ├─ Off-by-One:                0                       ║
║   ├─ Wild Pointers:             1                       ║
║   └─ Uninitialized:             2                       ║
║                                                          ║
║ Allocation Issues:                                       ║
║   ├─ Zero Size:                 0                       ║
║   ├─ Huge Allocations:          0                       ║
║   ├─ Alignment Errors:          1                       ║
║   └─ Fragmentation:             0                       ║
║                                                          ║
║ Summary:                                                 ║
║   ├─ Total Issues:            114                        ║
║   ├─ Critical:                  6                        ║
║   └─ Health Score:            0.0/100                    ║
╚════════════════════════════════════════════════════════════╝

🪄 Magic Trick Explained (Macro Magic)

How it works?

// In your Header file (venom/memory_tracker.h)

#ifdef CENOM_ENABLE_INTERCEPTION
    #undef malloc       // Undefine original
    #undef free         // Undefine original
    
    // Redefine with path and line injection
    #define malloc(size) cenom_malloc(size, __FILE__, __LINE__, __func__)
    #define free(ptr) do { cenom_free(ptr, __FILE__, __LINE__, __func__); ptr = NULL; } while(0)
#endif

Practical Example:

File: main.c (You changed nothing!)

#include <stdlib.h>

int main() {
    int *data = malloc(1000);   // ← Same old code
    free(data);                 // ← Same old code
    return 0;
}

Compilation without Cenom:

gcc main.c -o program
# Normal malloc/free

Compilation with Cenom:

gcc -DCENOM_ENABLE_INTERCEPTION -I./include main.c src/memory_tracker.c src/advanced_detector.c -o program -lpthread
# malloc/free become cenom_malloc/cenom_free automatically!

Result:

Every malloc becomes cenom_malloc(size, __FILE__, __LINE__, __func__)
Every free becomes cenom_free(ptr, __FILE__, __LINE__, __func__); ptr = NULL
Without modifying original code!

Benefits:

Feature	Benefit
Zero Code Changes	No need to modify a single line of code
Compile-Time Activation	Active only when compiling with `-DCENOM_ENABLE_INTERCEPTION`
Easy Integration	Easily add to any legacy project
Optional	Can be disabled without code changes
Automatic Tracking	Automatically tracks FILE, LINE, and func

Use Cases:

Legacy Project: Use -DCENOM_ENABLE_INTERCEPTION without code modification
New Project: Use #define CENOM_ENABLE_INTERCEPTION at the start
Dynamic Library: Enable only when needed
Testing: Easily test code with and without VENOM

🔍 Full Practical Example

#define CENOM_ENABLE_INTERCEPTION  // ✨ Magic Trick
#include "venom/memory_tracker.h"

int main() {
    cenom_mem_tracker_init();
    cenom_advanced_detector_enable(true);

    // Test 1: Simple Leak
    int *arr1 = malloc(100 * sizeof(int));  // ← Same as normal malloc
    // Forgot free - leak will be detected

    // Test 2: Use-After-Free
    int *arr2 = malloc(50 * sizeof(int));
    free(arr2);                              // ← Same as normal free
    arr2[0] = 10;  // Use after free - Error!

    // Test 3: Buffer Overflow
    int *arr3 = malloc(10);
    arr3[100] = 999;  // Out of bounds - Error!
    free(arr3);

    // Test 4: Double Free
    int *arr4 = malloc(20);
    free(arr4);
    free(arr4);  // Free twice - Error!

    // Test 5: Null Pointer
    int *arr5 = NULL;
    cenom_detect_null_pointer_dereference(arr5, __FILE__, __LINE__, __func__);

    // Test 6: Advanced Issues Detection
    cenom_detect_excessive_allocation(200 * 1024 * 1024, __FILE__, __LINE__, __func__);
    cenom_detect_progressive_leak(__FILE__, __LINE__, 1024);
    cenom_detect_format_string_vulnerability("%x %x %s");

    cenom_mem_tracker_shutdown();
    // You will get a comprehensive report containing all detected issues
    return 0;
}

Compilation:

gcc -DCENOM_ENABLE_INTERCEPTION -I./include main.c src/memory_tracker.c src/advanced_detector.c -o program -lpthread
./program

Expected Result:

❌ 1 Leak from arr1 (100 bytes)
❌ 1 Use-After-Free from arr2
❌ 1 Buffer Overflow from arr3
❌ 1 Double Free from arr4
❌ 5+ Issues detected by advanced functions
✅ Comprehensive report in cenom_memory_report.txt

🛠️ Useful Commands

# Build all tests
make -f Makefile.tracker clean build/extended_test build/detector_test build/magic_demo

# Run extended test
./build/extended_test

# Run detector test
./build/detector_test

# Run magic demo
./build/magic_demo

# Build your project with VENOM (without Intercept)
gcc -I./include your_program.c src/memory_tracker.c src/advanced_detector.c -o your_program -lpthread

# Build your project with VENOM + Magic Trick
gcc -DCENOM_ENABLE_INTERCEPTION -I./include your_program.c src/memory_tracker.c src/advanced_detector.c -o your_program -lpthread

# Run with full report view
./build/extended_test 2>&1 | grep -A 500 "DETECTED VULNERABILITIES"

📊 Comparison of Three Methods

Criteria	Manual Method	Macros	Magic Trick
Code	`cenom_malloc(...)`	`CENOM_MALLOC(...)`	`malloc(...)`
Code Modification	Yes ✏️	Yes ✏️	No ✨
Integration Ease	Complex	Medium	Very Easy ✅
Performance	High	High	High
Security	Full	Full	Full
Legacy Projects	Not suitable	Not suitable	Ideal ✨
Enable/Disable	Manual	Manual	One Flag

Recommendation: Use the Magic Trick for both new and legacy projects! 🚀

🚀 Application to Legacy Projects

Scenario:

You have an old C project using normal malloc and free. You want to add VENOM without modifying the code.

Solution (Just 3 Steps):

Step 1: Add VENOM to Project

cp -r include/venom your_project/
cp src/memory_tracker.c src/advanced_detector.c your_project/src/

Step 2: Modify your Makefile

Before:

CFLAGS = -Wall -O2
program: main.c
	gcc $(CFLAGS) main.c -o program

After:

CFLAGS = -Wall -O2 -DCENOM_ENABLE_INTERCEPTION  # Add this only!
program: main.c
	gcc $(CFLAGS) -I./include main.c src/memory_tracker.c src/advanced_detector.c -o program -lpthread

Step 3: Add Initialization and Shutdown

#include "venom/memory_tracker.h"  // Add this line only!

int main() {
    cenom_mem_tracker_init();      // Start
    cenom_advanced_detector_enable(true);
    
    // All old code works without change
    // malloc/free/calloc/realloc work with VENOM automatically
    
    cenom_mem_tracker_shutdown();  // End
    return 0;
}

Result:

✅ Your project is now protected with 33 vulnerability types!
✅ No code changes!
✅ Detailed report on all issues!

File	Usage
`include/venom/memory_tracker.h`	Basic definitions
`include/venom/advanced_detector.h`	Advanced detection functions
`src/memory_tracker.c`	Tracking engine
`src/advanced_detector.c`	Advanced detection engine
`examples/extended_test.c`	Test 24 vulnerability types
`examples/detector_test.c`	Test 16 detection functions
`cenom_memory_report.txt`	Final report (Auto-generated)

📋 Important Files

File	Usage
`include/venom/memory_tracker.h`	Basic definitions + Magic Trick ✨
`include/venom/advanced_detector.h`	Advanced detection functions
`src/memory_tracker.c`	Tracking engine
`src/advanced_detector.c`	Advanced detection engine
`examples/extended_test.c`	Test 24 vulnerability types
`examples/detector_test.c`	Test 16 detection functions
`examples/magic_intercept_demo.c`	Magic Trick Example (Best!) 🪄
`cenom_memory_report.txt`	Final report (Auto-generated)

💡 Important Tips

Always use macros for paths:

cenom_malloc(size, __FILE__, __LINE__, __func__)  // ✅
cenom_malloc(size, "file.c", 100, "main")         // ❌

Check report carefully:
- Look for 🔴 CRITICAL first
- Then 🟠 HIGH
- Then the rest

Use Advanced Detection for subtle issues:

cenom_detect_dangling_pointer_access(ptr, __FILE__, __LINE__, __func__);
cenom_detect_format_string_vulnerability(format_str);

Monitor Peak Usage:
- If much higher than Current Usage, there might be temporary heavy usage

✅ Conclusion

Automatic tracking of all allocations and deallocations
Detects 48 vulnerability types
Detailed reports for each issue
Fix recommendations for each vulnerability
Easy to use - Use the Magic Trick with -DCENOM_ENABLE_INTERCEPTION

Start Now: Use gcc -DCENOM_ENABLE_INTERCEPTION and get powerful memory protection! 🚀

📁 New Folder Structure

The project is organized to separate different security features:

include/venom/
  ├── cenom_security.h       (Unified Entry Point)
  └── security/              
      ├── memory_tracker.h   (Core Tracker)
      ├── advanced_detector.h (Detect 48 vulns)
      ├── security_monitor.h (Canary, ASLR, CFI)
      └── memory_profiler.h  (Heatmap, Graphs)

Use Makefile.security to build the project with the new structure.

FilesExpand file tree

security_USAGE_GUIDE.md

Latest commit

History

security_USAGE_GUIDE.md

File metadata and controls

📖 VENOM Memory Tracker Usage Guide - Full Version

🎯 Overview

⚡ Quick Start

Alternative Option: Using Unified Header

📊 Supported Types: 48 Vulnerability Types (and 8 Security Features)

Group 1: Basic Types (9)

Group 2: Boundary Issues (5)

Group 3: Pointer Issues (4)

Group 4: Performance Issues (4)

Group 5: Initialization Issues (4)

Group 6: Concurrency Issues (3)

Group 7: Advanced C Issues (4)

🆕 Group 8: Critical Security

🆕 Group 9: Memory Safety

🆕 Group 10: Advanced Performance

🆕 Group 11: Advanced Detection

🆕 Group 12: Security Hardening

🛡️ Active Monitors - New!

📊 Advanced Profilers - New!

🧵 Phase 2: Advanced Security Features (8 New Features!) 🆕

1. Data Race Detector

2. HoneyPot Allocator

3. Shadow Memory (Like ASan)

4. Taint Tracking (Injection Detection)

🚀 Usage Method

Step 1: System Initialization

Step 2: Using Monitored Allocation Functions

Traditional Method (Manual):

🪄 Magic Method (Auto-Intercept) - Best Choice!

Step 3: Advanced Detection

📈 Reading the Report

1. General Memory Statistics

2. Detected Vulnerabilities Report

3. Leak Report

4. Risk Assessment

5. Advanced Statistics

🪄 Magic Trick Explained (Macro Magic)

How it works?

Practical Example:

Benefits:

Use Cases:

🔍 Full Practical Example

🛠️ Useful Commands

📊 Comparison of Three Methods

🚀 Application to Legacy Projects

Scenario:

Solution (Just 3 Steps):

Step 1: Add VENOM to Project

Step 2: Modify your Makefile

Step 3: Add Initialization and Shutdown

Result:

📋 Important Files

💡 Important Tips

✅ Conclusion

📁 New Folder Structure