🚀 My First AI-Coauthored Blog with ChatGPT
Leave a CommentThis post is the result of my first deep, hands-on experience generating a full technical article using ChatGPT!
Together, we explored how to implement a challenge-response system on STM32, refine C code, modularize functions, fix compiler warnings, and prepare polished documentation.
Along the way, I encountered not just technical hurdles (like sandbox download issues, expired file links, debugging warnings), but also challenges working with the ChatGPT interface itself.
When generating long, detailed articles, I noticed occasional browser pop-ups like “Page Unresponsive” or Chrome’s wait/exit prompts — likely because the browser struggles to handle the massive live-generated output.
Despite having a powerful machine (32 GB RAM), the browser UI can lag when ChatGPT produces extended, continuous responses.
Pro tip: To optimize your workflow, break your requests into smaller pieces, only use the regenerate button when needed, and avoid keeping too many heavy tabs open.
Also, copy and paste sections progressively rather than highlighting everything at once to avoid browser freezes.
— proudly coauthored by me + ChatGPT
⚠️ Disclaimer
This project and writeup are provided solely for educational, ethical hacking, and research purposes.
Do not use these methods for unauthorized access or malicious intent.
Licensed under:
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)
View full license terms
🏗️ Project Overview
This STM32 project implements a challenge-response authentication system:
- The MCU generates a random challenge.
- The user computes response = challenge × 3.
- If correct → onboard LED blinks (non-blocking) five times.
- After 5 challenges, the screen clears, and the cycle resets.
- On boot, the LED blinks briefly to signal readiness.
🛠 Hardware Requirements
- STM32F411 Black Pill board
- Tigard multi-protocol debugger (JTAG + UART)
💻 Software Requirements
- STM32CubeIDE
- STM32CubeProgrammer
- OpenOCD (JTAG)
- GDB-multiarch
- Screen or Minicom (UART terminal)
🔌 Hardware Setup
✅ Tigard set to 3.3V
✅ Mode switch set to UART (not I2C/SWD)
UART2 Wiring
| STM32 Pin | Tigard UART Pin | Wire Label |
|---|---|---|
| A2 (TX2) | RX | Green |
| A3 (RX2) | TX | White |
| GND | GND | Black |
JTAG Wiring
| STM32 Pin | Tigard JTAG Pin | Wire Label |
|---|---|---|
| SCK (Pin 37) | TCK | Gray |
| DIO (Pin 34) | TMS/SS | Green |
| B4 (RST) | TRST | Blue |
| B3 (TDO) | TDO | Orange |
| A15 (TDI) | TDI | Yellow |
| GND | GND | Black |
🔍 Debugging and Bypass Steps
Terminal 1: Launch OpenOCD
sudo openocd -c "telnet_port 4443" -c "gdb_port 3344" -c "tcl_port 6678" \ -f tigard-jtag.cfg -f /usr/share/openocd/scripts/target/stm32f4x.cfg
Terminal 2: Connect via Telnet
sudo telnet localhost 4443
Terminal 3: Open UART Terminal
sudo screen /dev/ttyUSB0 115200
Terminal 4: Start GDB Session
sudo gdb-multiarch --eval-command="target extended-remote :3344" STM32f411CE-Lab1.elf
🐞 Debugging and Bypass Workflow
Step 0: Ensure Target is Halted
In Terminal 2 (OpenOCD Telnet), issue
halt
This ensures the MCU is ready for debugging. Without halting, GDB may show errors like “execution was not halted”.
Step 1: Inspect Available Functions
In Terminal 4 (GDB), list all available functions:
info functions
Look for the function named validate_response (or similar) to set your breakpoint.
1️⃣ Set a breakpoint at the response validation function:
b validate_response
2️⃣ Continue program execution:
c
3️⃣ Trigger a challenge from the UART terminal (Terminal 3) by submitting any answer.
4️⃣ When the breakpoint hits, you have two main bypass strategies:
🔀 Option A: Modify Inside the Function (Direct Bypass)
Inspect ARM registers: x/s $r0 # shows the input string (your answer) x/s $r1 # shows the internal challenge value
Force bypass by setting the return value directly:
set $r0 = 1 Continue execution:
c
✅ This immediately tricks the system into treating the response as correct.
🔀 Option B: Let the Function Complete, Then Modify
Step forward out of the function:
next
GDB will display:
Single stepping until exit from function validate_response, which has no line number information. Now at main ()
Manually set the function’s return value (simulate success):
set $r0 = 1 Continue execution: c
✅ You’ll now see the success message on the UART terminal (Terminal 3), for example:
✔️ Correct! Blinking LED
And the LED will start blinking, as programmed.
📜 Licensing
This project is licensed under:
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)
✔ Share
✔ Adapt (non-commercial)
✔ Provide attribution
✔ Derivatives under the same license
Conclusion
That’s all for now!
In the next post, we will cover how to create an STM32 project for the Black Pill board using STM32CubeIDE, configure it properly, build the firmware, and flash it onto the board using STM32CubeProgrammer.
Stay tuned for a detailed walkthrough on setting up your embedded development workflow — from IDE setup to on-chip debugging.
Happy hacking, and see you soon in the next article!
