11.7 Source Code Review & Encoded/Cryptographic Value Analysis

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

11.7 Source Code Review & Encoded/Cryptographic Value Analysis

Key Takeaways Explain This Topic AI

Source code review traces untrusted input from its entry point (source) to a dangerous operation (sink), and is the most reliable way to find injection and logic flaws.

Grep-driven review targets dangerous sinks: query concatenation, eval, system, deserialization, and hardcoded secrets.

Base64 is encoding, not encryption: it is reversible with no key, so identifying and decoding it is trivial and it protects nothing.

A 32-hex-character value is very likely an MD5 hash; length and character set identify the algorithm, and unsalted hashes fall to rainbow tables.

Distinguishing encoding from encryption from hashing tells the assessor whether a captured value can be decoded, decrypted or only cracked.

Last updated: September 2026

11.7 Source Code Review & Encoded/Cryptographic Value Analysis

Two final web-testing skills round out the syllabus. H13 (Source Code Review) requires common techniques for identifying and reviewing deficiencies in the areas of security. H12 (Encryption) requires identifying and exploiting encoded values (e.g. Base64) and cryptographic values (e.g. MD5 hashes) , and identifying common SSL vulnerabilities . They belong together because both are about reading what an application reveals of its own internals — one from the code, one from the data it hands the client.

1. Source Code Review (H13)

Source code review (SAST when automated) is white-box testing: with the source in hand, you can find flaws that black-box testing would never reach, and you can confirm suspected flaws definitively. It complements dynamic testing rather than replacing it.

The Source-to-Sink Method

The core technique is data-flow (taint) analysis : trace untrusted data from where it enters the application to where it is used dangerously. SOURCE (untrusted input) SINK (dangerous operation)

------------------------- ---------------------------
request.getParameter() Statement.execute(sql) -> SQLi
$_GET / $_POST / $_REQUEST eval(), system(), exec() -> code/cmd injection
request body / headers / cookies ...> Runtime.exec() -> command injection
file upload / filename new File(path), include() -> traversal / LFI
deserialized object readObject() -> deserialization RCE
database / external API (2nd order) innerHTML / response write -> XSS

If tainted data reaches a sink without adequate validation, encoding or parameterisation in between , that is a vulnerability. A "second-order" flaw is one where the input is stored first and reaches a sink later — invisible to naive black-box testing but obvious in the code.

Grep-Driven Review

Even without a full SAST tool, a targeted search for dangerous sinks and secrets is highly productive: # Injection sinks

grep -RInE "execute\(|executeQuery\(|Statement|createQuery|\.raw\(" .

grep -RInE "readObject|ObjectInputStream|pickle\.loads|unserialize|BinaryFormatter" .

# XSS sinks

grep -RInE "innerHTML|document\.write|dangerouslySetInnerHTML|\|safe" .

# Secrets and crypto misuse

grep -RInE "MD5|SHA1|DES|ECB|Math\.random|new Random\(" .

What to Look For Beyond Injection

Authentication and session logic — how credentials are checked, how tokens are generated (predictable? properly random?), how sessions expire.

Access-control checks — are they present on every sensitive operation, or only on the UI path (the recurring API-authorisation failure)?

Cryptographic choices — MD5/SHA-1 for passwords, hardcoded keys, ECB mode, Math.random() for tokens, disabled certificate validation.

Hardcoded secrets — credentials, keys and connection strings committed to source (and to version-control history).

Configuration — debug flags, default credentials, permissive CORS, verbose errors.

Automated SAST tools (Semgrep, SonarQube, CodeQL, Fortify) scale this up, but they generate false positives; the reviewer's judgement in confirming that a source genuinely reaches a sink without mitigation is what turns a tool finding into a real one.

2. Encoded Values: Base64 and Friends (H12)

During testing you constantly encounter opaque-looking strings in cookies, tokens, hidden fields and parameters. The first task is to recognise encoding , which is trivially reversible.

Encoding is a reversible representation change with no key. It exists for transport safety and interoperability, not secrecy. Common encodings and their tells:

Encoding Recognisable by Reverse
Base64 A-Z a-z 0-9 + / , length a multiple of 4, = / == padding base64 -d ; URL-safe variant uses - and _
Hex only 0-9 a-f , even length xxd -r -p
URL / percent %2F , %20 URL-decode
HTML entities < ' HTML-decode

The security point is stated plainly in the syllabus example: Base64 is not encryption. A session cookie, "encrypted" price field, or "secret" token that is merely Base64 offers no protection — decode it, read it, modify it, re-encode it. A very common finding is a role or user ID Base64-encoded in a cookie ( eyJyb2xlIjoidXNlciJ9 decodes to {"role":"user"} ), which the attacker simply changes to admin . Layered encodings (Base64 of hex of JSON) are still just encodings; peel each layer.

3. Cryptographic Values: Hashes and Encryption (H12)

When a value is not plain encoding, decide whether it is a hash or ciphertext , because that determines what you can do with it.

Identifying Hashes

Hashes are one-way : you cannot reverse them, only guess the input and compare. Identify by length and character set:

Length (hex) Bits Likely algorithm
32 128 MD5 (or NTLM, which is MD4 of UTF-16LE)
40 160 SHA-1
64 256 SHA-256
128 512 SHA-512

A 32-character hex string is the syllabus's own example: very likely MD5 . Tools like hashid / hash-identifier automate the guess, and the modular-crypt prefixes ( $1$ , $5$ , $6$ , $2y$ ) identify salted Unix hashes (see 9.6).

Exploiting hashes:

Unsalted hashes fall instantly to rainbow tables and to online lookup databases — a huge fraction of leaked MD5/SHA-1 hashes are simply searchable.

Salted hashes require per-hash cracking with hashcat / john , but weak passwords still fall.

Fast algorithms (MD5, SHA-1, SHA-256) are wrong for passwords precisely because they crack quickly; finding them used for password storage is itself a finding, and the fix is bcrypt/scrypt/Argon2.

Hash length extension attacks apply to H(secret || data) MAC constructions built on Merkle–Damgård hashes (MD5, SHA-1, SHA-256), which is why HMAC (3.2) exists.

Recognising Encryption

Ciphertext is reversible with the key . Tells: high entropy, no readable structure, often Base64-wrapped, and a length that is a multiple of the block size (8 bytes for DES/3DES, 16 for AES) for block ciphers. Client-side testing rarely recovers the key, but you can still find:

ECB mode , betrayed by identical plaintext blocks producing identical ciphertext blocks (the "ECB penguin"), which leaks structure and allows block cut-and-paste;

static IVs and encoded-not-encrypted values that only looked encrypted;

keys recovered by decompiling a thick client (10.6).

Common SSL/TLS Vulnerabilities (H12)

The syllabus explicitly folds SSL vulnerability identification into this item; section 3.3 covers these in depth, so here they are the checklist an assessor applies to any HTTPS endpoint:

Protocol: SSLv2/SSLv3 and TLS 1.0/1.1 enabled (POODLE, and deprecated).

Ciphers: RC4 (Bar Mitzvah), export-grade (FREAK/Logjam), 64-bit block ciphers in CBC (Sweet32 on 3DES).

Implementation: Heartbleed (CVE-2014-0160), BEAST, CRIME/BREACH (compression).

Certificate: expired, self-signed, weak signature (MD5/SHA-1), wrong hostname, weak key.

Config: no HSTS, no forward secrecy, insecure renegotiation.

testssl.sh , sslscan and sslyze automate the whole checklist and are the standard tools.

4. Bringing It Together Captured opaque value
|
Decodable with no key? --yes--> ENCODING (Base64/hex/URL): decode, tamper, re-encode
| no
Fixed length, hex, one-way? --yes--> HASH: identify by length; rainbow/crack; flag if used for passwords
| no
High entropy, block-multiple length? --> CIPHERTEXT: identify mode (ECB?), seek key (client decompile)

The discipline this section teaches is diagnostic: correctly classifying a value as encoded, hashed or encrypted tells you immediately whether it can be decoded (trivial), cracked (feasible for weak hashes/passwords), or decrypted (needs the key) — and that classification, together with a source-code review that shows how the value was produced, is what turns a mysterious blob into a finding.