DEV Community: YANG F

SpeakForward-Where young leaders turn words into action, funded by trust

YANG F — Sun, 06 Sep 2026 18:13:08 +0000

What I Built

SpeakForward is fair-speech infrastructure: it lets young leaders (18–25) whose health conditions — vocal cord injury, severe anxiety, ALS, stroke recovery, chronic fatigue syndrome — prevent them from speaking or recording naturally, share their vision through an AI-generated voice, and receive support through transparent, peer-to-peer donations on Solana.

The platform asks one uncomfortable question: what if asking for medical proof is the real barrier? SpeakForward's answer is radical trust. There is no KYC, no verification, no admin review. A creator declares their situation in a short public statement — displayed right on their project page — and the judgment of trust belongs entirely to the community. The disclaimer is permanent and site-wide: "This platform does not verify identities. Please judge for yourself."

The same honesty applies to the voice itself: every audio clip is visibly labeled as AI-generated, and the disclosure flag is embedded in every ElevenLabs request. An AI voice speaking for someone who can't is assistance; an AI voice pretending to be someone is deception. The line between the two is the whole product.

And with money, the platform keeps itself out of the loop entirely: SOL moves from the donor's wallet directly to the creator's wallet, signed by the donor's own Phantom. The platform never holds, routes, or custodies anything.

In the demo, you'll meet 小林 (Xiao Lin), a 19-year-old climate advocate who can no longer sustain a full spoken sentence — and who is, thanks to a voice that isn't hers but carries her words, still speaking.

Demo

🔴 Live demo: https://speakforward.vercel.app

🎬 Video demo:

Code

aaaadoga / SpeakForward

🎙️ SpeakForward

Where young leaders turn words into action, funded by trust.

Fair-speech infrastructure for young leaders whose voices need a helping hand.

🌤️ The Problem

Every community has young leaders with a vision — and some of them cannot physically deliver a speech. Vocal cord injuries, severe anxiety, ALS, stroke recovery, chronic fatigue syndrome.

Most platforms respond by asking for medical proof. But proof is a privilege: the people who most need to be heard are often exactly the people who cannot navigate that paperwork.

SpeakForward takes a different deal. You declare your situation in a short, public statement. An AI voice — chosen from three designed personas — speaks your words. Supporters judge your sincerity for themselves, and support you directly, wallet to wallet, on Solana.

⚠️ This platform does not verify identities. Please judge for yourself.

✨ What's Inside

🗣️ AI voices, honestly labeled	Three designed

…

View on GitHub

The full ethics design document — every trust/delegation decision and its rationale — lives in the repo: docs/ETHICS.md.

How I Built It

Stack: Next.js 16 (App Router, TypeScript) · Supabase (Postgres + RLS, magic-link auth, S3-compatible Storage) · ElevenLabs · @solana/web3.js + wallet-adapter · Tailwind CSS + shadcn/ui · Vercel.

ElevenLabs — the voice, with disclosure built in:

Three preset personas ("The Steady Advocate", "The Warm Storyteller", "The Powerful Mobilizer") — custom-designed voices, no cloning (§: consent-safe by design).
Generation happens server-side (the API key never reaches the browser), the resulting MP3 is stored in Supabase Storage, and the project page embeds a visible disclosure badge.
The ai_disclosure flag is sent with every request — labeling isn't a UI afterthought, it's baked into the audio pipeline.
§Resilience: if ElevenLabs fails or rate-limits, the project still publishes and the player automatically falls back to the browser's Web Speech API — with a visible "temporary voice engine" label. Disclosure survives the degradation path too.

Solana — trust without custody:

Content anchoring: when publishing, the creator signs a transaction combining SystemProgram.transfer with an SPL Memo instruction carrying a SHA-256 content hash, their wallet prefix, and a timestamp. Proof of existence, publicly verifiable — with zero custom programs deployed.
Donations: the donor's Phantom signs a transfer from their wallet straight to the creator's wallet, plus a Memo tagging the project. The server independently verifies the transaction on-chain before recording it to the public ledger. The platform has no keys, no hot wallet, no treasury — it cannot touch the money.
No wallet? A "pledge" button records intent in the donor's own localStorage, clearly labeled as simulated.
Everything runs on Devnet — no real money in this MVP, by design.

The interesting decisions:

No medical proof, no admin review. Verification infrastructure gates out the most marginalized users while manufacturing platform endorsement. Self-declaration + public statements + community judgment is a more honest trust model.
Health statements are public by default. That's not a privacy bug — it's what turns an anonymous ask into a human being. The creator chooses how to describe themselves; the platform never verifies or edits.
The platform is structurally incapable of touching funds. Trust me less: verify the chain.

Prize Categories

🥇 Best Use of ElevenLabs — The entire product is the ElevenLabs integration: three designed personas, server-side synthesis with the native AI-disclosure flag embedded in every request, MP3 archival to storage, and a Web Speech API fallback that preserves disclosure even in degraded mode.

🥇 Best Use of Solana — Memo-anchored content hashes via SystemProgram.transfer + SPL Memo (no custom programs), non-custodial Phantom-signed peer-to-peer donations with on-chain server-side verification, and a public donation ledger — all on Devnet at $0 infrastructure cost.

Built solo in one weekend. — YANG F

Approaches to code reviews

YANG F — Thu, 26 Mar 2026 09:46:19 +0000

1. What is a Code Audit?

A code audit, also known as a source code security review in the field of white-box testing, refers to the process of examining an application’s source code to identify bugs and security vulnerabilities.

1.1 Core Definition

Code auditing is a technical task that requires a diverse set of skills. It demands not only a solid foundation in programming languages (such as PHP and Java) but also a deep understanding of vulnerability mechanisms, as well as familiarity with operating system and middleware characteristics. Unlike black-box testing (functional testing), code auditing involves an open-source approach to identifying bugs at the code level, and software is only permitted to go live once all high-risk vulnerabilities have been eliminated.

1.2 Why Code Audits Are Necessary

Code audits are an indispensable component of enterprise security operations and the Software Development Lifecycle (SDL):

Core SDL Phase: Most security issues are resolved during the design, coding, and testing phases. Code audits fall under white-box testing within the testing phase and can effectively identify logical flaws and deep-seated code defects that black-box scanners cannot detect.
Support for Penetration Testing: For penetration testers, mastering code auditing means that, upon obtaining a source code backup package, they can identify database passwords and API keys within configuration files through auditing, or uncover high-risk vulnerabilities (such as secondary injection or unauthorized access via logic) that scanners cannot detect by analyzing code logic.
The Cornerstone of Secure Programming: Identifying and rectifying vulnerabilities through auditing encourages developers to write more secure code, thereby helping to establish an application security framework.

1.3 Competency Requirements for Auditing

To conduct effective code auditing, one cannot rely solely on automated tools; the following competencies are essential:

Programming Language Proficiency: The ability to comprehend code logic and, even when encountering unfamiliar functions, understand their functionality by consulting documentation.
Understanding of Vulnerability Mechanisms: A thorough understanding of the mechanisms underlying common vulnerabilities such as SQL injection, XSS, file operations, and command execution.
Awareness of Environmental Differences: An understanding of how variations in different systems (Windows/Linux), middleware (Apache/Nginx/IIS), and language versions (e.g., configuration differences between PHP 5.2 and 5.4) affect vulnerability exploitation.

2. Approach to Understanding the Target System

Before formally identifying vulnerabilities, auditors must first gain a comprehensive understanding of the target system’s architecture, business logic, and operating environment. Blindly searching for keywords is often inefficient; the correct approach is to first gain a "macro-level understanding" before proceeding to "micro-level exploration."

2.1 Environment Setup and Configuration Analysis

Vulnerability exploitation often relies on specific environmental configurations. Prior to the audit, a test environment identical to the target system (e.g., WAMP/LNMP) should be set up, with particular attention paid to the following core configurations (using PHP as an example):

PHP Core Configurations: Such as register_globals (global variable registration), allow_url_include (remote file inclusion), magic_quotes_gpc (magic quote filtering), and open_basedir (directory access restrictions). These settings directly determine whether many vulnerabilities exist or can be exploited.
Middleware Version: Different versions of web servers may have specific parsing vulnerabilities or configuration differences.

2.2 File Structure Analysis

By examining the program’s file directory structure, one can quickly identify the system’s functional modules and core files. Pay particular attention to the following types of files:

Entry File (Index): Such as index.php, which is typically the program’s entry point; reading it provides insight into the program’s architecture, execution flow, and the core files it includes.
Configuration Files (Config): File names often include the keyword config. These files contain database connection details and global variable settings. Note that if parameter values in configuration files are enclosed in double quotes, there may be a risk of code execution due to variable parsing.
Function Library Files (Functions/Common): File names often include functions or common. These files contain common functions, most of which are included in the header of other files; they are key to understanding the business logic.
Security Filter Files (Filter/Safe): File names often include filter, safe, or check. These files are responsible for filtering all input parameters (such as SQL injection filtering and XSS filtering) and are areas that require particular focus or verification during an audit.

2.3 Analyzing Business Logic

For complex systems, reading through the entire codebase is the best way to understand the business logic.

Trace the entry point files: Start from the entry point files and trace the files included via include or require to clarify the code execution flow.
Identify core modules: Pay attention to folders whose names contain api, admin, manage, or include; these typically contain core business logic.
Understand Data Flow: Observe how data enters from user input sources (GET/POST/COOKIE), which filtering functions it passes through, and how it is ultimately utilized (e.g., concatenated into SQL statements, output to a page, or written to a file).

3. Approaches to Code Auditing

Having understood the basic architecture of the target system, you can adopt the following three main auditing approaches to identify vulnerabilities. Each of these approaches has its own advantages and disadvantages; they are usually most effective when used in combination.

3.1 Tracing Parameters of Sensitive Functions (Reverse Tracing)

This is currently the most widely used and highly efficient method. Most vulnerabilities are caused by the improper use of high-risk functions.

Method: Search for keywords of sensitive functions within the code, then trace the variable passing process to determine whether variables are controllable and have not undergone strict filtering.

Common sensitive functions (PHP):

Vulnerability Type	Sensitive Functions
SQL Injection	`select`, `insert`, `update`, `delete`, `mysql_query`
Code/Command Execution	`eval`, `assert`, `system`, `exec`, `shell_exec`, `preg_replace` (with the `/e` modifier)
File Operations	`include`, `require`, `file_get_contents`, `unlink`, `move_uploaded_file`
XSS Output	`echo`, `print`, `printf`

Advantages: Targeted exploration, efficient, suitable for quickly identifying common vulnerabilities.
Disadvantages: Lack of in-depth understanding of the program’s overall architecture; logical vulnerabilities may be overlooked.

3.2 Reading the Full Source Code (Forward Tracing)

This approach is suitable for security operations within an organization or when auditing open-source frameworks.

Method: Read the code from start to finish following the file execution flow, or read through all the code for specific functional modules.
Applicable Scenarios: Identifying logical vulnerabilities (such as payment vulnerabilities, unauthorized access vulnerabilities, and race conditions), secondary vulnerabilities, and security issues at the framework level.
Advantages: Provides a better understanding of the program architecture and business logic, enabling the discovery of more and higher-quality logical vulnerabilities.
Disadvantages: Time-consuming; requires considerable patience and strong code-reading skills from the auditor.

Tip: There is no need to read every line meticulously; start by reviewing the directory structure, then examine the core configuration files and entry points, and finally delve into the code of specific functional modules.

3.3 Targeted Auditing Based on Functional Areas (Experience-Driven)

Based on auditing experience, identify which functional areas are typically prone to vulnerabilities and conduct a focused audit of the code in those specific areas.

Common high-risk functional areas:

File Upload: Check whether file extensions are restricted, whether files are renamed, and whether file headers are validated.
File Management: Check whether filename parameters are controllable and whether directory traversal (../) is possible.
Login Authentication: Check the cookie validation logic, session generation mechanism, and whether there are any arbitrary user login vulnerabilities.
Password Recovery: Check whether verification codes can be brute-forced, whether reset tokens are predictable, and whether they are bound to the user’s identity.
Payment Process: Check whether unit price, quantity, and total price are controlled by the client, and whether there are any race conditions.
Third-Party Interaction: Such as SSRF (Server-Side Request Forgery) and unauthorized access to API interfaces.

Methodology: First perform black-box testing of functional points; once anomalies are identified, conduct white-box code auditing; or directly locate and review the relevant functional code files.

3.4 Use of Supporting Tools

Although code auditing relies primarily on manual logic, tools can significantly improve efficiency.

Code Editors: Such as Notepad++, UltraEdit, and Zend Studio, used for code highlighting, searching, and debugging.
Audit Systems: Such as the Seay source code audit system, RIPS, and Fortify SCA, which can automatically scan for sensitive functions and potential vulnerabilities.
Debugging Tools: Such as Burp Suite (for packet capture and modification), browser extensions (HackBar, Firebug), regular expression debugging tools, and SQL execution monitoring tools, used to verify the existence of vulnerabilities.

Conclusion

Code auditing is both an art and a core discipline within information security. Whilst automated tools can resolve some issues, they are unable to comprehend complex business logic and code context. An excellent auditor must be able to endure repetitive, manual tasks whilst maintaining a passion for innovation, and must be able to flexibly apply the three approaches of "sensitive function tracing," "full-text reading," and "function-point targeting." Only by deeply understanding code logic and combining this with extensive knowledge of vulnerabilities can one uncover the most deeply hidden security risks within enterprise-level web architectures.

An In-Depth Look at CIP: The Impact of Virtual Cameras and AI Face Swapping on Identity Verification, and How to Address It

YANG F — Thu, 26 Mar 2026 07:28:53 +0000

Introduction

With the rapid development of the digital economy, scenarios such as remote account opening, online payment, and cryptocurrency trading are becoming increasingly common. Face-to-face identity verification is gradually being replaced by online KYC (Know Your Customer) processes. However, with the rapid evolution of generative AI and virtual camera technologies, traditional facial recognition-based identity verification systems are facing unprecedented challenges. This article delves into the core of KYC—CIP (Customer Identification Program)—analyzing current technological threats and countermeasures.

I. Overview and Core Components of KYC

KYC is a customer identification process that financial institutions and certain non-financial institutions must implement to prevent money laundering, terrorist financing, and fraud. It is not only a compliance requirement but also the first line of defense in risk control.

A complete KYC process typically includes three core components:

CIP (Customer Identification Program): The customer identification process. Its core objective is to confirm "who the customer is," verifying the authenticity of identity documents and the consistency of the holder.
CDD (Customer Due Diligence): Customer due diligence. Assessing the customer's risk level and understanding their business nature and funding sources.
EDD (Enhanced Due Diligence): Enhanced due diligence. A more in-depth background investigation for high-risk customers.

Among these, the CIP stage is the most online and currently the most directly impacted by AI technology.

II. Automated Recognition Process in the CIP Stage

In current mainstream automated CIP processes, users typically complete verification via mobile devices. The standard process is as follows:

Document Collection and OCR Recognition: Users upload ID cards, passports, etc. The system uses OCR technology to extract information such as name, document number, and validity period, and verifies the document's anti-counterfeiting features (such as holograms and micro-fonts).
Face Collection: Users take a selfie or record a short video in front of the camera.
Liveness Detection: The system determines whether the operator is a real person. Traditional methods include action commands (blinking, head shaking) and silent liveness detection (through analysis of texture, reflection, and depth information).
Face Comparison (1:1 Verification): This compares the captured face with an ID photo using feature values to confirm identity.

This process greatly enhances the user experience, but its security heavily relies on the assumption that "the data captured by the camera is real-time and a genuine human image."

III. Technological Shadows: The Evolution of Virtual Cameras and AI Face Swapping

However, the above assumptions are being gradually undermined by cybercrime techniques. Current threats primarily come from two directions:

Virtual Camera Technology: This uses software to simulate the system's camera driver, "injecting" pre-recorded or synthesized video streams into applications. For the app, the data source it receives is still the "camera," but it is actually playing high-definition video prepared by the attacker.
AI Generation and Face Swapping Technology (Deepfake & Face Swap): Based on Generative Adversarial Networks (GANs) and diffusion models, attackers can generate realistic dynamic face videos using a small number of photos. Advanced technologies even support real-time face swapping, where an attacker operates the camera, but the victim's face appears on the screen, capable of performing liveness commands such as blinking and opening their mouth.

The combination of these two technologies allows attackers to create a perfect "digital avatar" without physical contact with the victim.

IV. Authenticity Risks: When "Liveness" Is No Longer Reliable

Virtual cameras and AI technology pose multi-dimensional risks to the authenticity of the CIP stage:

Presentation Attack: Utilizing high-definition screen replay or 3D masks, combined with virtual camera injection, bypassing traditional texture liveness detection.
Injection Attack: Directly hijacking the video stream at the system's underlying level, rendering the front-end liveness detection algorithm completely ineffective, because the algorithm detects "perfectly synthesized video," not real changes in physical lighting.
Synthetic Identity: Using AI to generate non-existent facial ID photos, combined with false identity information, constructing completely fictitious "clean" accounts for subsequent money laundering or fraud.

These risks make it difficult to guarantee the core objective of the CIP process—"verifying that the operator is the document holder."

V. Industry Risk Event Warnings

In recent years, numerous real-world incidents involving biometric bypass have occurred globally. Data shows that this is not a theoretical threat, but a reality. The following typical cases reveal the enormous economic losses and industry impact caused by the misuse of this technology:

Large-scale Loan Fraud in Financial Institutions: Security vendor Group-IB's fraud protection team assisted an Indonesian financial institution in identifying over 1,100 deepfake fraud attempts. Attackers successfully bypassed the institution's digital KYC process using AI-generated photos for fraudulent loan applications. Further investigation identified 45 specific devices (41 Android devices and 4 iOS devices), indicating that the cybercrime industry has developed a device-based, mass attack capability.
Real-time Video Verification Failure: According to Hong Kong police, a multinational company's finance personnel were deceived by deepfake technology, with attackers impersonating the company's Chief Financial Officer (CFO) during video conference calls. Due to the highly realistic video and audio, the employee was ultimately defrauded of $25 million. This case demonstrates that even real-time interactive video verification is vulnerable to breaches by advanced AI technology.
Huge Losses in the Cryptocurrency Industry: Data shows that in 2024, the cryptocurrency industry suffered $4.6 billion in fraud-related losses, a 24% increase from the previous year. Deepfake technology and social engineering have become the fastest-growing attack tactics. These losses not only directly impact victims but also severely affect cryptocurrency platforms, subjecting them to both reputational damage and compliance scrutiny due to associated fraudulent activities.

These incidents demonstrate that single facial recognition methods are no longer a secure "lock." When attackers can create "perfect identities" in bulk at low cost, financial institutions and platforms face not only financial losses but also the erosion of the foundation of trust.

VI. Building a Defense System: Strategies and Recommendations

Faced with ever-evolving attack methods, financial institutions and platforms need to build a "defense-in-depth" system, shifting from solely relying on facial recognition to multimodal risk control.

Enhanced Liveness Detection Technology:
- Combines interactive liveness detection with silent liveness detection, increasing randomness of commands.
- Introduces infrared liveness detection or 3D structured light hardware support (if device-permitted), leveraging depth information to defend against 2D injection.
- Upgrades algorithms to detect AI-generated traces (e.g., frequency domain analysis, abnormal blink frequency, edge artifacts).
Device and Environment Fingerprinting:
- Detects if the device is jailbroken, if virtual camera software is installed, and if debug mode is present.
- Collects device sensor data (gyroscope, accelerometer) to determine if the phone is moving physically, not just within the video feed.
Multi-Factor Authentication (MFA):
- Does not rely solely on facial recognition. Combines cross-verification with phone number verification, bank card four-factor authentication, carrier data, and other multi-dimensional information.
- For high-risk operations, introduces manual review or video customer service connection.
Behavioral Biometrics and Backend Risk Control:
- Analyzes user behavior (click frequency, swipe trajectory) to identify automated scripts.
- Establishes a network of connections to identify clusters of abnormal accounts linked by the same device, IP address, or facial features.
Continuous Monitoring and Compliance Updates:
- Regularly updates anti-fraud models to keep up with the latest Deepfake detection technologies.
- Complies with local regulatory requirements and adjusts KYC strategies promptly to ensure a balance between compliance and security.

Conclusion

KYC is the cornerstone of digital trust, and CIP is the entry point to this cornerstone. The emergence of virtual cameras and AI face-swapping technology marks a new stage in the identity authentication field, a constant battle between security and fraud. No single technology is absolutely secure; only through technological upgrades, multi-dimensional verification, and continuous risk control operations can we enjoy the convenience of digitalization while upholding the bottom line of identity authenticity. For industry practitioners, maintaining vigilance against new technologies and building a resilient security architecture are key to meeting future challenges.