Losowe Tematy: Code Review, AI, Q&A

Overview

This live stream is a mix of:

• (1) channel/community Q&A
• (2) announcements about security/low-level training and publications
• (3) a live code review of a small C/C++ game-like console program
• (4) discussion around AI tools (Gemini) and PRNG/security practices

---

Key announcements / guides / tutorials

Book preorder: Introduction to IT Security (Volume 2)

• Preorder: “Introduction to IT Security” (volume 2)
• Speaker’s notes:
  • Volume 2 complements volume 1 well.
  • You can start with volume 2 without needing volume 1.
  • Mentions availability/order flexibility.
  • Notes there’s no English version (the book is Polish).
  • Mentions possible conference pickup (MSHP). Last year included an author-signing stand; expects similar autograph opportunities.

Blog + newsletter system (web dev)

• A blog was launched.
• Users can subscribe via RSS/Atom feeds or a newsletter.
• Speaker explains RSS/Atom as XML-based syndication, used by RSS readers (e.g., Inoreader / Good Old Reader–type tools).
• Notes that feeds can be aggregated into a single reader.
• Mentions:
  • RSS is “older/archaic” but still useful.
  • Google Reader’s closure reduced RSS usage.

Free training event (security / low-level)

• Free 2-hour mini-lecture titled: “A Hacker’s Eye”
• Co-presenter: SEK Kurak
• Scheduled for: Aug 21
• Focus includes:
  • what files are
  • “strange facts/tries/hacks”
  • security-relevant mistakes/exploitable errors
  • covering perspectives from user/admin/programmer, with emphasis on the hacker perspective

Other planned training

• Upcoming courses:
  • Assembly + reverse engineering
  • Python for security themed training (around September)
  • Longer courses between Nov–Dec
• Monthly training on Hex editors / file analysis
  • Planned extension path into network packet analysis
  • Packet analysis differs mainly in temporal/streaming aspects

---

Code review: C console game (main technical segment)

The speaker reviews code for a console guessing/number game (with colored output), covering structure, style, correctness, and security/robustness issues.

Project/build and structure

• Commends the presence of a Makefile.
• Notes cross-platform structure:
  • make targets/commands adapt for Linux vs Windows
• Naming/casing expectations:
  • make variable should use canonical uppercase MAKE (not lowercase)
• Compiler warnings:
  • Uses something like -Wall -Werror
  • Possibly includes older C standard flags like C89/C90
  • Suggests an attempt to enforce safer compilation
• Directory/layout comments:
  • Discusses whether auxiliary files belong in lib/ vs same directory
  • Concludes there’s no single “right” layout without project guidelines

Style and maintainability issues

• Polish variable names
  • Considered “allowed” in some local contexts (e.g., government/Polish-company conventions)
  • But generally atypical elsewhere
• Formatting/line length:
  • Prefers around ~80 chars for readability
• Indentation around preprocessor directives:
  • Mentions inconsistency between #ifdef/#endif indentation vs normal code indentation
• Redundant syntax:
  • unnecessary parentheses in conditions
  • unnecessary casts / redundant int typing in literals
  • overuse of pointers where passing by value would be sufficient

Type correctness and pointer usage

Major theme: passing pointers when the value is effectively unchanged.

• Example complaint:
  • passing small constants (literals) by pointer is unnecessary overhead and adds complexity
• const/global/static concerns:
  • criticizes static where it’s not needed
  • suggests local visibility or const would be clearer
  • explains that static in C has multiple meanings, and mixing them harms clarity
• static initialization and thread-safety:
  • mentions initialization protections (e.g., via mutex-like mechanisms in compiler/runtime context)

Randomness / determinism

• The game uses time (time() / seconds since epoch) to seed RNG.
• Vulnerability/logic quirk:
  • rerun/re-roll within the same second → same seed → same “random” sequence → predictable outcomes
• Recommendation:
  • avoid trivial time-based seeding if predictability matters

Parsing/validation bugs (security relevant)

Strong focus on input handling:

• scanf return value:
  • not properly checked in places
  • demonstrated: closing stdin (Ctrl-D on Linux / console-close on Windows) makes scanf fail and return an error/negative/0 value
  • suggestion: validate number of fields read and handle failures gracefully
• Buffer overflow / memory overwrite behavior (as observed in testing):
  • input handling can overwrite memory due to unsafe parsing/bounds
  • reviewer describes a scenario where memory corruption could allow cheating by affecting control flow/return address
• Conversion logic issues:
  • numeric string → integer conversion should be in a dedicated conversion function
  • prefers using scanf instead of custom string-to-int logic (unless learning)
  • warns about edge cases like integer overflow and maximum digit length
• Negative number oddities:
  • logic may “ignore” a negative sign, accepting unexpected values

Console/color and terminal control

• Explains Windows vs terminal escape sequences:
  • historically Windows console APIs were used instead of terminal escapes
  • modern Windows increasingly supports ANSI escape sequences (around Windows 10)
• Mentions how escape code behavior works:
  • ESC[...m codes can behave like “stacked” color changes depending on the terminal implementation

Suggested improvements by the reviewer

• Replace unnecessary pointer passing with pass-by-value for small values
• Reduce globals; remove redundant static/const when it harms clarity or isn’t needed
• Simplify control flow; follow style guide (remove unnecessary braces/parentheses)
• Harden input parsing:
  • always validate scanf returns
  • avoid homegrown string-to-number conversion errors
  • enforce correct bounds for arrays/buffers
• Improve RNG seeding if predictability is a concern

---

AI / Gemini discussion (lightweight)

• Speaker references using Gemini:
  • mentions models with large context windows (e.g., “10 million tokens” vs “2 million tokens”)
  • says they intended to try Gemini during the stream but planned it for later due to limitations (e.g., “Flash” access/availability)

---

Security / Q&A points (selected)

PRNG vs cryptography

• Asked about implementing randomness in assembler:
  • speaker says no for crypto/security goals
• Emphasizes:
  • use operating system / standard cryptographic RNG APIs
    • e.g., Linux /dev/random or language wrappers around crypto-safe OS randomness
• Warning:
  • don’t roll your own CSPRNG—mistakes are easy and severe

OS security evolution since the 2000s

• Claims major improvements (“night and day”)
• Examples given:
  • sandboxing
  • moving subsystems out of kernel into user mode
    • e.g., Windows font rendering and console

Malware on GPU

• Notes it’s technically possible to upload firmware to devices (GPU/network adapters/monitors)
• But it’s non-trivial and generally less practical than other attack paths

Style guide professionalism

• Advice:
  • don’t be the newcomer who says “your style guide is stupid”
  • adapt to the project’s existing style
• Suggestion:
  • ask for the team’s style guide and generate code consistent with it

---

Main speakers / sources (end)

• Primary speaker: the channel host/reviewer
  • speaks as himself throughout the stream
  • mentions identity via “Hex Arkana” / “Hear” and his blog
• Moderator: Foxtrot Charlie (explicitly thanked)
• Co-organizer for the free lecture: SEK Kurak
• External references mentioned:
  • authors of Introduction to IT Security volumes
  • Google / Google Reader
  • Windows/Linux console/terminal escape sequence documentation
  • OpenBSD opinions (e.g., “Julian Voin” mentioned)