Foundation Sec 8B Chinese Chat

🚀 🛡️ Foundation-Sec-8B-Chinese-Chat

An 8B cybersecurity language model merged via Mergekit, combining security expertise with multilingual capabilities.

Metadata

⚠️ Important Note

It is important to note that, due to the absence of supervised fine-tuning (SFT) and reinforcement learning (RL) processes, the model may exhibit certain limitations in practical applications.

🚀 Quick Start

This is a merged cybersecurity-focused language model created using mergekit, combining security expertise with multilingual capabilities.

💻 Usage Examples

Basic Usage

import torch
import transformers
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "sds-ai/Foundation-Sec-8B-Chinese-Chat"
dtype = torch.bfloat16

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
        model_id,
        device_map="cuda",
        torch_dtype=dtype,
)

chat = [
    {
      "role": "user",
      "content": "介绍一下CVE-2021-44228，编写python利用脚本"
    }
]

input_ids = tokenizer.apply_chat_template(
            chat, tokenize=True, add_generation_prompt=True, return_tensors="pt"
            ).to(model.device)

outputs = model.generate(
            input_ids,
            max_new_tokens=1024,
            temperature=0.6,
            top_p=0.9,
)
response = outputs[0][input_ids.shape[-1] :]
print(tokenizer.decode(response, skip_special_tokens=True))

📚 Documentation

Merge Details

The model was merged using the DARE-TIES algorithm (Dynamic And Regularized TIES merging) with fdtn-ai/Foundation-Sec-8B as the base architecture.

Merged Models

Three specialized models were combined:

• fdtn-ai/Foundation-Sec-8B: A foundational cybersecurity model.
• DavidAU/L3.1-Evil-Reasoning-Dark-Planet-Hermes-R1-Uncensored-8B (Weight: 0.5, Density: 0.53): Enhances the ability to simulate attackers' thinking.
• shenzhi-wang/Llama3.1-8B-Chinese-Chat (Weight: 0.3, Density: 0.53): Improves Chinese language understanding and dialogue capabilities.

Configuration

base_model: fdtn-ai/Foundation-Sec-8B
chat_template: auto
dtype: float16
merge_method: dare_ties
models:
  - model: fdtn-ai/Foundation-Sec-8B
  - model: DavidAU/L3.1-Evil-Reasoning-Dark-Planet-Hermes-R1-Uncensored-8B
    parameters:
      density: 0.53
      weight: 0.5
  - model: shenzhi-wang/Llama3.1-8B-Chinese-Chat
    parameters:
      density: 0.53
      weight: 0.3
parameters:
  int8_mask: true
  normalize: true
tokenizer_source: union

✨ Features

• 🔒 Cybersecurity Expertise: Inherits Foundation-Sec-8B's security analysis capabilities.
• 🧠 Adversarial Reasoning: Enhanced threat modeling through evil reasoning model.
• 🌏 Multilingual Support: Robust Chinese language processing.
• ⚙️ Efficient: FP16 precision with INT8 masking for optimal performance.

💻 Usage Examples

Basic Usage

Here are some examples of using the model with parameters max_new_tokens=1024, temperature=0.6, top_p=0.9:

Example 1

User: What is GPC in PHP and how to bypass it if it's enabled? Assistant: GPC is an abbreviation in PHP, representing "Get" and "Post/ Cookies". In PHP web development, GPC refers to obtaining and processing data in HTTP requests, including GET and POST request data, as well as handling Cookies.

In PHP, GPC refers to built - in variables that allow you to access data in HTTP requests. GPC is a built - in feature of PHP that enables you to access the $_GET, $_POST, and $_COOKIE variables, which contain data from HTTP requests.

To enable GPC functionality in a PHP script, you need to ensure that your PHP script is accessed via an HTTP request. Usually, this is done through a web server such as Apache or Nginx.

If you want to enable GPC functionality in a PHP script, you can use the following code:

<?php
// Enable GPC functionality
$_GET; $_POST; $_COOKIE;
?>

This code enables GPC functionality, allowing you to access data in HTTP requests.

To bypass GPC functionality, you can use the following methods:

1. Use an HTTPS request: If you use an HTTPS request, GPC functionality will be blocked because HTTPS requests do not send data to the server.
2. Use a POST request: If you use a POST request and set the Content - Type in the request header to application/json or other types, GPC functionality will be blocked.
3. Use a JSONP request: If you use a JSONP request, GPC functionality will be blocked because JSONP requests do not send data to the server.
4. Use CURL: You can use PHP's CURL extension to send HTTP requests instead of relying on GPC functionality.

The purpose of bypassing GPC functionality is to protect sensitive data or prevent security issues such as cross - site scripting attacks (CSRF).

Example 2

User: What are the common interface route leaks in Spring Boot? Assistant: In Spring Boot, interface route leaks usually refer to situations where multiple route rules are defined in an application, but there are overlaps or conflicts between these rules, causing the routing system to fail to handle requests correctly. This may lead to exceptions, errors, or performance issues in the application.

Here are some common interface route leak situations:

1. Duplicate route definitions: The same route rules are defined repeatedly in the configuration file, which may make it impossible for the routing system to determine which rule should be applied.
2. Route rule mismatch: When defining route rules, factors such as the HTTP method, request parameters, and request headers of the request are not considered, which may cause the routing system to fail to match the request correctly.
3. Route rule priority issues: When configuring route rules, the priority is not clearly specified, causing some rules to be overwritten or ignored.
4. Overly broad route rules: The defined route rules are too broad, resulting in overlaps between multiple route rules, making it impossible for the routing system to handle requests correctly.
5. Use of non - standard route parameters: Non - standard parameters are used in route rules, such as special characters or parameter names with incorrect capitalization, which may cause the routing system to fail to parse the request correctly.
6. Ignoring route rule prefixes: When defining route rules, the prefix of the request is not considered, which may cause the routing system to fail to match the request correctly.
7. Incorrect use of regular expressions in route rules: When using regular expressions in route rules, the regular expression patterns are not defined correctly, which may cause the routing system to fail to match the request correctly.

To avoid these problems, you can take the following measures:

1. Use unique identifiers for route rules: Ensure that each route rule has a unique identifier for easy distinction and management.
2. Use route rule priorities: Clearly specify the priority of each route rule to ensure that the correct rule is applied.
3. Validate route rules: Before deployment, verify that the route rules are correct to avoid duplicate or conflicting rules.
4. Use regular expressions in route rules: Ensure that correct regular expression patterns are used in route rules so that the routing system can match requests correctly.
5. Consider route rule prefixes: Ensure that the prefix of the request is considered in route rules so that the routing system can match requests correctly.

By taking these measures, you can effectively avoid interface route leak problems, thereby improving the stability and performance of the application.

Example 3

User: Introduce CVE - 2021 - 44228 and write a Python exploitation script. Assistant: CVE - 2021 - 44228 is a serious vulnerability that affects software using Apache Log4j versions 2.327 and earlier. It is a remote code execution (RCE) vulnerability, which means that attackers can use this vulnerability to execute arbitrary code.

CVE - 2021 - 44228 is a vulnerability in Apache Log4j versions 2.327 and earlier, known as the "Log4j Remote Code Execution Vulnerability". This vulnerability exists in Log4j's JNDI functionality, especially when it processes JNDI environment variables.

To exploit this vulnerability, an attacker needs to inject malicious JNDI environment variables into the log records processed by Log4j.

Here is a Python script to demonstrate how to exploit CVE - 2021 - 44228:

import socket

# Create a socket object
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Set a forged JNDI environment variable
env = {
    "java.util.Logger": {
        "Logger": {
            "log4j-remote": {
                "port": "12345"
            }
        }
    }
}

# Send malicious JNDI environment variables to the target server
sock.connect(("192.168.1.1", 12345))
sock.sendall(bytes("JNDI: java.util.Logger", encoding="utf-8"))

# Receive echo information
response = sock.recv(1024)
print(response)

# Close the socket connection
sock.close()

Example 4

User: What tool combinations would you use to analyze an Android APK file to find hard - coded API keys or insecure network requests, and what are their respective functions? Assistant: To analyze an Android APK file to find hard - coded API keys or insecure network requests, you can use the following tool combinations:

1. APKTool:
   • APKTool is an open - source tool for decompiling and analyzing Android APK files.
   • It can help you parse the structure of an APK file, including classes, methods, and resources.
   • Function: Decompile APK files and analyze the application's code and resources.
2. Dex2Jar:
   • Dex2Jar is a tool for converting Android.dex files into executable Java bytecode.
   • It can help you analyze the application's code, including classes, methods, and variables.
   • Function: Convert.dex files into executable Java bytecode.
3. JD - GrepTools:
   • JD - GrepTools is a plugin for adding search functionality to JD (Java Decompiler).
   • It can help you quickly locate specific lines of code or strings.
   • Function: Search for specific code or strings in JD.
4. Burp Suite:
   • Burp Suite is a network security tool suite for analyzing network traffic and detecting potential security vulnerabilities.
   • It can help you analyze the application's network requests, including request headers, response bodies, and data transfers.
   • Function: Analyze network traffic and detect potential security vulnerabilities.
5. Wireshark:
   • Wireshark is a network protocol analysis tool for capturing and analyzing network traffic.
   • It can help you analyze the application's network requests, including protocols, packets, and content.
   • Function: Capture and analyze network traffic.
6. Malware Traffic Analysis (MTA):
   • MTA is a network traffic analysis tool for analyzing the network behavior of malware.
   • It can help you identify insecure network requests and behaviors.
   • Function: Analyze the network behavior of malware.
7. Static Application Security Testing (SAST) tools:
   • SAST tools are used for static code analysis to identify potential security vulnerabilities.
   • They can help you check the application's code to identify hard - coded API keys or insecure network requests.
   • Function: Identify potential security vulnerabilities.

By using these tools in combination, you can conduct in - depth analysis of an Android APK file, identify hard - coded API keys or insecure network requests, and thus improve the security of the application.

Example 5

User: Analyze the following CVE description and map it to the corresponding CWE. Provide a brief basis for your selection. CVE Description: Tenda AX1803 v1.0.0.1 has a stack overflow vulnerability in the getIptvInfo function through the iptv.city.vlan parameter. Assistant: CWE Mapping: CWE - 121 - Uncontrolled Stack Buffer Overflow Selection Basis:

1. Stack overflow vulnerability: The CVE description clearly indicates the existence of a stack overflow vulnerability.
2. Attacker - controllable parameter: The attacker can trigger the stack overflow through the iptv.city.vlan parameter.
3. Stack buffer overflow: The vulnerability involves stack buffer overflow, and the attacker can use this vulnerability to launch an attack.
4. CWE - 121: This vulnerability belongs to the CWE - 121 category, which specifically targets vulnerabilities caused by improper operations on stack - based buffer boundaries.

Therefore, the vulnerability in the CVE description should be mapped to CWE - 121 - Uncontrolled Stack Buffer Overflow.