DEV Community: Umitomo

Weekly Dev Log 2026-W09

Umitomo — Fri, 12 Jun 2026 00:10:44 +0000

🗓️ This Week

Completed the SwiftUI app development tutorial and tested the app I built on a real iPhone🦾
Learned the overall flow of building an iOS app with SwiftUI.
Organized my app ideas in Notion because I want to start building a real app next week🤔 I also realized that starting with a small app is important at this stage💡
Worked on the UI design for my portfolio site using the official shadcn/ui Figma template. I want to finish one design direction next week and then move on to implementation.
Worked on the AI Threat Modelling room from the AI Security Learning Path on TryHackMe this week🤖

📱 iOS (SwiftUI)

Completed the SwiftUI app development tutorial.
Learned how to run an app on a real iPhone by connecting it to my computer, without joining the Apple Developer Program yet.

🌐 Web Development

Posted my weekly dev log on Dev.to📝
Worked on my portfolio site UI design using the official shadcn/ui Figma template.

🔐 Security (TryHackMe)

Worked on the AI Threat Modelling room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

🔬 What I learned from testing an app on a real iPhone

I need to connect my iPhone, choose it as the run destination, and configure Signing & Capabilities before running the app.
A unique Bundle Identifier is needed to identify the app.
Xcode uses my personal Apple Account to sign the app for testing on my iPhone.
I need to enable Developer Mode and trust the developer profile on the iPhone before launching the app.
Preview data and real app data are handled differently in SwiftUI/SwiftData.
In previews, sampleContainer is used, so includeSampleMoments is passed as true.
The diary entries I create on the real iPhone are saved in the app’s local storage on the device.
The data is not automatically saved to my Apple Account or iCloud.

🦄 What I learned from organizing ideas for my first iOS app

As a beginner developer, I should not try to build a large, market-ready app from the beginning.
Large apps usually include many hidden complexities, such as data management, user experience design, error handling, security, performance, and long-term maintenance.
Since I have a full-time job, my development time is limited, so starting too big would make it harder to keep making steady progress.
Starting with a small app helps me focus on one or two core ideas and understand each part more deeply.
Building something small first also makes it easier to finish, test, and improve the app step by step.
I realized that the goal at this stage is not to compete with polished apps on the market, but to build practical experience by completing small projects.
This approach should help me stay motivated while gradually improving my skills in real app development.

🌐 Web Development Learning

Learned more about how to create UI designs in Figma and how to design screens using components.
Practiced building a consistent portfolio site design based on a design system instead of creating each part separately.

🔐 TryHackMe Learning

AI Threat Modelling

Task2 AI-Specific Assets and Attack Surfaces

AI systems add new assets such as training data, model weights, embedding vectors, system prompts, feature stores, and model registries.
I learned that poisoned training data can corrupt a model’s behaviour at the source.
I learned that model weights are especially valuable because they define what the model has learned.
If model weights are stolen, an attacker may obtain a functional copy of the AI system.
I learned that system prompts can reveal the model’s behaviour, constraints, business logic, and security guardrails.
Embedding vectors are important in systems such as RAG pipelines, recommendation engines, and fraud detection systems.
Manipulating embeddings can change what information the model sees at query time.
Feature stores are important because they provide preprocessed data used as real-time model inputs.
Tampering with feature stores can affect model decisions without changing the model itself.
A compromised model registry can allow an attacker to replace a legitimate model with a backdoored one.
AI threat modelling needs to consider not only traditional application risks, but also AI-specific assets, behaviours, and failure modes.

Task3 Data Supply Chain and STRIDE's Gaps

I learned that AI systems have a data supply chain in addition to a traditional software supply chain.
Each stage of the AI data supply chain can become a point of compromise.
Data poisoning can start from data collection, labelling, or other early pipeline stages.
If poisoned data reaches training, the damage can become embedded in the model’s weights.
A compromised model registry can allow attackers to replace a validated model with a backdoored one.
A backdoored model may look normal until it receives specific trigger inputs in production.
LLM-based systems can introduce additional injection points through retrieval pipelines during inference.
AI threats such as data poisoning, adversarial manipulation, tool misuse, and model theft do not always fit neatly into traditional STRIDE categories.
The key takeaway is that AI threat modelling must cover the full data supply chain and AI-specific failure modes.

Task4 Adapting STRIDE for AI Systems

I learned that STRIDE does not need to be replaced, but it needs to be adapted for AI systems.
In AI systems, familiar STRIDE categories can appear in new forms, such as data source impersonation, data poisoning, model extraction, and inference cost exploitation.
AI decisions are harder to audit because the model version, input features, prompts, and retrieved context may not be fully recorded.
Tool-enabled AI systems can make privilege risks broader, because a jailbroken model may misuse databases, email systems, or other connected tools.
The key takeaway is that STRIDE is still a useful starting point, but some AI risks require additional AI-specific frameworks such as MITRE ATLAS.

Task5 MITRE ATLAS: The AI Threat Technique Catalogue

I learned that MITRE ATLAS is an AI-focused knowledge base for adversary tactics and techniques against AI and ML systems.
ATLAS complements STRIDE by adding AI-specific technical detail, documented techniques, mitigations, and real-world case studies.
I learned key ATLAS techniques such as Data Poisoning, Model Extraction, Evade ML Model, LLM Prompt Injection, and Backdoor ML Model.
ATLAS helps turn broad STRIDE findings into specific, actionable threat findings with technique IDs and defensive guidance.
Real-world cases such as ShadowRay and Morris II show that AI threats are not only theoretical, but can affect real AI infrastructure and RAG-based systems.

🚀 Next Week

Start building a small iOS app based on the app ideas I organized this week.
Finish one portfolio site UI design in Figma and start implementing it in code.
Continue posting small articles on Dev.to.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W08

Umitomo — Thu, 04 Jun 2026 02:13:06 +0000

🗓️ This Week

Completed one section of the SwiftUI tutorial 🦾 Since I want to continue through the tutorial until I can build the app for testing and run it on an actual iPhone, I’ll focus on that from next week.
I also wrote another standalone article this week. It was about my experience experimenting with Codex and Figma MCP to see how much UI design work I could delegate to AI📝 If you're interested, feel free to check it out 👇

I Thought Figma MCP Could Recreate Any Design. I Was Wrong.

Umitomo
Umitomo

Umitomo

Follow

Jun 2

I Thought Figma MCP Could Recreate Any Design. I Was Wrong.

#beginners #devjournal #ai #figma

4 reactions
5 comments

6 min read
I’ll continue working steadily on my portfolio site design by combining AI-generated UI ideas with the official shadcn/ui Figma design template.
Completed LLM Security room from the AI Security Learning Path on TryHackMe this week🤖

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed "Reproduce a bug with unit tests"

🌐 Web Development

Posted my weekly dev log on Dev.to and a standalone article about my experience using Codex × Figma MCP 📝
Started learning UI design in Figma using community resources

🔐 Security (TryHackMe)

Completed LLM Security room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Reproduce a bug with unit tests

Learned that a streak should only increase when a moment exists on the next consecutive day.
Understood that multiple moments on the same day should not increase the streak more than once.
Learned how continue skips duplicate days while keeping the current streak.
Realized that break stops the calculation as soon as a gap in the streak is found.
Learned that fixing one bug can accidentally introduce new bugs in other scenarios.
Learned how to implement parameterized unit tests by preparing multiple input patterns and expected values.
Used @Test(arguments:) to run the same test logic with different test data.
Used #expect to compare the actual result with the expected value for each case.

🌐 Web Development Learning

While experimenting with automating UI design using Codex × Figma MCP, I learned that clearly defining design system rules first and then building the UI from small components is important for reducing the gap between the original Figma design and the implementation generated from its design data.

🔐 TryHackMe Learning

LLM Security

Threat Categories

Data-Based Threats

Training data extraction
Membership inference
Prompt leakage

Model-Based Threats

Model extraction
Model inversion

System-Based Threats

Prompt injection
Context Overflow
Memory Poisoning

User-Based Threats

LLM-powered social engineering
Trust exploitation

LLM Security Threat Cheat Sheet

Type	Threat	Target / Attack Surface	Input	Output
Data-Based	Training Data Extraction	Training dataset (confidentiality)	Crafted prompts designed to trigger memorised content	Verbatim or near verbatim training data (text, PII, secrets)
Data-Based	Membership Inference	Training dataset membership (privacy metadata)	Known candidate data sample already possessed by the attacker	Yes/no (or probability) decision indicating whether the sample was used in training
Data-Based	Prompt Leakage / System Prompt Exposure (LLM07:2025)	System prompt / developer instructions	Prompts asking the model to reveal or reflect on its instructions	Partial or full disclosure of hidden system or developer prompts
Model-Based	Weight Extraction (Model Stealing)	Model parameters (intellectual property)	Large volumes of carefully chosen API queries	A surrogate or distilled model replicating the original model's behaviour
Model-Based	Model Inversion	Model's internal representations	Unknown or partially known data, or model embeddings/outputs	New training data or attributes reconstructed from the model
System-Based	Context Window Poisoning (Prompt Injection)	LLM context window (instruction hierarchy)	Attacker controlled text embedded in input or retrieved content	Altered behaviour, policy bypass, unintended actions
System-Based	Context Overflow / Unbounded Consumption (LLM10:2025)	Context window size and system resources	Excessively large prompts or documents	Truncated safeguards, degraded responses, or denial of service
System-Based	Stateful Conversation Manipulation (Memory Poisoning)	Persistent conversation memory	Malicious statements intended to be stored as long term context	Persistent misinformation or corrupted future responses
User-Based	LLM-Powered Social Engineering	Human cognition and decision-making	Contextual or personal information used to craft persuasive output	Manipulated users (phishing success, fraud, coerced actions)
User-Based	Trust Exploitation / Misinformation (LLM09:2025)	User trust and judgment	Confident but incorrect or maliciously framed prompts	Users accepting false, unsafe, or harmful information

Key Takeaways

LLMs introduce a unique attack surface distinct from traditional ML systems, driven by natural language interaction, context handling, and emergent behaviour.
Data-based threats exploit how LLMs learn from and memorise training data, enabling attacks such as training data extraction, membership inference, and system prompt leakage.
Model-based threats target the model itself, including model extraction (theft of model behaviour or weights) and model inversion (reconstructing sensitive training data).
System-based threats arise from how LLMs process all inputs as a single context, enabling prompt injection, context window overflow, and memory poisoning.
User-based threats leverage LLMs as force multipliers for social engineering, increasing the effectiveness of phishing, scams, and trust exploitation.

🚀 Next Week

Work through the "Preparation for Distribution" section of the SwiftUI tutorial.
Continue posting small articles on Dev.to.
Explore Figma MCP and experiment with generating UI design ideas using AI.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

I Thought Figma MCP Could Recreate Any Design. I Was Wrong.

Umitomo — Tue, 02 Jun 2026 00:30:16 +0000

Introduction

Since I started publishing articles on Dev.to, I've been working on a personal project to transform my old blog website—which is no longer actively maintained—into a portfolio site♻️

As part of that project, I recently started learning Figma and UI design🎨 When I discovered Figma MCP, I imagined a future where generative AI could automatically create polished, modern, and visually appealing designs for me with minimal effort😎

Unfortunately, reality turned out to be quite different.

This article is a reflection on that experience and a reminder to my future self about what I learned along the way📝

TL;DR

I wanted to design a portfolio website in Figma, but quickly realized that UI design was more difficult than I expected.
I wondered whether using Codex and Figma MCP would allow me to outsource the design process to AI, so I decided to try it.
I couldn't magically generate the polished design I had imagined while also maintaining a well-structured Figma file with globally managed variants and reusable components.
I learned that defining design rules first and building components step by step helped produce results that were much closer to my original vision.
Even then, the process was not dramatically easier than expected, so I eventually decided to keep things simple and build my portfolio around the design principles already provided by shadcn/ui.

What I Tried with Figma MCP🎨

While planning the UI design for my portfolio website, I initially created simple wireframe-like layouts in Figma to explore the overall page structure and component placement before working on detailed designs.

At first, I wanted to keep things simple.

However, as I continued working on the project, I found myself wanting something more polished, more modern, and ultimately more impressive.

The problem was that I have very little confidence in my design skills. I'm an in-house IT engineer, not a professional developer or designer, so I often struggle to judge what makes a design truly good.

That led me to a simple idea:

What if I could let AI handle the design work for me?

While researching possible solutions, I discovered that Codex could interact with Figma through Figma MCP. By connecting the two, Codex could actually edit Figma files and create designs based on my instructions.

That sounded promising.

So I decided to give it a try.

Doesn't Everyone Dream at First?🎰

Before using it for my real portfolio project, I wanted to answer a few questions:

Can Codex really create designs directly in Figma?
Can it generate polished and visually appealing layouts?
How accurately can it turn a Figma design into a real web page?

Since it was also my first time using Codex, I decided to run a quick experiment.

My test process looked like this:

Install the Codex application.
Set up the Figma integration so Codex could write design data to Figma.
Create a blank Figma design file.
Create a local test project.
Send a simple prompt to Codex and verify whether it could generate a design inside Figma.
Ask Codex to build a web page from the generated design and evaluate how closely the implementation matched the design.

There are already plenty of great articles from DEV Community members explaining the setup process in detail, so I won't cover it here😂

The prompt I used was surprisingly simple:

Create a stylish portfolio website design.

(Screenshot of the generated Figma design)

(Screenshot of the web page generated from the Figma design)

And honestly?

The results were far better than I expected😮

The generated design looked great.

The generated web page closely matched the design.

For a moment, it genuinely felt like magic.

Reality Hits🪄

Encouraged by the results of my initial experiment, I decided to use the same approach for my actual portfolio project.

This time, I asked Codex to create a Figma design based on a homepage concept image generated by ChatGPT.

However, the results were very different from what I had expected.

At first glance, the generated design looked somewhat reasonable. But once I looked more closely, it lacked consistency. Component sizes, spacing, and layout rules all felt disconnected from one another.

It seemed as though the AI had focused only on the overall "polished feeling" of the image while missing the underlying structure that made the design work.

As a result, the entire page ended up feeling cluttered and disorganized.

To be honest, my only reaction was:

"Wait... how did it end up like this?"

Because my earlier experiment had produced surprisingly good results, I had assumed the same thing would happen with my real project.

Reality turned out to be much less forgiving.

It was at this point that I finally realized I had misunderstood something important.

The Problem Wasn't AI🔎

My first thought was:

"Maybe AI just isn't smart enough yet."

But the more I worked on the problem, the more I realized that the issue was somewhere else.

I had only provided the AI with a finished design image.

What I had not provided were the rules behind that design.

For example:

A color palette
Typography rules
Spacing guidelines
Component variants
A layout grid

None of those things had been defined.

A human designer might be able to infer some of those details from an image.

However, an AI generating designs through Figma MCP needs more than just a visual reference. It has to translate that image into actual components, layouts, and reusable design patterns.

In other words, I was essentially saying:

"Make it look like this image."

without having any design system in place.

Looking back, it's no surprise that the results were disappointing.

Starting Over with Small Steps🚶‍♂️

So I changed my approach.

Instead of generating an entire page from the start, I decided to build the foundation first.

I began by creating a design specification file and defining things such as:

Colors
Typography
Spacing
Border radius values
Shadows

Next, I created small reusable components, including:

Buttons
Cards
Tags
Navigation elements

I then defined variants such as:

Primary
Secondary
Outline

Only after those pieces were in place did I move on to creating the page design itself.

The results were dramatically better.

The design was no longer chaotic, and the overall structure felt much more consistent.

Communication with the AI also became smoother, and providing feedback or requesting changes became significantly easier.

It Still Wasn't Magic👻

There was, however, one thing that surprised me.

The design was definitely better.

But the feeling I had during my first experiment—

"Wow, this is the future!"

—was gone.

In the end, I still needed to:

Organize design tokens
Design components
Define variants
Think through layouts

AI hadn't eliminated those tasks.

Instead, I realized something different:

The better your design system is, the more effectively you can use AI.

That felt much closer to reality.

What I Ended Up Doing🤖

Eventually, I decided to base my portfolio design on shadcn/ui, which had been my original plan from the beginning.

The reason was simple.

A lot of work had already gone into defining:

Component architecture
Variant patterns
Design consistency

and those decisions had been validated by a large community of developers.

To be clear, I still think Figma MCP and Codex are incredibly interesting technologies.

Using them made it obvious that the gap between design and implementation is getting smaller.

But the biggest lesson I learned was this:

AI is not a replacement for a design system.

AI can be an excellent assistant.

However, it is not a magical tool that can automatically generate a complete and well-structured design from a vague idea alone.

At least, not in the way I was hoping to use it.

What I Learned✨

This experience taught me three important lessons:

Think about your design system before asking AI to generate pages.
Design components before designing entire pages.
Good results require clear rules and constraints.

AI can create designs.

But it cannot magically create a design system for you.

Although the experience was a little frustrating, it ultimately helped me understand the importance of design systems far better than before.

Weekly Dev Log 2026-W07

Umitomo — Fri, 29 May 2026 00:18:11 +0000

🗓️ This Week

Completed two more sections of the SwiftUI tutorial 🦾 As I continue working through the tutorial, I can feel my understanding of SwiftUI fundamentals becoming more solid🔥
It was my first time posting a standalone article about reverse engineering📝 If you're interested, feel free to check it out 👇

A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

Umitomo
Umitomo

Umitomo

Follow

May 26

A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

#beginners #reversing #security #python

6 reactions
Add Comment

5 min read
I started creating UI designs for my future portfolio website in Figma. I was able to roughly sketch out the overall structure of the site, but I also realized how difficult it is to create modern and stylish UI designs. (It really made me realize I don’t have much design sense yet 😂💦)
While struggling with the design process, I came across several articles about Figma MCP. That made me interested in exploring how generative AI could help with UI design ideas, so I decided to start researching Figma MCP further.
Completed Securing AI Systems room from the AI Security Learning Path on TryHackMe this week🤖

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed "Create an Algorithm for Badges" and "Add inclusive features"

🌐 Web Development

Posted my weekly dev log on Dev.to and a standalone article about my first attempt at reverse engineering 📝
Created rough portfolio website UI layouts in Figma
Used shadcn/ui component library design templates in Figma
Started learning UI design in Figma using community resources

🔐 Security (TryHackMe)

Completed Securing AI Systems room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Add inclusive features

Learned that SwiftUI automatically adapts UI elements for Light and Dark Mode by default.
Learned how to preview and compare Light and Dark Mode layouts in the Xcode canvas.
Understood that system-provided semantic styles help SwiftUI automatically adjust UI appearance.
Learned that SwiftUI uses view modifiers to customize ScrollView behavior.
Understood that .scrollBounceBehavior(.basedOnSize) only enables bouncing when the content is larger than the visible area.
Learned that .defaultScrollAnchor(.center, for: .alignment) centers smaller content inside a ScrollView.
Learned that the dynamicTypeSize modifier can be applied to any SwiftUI view.
Learned how AttributedString(localized:) supports localization-aware text in SwiftUI.
Understood that (inflect: true) automatically changes words like “Day” and “Days” based on the number value.
Learned that SwiftUI can apply different font styles to specific parts of an AttributedString.
Realized that Apple provides built-in grammar inflection support for more natural localized UI text.

🌐 Web Development Learning

Reviewed several useful functions in Figma
Learned the importance of focusing on the overall page layout before designing detailed UI components

🔐 TryHackMe Learning

Securing AI Systems

Task 2 Anatomy of an AI System

Traditional apps use deterministic logic, while AI systems rely on probabilistic model inference.
AI systems accept free-form natural language, making input validation much harder.
Prompt Construction combines the system prompt, user input, and retrieved context before sending data to the LLM.
RAG allows LLMs to retrieve external knowledge from a vector store or other data sources.
A vector store contains embedded representations of internal documentation for retrieval-augmented generation (RAG)
Trust boundaries are points where data moves between different security contexts.
Major trust boundaries include user-to-system, system-to-LLM, LLM-to-tools, and system-to-user.
LLM-to-tools is especially sensitive because model output can trigger real actions.
Tool layers may execute database queries, API calls, or file operations on behalf of the LLM.
Security controls are needed at every boundary to reduce prompt injection and data leakage risks.

Task3 The AI Attack Surface

Studied the OWASP LLM Top 10 and how major risks affect AI-integrated systems.
Learned that MITRE ATLAS documents adversary tactics and exploitation techniques for AI systems.
Studied how the NIST AI RMF approaches AI security from a governance and risk management perspective.
Learned the difference between OWASP (vulnerabilities), ATLAS (attack techniques), and NIST AI RMF (risk governance).

Task4 System-Level Threats

Studied how LLM10 Unbounded Consumption can cause resource exhaustion and extreme cost increases through excessive requests.
Learned that system prompts may leak internal rules, tool information, and architecture details if exposed.(LLM07).
Understood that LLM output must never be trusted as safe input for downstream systems.(LLM05)
Learned that Excessive Agency occurs when AI systems are given unnecessary permissions, tools, or autonomy.(LLM06)
Learned that users may unintentionally leak sensitive information when using AI systems.(LLM02)
Studied how the OWASP LLM risks relate to the CIA triad across confidentiality, integrity, and availability.

Task 5 Secure Design Patterns

Learned that security controls are most effective when applied during the design stage of AI systems.
Learned that layered controls reduce the risk of end-to-end attack success.
Understood the importance of least privilege for AI tools, API tokens, and database access.
Learned that write operations should require human approval before execution.
Studied how input and output validation reduce prompt injection and downstream injection risks.
Learned that MLSecOps integrates security throughout the AI and machine learning lifecycle.

🚀 Next Week

Complete the badge algorithm in the SwiftUI tutorial.
Continue posting small articles on Dev.to.
Explore Figma MCP and experiment with generating UI design ideas using AI.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

Umitomo — Tue, 26 May 2026 05:02:08 +0000

Introduction

I usually post weekly learning and development updates on Dev.to📝

This time, however, I decided to write a standalone article about something a little different — my first attempt at reverse engineering🦾

What started as simple curiosity quickly turned into an exciting journey of uncovering how a modern AI-generated Python application was actually structured internally🔎

TL;DR

Reverse engineered a PyInstaller-based Python .exe
Reconstructed a surprisingly large portion of the application's architecture from the packaged .exe
Analyzed .pyc files using tools like strings, pycdc, and pycdas
Learned how React/Vite frontend assets can be bundled into a standalone executable
Realized how difficult production frontend bundles are to understand without the original source code
Thought deeply about maintainability in the age of AI-generated applications

What I Reverse Engineered

As someone who works in IT administration and internal tooling, I often become curious about how applications are actually built under the hood.

This time, a coworker showed me a PDF-processing desktop application that had been created with the help of generative AI.

The overall architecture had already been explained to me verbally beforehand.
However, that led me to a simple but exciting question:

How much of an application's internal structure can actually be reconstructed just by reverse engineering the final .exe file?

That curiosity became the starting point of this exploration.

The application itself was a harmless internal utility designed for local use, and this investigation was performed purely within an authorized and educational context.

Rather than trying to analyze malware or bypass protections, I wanted to understand:

What information remains inside packaged executables
How modern Python applications are bundled
Whether frontend/backend structures could still be inferred after packaging
How much architectural detail could realistically be reconstructed from compiled artifacts alone

What made the process especially exciting was slowly piecing together the architecture from small clues hidden inside the executable.

Reverse Engineering Environment Setup

Since I was using Kali Linux on WSL for this experiment, I first prepared a small reverse engineering workspace.

Creating a Python Virtual Environment

mkdir -p ~/reverse
cd ~/reverse

python3 -m venv venv
source venv/bin/activate

At first, the virtual environment failed because python3-venv was missing:

sudo apt install python3.13-venv

After that, I recreated the environment successfully.

Installing Basic Analysis Tools

I installed a few basic tools for inspecting the executable and analyzing Python bytecode.

pip install pyinstaller

I also installed binutils so I could use strings:

sudo apt install binutils

Building `pycdc`

To inspect .pyc files more deeply, I built pycdc from source:

sudo apt install -y cmake g++ git

mkdir -p ~/reverse/tools
cd ~/reverse/tools

git clone https://github.com/zrax/pycdc.git

cd pycdc
mkdir build
cd build

cmake ..
make -j4

This generated:

pycdc
pycdas

which I later used to inspect Python bytecode files.

Extracting the PyInstaller Executable

After confirming the executable was likely packaged with PyInstaller, I used pyinstxtractor to extract its contents:

git clone https://github.com/extremecoders-re/pyinstxtractor.git

Then:

cd ~/reverse/pdf_exe

python ~/reverse/pyinstxtractor/pyinstxtractor.py PDF.exe

This generated a directory like:

PDF.exe_extracted/

Inside the extracted directory, I was finally able to inspect files such as:

app.pyc
pdf_stamp_processor.pyc
pdf-stamp-frontend/dist

This was the point where the application's overall structure started becoming much clearer.

How I Reverse Engineered It

Step 1 — Running `strings`

I first started with:

strings PDF.exe

Very quickly, I noticed Python-related strings:

python313.dll
pyi-python-flag
...

This strongly suggested that the application had been packaged using PyInstaller.

Step 2 — Inspecting the PyInstaller Archive

Next, I used:

pyi-archive_viewer PDF.exe

This helped confirm that the executable had been packaged using PyInstaller and allowed me to inspect the internal archive structure.

Step 3 — Analyzing `.pyc` Files

I then used:

pycdc
pycdas

to inspect the extracted Python bytecode files.

However, when running pycdc, I noticed that some parts of the bytecode could not be fully reconstructed.

In many cases, the output stopped after displaying messages like:

Unsupported opcode: CALL_KW (247)
from fastapi import FastAPI, File, UploadFile, Form, HTTPException
...
# WARNING: Decompyle incomplete

Instead of fully recovering the original source code, I had to combine multiple fragmented clues together:

Partial pycdc output
pycdas disassembly output
Extracted strings
Module names
API route names
Library imports

I also used generative AI to help interpret and organize those fragmented technical details while reconstructing the application's architecture.

Even with incomplete reconstruction, I was still able to identify:

FastAPI routes
PDF processing logic
OpenCV-based blank-space detection
PyMuPDF page rendering
Automatic browser launching
Local API endpoints such as:

/api/scan
/api/stamp_and_merge
/api/shutdown

Step 4 — Investigating the Frontend

The frontend bundle was much harder to understand.

The built JavaScript looked like this:

var e=Object.create,t=Object.defineProperty,...

At first, it felt almost impossible to read.

The extracted JavaScript was difficult to understand, and I could not initially tell what kind of frontend structure had originally existed before packaging.

By combining:

The extracted dist/ directory structure
The bundled JavaScript files
API communication behavior observed in the browser developer tools
And explanations generated through conversations with AI

I gradually started to understand how the frontend had likely been packaged and bundled, and that the application was probably using a modern frontend workflow similar to React/Vite.

At the same time, I also realized that the original frontend source structure itself was no longer included inside the executable.

Reconstructing the Architecture

By combining clues from strings, embedded .pyc files, frontend assets, and API routes, I was eventually able to reconstruct a rough picture of the application's architecture:

PDF.exe
    ↓
Launch FastAPI server
    ↓
Open browser automatically
    ↓
Serve React frontend
    ↓
React sends API requests
    ↓
Python processes PDFs locally

The application was not rendering a desktop GUI directly.

Instead:

FastAPI served static frontend files
React rendered the UI inside the browser
Python handled backend processing

What fascinated me most was not simply discovering the architecture itself, but realizing how much of it could still be reconstructed purely from packaged artifacts.

What I Learned

Reverse Engineering Can Reveal More Than I Expected

Before starting this experiment, I assumed that most of an application's architecture would disappear once everything had been packaged into a standalone .exe.

However, I was surprised by how many clues still remained inside the executable:

Python runtime artifacts
PyInstaller structures
Embedded .pyc files
Frontend build outputs
API routes
Localhost references
Technology-specific strings

By connecting those small clues together step by step, I was able to reconstruct a surprisingly large portion of the application's overall architecture.

That process itself was one of the most exciting parts of the experience.

“Working Software” and “Understandable Software” Are Different Things

This experience also made me think deeply about AI-generated applications and software maintainability.

Generative AI can absolutely help create working applications quickly.
However, once only compiled artifacts remain, reconstructing the original design and development intent becomes much harder.

Even after reverse engineering the executable, I still could not fully reconstruct the original frontend source code or understand every implementation detail.

That limitation itself became an important lesson for me.

It reminded me that understanding software architecture and preserving maintainable source structures are just as important as making software work.

Especially in the age of AI-assisted development.

Final Thoughts

This reverse engineering journey was honestly a lot of fun.

What made the experience especially enjoyable was gradually reconstructing the application's architecture from small technical clues hidden inside the executable.

At the same time, the experience gave me a deeper appreciation for software architecture, maintainability, and the importance of preserving understandable source code alongside AI-generated applications.

Weekly Dev Log 2026-W06

Umitomo — Thu, 21 May 2026 01:25:54 +0000

🗓️ This Week

Made a little more progress in the SwiftUI tutorial🦾
Started the journey of building my future portfolio site✈️ First, I created the project files and set up a repository on GitHub. I also started reserching React Router v7 by reading its documentation. I'm moving forward little by little🔥
Completed the ContAInment room from the AI Security Learning Path on TryHackMe this week🤖

💡 Thoughts on the ContAInment Room

This room was a hands-on investigation exercise set in a scenario where a company had suffered a security breach, resulting in important data being encrypted and used for blackmail. The goal was to investigate the compromised environment and discover the hidden flags🔎

I felt that this room built nicely on the concepts I learned in the previous AI Forensics room. One thing I especially enjoyed was solving the investigation by using a dedicated AI assistant available inside the victim environment🤖

As I worked through the challenge, I had to think carefully about what looked suspicious and follow clues step by step while actively using Linux commands. It also turned out to be a great review of Linux operations and practical investigation workflows🔥

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed Sections 7 and 8: "Create an Algorithm for Badges"

🌐 Web Development

Posted my weekly dev log on Dev.to 📝
Created a new React Router v7 project for my future portfolio site.

🔐 Security (TryHackMe)

Completed the ContAInment room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Section 8: Calculate and Show Streaks

Learned how to calculate a daily streak by comparing saved dates with the current day.
Understood how reversing the array helps process moments from newest to oldest.
Learned how map and compactMap can transform Moment objects into simple day offsets like [0, 1, 2].
Understood how Calendar.dateComponents calculates date differences in calendar-based units.
Learned that multiple moments on the same day should count as a single streak day.
Realized that the streak variable represents the next expected day offset during the calculation.
Learned that comparing daysAgo == streak is a simple way to detect consecutive days.
Understood why using the end of the current day makes streak calculations more stable and predictable.
Learned that @ViewBuilder is used to build conditional or multiple-view UI structures, while Group is mainly used to organize existing views or share modifiers without affecting layout.
Understood that VStack creates all child views immediately, whereas LazyVStack generates views only when they become visible on screen.
Realized that LazyVStack is more suitable for scrollable, data-driven UIs with many or heavy views because it improves memory efficiency and performance.

🌐 Web Development Learning

React Router v7 Framework Mode is similar to Remix, so my Remix experience will still be useful.
root.tsx, routes.ts, and route files work together to render each page.

🔐 TryHackMe Learning

ContAInment

Identified useful indicators from attacker notes and used them to recover encrypted files.
Practiced DFIR-style investigation by following clues across logs, archives, and extracted data.
Used AI-assisted forensic tools to analyze encoded flag candidates and identify the correct flag.
Improved my understanding of how AI systems themselves can become targets in modern cyberattacks.

🚀 Next Week

Complete the badge algorithm in the SwiftUI tutorial.
Continue posting small articles on Dev.to and start creating Web UI designs in Figma.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W05

Umitomo — Fri, 15 May 2026 04:44:53 +0000

🗓️ This Week

Made a little more progress in the SwiftUI tutorial.
Started researching web technology stacks and creating a roadmap to gradually turn my current blog into a portfolio site using React Router v7. I'm moving forward little by little.
Completed the AI Forensics room from the AI Security Learning Path on TryHackMe this week.

💡 Thoughts on the AI Forensics Room

The AI Forensics room was much deeper and more challenging than I initially expected, and each task took a significant amount of time to complete. However, it turned out to be an incredibly valuable learning experience 🔥

Task 5, "Practical - The Digital Trail," was especially impressive. It was a story-driven hands-on investigation where I analyzed a compromised company environment after attackers stole critical proprietary source code 🔎

Instead of simply reading explanations, I had to actively investigate logs, suspicious files, reverse shells, persistence mechanisms, and data exfiltration activity step by step.

Because I was constantly thinking, investigating, and connecting the dots myself, the experience felt far more practical and realistic. It gave me a much deeper understanding of how AI-assisted DFIR investigations work in real-world scenarios.

One of the biggest lessons I learned from this room was that AI is a powerful tool, but human insight is still essential. AI can quickly detect suspicious activity, but investigators still need to analyze the context and validate the findings themselves.

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed Sections 6 and 7: "Create an Algorithm for Badges"

🌐 Web Development

Posted my weekly dev log on Dev.to 📝
Researched how to transform my current blog site into the portfolio site I want to build in the future.
Created a roadmap with ChatGPT to gradually turn my blog site into a portfolio site.

🔐 Security (TryHackMe)

Completed the AI Forensics room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Review

Reviewed how SwiftData automatically creates relationships between @Model objects through model properties.
Understood how bidirectional relationships work between Moment and Badge models.
Learned that Group is useful when applying modifiers to conditionally displayed views.
Realized that SwiftUI modifiers can only be attached to actual views, not directly to an if statement.
Reviewed how @ViewBuilder allows a custom SwiftUI view to accept and display child views passed from outside.
Understood that .offset(y:) moves a view from its original position to fine-tune layouts.

🔐 TryHackMe Learning

AI Forensics Task 3 — AI & DFIR

Learned how AI and machine learning are transforming modern DFIR investigations.
Studied how CNN models can detect image tampering and manipulated content.
Learned how machine learning is used in dynamic malware analysis.
Understood that API call sequences represent program behavior patterns.
Studied how API sequences can be converted into 2D images for AI analysis.
Learned why CNN-based image recognition models can classify malware behavior.
Learned how NLP models help identify phishing emails and suspicious communications.
Understood how AI can reconstruct incident timelines from fragmented evidence.
Studied how AI accelerates forensic analysis and improves detection capabilities.
Understood that AI enhances human investigators rather than replacing them.
Learned the importance of combining AI-assisted analysis with human expertise in cybersecurity.

AI Forensics Task 4 — AI Legal & Ethical Implications

Learned that AI in forensics must be explainable and defensible in court.
Understood how “black box” AI models can weaken the credibility of digital evidence.
Learned that biased AI systems can lead to real-world injustice and wrongful accusations.
Studied the importance of maintaining chain of custody and audit trails when using AI in DFIR.
Understood why undocumented AI processing can make forensic evidence legally challengeable.
Learned that privacy and legal compliance are critical when handling sensitive evidence with AI tools.
Studied how Federated Learning and offline AI environments help preserve privacy.
Learned that AI should enhance human investigators, not replace human judgment and responsibility.

AI Forensics Task 5 — Practical: The Digital Trail

Learned how AI and machine learning can support DFIR investigations by identifying suspicious logs and files.
Studied how attackers use reverse shells to gain and maintain remote access to compromised systems.
Learned how hidden files, /tmp, and /dev/shm are commonly abused for stealth and persistence.
Understood how attackers disguise malicious tools as legitimate system utilities to evade detection.
Studied how SSH key abuse and authorized_keys modification can enable stealthy privilege escalation.
Learned how fake telemetry logs and masquerading techniques help attackers blend into normal environments.
Understood how compressed and Base64-encoded archives can be staged for data exfiltration.
Learned how DFIR investigations connect evidence from logs, bash history, suspicious files, and network activity.
Studied how AI can misclassify legitimate files as suspicious, highlighting the importance of human validation.
Learned that AI enhances investigations, but human reasoning and contextual analysis remain essential in DFIR.

🚀 Next Week

Complete the badge algorithm in the SwiftUI tutorial.
Continue posting small articles on Dev.to.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W04

Umitomo — Sat, 09 May 2026 05:36:45 +0000

🗓️ This Week

I had a long holiday during Golden Week in Japan and really enjoyed the break!
Because of that, I didn't have as much learning time compared to last week 😂
I made a little more progress in the SwiftUI tutorial
It was my first time using GitHub Copilot in Xcode, and I tried using the chat feature to generate unit tests. I'd also like to gradually explore more advanced features such as custom instructions.

I also want to thank everyone who commented on my previous Weekly Dev Log 2026-W03✨

Since English is not my native language, I was honestly a bit nervous about posting in English at first. But interacting with people on this platform has been a really valuable learning experience for me.

The kind comments and discussions gave me more confidence to continue sharing my learning journey here. Thank you so much😊

📱 iOS (SwiftUI)

Worked through the Swift tutorial and completed Section 5: "Create an Algorithm for Badges"
Used GitHub Copilot in Xcode to generate unit tests for badge sorting logic.

🌐 Web Development

Posted my weekly dev log on Dev.to 📝

🔐 Security (TryHackMe)

Worked on the AI Forensics room (part of the AI Security Learning Path) on TryHackMe

💡 Key Takeaways

Reviewed the basics of building SwiftUI views using NavigationStack, ScrollView, and HStack
Learned how to integrate AI-assisted code generation into the testing workflow.

TryHackMe Learning

AI Forensics

Learned how AI/ML enhances DFIR through large-scale data processing, anomaly detection, and scalable analysis
Explored practical AI use cases in DFIR tools, including phishing detection, malware classification, alert prioritisation, and event correlation
Learned the difference between deterministic systems and probabilistic AI models, and why non-determinism can become a challenge in digital forensics
Studied key AI evaluation metrics such as accuracy, precision, and recall, and learned why these metrics can be misleading when viewed in isolation
Understood the “Garbage In, Garbage Out (GIGO)” principle and how low-quality training data can lead to unreliable AI outputs
Learned that AI can accelerate DFIR workflows, but human oversight and validation are still essential in forensic investigations

🚀 Next Week

Continue working on the badge algorithm (Section 6) in the SwiftUI tutorial
Continue posting small articles on Dev.to
Continue working on the AI Security Learning Path

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7

🔐 Security (TryHackMe)

Keep learning cybersecurity on TryHackMe

Weekly Dev Log 2026-W03

Umitomo — Tue, 28 Apr 2026 06:21:07 +0000

🗓️ This Week

Finally finished the Cyber Security 101 learning path and discovered the AI Security Learning Path on TryHackMe
Completed 2 rooms from the AI Security Learning Path this week
Decided to continue working on the SwiftUI tutorial (also explored React Native with Expo out of curiosity)

📱 iOS (SwiftUI)

Ran unit tests for badge unlocking logic and stepped through them using breakpoints
Researched the differences between SwiftUI and React Native (with Expo) to determine the best platform for my learning

🌐 Web Development

Posted my weekly learning and development log on Dev.to📝

🔐 Security (TryHackMe)

Completed 2 rooms from the AI Security Learning Path on TryHackMe (AI Models & Data, Prompt Engineering)

💡 Key Takeaways

Learned how to use the po command and the map function in the console during debugging
Chose SwiftUI to focus on native iOS development (compared to React Native with Expo)

TryHackMe Learning

AI Models & Data

Learned that most AI models rely heavily on Common Crawl, a large public dataset collected from the internet
Realized that unclear data provenance and hidden sensitive data can lead to security risks
Learned that training decisions can impact security, including potential data leakage
Understood that optimization techniques introduce trade-offs between efficiency and security
Learned that fine-tuning inherits risks from base models such as bias and unsafe behavior
Realized that models are black boxes and difficult to fully audit
Learned that model cards are important but often incomplete

Prompt Engineering

Learned that LLMs process text as tokens and generate probabilistic outputs
Learned how parameters like temperature and top-p affect responses
Learned that effective prompts require clear instructions, context, format, and constraints
Understood the difference between system prompts and user prompts
Practiced prompt techniques such as zero-shot, few-shot, and Chain-of-Thought

🚀 Next Week

Continue working on the badge algorithm (Section 5) in the SwiftUI tutorial
Continue posting small articles on Dev.to
Continue working on the AI security Learning Path

Weekly Dev Log 2026-W02

Umitomo — Wed, 22 Apr 2026 07:24:49 +0000

🗓️ This Week

📱 iOS (SwiftUI)

Worked on the SwiftUI tutorial and completed Section 4 (Create an algorithm for badges)
Built a test file to verify the badge algorithm
Created unit tests for badge unlocking logic using an in-memory SwiftData container
Ran unit tests and stepped through them using breakpoint

🌐 Web Development

Posted my weekly learning and development log on Dev.to

🔐 Security (TryHackMe)

Completed OWASP Top 10 2025: Insecure Data Handling on TryHackMe
Worked on the AI/ML Security Threats room and completed Tasks 1–4

💡 Key Takeaways

Learned how to use MARK: comments for code organization
Understood the difference between insert and save, and how to isolate business logic from the UI
Reviewed how to inspect variable values during debugging
Learned how SSTI can lead to server-side code execution
Understood the difference between Base64 encoding and actual encryption
Reviewed the basics of AI/ML
Learned how LLMs work

🚀 Next Week

Test the badge algorithm and complete the SwiftUI tutorial section
Continue posting small articles on Dev.to
Continue working on the AI security learning path

Weekly Dev Log 2026-W01

Umitomo — Fri, 17 Apr 2026 07:22:41 +0000

🗓️ This Week

📱 iOS (SwiftUI)

Worked on the SwiftUI tutorial and completed Section 4 Steps 9–12 (Create an algorithm for badges)

🌐 Web Development

Started posting articles on Dev.to
Managing my articles using GitHub and GitHub Actions

🔐 Security (TryHackMe)

Completed OWASP Top 10 2025: IAAA Failures and Application Design Flaws on TryHackMe

💡 Key Takeaways

Learned basic state management through implementing a badge system in SwiftUI
Building a habit of posting regularly is important for consistency
Application design flaws can lead to serious security vulnerabilities
Relearned how to check port status using nc and Nmap in Bash
Learned how to send POST requests using curl
Learned how to decrypt data using OpenSSL
Understood the difference between Base64 encoding and AES-128-ECB encryption
Learned how to use Gobuster

🚀 Next Week

Test the badge algorithm implementation
Continue posting small articles on Dev.to
Complete the remaining OWASP challenge rooms

Hello Dev.to!👋 I'm starting my journey as a developer🌱

Umitomo — Wed, 15 Apr 2026 02:52:20 +0000

👋 Hello Dev.to!

Hi, I'm Umitomo 🐠 from Japan 🇯🇵

I work as an in-house systems engineer, mainly focusing on IT infrastructure and security.

💼 What I do

In my daily work, I handle IT infrastructure and security operations.

Outside of work, I enjoy building things as a hobby and have been learning:

SwiftUI (iOS development)
Web development (Remix, Cloudflare)
Cybersecurity (TryHackMe)

🚀 What I'm building

🌐 Web Development

I built a personal blog using Remix + Cloudflare + microCMS.

Since I plan to publish articles on Dev.to, I'm thinking about turning it into a portfolio site using React Router v7.

📱 iOS Development

I'm currently learning SwiftUI through tutorials.

I'd love to build apps that I can enjoy with my kids.

🎯 Why I'm here

I chose Dev.to because:

I want to challenge myself to write in English
I like the culture where it's okay to share not only tutorials but also personal learning journeys

I feel it's a great place to grow as a developer while sharing my progress.

✍️ What I’ll write about

My journey from infrastructure to development
Development logs and technical notes
Security learning and experiments

🌱 My goal

I'm starting small, but I want to stay consistent and keep learning step by step.

🙌 Nice to meet you!

Feel free to connect with me!